Codis是一個分佈式Redis解決方案，與官方的純P2P的模式不同，Codis採用的是Proxy-based的方案。今天我們介紹一下Codis及下一個大版本RebornDB的設計，同時會介紹一些Codis在實際應用場景中的tips。最後拋磚引玉，會介紹一下我對分佈式存儲的一些觀點和看法，望各位首席們雅正(黃旭東)。
一、 Redis，RedisCluster和Codis
Redis：想必大家的架構中，Redis已經是一個必不可少的部件，豐富的數據結構和超高的性能以及簡單的協議，讓Redis能夠很好的作爲數據庫的上游緩存層。但是我們會比較擔心Redis的單點問題，單點Redis容量大小總受限於內存，在業務對性能要求比較高的情況下，理想情況下我們希望所有的數據都能在內存裏面，不要打到數據庫上，所以很自然的就會尋求其他方案。 比如，SSD將內存換成了磁盤，以換取更大的容量。更自然的想法是將Redis變成一個可以水平擴展的分佈式緩存服務，在Codis之前，業界只有Twemproxy，但是Twemproxy本身是一個靜態的分佈式Redis方案，進行擴容/縮容時候對運維要求非常高，而且很難做到平滑的擴縮容。Codis的目標其實就是儘量兼容Twemproxy的基礎上，加上數據遷移的功能以實現擴容和縮容，最終替換Twemproxy。從豌豆莢最後上線的結果來看，最後完全替換了Twem，大概2T左右的內存集羣。
Redis Cluster ：與Codis同期發佈正式版的官方cluster，我認爲有優點也有缺點，作爲架構師，我並不會在生產環境中使用，原因有兩個:
cluster的數據存儲模塊和分佈式的邏輯模塊是耦合在一起的，這個帶來的好處是部署異常簡單，all-in-the-box，沒有像Codis那麼多概念，組件和依賴。但是帶來的缺點是，你很難對業務進行無痛的升級。比如哪天Redis cluster的分佈式邏輯出現了比較嚴重的bug，你該如何升級?除了滾動重啓整個集羣，沒什麼好辦法。這個比較傷運維。
對協議進行了較大的修改，對客戶端不太友好，目前很多客戶端已經成爲事實標準，而且很多程序已經寫好了，讓業務方去更換Redisclient，是不太現實的，而且目前很難說有哪個Rediscluster客戶端經過了大規模生產環境的驗證，從HunanTV開源的Rediscluster proxy上可以看得出這個影響還是蠻大的，否則就會支持使用cluster的client了。
Codis：和Redis cluster不同的是，Codis採用一層無狀態的proxy層，將分佈式邏輯寫在proxy上，底層的存儲引擎還是Redis本身（儘管基於Redis2.8.13上做了一些小patch），數據的分佈狀態存儲於zookeeper(etcd)中，底層的數據存儲變成了可插拔的部件。這個事情的好處其實不用多說，就是各個部件是可以動態水平擴展的，尤其無狀態的proxy對於動態的負載均衡，還是意義很大的，而且還可以做一些有意思的事情，比如發現一些slot的數據比較冷，可以專門用一個支持持久化存儲的server group來負責這部分slot，以節省內存，當這部分數據變熱起來時，可以再動態的遷移到內存的server group上，一切對業務透明。比較有意思的是，在Twitter內部棄用Twmeproxy後，t家自己開發了一個新的分佈式Redis解決方案，仍然走的是proxy-based路線。不過沒有開源出來。可插拔存儲引擎這個事情也是Codis的下一代產品RebornDB在做的一件事情。btw，RebornDB和它的持久化引擎都是完全開源的，見https://github.com/reborndb/reborn和https://github.com/reborndb/qdb。當然這樣的設計的壞處是，經過了proxy，多了一次網絡交互，看上去性能下降了一些，但是記住，我們的proxy是可以動態擴展的，整個服務的QPS並不由單個proxy的性能決定（所以生產環境中我建議使用LVS/HA Proxy或者Jodis），每個proxy其實都是一樣的。
作者：黃旭東