Codis--分佈式redis架構設計

Codis是一個分佈式Redis解決方案，與官方的純P2P的模式不一樣，Codis採用的是Proxy-based的方案。今天咱們介紹一下Codis及下一個大版本RebornDB的設計，同時會介紹一些Codis在實際應用場景中的tips。最後拋磚引玉，會介紹一下我對分佈式存儲的一些觀點和見解，望各位首席們雅正(黃旭東)。

1、 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其實都是同樣的。

做者：黃旭東