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

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

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

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

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

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

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

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

缺點

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

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

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

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