Redis 叢集方案

標籤：blog   http   ar   os   使用   sp   strong   on   檔案   

根據一些測試整理出來的一份方案：

1. Redis 效能

對於redis 的一些簡單測試，僅供參考：

測試環境：Redhat6.2 , Xeon E5520(4核)*2/8G，1000M網卡

Redis 版本：2.6.9

 

用戶端機器使用redis-benchmark 簡單GET、SET操作：

1. 1單一實例測試

1. Value大小：10Byte~1390Byte

處理速度： 7.5 w/s，速度受單線程處理能力限制

2. Value 大小：1400 左右

處理速度突降到5w/s 樣子，網卡未能跑滿；由於請求包大於MTU造成TCP分包，服務端中斷處理請求加倍，造成業務急劇下降。

3. Value大小：>1.5 k

1000M網卡跑滿，速度受網卡速度限制

處理速度與包大小大概關係如下：

1.2  多執行個體測試

前提是系統網卡非強制中斷均衡到多CPU核心處理，測試機器網卡開啟RSS，有16個隊列：

操作：10位元組Value SET，服務端開啟8個執行個體，四台用戶端伺服器每台開啟兩個redis-benchmark，每個client 速度近4W/s，服務端總處理30w/s左右。

網卡流量：

其中8個單數核心CPU全部耗盡，像是超執行緒沒有利用上，測試已經達到很好效果，就沒有繼續測試下去了。從單一實例跑滿一個核心7.5w/s，8個執行個體跑滿8個核心，30W/s來看，CPU使用和效能提升不成正比， RSS會造成redis-server線程基本每收到一個請求都切換一次CPU核心，非強制中斷CPU佔用太高。這種情況RPS/RFS功能也許就很合適了，RSS只需要映射1~2個核心，然後再講非強制中斷根據redis-server連接埠動態轉寄，保證redis進程都在一個核心上執行，減少進程不必要的切換。

 

開多執行個體可以充分利用系統CPU、網卡處理小包能力。具體看業務情境，考慮包平均大小、處理CPU消耗、業務量。如果多執行個體是為了提高處理能力，需要注意配置網卡非強制中斷均衡，否則處理能力也無法提升。

 2. Redis 持久化

測試策略：AOF + 定時rewriteaof

1. 準備資料量：

1億，Key：12 位元組 Value：15位元組，儲存為string，進程佔用記憶體12G

2. Dump

檔案大小2.8G，執行時間：95s，重啟載入時間：112s

2. Bgrewriteaof

檔案大小5.1G，執行時間：95s，重啟載入時間：165s

3.開啟AOF後效能影響（每秒fsync一次）：

8K/s SET 操作時：cup 從20% 增加到40%

4.修改1Kw資料：

檔案大小：5.6G，重啟載入時間：194s

5.修改2K資料

檔案大小：6.1G，重啟載入時間：200s

另：Redis2.4 版本以後對fsync做了不少最佳化， bgrewriteaof，bgsave 期間對redis對外提供服務完全無任何影響。

 3. Redis 主從複製

因為目前版本沒有mysql 主從那樣的增量備份，對網路穩定性要求很高，如果頻繁TCP串連斷開會對伺服器和網路帶來很大負擔。

就目前生產環境主從機器部署同一個機架下，幾個月都不會又一次串連斷開重連的情況的。

 4. keepalived 簡介

參考官方文檔：http://keepalived.org/pdf/sery-lvs-cluster.pdf

Keepalived 是一個用c寫的路由選擇軟體，配合IPVS 負載平衡實用，通過VRRP 協議提供高可用。目前最新版本1.2.7.Keepalived 機器之間實用VRRP路由協議切換VIP，切換速度秒級，且不存在腦裂問題。可以實現

可以實現一主多備，主掛後備自動選舉，漂移VIP，切換速度秒級；切換時可通過運行指定指令碼更改商務服務狀態。

如兩台主機A、B，可以實現如下切換：

