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，我認為有優點也有缺點，作為架構師，我並不會在生產環境中使用，原因有兩個:
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和它的持久化引擎都是完全開源的，見和當然這樣的設計的壞處是，經過了proxy，多了一次網路互動，看上去效能下降了一些，但是記住，我們的proxy是可以動態擴充套件的，整個服務的qps並不由單個proxy的效能決定（所以生產環境中我建議使用lvs/ha proxy或者jodis），每個proxy其實都是一樣的。
Codis 分布式redis架構設計
codis是乙個分布式redis解決方案，與官方的純p2p的模式不同，codis採用的是proxy based的方案。今天我們介紹一下codis及下乙個大版本reborndb的設計，同時會介紹一些codis在實際應用場景中的tips。最後拋磚引玉，會介紹一下我對分布式儲存的一些觀點和看法，望各位首席...
Codis 分布式redis架構設計
codis是乙個分布式redis解決方案，與官方的純p2p的模式不同，codis採用的是proxy based的方案。今天我們介紹一下codis及下乙個大版本reborndb的設計，同時會介紹一些codis在實際應用場景中的tips。最後拋磚引玉，會介紹一下我對分布式儲存的一些觀點和看法，望各位首席...
python分布式架構 分布式架構
1.分布式架構 採用centos mongodb windows2012 python redis進行分布式架構搭建，mongodb的框架最核心的設計就是 mongodb和mapreduce。mongodb為海量的資料提供了儲存，則mapreduce為海量的資料提供了計算，windows2012作為...