如何深入了解Redis中的Codis

這篇文章給大家介紹如何深入了解Redis中的Codis，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

場景

在大數(shù)據(jù)高并發(fā)場景下，使用單個redis實例，即使redis的性能再高，也會變的非常吃力，

首先，數(shù)據(jù)量越大，redis占用內(nèi)存就越大，進一步導致rdb文件過大，這種情況會使的主從全量同步時間過長，同時實例重啟時，加載過大的rdb也會讓啟動時間變長?！鞠嚓P推薦：Redis視頻教程】

其次在CPU的使用上，單個實例的Redis只能使用一個CPU核心，一個核心應多過多的數(shù)據(jù)，也會顯得力不從心，

因此需要一個集群方案，將巨大的數(shù)據(jù)量由一臺實例分散到多臺實例上，從Redis流行到官方支持自己的Cluster方案之間，第三方也在自己開發(fā)支持集群的組件，Codis就是其中之一，

Codis使用Go語言開發(fā)，在Redis與客戶端中間充當代理的角色，使用Redis協(xié)議，所以客戶端直接連接Codis，向其發(fā)送指令即可，Codis負責轉發(fā)指令給Redis，最后接收返回結果再返回給客戶端，

Codis代理的Redis實例構成一個Redis集群，當集群空間也不足以使用時，可以動態(tài)擴容，繼續(xù)增加Redis實例，與此同時，客戶端使用的sdk不需要做任何改動，只需由原來的連接redis改成連接codis即可，

Codis自身也可以采取一個集群，來保證自身的高可用，由于其本身就是無狀態(tài)的，只負責轉發(fā)內(nèi)容，增加多個Codis沒有副作用還可以保證QPS的提高，當其中一個Codis掛掉時，還可以使用別的。

原理

Codis將特定的Key轉發(fā)到特定的Redis實例，集群中每個實例都保存一部分Key，降低其他實例的壓力，同時所有實例的數(shù)據(jù)加起來，就是一份完整的信息。

Codis默認劃分了1024個槽位(slot)，集群中的每個Redis實例對應一部分槽位，Codis會在內(nèi)存中維護槽位與Redis實例的對應關系，

槽位的數(shù)量默認是1024，可以更改，如果集群節(jié)點比較多，可以將數(shù)字調(diào)大。

當接收到客戶端發(fā)送過來的key時，Codis對該key進行 crc32 運算得出一個 hash 值，

再將 hash 后的整數(shù)值對 1024(槽位數(shù)量) 進行取模得到一個余數(shù)，該余數(shù)就是Key將被保存到的槽位，有了槽位就可以找到這個key該發(fā)到哪個redis實例上了。

偽代碼：

hash = crc32(command.key) # 計算hash值
slot = hash % 1024 # 取模得到槽位
redisInstance = slots[slot].redis # 得到redis實例
redis.do(command) # 執(zhí)行命令復制代碼

集群槽位同步

Redis與槽位的映射關系存在Codis的內(nèi)存當中，因此Codis集群需要考慮保證每個節(jié)點中的槽位映射關系同步，所以Codis采用 Zookeeper、Etcd 分布式配置存儲中間件來持久化槽位映射關系，保證Codis集群之間的數(shù)據(jù)同步，

如下圖，Codis將槽位關系存在Zookeeper中，并提供了一個Dashboard 觀察與修改槽位關系，當發(fā)生改變時，Codis Proxy 監(jiān)聽到變化并重新同步槽位關系。

拓容

當現(xiàn)有集群也不滿足業(yè)務需求時，就需要新增實例加入到的集群中，此時槽位映射關系需要進行重新分配，需要分配一部分的槽位給新節(jié)點。

Codis新增了一個 SLOTSSCAN 指令，可以遍歷指定slot下的所有key，通過該指令掃描出待遷移槽位的所有key，然后挨個遍歷每個key遷移到新節(jié)點中，