1．A 、B 依次啟動，A作為主、B為從

2 .主A 掛掉，B接管業務，作為主

3.A 起來，作為從SLAVEOF B

4.B 掛掉，A 切回主

將一台全部作為主，即可實現主從，可做讀寫分離；也可以通過多個VIP，在一台機器上多個執行個體中一半主、一半從，實現互備份，兩機同時負責部分業務，一台宕機後業務都集中在一台上

安裝配置都比較簡單：

　　需要依賴包：openssl-devel（ubuntu 中為 libssl-dev),popt-devel （ubuntu中為libpopt-dev）。

　　設定檔預設路徑：/etc/keepalived/keepalived.conf 也可以手動指定路徑，不過要注意的是手動指定需要使用絕對路徑。主要要確保設定檔的正確性，keepalived 不會檢查配置是否符合規則。

　　使用keepalived -D 運行，即可啟動3個守護進程：一個父進程，一個check健全狀態檢查，一個Vrrp，-D將日誌寫入/var/log/message，可以通過日誌查看切換狀況。

注意問題：

1. VRRP 協議是組播協議，需要保證主、備、VIP 都在同一個VLAN下

2. 不同的VIP 需要與不同的VRID 對應，一個VLAN 中VRID 不能和其他組衝突

3. 在keepalived 有兩個角色：Master(一個)、Backup（多個），如果設定一個為Master，但Master掛了後再起來，必然再次業務又一次切換，這對於具狀態服務是不可接受的。解決方案就是兩台機器都設定為Backup，而且優先順序高的Backup設定為nopreemt 不搶佔。

 5. 通過keepalived實現的高可用方案

 

切換流程：

1. 當Master掛了後，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one ,開始提供業務

2. 當Master起來後，VIP 位址不變，Master的keepalived 通知redis 執行slaveof slave IP host ，開始作為從同步資料

3. 依次類推

主從同時Down機情況：

1. 非計劃性，不做考慮，一般也不會存在這種問題

2. 、計劃性重啟，重啟之前通過營運手段SAVE DUMP 主庫資料；需要注意順序：

1. 關閉其中一台機器上所有redis，是得master全部切到另外一台機器（多執行個體部署，單機上既有主又有從的情況）；並關閉機器

2. 依次dump主上redis服務

3. 關閉主

4. 啟動主，並等待資料load完畢

5. 啟動從

刪除DUMP 檔案（避免重啟載入慢）

 

6. 使用Twemproxy 實現叢集方案

一個由twitter開源的c版本proxy，同時支援memcached和redis，目前最新版本為：0.2.4，持續開發中;https://github.com/twitter/twemproxy .twitter用它主要減少前端與快取服務間網路連接數。

特點：快、輕量級、減少後端Cache Server串連數、易配置、支援ketama、modula、random、常用hash 分區演算法。

這裡使用keepalived實現高可用主備方案，解決proxy單點問題；

優點：

1. 對於用戶端而言，redis叢集是透明的，用戶端簡單，遍於動態擴容

2. Proxy為單點、處理一致性hash時，叢集節點可用性檢測不存在腦裂問題

3. 高效能，CPU密集型，而redis節點叢集多CPU資源冗餘，可部署在redis節點叢集上，不需要額外裝置

 

7 . 一致性hash

使用zookeeper 實現一致性hash。

redis服務啟動時，將自己的路由資訊通過臨時節點方式寫入zk，用戶端通過zk client讀取可用的路由資訊。

 

具體實現見我另外一篇：redis 一致性hash

 8 . 監控工具

曆史redis執行查詢：CPU、記憶體、命中率、請求量、主從切換等

即時監控曲線

簡訊警示

使用基於開源Redis Live 修改工具，便於批量執行個體監控，基礎功能都已實現，細節也將逐步完善。

源碼地址如下：

https://github.com/LittlePeng/redis-monitor

http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html

Redis 叢集方案