對於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網卡跑滿,速度受網卡速度限制
處理速度與包大小大概關系如下:
2. Redis 持久化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消耗、業務量。如果多實例是為了提高處理能力,需要注意配置網卡軟中斷均衡,否則處理能力也無法提升。
3. 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對外提供服務完全無任何影響。
4. keepalived 簡介因為目前版本沒有mysql 主從那樣的增量備份,對網路穩定性要求很高,如果頻繁TCP連接斷開會對服務器和網絡帶來很大負擔。
就目前生產環境主從機器部署同一個機架下,幾個月都不會又一次連接斷開重連的情況的。
參考官方文檔: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,可以通過日志查看切換狀況。
5. 通過keepalived實現的高可用方案注意問題:
1. VRRP 協議是組播協議,需要保證主、備、VIP 都在同一個VLAN下
2. 不同的VIP 需要與不同的VRID 對應,一個VLAN 中VRID 不能和其他組沖突
3. 在keepalived 有兩個角色:Master(一個)、Backup(多個),如果設置一個為Master,但Master掛了後再起來,必然再次業務又一次切換,這對於有 狀態服務是不可接受的。解決方案就是兩台機器都設置為Backup,而且優先級高的Backup設置為nopreemt 不搶占。
切換流程:
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 文件(避免重啟加載慢)
7 . 一致性hash一個由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節點集群上,不需要額外設備
8 . 監控工具使用zookeeper 實現一致性hash。
redis服務啟動時,將自己的路由信息通過臨時節點方式寫入zk,客戶端通過zk client讀取可用的路由信息。
具體實現見我另外一篇:redis 一致性hash
歷史redis運行查詢:CPU、內存、命中率、請求量、主從切換等
實時監控曲線
短信報警
使用基於開源Redis Live 修改工具,便於批量實例監控,基礎功能都已實現,細節也將逐步完善。
源碼地址如下:
https://github.com/LittlePeng/redis-monitor