緩存的使用二-緩存如何高可用
爲了減少數據庫的壓力，我們開始使用緩存承擔大部分的讀壓力，在提升性能的同時也需要保證系統的穩定性。
分佈式緩存的高可用方案有以下幾種：
- 客戶端方案
- 中間代理方案
- 服務端方案
1、客戶端方案
- 寫入數據時，需要把被寫入緩存的數據分散到多個節點中，即進行數據分片
- 讀數據時，利用多組的緩存來做容錯，有主從和多副本兩種策略 來提升緩存系統的可用性
1.1、緩存數據如何分片
按照分片算法將數據打散到多個不同的節點上，每個節點上存儲部分數據，
分片算法常見的有：
- Hash 分片算法
- 一致性 Hash 分片算法
1.1.1、Hash 分片算法
對緩存中的 Key 做哈希計算，然後對總的緩存節點個數取餘
缺點
當增加或者減少緩存節點時，緩存總的的節點個數發生變化造成計算出來的節點發生變化，從而造成緩存失效不可用。
1.1.2、一致性Hash 算法
將整個 Hash 值空間組成一個虛擬的圓環，然後將緩存節點的 IP 地址或者主機名做 Hash 取值後，放置在這個圓環上。當我們需要確定某一個 Key 需要存取到哪個節點上的時候，先對這個 Key 做相同的 Hash 取值，確定在環上的位置，然後按照順時針方向在環上計數，遇到的第一個緩存節點就是要訪問的節點。
缺點
-
緩存節點在圓環上分佈不平均，會造成部分緩存節點的壓力比較大，當某個節點發生故障時，這個節點所要承擔的訪問都會被順移到另一個節點上，造成該節點壓力變大
-
一致性Hash算法的髒數據問題
在使用一致性Hash算法時一定要設置緩存的過期時間這樣當發生偏移時，之前存儲的髒數據可能就過期了，就可以減少存在髒數據的機率。
2、中間代理層方案
爲了解決客戶端方案 只能在單一語言系統之間複用 的問題
業界也有很多中間代理層方案，比如 Facebook 的Mcrouter，Twitter 的Twemproxy，豌豆莢的Codis。
所有緩存的讀寫請求都是經過代理層完成的。代理層是無狀態的，主要負責讀寫請求的路由功能，並且在其中內置了一些高可用的邏輯，不同的開源中間代理層方案中使用的高可用策略各有不同。
比如在 Twemproxy 中，Proxy 保證在某一個 Redis 節點掛掉之後會把它從集羣中移除，後續的請求將由其他節點來完成；而 Codis 的實現略複雜，它提供了一個叫 Codis Ha 的工具來實現自動從節點提主節點，在 3.2 版本之後換做了 Redis Sentinel 方式，從而實現 Redis 節點的高可用
3、服務端方案
Redis 在 2.4 版本中提出了 Redis Sentinel 模式來解決主從 Redis 部署時的高可用問題，它可以在主節點掛了以後自動將從節點提升爲主節點，保證整體集羣的可用性
Redis Sentinel 也是集羣部署的，這樣可以避免 Sentinel 節點掛掉造成無法自動故障恢復的問題，每一個 Sentinel 節點都是無狀態的。
在 Sentinel 中會配置 Master 的地址，Sentinel 會時刻監控 Master 的狀態，當發現 Master 在配置的時間間隔內無響應，就認爲 Master 已經掛了，Sentinel 會從從節點中選取一個提升爲主節點，並且把所有其他的從節點作爲新主的從節點。
Sentinel 集羣內部在仲裁的時候，會根據配置的值來決定當有幾個 Sentinel 節點認爲主掛掉可以做主從切換的操作，也就是集羣內部需要對緩存節點的狀態達成一致才行。