如何深入了解Redis中的Codis

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

場景

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

首先，數據量越大，redis占用內存就越大，進一步導致rdb文件過大，這種情況會使的主從全量同步時間過長，同時實例重啟時，加載過大的rdb也會讓啟動時間變長。【相關推薦：Redis視頻教程】

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

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

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

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

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

原理

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

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

槽位的數量默認是1024，可以更改，如果集群節點比較多，可以將數字調大。

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

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

偽代碼：

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

集群槽位同步

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

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

拓容

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

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

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

因此這種情況 Codis 會立即強制對當前的 key 進行單個遷移，遷移完成后，將請求轉發給新的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指令一樣，無法避免掃描出來的數據重復，但這不會影響到遷移的正確性，因為單個key遷移之后，就立刻從舊實例中刪除了，無法再被掃描出來。

自動均衡槽位

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

缺點

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

不支持事務

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

不支持rename

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

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

擴容卡頓

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

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

網絡開銷

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

中間件運維開銷

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

優點

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

Redis官方的Cluster為了實現去中心化，引入了Raft與Gossip協議，以及大量需要調優的配置參數，復雜度驟增。

批量獲取

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

其他功能

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

Codis是為了彌補Redis官方沒有提供集群這一概念時出現的，現在Redis官方提供Cluster功能，官方的支持自然比第三方的更有優勢，

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

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