轉 Redis集羣技術及Codis實踐

轉  Redis集羣技術及Codis實踐

轉自 ：http://blog.51cto.com/navyaijm/1637688

codis開源地址：https://github.com/CodisLabs/codis

 

redis是分佈式緩存的一種實現，分佈式緩存存在的前提在於提升服務器響應能力，原理嘛就在於，直接與io外設存儲設備如硬盤，磁帶讀寫屬於非高速io，而cpu與內存讀寫屬於高速io因此直接提高了響應能力。

redis的除了服務器高併發能力以外在於內存的容量，內存容量越高緩存數據量越大，所以須要藉助集羣化來實現容量擴展，可是集羣會丟失單點數據庫特性能力，如事務，垮點集合計算。在redis領域集羣也叫作分區

相應的須要分區算法，來達到合理的負載均衡和讀寫路由，因此集羣也就是分區的關鍵在於key的分配上，hash算法是實現key合理分配的一個很是適合且廣泛的算法

 

 

 

專欄介紹

「高效運維最佳實踐」是InfoQ在2015年推出的精品專欄，由觸控科技運維總監蕭田國撰寫，InfoQ總編輯崔康策劃。

前言

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

互聯網早在幾年前就已進入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

PS：線上文檔的可讀性，也是至關值得稱讚的地方。一句話：很走心，贊！

最後，Redis初學者請參考這個連接：http://www.gamecbg.com/bc/db/redis/13852.html，文字淺顯易懂，並且比較全面。

本文獲得Codis開發團隊劉奇和黃東旭同窗的大力協助，並獲得Tim Yang老師等朋友們在內容把控方面的指導。本文共同做者爲趙文華同窗，他主要負責Codis及Twemproxy的對比測試。在此一併謝過。