根據一些測試整理出來的一份方案：
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 . 監控工具
來源 http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html歷史redis執行查詢：CPU、記憶體、命中率、請求量、主從切換等
實時監控曲線
簡訊報警
使用基於開源Redis Live 修改工具，便於批量例項監控，基礎功能都已實現，細節也將逐步完善。
原始碼地址如下：