我們都知道Redis是單機單進程的，在之前的測試中，我們也知道Redis的單機性能是有限的，并且高性能的機器其實非常昂貴。一個好漢三個幫，分布式系統正是利用了多臺普通計算器從而被大量互聯網公司所使用，今天我們來聊一聊Redis集群的一種解決方案--Codis。

Codis，Github上面近萬star，是一款由中國人開源的Redis集群解決方案，由前豌豆夾團隊提供。Codis，它是一款Redis的Proxy，主要負責把Redis的請求分發到不同的Redis實例當中。

我們從一次get請求來解釋一下，Codis是如何工作的。因為Codis代理了Redis服務，所以我們發起請求的時候，并不是請求到Redis-server所在的機器上，而是到Codis機器上，Codis機器再根據一定的路由規則進行分發，最終請求到Redis-Server的機器上，也就是說，如果我們使用一個mget請求，可能會到多臺機器上。

很顯然，這樣子Codis也會存在單點問題，好在Codis是一個無狀態的服務，所以我們可以同時部署多個Codis實例。

Codis是如何把對應的key分配到不同機器的呢？奧秘就在于Codis的Slot，Codis切分出1024（可配置）個Slot，每個Slot會綁定不同的Redis實例，這里為什么要切分到1024個呢？這是一個不錯的思考題？可以從擴容縮容方向進行考慮。

那么不同的Codis實力是如何同步Slot的數據呢？Codis的方法非常簡單粗暴，那便是使用ZooKeeper。ZooKeeper不是發現服務么？怎么還能用來存儲數據？ZooKeeper其實為每個目錄提供了1M的存儲空間，通過Quorum的2pc機制來做數據一致性。所以，ZooKeeper可以偷偷用來做數據小，吞吐不是那么大的數據存儲。

Codis提供一個Dashboard給用戶編輯Slot的情況，當用戶編輯的時候，會由Zookeeper分發給所有的Codis實例。優點

Codis非常的簡單，無論是理解上，問題排查上還是部署上，都非常的簡單。他把一些分布式一致性的東西交給了另外的開源方案Zookeeper去解決，自身非常輕量級。

缺點

由于Codis的數據是落在多臺機器上的，所以，Redis的事務功能就不能使用了，對于批量查詢接口，Codis需要到多臺機器上去獲取結果，這就不能保證數據的一致性。會存在這樣的情況，使用Codis同時獲取key1與key2，同時Update兩者的值，可能獲取到的Value1是新版本，而Value2為舊版本。

Codis會對Slot進行數據遷移，如果key-value的數據太小太大的話，就會影響遷移的效率，所以Codis官方推薦Codis的key-value大小不要超過1M。

由于Codis不是Redis的官方項目，所以每當Redis發布新版本的時候，Codis都會瑟瑟發抖，隨著Redis退出自己的親兒子Redis-Cluster，Codis的競爭力都在減弱。

今天我們對Github上面10kstar的Codis就介紹到這里，如果你有興趣，歡迎關注我，我們后面再繼續分析,談一談Codis中是如何做數據遷移的。