1. 程式人生 > >Redis常見叢集方案、Codis實踐及與Twemproxy比較

Redis常見叢集方案、Codis實踐及與Twemproxy比較

前言

誠如開篇文章所言,高效運維包括管理的專業化和技術的專業化。前兩篇我們主要在說些管理相關的內容,本篇說一下技術專業化。希望讀者朋友們能適應這個轉換,謝謝。

網際網路早在幾年前就已進入Web 2.0時代,對後臺支撐能力的要求,提高了幾十倍甚至幾百倍。在這個演化過程中,快取系統扮演了舉足輕重的角色。

運維進化到今天,已經不是重複造輪子的時代。所以,我們在架構優化和自動化運維中,可以儘可能地選用優秀的開源產品,而不是自己完全從頭再來(各種技術geek除外)。

本文主要討論Redis叢集相關技術及新發展,關於Redis運維等內容,以後另開主題討論。

本文重點推薦Codis——豌豆莢開源的Redis分散式中介軟體(該專案於4個月前在GitHub開源,目前star已超過2100)。其和Twemproxy相比,有諸多激動人心的新特性,並支援從Twemproxy無縫遷移至Codis。

本文主要目錄如下,對Redis比較瞭解的朋友,可跳過前兩部分,直接欣賞Codis相關內容。

1. Redis常見叢集技術

1.1 客戶端分片

1.2 代理分片

1.3 Redis Cluster

2. Twemproxy及不足之處

3. Codis實踐

3.1 體系架構

3.2 效能對比測試

3.3 使用技巧、注意事項

好吧我們正式開始。

1. Redis常見叢集技術

長期以來,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,是一種完全的去中心化……

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

2. Twemproxy及不足之處

Twemproxy是一種代理分片機制,由Twitter開源。Twemproxy作為代理,可接受來自多個程式的訪問,按照路由規則,轉發給後臺的各個Redis伺服器,再原路返回。

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

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

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

這樣導致運維同學非常痛苦:業務量突增,需增加Redis伺服器;業務量萎縮,需要減少Redis伺服器。但對Twemproxy而言,基本上都很難操作(那是一種錐心的、糾結的痛……)。

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

Twemproxy另一個痛點是,運維不友好,甚至沒有控制面板。

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

3. Codis實踐

Codis由豌豆莢於2014年11月開源,基於Go和C開發,是近期湧現的、國人開發的優秀開源軟體之一。現已廣泛用於豌豆莢的各種Redis業務場景(已得到豌豆莢@劉奇同學的確認,呵呵)。

從3個月的各種壓力測試來看,穩定性符合高效運維的要求。效能更是改善很多,最初比Twemproxy慢20%;現在比Twemproxy快近100%(條件:多例項,一般Value長度)。

3.1 體系架構

Codis引入了Group的概念,每個Group包括1個Redis Master及至少1個Redis Slave,這是和Twemproxy的區別之一。這樣做的好處是,如果當前Master有問題,則運維人員可通過Dashboard“自助式”切換到Slave,而不需要小心翼翼地修改程式配置檔案。

為支援資料熱遷移(Auto Rebalance),出品方修改了Redis Server原始碼,並稱之為Codis Server。

Codis採用預先分片(Pre-Sharding)機制,事先規定好了,分成1024個slots(也就是說,最多能支援後端1024個Codis Server),這些路由資訊儲存在ZooKeeper中。

ZooKeeper還維護Codis Server Group資訊,並提供分散式鎖等服務。


3.2 效能對比測試

Codis目前仍被精益求精地改進中。其效能,從最初的比Twemproxy慢20%(雖然這對於記憶體型應用而言,並不明顯),到現在遠遠超過Twemproxy效能(一定條件下)。

我們進行了長達3個月的測試。測試基於redis-benchmark,分別針對Codis和Twemproxy,測試Value長度從16B~10MB時的效能和穩定性,並進行多輪測試。

一共有4臺物理伺服器參與測試,其中一臺分別部署codis和twemproxy,另外三臺分別部署codis server和redis server,以形成兩個叢集。

從測試結果來看,就Set操作而言,在Value長度<888B時,Codis效能優越優於Twemproxy(這在一般業務的Value長度範圍之內)。

就Get操作而言,Codis效能一直優於Twemproxy。

3.3 使用技巧、注意事項

Codis還有很多好玩的東東,從實際使用來看,有些地方也值得注意。

1)無縫遷移Twemproxy

出品方貼心地準備了Codis-port工具。通過它,可以實時地同步 Twemproxy 底下的 Redis 資料到你的 Codis 叢集。同步完成後,只需修改一下程式配置檔案,將 Twemproxy 的地址改成 Codis 的地址即可。是的,只需要做這麼多。

2)支援Java程式的HA

Codis提供一個Java客戶端,並稱之為Jodis(名字很酷,是吧?)。這樣,如果單個Codis Proxy宕掉,Jodis自動發現,並自動規避之,使得業務不受影響(真的很酷!)。

3)支援Pipeline

Pipeline使得客戶端可以發出一批請求,並一次性獲得這批請求的返回結果。這提升了Codis的想象空間。

從實際測試來看,在Value長度小於888B位元組時,Set效能迅猛提升;

Get效能亦復如是。

4)Codis不負責主從同步

也就是說, Codis僅負責維護當前Redis Server列表,由運維人員自己去保證主從資料的一致性。

這是我最讚賞的地方之一。這樣的好處是,沒把Codis搞得那麼重。也是我們敢於放手在線上環境中上線的原因之一。

5)對Codis的後續期待?

好吧,粗淺地說兩個。希望Codis不要變得太重。另外,加pipeline引數後,Value長度如果較大,效能反而比Twemproxy要低一些,希望能有改善(我們多輪壓測結果都如此)。

因篇幅有限,原始碼分析不在此展開。另外Codis原始碼、體系結構及FAQ,參見如下連結:https://github.com/wandoulabs/codis