javaredis緩存分布式
1. 總是聽說很多javaweb系統用redis或memcache做緩存，具體怎麼操作的
其實就相當於在應用程序和資料庫之間開了一塊內存區域，將一些高頻訪問的數據放在其中，避免每次都請求資料庫。至於之所以用memcached和redis，而不是自己在程序里開個hashmap，是因為這塊區域可以共享且容易管理，在集群環境下更方便使用。
有些做法是直接將數據序列化後存在redis的string或是memcached中，也有些其他做法是利用redis特有的數據結構存儲一些關系，例如用sorted set存排行榜，string用來計數，set做一些倒排索引、用戶好友關系之類的。我覺得這些都可以稱之為緩存。
2. java web開發緩存方案，ehcache和redis哪個更好
Ehcache
在java項目廣泛的使用。它是一個開源的、設計於提高在數據從RDBMS中取出來的高花費、高延遲採取的一種緩存方案。正因為Ehcache具有健壯性（基於java開發）、被認證（具有apache 2.0 license）、充滿特色（稍後會詳細介紹），所以被用於大型復雜分布式哪蘆粗web application的各個節點中。
1. 夠快
Ehcache的發行有一段時長了，經過幾年的努力和不計其數的性能測試，Ehcache終被設計於large, high concurrency systems.
2. 夠簡單
開發者提供的介面非常簡單明了，從Ehcache的搭建到運用運行僅僅需要的是你寶貴的幾分鍾。其實很多開發者都不知道自己用在用Ehcache，Ehcache被廣泛的運用於其他的開源項目
比如：hibernate
3.夠袖珍
關於這點的特性，官方給了一個很可愛的名字small foot print ，一般Ehcache的發布版本不會到2M，V 2.2.3 才 668KB。
4. 夠輕量
核心程序僅僅依賴slf4j這一個包，沒有之一！
5.好擴展
Ehcache提供了對大數據的內存和硬碟的存儲，最近版本允許多實例、保存對象高靈活性、提供LRU、LFU、FIFO淘汰演算法，基礎屬性支持熱配置、支持的插件多
6.監聽器
緩存管理器監聽器 （CacheManagerListener）和 緩存監聽器（CacheEvenListener）,做一些統計或數據一致性廣播挺好用的
如何使用？
夠簡單就是Ehcache的一大特色，自然用起來just so easy!
redis
redis是在memcache之後編寫的，大家經常把這兩者做比較，如果說它是個key-value store 的話但是它具有豐富的數據類型，我想暫時把它叫做緩存數據流中心，就像現在物流中心那樣，order、package、store、classification、distribute、end。現在還很流行的LAMP PHP架構 不知道和 redis+mysql 或者 redis + mongodb的性能比較（聽群里的人說mongodb分片不穩定）。
先說說reidis的特性
1. 支持持久化
redis的本地持久化支持兩種方式：RDB和AOF。RDB 在redis.conf配置文件里配置持久化觸發器，AOF指的是redis沒增加一條記錄都會保存到持久化文件中（保存的是這條記錄的生成命令），如果不是用redis做DB用的話還會不要開AOF ，數據太龐大了，重啟恢復的時候是一個巨大的工程！
2.豐富的數據類型
redis 支持 String 、Lists、sets、sorted sets、hashes 多種數據類型,新浪微博會使用redis做nosql主要也是它具有這些類型，時間排序、職能排序、我的微博、發給我的這些功能List 和 sorted set 的強大操作功能息息相關
3.高性能
這點跟memcache很想像，內存操作的級別是毫秒級的比硬碟操作秒級操作自然高效不少，較少了磁頭尋道、數據讀取、頁面交換這些高開銷的操作！這也是NOSQL冒出來的原因吧，應該是高性能
是基於RDBMS的衍生產品，雖然RDBMS也具有緩存結構，但是始終在app層面不是我們想要的那麼操控的。
4.replication
redis提供主從復制方案，跟mysql一樣增量復制而且復制的實現都很相似，這個復制跟AOF有點類似復制的是新增記錄命令，主庫新增記錄將新增腳本發送給從庫，從庫根據腳本生成記錄，這個過程非常快，就看網路了，一般主從都是在同一個區域網，所以可以說redis的主從近似及時同步，同事它還支持一主多從，動態添加從庫李鎮，從庫數量沒有限制。 主從庫搭建，我覺得還是採用網狀模式，如果使用鏈式（master-slave-slave-slave-slave·····）如果第一個slave出現宕機重啟，首先從master 接收 數據恢復腳本，這個是阻塞的，如果主庫數據幾TB的情況恢復過程得花上一段時間，在這個過程中其他的slave就無法嘩哪和主庫同步了。
5.更新快
這點好像從我接觸到redis到目前為止 已經發了大版本就4個，小版本沒算過。redis作者是個非常積極的人，無論是郵件提問還是論壇發帖，他都能及時耐心的為你解答，維護度很高。有人維護的話，讓我們用的也省心和放心。目前作者對redis 的主導開發方向是redis的集群方向。
所以以前遠標老師建議我們如果希望簡單就用ehcache，如果開發任務比較復雜，希望得到比較多的支持什麼的就redis
3. java web開發緩存方案，ehcache和redis哪個更好
個人更看好redis，畢含redis不僅僅手正笑可以把key-value鍵清磨值對存儲在內存，也可以存儲在db等持久化工具中，並且提供了豐富的api操作
4. 阿里P8推薦：《Netty、Redis、Zookeeper高並發實戰》看完真不錯
移動時代、5G時代、物聯網時代的大幕已經開啟，它們對於 高性能、高並發 的開發知識和技術的要求,抬升了 Java工程師的學習台階和面試門檻。
大公司的面試題從某個側面映射出生產場景中對專項技術的要求。高並發的面試題以前基本是BAT等大公司的專利,現在幾乎蔓延至與Java項目相關的整個行業。例如，與 Java NIO、Reactor模式、高性能通信、分布式鎖、分布式ID、分布式緩存、高並發架構等 技術相關的面試題，從以前的加分題變成了現在的基礎題，這也映射出開發Java項目所必需的技術棧： 分布式Java框架、Redis緩存、分布式搜索ElasticSearch、分布式協調ZooKeeper、消息隊列Kafka、高性能通信框架Netty。
《Netty、Redis、Zookeeper高並發實戰》為了讓大家扎穩高性能基礎，淺顯易懂地剖析高並發IO的底層原理，細致細膩地解析Reactor高性能模式，圖文並茂地介紹Java非同步回調模式。掌握這些基礎原理，能夠幫助大家解決Java後台開發的一些實際問題。
本書共12章，主要介紹高性能通信框架Netty，並詳盡介紹Netty的EventLoop、Handler、Pipeline、ByteBuf、Decoder、Encoder等重要組件，然後介紹單體IM的實戰設計和模塊實現。本書對ZooKeeper、 Curator API、畢蠢物Redis、Jedis API的使用也進行詳盡的介紹，讓大傢具備高手液並發、可擴展系統的設計和開發能力。
由於內容較多，本次將展示部分截圖，如果看得不過癮想更加深入檔則地了解本筆記徹底掌握，只需轉發後私信回復【666】即可來獲取免費領取方式了！
5. redis集群 java怎麼做分布式訪問
package project1_Thread;
public class Threads {
public static void main(String[] args) {
// TODO Auto-generated method stub
for(int i=0;i<10;i++){
System.out.println("main begins:");
}
Threads1 nt1 = new Threads1();
Threads2 nt2 = new Threads2();
nt1.start();
nt2.start();
for(int i=0;i<10;i++){
System.out.println("Main End");
}
}
6. java web開發緩存方案，ehcache和redis哪個更好
ehcache直接在jvm虛擬機中緩存，速度快，效率高；但是緩存共享麻煩，集群分布式應用不方便。
redis是通過socket訪問到緩存服務，效率比ecache低，比資料庫要快很多，處理集群和分布式緩存方便，有成熟的方案。
如果是單個應用或者對緩存訪問要求很高的應用，用ehcache。
如果是大型系統，存在緩存共享、分布式部署、緩存內容很大的，建議用redis。
摘引自：
作者：饒維立
鏈接：https://www.hu.com/question/24504292/answer/86908460
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
7. java怎麼實現redis分布式鎖
Redis有一系列的命令，特點是以NX結尾，NX是Not eXists的縮寫，如SETNX命令就應該理解為：SET if Not eXists。這系列的命令非常有用，這里講使用SETNX來實現分布式鎖。
用SETNX實現分布式鎖
利用SETNX非常簡單地實現分布式鎖。例如：某客戶端要獲得一個名字foo的鎖，客戶端使用下面的命令進行獲取：
SETNX lock.foo <current Unix time + lock timeout + 1>
如返回1，則該客戶端獲得鎖，把lock.foo的鍵值設置為時間值表示該鍵已被鎖定，該客戶端最後可以通過DEL lock.foo來釋放該鎖。
如返回0，表明該鎖已被其他客戶端取得，這時我們可以先返回或進行重試等對方完成或等待鎖超時。
解決死鎖
上面的鎖定邏輯有一個問題：如果一個持有鎖的客戶端失敗或崩潰了不能釋放鎖，該怎麼解決？我們可以通過鎖的鍵對應的時間戳來判斷這種情況是否發生了，如果當前的時間已經大於lock.foo的值，說明該鎖已失效，可以被重新使用。
發生這種情況時，可不能簡單的通過DEL來刪除鎖，然後再SETNX一次，當多個客戶端檢測到鎖超時後都會嘗試去釋放它，這里就可能出現一個競態條件,讓我們模擬一下這個場景：
C0操作超時了，但它還持有著鎖，C1和C2讀取lock.foo檢查時間戳，先後發現超時了。
C1 發送DEL lock.foo
C1 發送SETNX lock.foo 並且成功了。
C2 發送DEL lock.foo
C2 發送SETNX lock.foo 並且成功了。
這樣一來，C1，C2都拿到了鎖！問題大了！
幸好這種問題是可以避免D，讓我們來看看C3這個客戶端是怎樣做的：
C3發送SETNX lock.foo 想要獲得鎖，由於C0還持有鎖，所以Redis返回給C3一個0
C3發送GET lock.foo 以檢查鎖是否超時了，如果沒超時，則等待或重試。
反之，如果已超時，C3通過下面的操作來嘗試獲得鎖：
GETSET lock.foo <current Unix time + lock timeout + 1>
通過GETSET，C3拿到的時間戳如果仍然是超時的，那就說明，C3如願以償拿到鎖了。
如果在C3之前，有個叫C4的客戶端比C3快一步執行了上面的操作，那麼C3拿到的時間戳是個未超時的值，這時，C3沒有如期獲得鎖，需要再次等待或重試。留意一下，盡管C3沒拿到鎖，但它改寫了C4設置的鎖的超時值，不過這一點非常微小的誤差帶來的影響可以忽略不計。
注意：為了讓分布式鎖的演算法更穩鍵些，持有鎖的客戶端在解鎖之前應該再檢查一次自己的鎖是否已經超時，再去做DEL操作，因為可能客戶端因為某個耗時的操作而掛起，操作完的時候鎖因為超時已經被別人獲得，這時就不必解鎖了。
示例偽代碼
根據上面的代碼，我寫了一小段Fake代碼來描述使用分布式鎖的全過程：
# get lock
lock = 0
while lock != 1:
timestamp = current Unix time + lock timeout + 1
lock = SETNX lock.foo timestamp
if lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)):
break;
else:
sleep(10ms)
# do your job
do_job()
# release
if now() < GET lock.foo:
DEL lock.foo
是的，要想這段邏輯可以重用，使用python的你馬上就想到了Decorator，而用Java的你是不是也想到了那誰？AOP + annotation？行，怎樣舒服怎樣用吧，別重復代碼就行。
8. java怎麼實現redis分布式鎖
一、使用分布式鎖要滿足的幾個條件：
系統是一個分布式系統（關鍵是分布式，單機的可以使用ReentrantLock或者synchronized代碼塊來實現）
共享資源（各個系統訪問同一個資源，資源的載體可能是傳統關系型資料庫或者NoSQL）
同步訪問（即有很多個進程同事訪問同一個共享資源。沒有同步訪問，誰管你資源競爭不競爭）
二、應用的場景例子
管理後台的部署架構（多台tomcat伺服器+redis【多台tomcat伺服器訪問一台redis】+mysql【多台tomcat伺服器訪問一台伺服器上的mysql】）就滿足使用分布式鎖的條件。多台伺服器要訪問redis全局緩存的資源，如果不使用分布式鎖就會出現問題。 看如下偽代碼：
long N=0L;
//N從redis獲取值
if(N<5){
N++；
//N寫回redis
}
復制代碼
9. 怎樣使用redis緩存，java代碼
應用Redis實現數據的讀寫，同時利用隊列處理器定時將數據寫入mysql。
同時要注意避免沖突，在redis啟動時去mysql讀取所有表鍵值存入redis中，往redis寫數據時，對redis主鍵自增並進行讀取，若mysql更新失敗，則需要及時清除緩存及同步redis主鍵。
這樣處理，主要是實時讀寫redis，而mysql數據則通過隊列非同步處理，緩解mysql壓力，不過這種方法應用場景主要基於高並發，而且redis的高可用集群架構相對更復雜，一般不是很推薦。
10. java有哪些簡潔的ORM框架
java簡潔的ROM框架太多了，並且每天都在更新迭渣彎斗代，從一下幾方面總結。
1、整如磨合資料庫的orm框架：Mybatis（batis）、Hibernate、Jpa、Jdo等。
2、緩存以及分布式緩存：Ecache、Memcached、Redis等。
3、web框架：WebWok、Struts2、SpringMvc等。
4、遠程調用的相關的服務框架:bbo、webService等。
4、其他大大小小，在鬧此各領域發揮的有很多，如日誌處理Log4J、sj4j，xml處理dom4j等等數不勝數。