NO IMAGE

    Redis作為時下比較常用的記憶體資料庫有其幾個優勢,效能高,穩定強,操作簡單,提供多種語言且豐富API,叢集部署簡便等。目前很多企業用Redis叢集主要用於快取資料(設定與應用與資料庫之間中間層),如TOP10排序,全域性序號生產等,能較大提升使用者響應時間。本文主要介紹如何用ZooKeeper維護Redis叢集系統,已經如何實現基於Redis訂閱釋出功能實現訊息路由功能。

   ZooKeeper介紹不多說,網上資料有很多。Zookeeper有兩個重要概念就znode和Watcher,znode是一個跟Unix檔案系統路徑相似的節點,可以往這個節點儲存或獲取資料。Watcher可由使用者實現,使用者監聽znode狀態變化,如子節點增加/修改/更新事件,監聽父節點也可以監聽到子節點的變化如增加和刪除。這方便可以參考ZooKeeper官方手冊。關於ZooKeeper部署,節點數目最好是基數,原因大致如下:

    zookeeper有這樣一個特性:叢集中只要有過半的機器是正常工作的,那麼整個叢集對外就是可用的。也就是說如果有2個zookeeper,那麼只要有1個死了zookeeper就不能用了,因為1沒有過半,所以2個zookeeper的死亡容忍度為0;同理,要是有3個zookeeper,一個死了,還剩下2個正常的,過半了,所以3個zookeeper的容忍度為1;同理你多列舉幾個:2->0;3->1;4->1;5->2;6->2會發現一個規律,2n和2n-1的容忍度是一樣的,都是n-1,所以為了更加高效,不必要的多增加一個zookeeper。

    如果Redis叢集有很多,如何進行高效的管理?ZooKeeper是一個不錯的選擇。通過ZooKeeper維持一個全域性Redis執行資訊,達到監控整個叢集的目的。同時可以把Redis和ZooKeeper API進行二次開發,開發人員即可透明的訪問Redis,無需關注Redis叢集執行狀態。分兩步考慮問題:

    1.開發RedisMonitor,用於定時監控Redis叢集狀態,儲存諸如Redis Master/Slave資訊,執行狀態,資料量大小等。具體實現:

     1)主程序定期發命令檢查所有節點狀態,目前有API可以查詢到所有redis叢集狀態,再呼叫ZooKeeper API修改znode資訊

     2)znode狀態變化觸發通知和相關切換

     附件提供相關RedisMonitor和HA原始碼

     2.結合ZooKeeper和Redis API開發通用API。本篇準備論述一下如何實現基於Redis的訊息路由。由於Redis自帶訊息訂閱和釋出功能,可以說是一個很不錯的功能。釋出訂閱(pub/sub)是一種訊息通訊模式,主要的目的是解耦訊息釋出者和訊息訂閱者之間的耦合。訂閱釋出在如下場景應用廣泛,如訊息推送,訊息路由,事件驅動告警與診斷等,對於開發來說,訂閱和釋出能大大減少系統之間的耦合。在設計模式中,釋出訂閱也是一個程式設計師必須掌握的模式。釋出/訂閱模型使釋出者和訂閱者之間不需要直接通訊(如遠端介面呼叫RMI)就可保證訊息的傳送,有效解決系統間耦合問題(當然有這個中介),還有就是提供了一對一、一對多的通訊方式,比較靈活。訂閱者可以通過subscribe和psubscribe命令向Redis訂閱自己感興趣的訊息型別,Redis將訊息型別稱為通道(channel)。當釋出者通過publish命令向Redis傳送特定型別的訊息時。訂閱該訊息型別的全部client都會收到此訊息。這裡訊息的傳遞是多對多的。一個client可以訂閱多個
channel,也可以向多個channel傳送訊息。

      那麼問題來了,在一個Redis叢集中,如何對外提供可靠的訊息路由功能,既保證了可靠性有保證了負載均衡。這裡提供了一個簡單的思路,讀者可以進一步實現。訂閱者在訂閱channel時要進行相關判斷,保持當前各個Redis Server負載基本均衡(選擇一個負載最輕的server),同時,釋出責傳送時也要遵循此原則。可以採用ZooKeeper保持這些channel資訊,以及Redis負載情況等等,資訊越完善越能做出更合理的決策。還需要解決的一個問題是熱切換。當某一臺Redis叢集掛掉之後,要求能自動切換到其他Redis
Server。以上操作對使用者透明。後續會補上原始碼和流程圖