遷移過程中，Codis繼續(xù)對外提供服務，此時來了一個請求打在了正在遷移的槽位上，由于該槽位現(xiàn)在對應新老兩個節(jié)點，此時 Codis 無法判斷該 key 有沒有從舊節(jié)點中遷移到新節(jié)點上，

因此這種情況 Codis 會立即強制對當前的 key 進行單個遷移，遷移完成后，將請求轉發(fā)給新的Redis實例上。

偽代碼：

slot_index = crc32(command.key) % 1024
if slot_index in migrating_slots:
    doMigratingKey(command.key)
    redis = slots[slot_index].new_redis
else:
    redis = slots[slot_index].redis復制代碼

SLOTSSCAN 與 Redis自身的Scan指令一樣，無法避免掃描出來的數(shù)據(jù)重復，但這不會影響到遷移的正確性，因為單個key遷移之后，就立刻從舊實例中刪除了，無法再被掃描出來。

自動均衡槽位

每次新增實例，如果都需要人工維護slot的映射關系太麻煩，Codis提供自動均衡，該功能會在系統(tǒng)比較空閑的時候觀察每個Redis實例對應的slot數(shù)量，如果不平衡，就進行自動均衡，遷移數(shù)據(jù)的操作。

缺點

Codis給Redis帶來擴容好處，但也造成了一些副作用。

不支持事務

一個事務可能對多個key做了操作，但事務只能在單個實例中完成，但是由于key分散在不同的實例中，因此Codis無法支持事務操作。

不支持rename

rename將一個key命名成另一個key，但是這兩個key可能hash出來的槽位并不是同一個，而是在不同實例的槽位上，因此rename也不被支持。

官方提供的不支持的指令列表：https://github.com/CodisLabs/codis/blob/master/doc/unsupported_cmds.md

擴容卡頓

Codis在擴容過程中，對數(shù)據(jù)的遷移是將整個key直接遷移過去的，例如一個hash結構，Codis會直接 hgetall 拉取所有的內(nèi)容，使用 hmset 放到 新節(jié)點中，

如果該hash的內(nèi)容過大，將會引起卡頓，官方建議單個集合結構的總大小不超過1MB，在業(yè)務上可以通過分桶存儲等，將大型數(shù)據(jù)拆成多個小的，做一個折中。

網(wǎng)絡開銷

由于 Codis 在 客戶端與Redis實例之間充當網(wǎng)絡Proxy，多了一層，網(wǎng)絡開銷自然多一些，比直接連接Redis的性能要稍低一些。

中間件運維開銷

Codis集群配置需要使用Zk或Etcd，這意味著引入Codis集群又要引入其他中間件，增加運維機器資源成本。

優(yōu)點

Codis將分布式一致性的問題交給了第三方(ZK或Etcd)負責，省去了這方面的維護工作，降低實現(xiàn)代碼的復雜性，

Redis官方的Cluster為了實現(xiàn)去中心化，引入了Raft與Gossip協(xié)議，以及大量需要調(diào)優(yōu)的配置參數(shù)，復雜度驟增。

批量獲取

對于批量操作，例如使用 mget 獲取多個key的值，這些key可能分散在多個實例中，Codis將key按照所在的實例進行分組，然后對每個實例挨個調(diào)用 mget，最后匯總返回給客戶端。

其他功能

Codis 提供 Dashboard 界面化，以及 Codis-fe 對集群進行管理，還可以進行增加分組、節(jié)點、執(zhí)行自動均衡等操作，查看 slot 狀態(tài)以及 slot 對應的 redis 實例，這些功能使的運維更加方便輕松。

Codis是為了彌補Redis官方?jīng)]有提供集群這一概念時出現(xiàn)的，現(xiàn)在Redis官方提供Cluster功能，官方的支持自然比第三方的更有優(yōu)勢，

同時第三方軟件還需要實時關注官方發(fā)布的新特性各種，而Cluster肯定是實時兼容新特性，因此更推薦使用官方的Cluster，Codis作為曾經(jīng)的一個知識點了解，某些思想與Cluster是有重合的。

關于如何深入了解Redis中的Codis就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。