http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html
根據一些測試整理出來的一份方案：
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.修改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 修改工具，便於批量實例監控，基礎功能都已實現，細節也將逐步完善。
源碼地址如下：