最近整理redis，對sentinel有了更深入的理解，特地總結如下
1.主從redis
主從redis實際上是一種主備模式，即主redis宕機後，可以切換從redis繼續提供服務。
缺點：1.人為關注master是否宕機
2.無法完成自動切換主從
3.從節點的功能未被充分利用
主從模式：
為了解決上述確定，redis官方提供了sentinel，保證redis的高可用性
命令連線：傳送info命令，與redis保持通訊
訂閱連線：通過訂閱連線，自動發現其他sentinel例項
圖2展示乙個最小規模的sentinel，即至少由三個sentinel例項組成，當被監視的redis被判斷為主管下線時，需要從sentinel中選舉零頭sentinel來進行主從切換
優點：1.sentienl可以監控主從節點的健康狀況，降低了人為監控成本
2.sentinel可以完成主從切換
缺點：1.從節點依然未被充分利用
2.無法做到橫向擴充套件，提供伺服器的只有乙個master
sentinel模式：
圖1
圖23.分片
分片思想主要是利用一致性雜湊演算法，完成redis的橫向擴充套件
1.通過zookeeper儲存sentinel的配置資訊
2.在客戶端實現一致性雜湊演算法，通過路由演算法決定redis命令由那個redis例項進行執行
3.通過增加shard，來分擔單個shard的壓力
缺點：1.擴容時涉及到資料遷移，如果redis中只是快取資料則方便處理，但如果有業務資料強依賴redis，則遷移時只能停機處理
2.無法解決冷熱資料問題
分片模式：
下節重點：
jedisclient客戶單的實現原理
redis 高可用切換 Redis高可用使用方法二
redis高可用使用方法一 redis高可用使用方法三 之前是主從模式下,但如果考慮到主從切換時，對於開發者來說需要更換配置檔案，是乙個不明智的選擇 而官方提供了哨兵模式 當然在官方不提供的前提下方式是有多種解決的 dns，四層等 一 哨兵的配置 cd redis 4.0.12 切換到之前解壓的目錄...
高可用集群架構的演進
我們專案組是做企業資料匯流排的，一開始的架構是採用apache httpd mod jk 做負載均衡，應用則部署在tomcat集群上面，該架構方案雖然考慮了tomcat容器級別的高可用，但並未考慮httpd的高可用，該方案的拓撲圖如下 該方案的缺點顯而易見，一旦httpd宕機，使用者將無法訪問應用，...
Redis的高可用
1.持久化 主要作用是資料備份，將資料儲存在硬碟，保證資料不會因程序退出而丟失 2.複製 哨兵和集群都是在複製的基礎上實現高可用的，複製主要實現了資料的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復 缺陷 故障恢復無法自動化，寫操作無法負載均衡，儲存能力受到單機的限制 3.哨兵 在複製的基礎上，...