為什么要使用反向代理
如果沒有反向代理肾请，一臺Redis客戶端需要跟很多個客戶端連接：
多客戶端與Redis鏈接.png
看著是不是很懵逼练慕？沒關系枉阵，主要連接需要消耗線程資源译红，沒有代理的話，Redis要將很大一部分的資源用在與客戶端建立連接上兴溜，Redis的高可用和可擴展性侦厚，無論是自帶的Sentinel還是Cluster都要求客戶端進行額外的支持耻陕，而目前基本上沒有合適的客戶端能夠做這些事情，客戶端來做這些事情也并不合適刨沦，它會讓維護變的跟糟糕诗宣。
因此客戶端和Redis服務端之間加一層代理成了一種理想的方案，代理屏蔽后端
Redis實現(xiàn)細節(jié)想客戶端提供Redis服務想诅，可以完美的解決Redis的高可用和擴展性的問題召庞。
如何使用代理
很簡單，將請求鏈接到代理服務器上来破，有Proxy負責將請求轉(zhuǎn)發(fā)到后面的Redis服務器實例：
Proxy.png
那么問題來了篮灼，如果Proxy掛了呢？
所以Proxy需要做集群徘禁，前面再加一層負載均衡（LVS）,而其單機也存在故障的風險诅诱，所以整一個主備，備機通過KeeAlived來檢測主LVS的健康狀況晌坤，出現(xiàn)故障自動切換過去：
LVS keepalived.png
redis cluster
Redis Cluster 的實現(xiàn)方案十分的聰明逢艘，它的分區(qū)方式采用了虛擬槽分區(qū)。
Redis Cluster 首先會預設虛擬槽骤菠，每個槽就相當于一個數(shù)字，有一定范圍疤孕，每個槽映射一個數(shù)據(jù)子集商乎。
Redis Cluster中預設虛擬槽的范圍為 0 到 16383
- Redis Cluster 會把 16384 個槽按照節(jié)點數(shù)量進行平均分配，由節(jié)點進行管理祭阀。
- 當一個 key 過來的時候鹉戚，會對這個 key 按照 CRC16 規(guī)則進行 hash 運算。
- 把 hash 結(jié)果對 16383 進行取余专控。
- 把余數(shù)發(fā)送給 Redis 節(jié)點抹凳。
- 節(jié)點接收到數(shù)據(jù)，驗證是否在自己管理的槽編號的范圍：
5.1. 如果在自己管理的槽編號范圍內(nèi)伦腐，則把數(shù)據(jù)保存到數(shù)據(jù)槽中赢底，然后返回執(zhí)行結(jié)果。
5.2. 如果在自己管理的槽編號范圍外柏蘑，則會把數(shù)據(jù)發(fā)送給正確的節(jié)點幸冻，由正確的節(jié)點來把數(shù)據(jù)保存在對應的槽中。
注意：Redis Cluster 的節(jié)點之間會共享消息咳焚，每個節(jié)點都會知道是哪個節(jié)點負責哪個范圍內(nèi)的數(shù)據(jù)槽
虛擬槽分布方式中洽损，由于每個節(jié)點管理一部分數(shù)據(jù)槽，數(shù)據(jù)保存到數(shù)據(jù)槽中革半。當節(jié)點擴容或者縮容時碑定，對數(shù)據(jù)槽進行重新分配遷移即可流码，數(shù)據(jù)不會丟失。
cluster.png
————————————————————
坐標帝都延刘，白天上班族漫试，晚上是知識的分享者
如果讀完覺得有收獲的話，歡迎點贊加關注
