Codis--分布式redis架構設計

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

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其實都是一樣的。

本文轉自 撫琴煮酒 51CTO部落格，原文連結：http://blog.51cto.com/yuhongchun/1901146，如需轉載請自行聯系原作者