21集群3眾cluster天下無魚

Redis相對(duì)于CdisdisRedisCluster將所有數(shù)據(jù)劃分為16384的slots，它?Codis的1024個(gè)槽劃分的更為精細(xì)，每個(gè)節(jié)點(diǎn)負(fù)責(zé)其中?部分槽位。槽位的信息存儲(chǔ)于每個(gè)節(jié)點(diǎn)中，它不像Codis，它不需要另外的分布式存儲(chǔ)當(dāng)RedisCluster的客戶端來連接集群時(shí)，它也會(huì)得到?份集群的槽位配置信息。這樣當(dāng)客戶端要查找某個(gè)key時(shí)，可以直接定位到?這點(diǎn)不同于Codis，Codis需要通過ProxyRedisClusterkey所在的節(jié)點(diǎn)，它就需要緩存槽位相關(guān)信息，這樣才可以準(zhǔn)確快速另外，RedisClusterCluster默認(rèn)會(huì)對(duì)key值使?crc16算法進(jìn)?hash得到?個(gè)整數(shù)值，然后?這個(gè)整數(shù)值對(duì)16384進(jìn)?取模來得到具體槽位。Cluster還允許?戶強(qiáng)制某個(gè)key掛在特定槽位上，通過在key字符串??嵌?tag標(biāo)記，這就可以強(qiáng)制key所掛在的槽位等于tagdefdefs=key.index"{"ifse=key.index"}",s+1ife&&e!=s+1key=key[s+1..e-crc16(key)%當(dāng)客戶端向?個(gè)錯(cuò)誤的節(jié)點(diǎn)發(fā)出了指令，該節(jié)點(diǎn)會(huì)發(fā)現(xiàn)指令的keyGETGET-MOVED3999MOVED指令的第?個(gè)參數(shù)3999是key?標(biāo)節(jié)點(diǎn)地址。MOVED指令前?有?個(gè)減號(hào)，表示該指令是?個(gè)錯(cuò)MOVED指令后，要?即糾正本地的槽位映射表。后續(xù)所有key將使?新的槽位映射表。RedisCluster提供了?具redis-trib可以讓運(yùn)維?員?動(dòng)調(diào)整槽位的分配情況，它使?Ruby語?進(jìn)?開發(fā)，通過組合各種原?的RedisCluster指令來實(shí)現(xiàn)。這點(diǎn)Codis做的更加?性化，它不但提供了UI界?可以讓我們?便的遷移，還提供了?動(dòng)化平衡槽位?具，?需???預(yù)就可以均衡集群負(fù)載。不過Redis官?向來的策Redis遷移的單位是槽，Redis?個(gè)槽?個(gè)槽進(jìn)?遷移，當(dāng)?個(gè)槽正遷移?具rdistribky(kynslt)k進(jìn)?遷移。每個(gè)kyk執(zhí)?dumprstor攜O從源節(jié)點(diǎn)獲取內(nèi)容從源節(jié)點(diǎn)刪除內(nèi)容注意這?的遷移過程是同步的，在?標(biāo)節(jié)點(diǎn)執(zhí)?restore指令到原節(jié)點(diǎn)刪除key之間，原節(jié)點(diǎn)的主線程會(huì)處于阻塞狀態(tài)，直到key被成功如果遷移過程中突然出現(xiàn)?絡(luò)故障，整個(gè)slot的遷移只進(jìn)?了?半。在遷移過程中，如果每個(gè)key的內(nèi)容都很?，migrate指令執(zhí)?會(huì)很快，它就并不會(huì)影響客戶端的正常訪問。如果key的內(nèi)容很?，因?yàn)?先新舊兩個(gè)節(jié)點(diǎn)對(duì)應(yīng)的槽位都存在部分key數(shù)據(jù)?？蛻舳讼葒L試會(huì)向客戶端返回?個(gè)-ASKtargetNodeAddr的重定向指令?？蛻魰?huì)形成重定向循環(huán)。asking指令的?標(biāo)就是打開?標(biāo)節(jié)點(diǎn)的選項(xiàng)，情況下?個(gè)ttl就能完成，?在遷移中得3個(gè)ttl才能搞定。RedisCluster可以為每個(gè)主節(jié)點(diǎn)設(shè)置若?個(gè)從節(jié)點(diǎn)，單主節(jié)點(diǎn)故障Redis也提供了?個(gè)參數(shù)cluster-require-full-coverage可為解決這種問題，RedisCluster提供了?種選項(xiàng)cluster-node-timeout，表示當(dāng)某個(gè)節(jié)點(diǎn)持續(xù)timeout的時(shí)間失聯(lián)時(shí)，才可以認(rèn)動(dòng)會(huì)導(dǎo)致主從頻繁切換(數(shù)據(jù)的重新復(fù)制)。rsevtyt作為倍乘1可能下線(PFAIL-PossiblyFail與確定下線(Fail)因?yàn)镽edisCluster是去中?化的，?個(gè)節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn)失聯(lián)了并Redis集群節(jié)點(diǎn)采?Gossip協(xié)議來?播??的狀態(tài)以及??對(duì)整個(gè)集群認(rèn)知的改變。?如?個(gè)節(jié)點(diǎn)發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)失聯(lián)了(PFail)，它會(huì)如果?個(gè)節(jié)點(diǎn)收到了某個(gè)節(jié)點(diǎn)失聯(lián)的數(shù)量(PFailCount)已經(jīng)達(dá)到了集群的?多數(shù)，就可以標(biāo)記該節(jié)點(diǎn)為確定下線狀態(tài)(Fail)，然后向整Cluster另外?個(gè)包，這個(gè)包是依賴redis-py包的。pippipinstallredis-py-redis-py-cluster>>>>>>fromredisclusterimport>>>#Requiresatleastonenodeforclusterdiscovery.Multiplenodesisrecommended.>>>startup_nodes=[{"host":"127.0.0.1","port":"7000"}]>>>rc=>>>rc.set("foo","bar")>>>Cluster是去中?化的，它有多個(gè)節(jié)點(diǎn)組成，構(gòu)造StrictRedisCluster實(shí)例時(shí)，我們可以只??個(gè)節(jié)點(diǎn)地址，其它地址必須更換地址才可以繼續(xù)訪問Cluster。decode_responses數(shù)組轉(zhuǎn)換成unicodeCluster使?起來?常?便，?起來和普通的redis-py差別不?，Cluster不?持事務(wù)，Cluster的mget?法相?Redis要慢很多，被拆分成了多個(gè)get指令，Cluster的rename?法不再是原?如果Cluster中某個(gè)槽位正在遷移或者已經(jīng)遷移完了，client如何能我們前?提到Cluster有兩個(gè)特殊的error指令，?個(gè)是asking第?個(gè)moved是?來糾正槽位的。如果我們將指令發(fā)送到了錯(cuò)誤的地址隨同moved指令回復(fù)給客戶端通知客戶端去?標(biāo)節(jié)點(diǎn)去訪問。第?個(gè)asking指令和moved不?樣，它是?來臨時(shí)糾正槽位的?；?個(gè)askingerror攜帶上?標(biāo)節(jié)點(diǎn)的地址?？蛻舳耸盏竭@個(gè)askingerror后，就會(huì)去?標(biāo)節(jié)點(diǎn)去嘗試。客戶端不會(huì)刷新槽位重試2movedasking指令都是重試指令，客戶端會(huì)因?yàn)檫@兩個(gè)指令多2次呢？這種情況是存在的，?如?條指令被發(fā)送到錯(cuò)誤的節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)會(huì)先給你?個(gè)moved錯(cuò)誤告知你去另外?個(gè)節(jié)點(diǎn)重試。所以個(gè)槽位進(jìn)?遷移操作，于是給客戶端回復(fù)了?個(gè)asking指令告知客戶端去?標(biāo)節(jié)點(diǎn)去重試指令。所以這?客戶端重試了2次。會(huì)有?個(gè)循環(huán)，然后會(huì)設(shè)置?個(gè)最?重試次數(shù)，Java和Python都點(diǎn)關(guān)系表。那客戶端是如何得到通知的呢？這?要分2種情況：Connecti