Redis集群技術及Codis實踐 1

本文重點推薦codis——豌豆莢開源的redis分布式中介軟體（該專案於4個月前在github開源，目前star已超過2100）。其和twemproxy相比，有諸多激動人心的新特性，並支援從twemproxy無縫遷移至codis。

好吧我們正式開始。

長期以來，redis本身僅支援單例項，記憶體一般最多10~20gb。這無法支撐大型線上業務系統的需求。而且也造成資源的利用率過低——畢竟現在伺服器記憶體動輒100~200gb。

為解決單機承載能力不足的問題，各大網際網路企業紛紛出手，「自助式」地實現了集群機制。在這些非官方集群解決方案中，物理上把資料「分片」（sharding）儲存在多個redis例項，一般情況下，每一「片」是乙個redis例項。

包括官方近期推出的redis cluster，redis集群有三種實現機制，分別介紹如下，希望對大家選型有所幫助。

1.1 客戶端分片

這種方案將分片工作放在業務程式端，程式**根據預先設定的路由規則，直接對多個redis例項進行分布式訪問。這樣的好處是，不依賴於第三方分布式中介軟體，實現方法和**都自己掌控，可隨時調整，不用擔心踩到坑。

這實際上是一種靜態分片技術。redis例項的增減，都得手工調整分片程式。基於此分片機制的開源產品，現在仍不多見。

這種分片機制的效能比**式更好（少了乙個中間分發環節）。但缺點是公升級麻煩，對研發人員的個人依賴性強——需要有較強的程式開發能力做後盾。如果主力程式設計師離職，可能新的負責人，會選擇重寫一遍。

所以，這種方式下，可運維性較差。出現故障，定位和解決都得研發和運維配合著解決，故障時間變長。

這種方案，難以進行標準化運維，不太適合中小公司（除非有足夠的devops）。

1.2 **分片

這種方案，將分片工作交給專門的**程式來做。**程式接收到來自業務程式的資料請求，根據路由規則，將這些請求分發給正確的redis例項並返回給業務程式。

這種機制下，一般會選用第三方**程式（而不是自己研發），因為後端有多個redis例項，所以這類程式又稱為分布式中介軟體。

這樣的好處是，業務程式不用關心後端redis例項，運維起來也方便。雖然會因此帶來些效能損耗，但對於redis這種記憶體讀寫型應用，相對而言是能容忍的。

這是我們推薦的集群實現方案。像基於該機制的開源產品twemproxy，便是其中代表之一，應用非常廣泛。

1.3 redis cluster

在這種機制下，沒有中心節點（和**模式的重要不同之處）。所以，一切開心和不開心的事情，都將基於此而展開。

redis cluster將所有key對映到16384個slot中，集群中每個redis例項負責一部分，業務程式通過整合的redis cluster客戶端進行操作。客戶端可以向任一例項發出請求，如果所需資料不在該例項中，則該例項引導客戶端自動去對應例項讀寫資料。

redis cluster的成員管理（節點名稱、ip、埠、狀態、角色）等，都通過節點之間兩兩通訊，定期交換並更新。

由此可見，這是一種非常「重」的方案。已經不是redis單例項的「簡單、可依賴」了。可能這也是延期多年之後，才近期發布的原因之一。

這令人想起一段歷史。因為memcache不支援持久化，所以有人寫了乙個membase，後來改名叫couchbase，說是支援auto rebalance，好幾年了，至今都沒多少家公司在使用。

這是個令人憂心忡忡的方案。為解決仲裁等集群管理的問題，oracle rac還會使用儲存裝置的一塊空間。而redis cluster，是一種完全的去中心化……

本方案目前不推薦使用，從了解的情況來看，線上業務的實際應用也並不多見。

twemproxy是一種**分片機制，由twitter開源。twemproxy作為**，可接受來自多個程式的訪問，按照路由規則，**給後台的各個redis伺服器，再原路返回。

這個方案順理成章地解決了單個redis例項承載能力的問題。當然，twemproxy本身也是單點，需要用keepalived做高可用方案。

我想很多人都應該感謝twemproxy，這麼些年來，應用範圍最廣、穩定性最高、最久經考驗的分布式中介軟體，應該就是它了。只是，他還有諸多不方便之處。

twemproxy最大的痛點在於，無法平滑地擴容/縮容。

這樣導致運維同學非常痛苦：業務量突增，需增加redis伺服器；業務量萎縮，需要減少redis伺服器。但對twemproxy而言，基本上都很難操作（那是一種錐心的、糾結的痛……）。

或者說，twemproxy更加像伺服器端靜態sharding。有時為了規避業務量突增導致的擴容需求，甚至被迫新開乙個基於twemproxy的redis集群。

twemproxy另乙個痛點是，運維不友好，甚至沒有控制面板。

codis剛好擊中twemproxy的這兩大痛點，並且提供諸多其他令人激賞的特性。