http://www.tuicool.com/articles/n6VzMf2
redis是一款高性能的內存數據庫，本文側重描述redis在主從模式下遇到的一些問題以及如何調優，特別是在云環境下遇到的一些特殊問題，至于redis如何使用以及數據結構等，可以百度，網上有大量的資料。
主結點
在非集群環境的情況下，使用redis主從模式來保證業務的高可用性，因此在此種模式下，讀寫都在主機，要保證主機高性能必須在主機上盡量少的IO操作同時又要兼顧網絡導致的主從斷鏈而帶來的頻繁的fullsync，因此針對主機優化要點如下：
關閉主結點aof
關閉主aof比較簡單，可以通過如下命令進行關閉，在主結點上執行
config set appendonly no
關閉主結點save
關閉主上的save原因是避免save的規則導致的bgsave而引起業務波動，bgsave是非常消耗性能的，redis的默認save規則為" 900 1 "," 300 10 ","," 60 10000 ",在此規則下寫入量大的情況下會導致主機頻繁的bgsave而導致性能急劇下降，可以通過命令 config set save 關閉主機上因寫入而觸發的bgsave，數據的完整性交給備機完成，即使這樣也無法完全杜絕bgsave，在從機第一連上來或者從機斷開過久的情況下還是會觸發bgsave
主從同步后key數量不一致問題
因為redis只會在主上進行定期key淘汰并命令傳播到從機，因此在key數量很多而且很多key又帶有過期時間的情況下，因為淘汰機制問題會導致主從同步后從機的key數量和主機的key數量不一致（過期的key不會同步到從機），而最根本原因是主機在在serverCron函數中進行淘汰的時候一次默認只會淘汰20個key，默認值在 redis.h 中 #define ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 /* Loopkups per loop. */定義，解決該問題的方式一是修改該數量重新編譯，而是修改redis.conf中的hz屬性，加快serverCron執行頻率
發送緩沖區滿導致主從斷開頻繁fullsync問題
redis為每一個鏈接的客戶端維護了一個發送緩沖區，并限定了大?。ㄓ熊浻仓郑?，當發送緩沖區滿后（超過了設定的值）redis即會斷開該鏈接從而實現自我保護功能，但是問題也出現，當寫入量非常大的時候而該值又設置的不合理會導致主從頻繁斷連，而且因為寫入量巨大新連接上來的從機不能進行部分同步而觸發全量同步，因此為了避免該問題可以根據redis實際的寫入數據以及網絡情況綜合來修改參數 client-output-buffer-limit ，具體修改多大要結合實際寫量和網絡情況而定，設置方式為：
config set client-output-buffer-limit "slave 4295000768 4295000768 0" slave 表示從機鏈接，普通客戶端為normal，發布訂閱客戶端為：pubsub
復制積壓緩沖區repl-backlog-size
復制積壓緩沖區緩存了最近的寫命令，在有從機鏈接的時候創建，該緩沖區大小默認為1M，改值決定了從機斷開在重新鏈接上來后是全量同步還是部分同步，如果復制偏移量在復制積壓緩沖區內為部分同步，小于或者大于復制積壓緩沖區那么就行全量同步，可以根據實際情況通過config set 命令重新設定repl-backlog-size
節點死活判定
在高可用系統中，節點的死活檢查非常重要，檢測邏輯要快速發現問題并迅速切換，檢測手段也是多重多樣， redis檢測節點死活采用了進程探測加服務ping的方式進行，進程探測是為了確認目標進程存在，但是目標進程存在也不一定確認服務可用，所以另加了去ping指定服務節點的方式，在實際使用過程中發現某些節點會奇怪的進行切換，而去看機器的內存、網絡、以及IO都很低，除了某些CPU核在切換的時刻被跑滿，然后分析切換節點的slowlog發現，用戶在那個時間點提交了耗時高達幾分鐘的查詢，因為redis是單線程處理，因為某一個耗時高的命令而導致了ping超時導致了切換，優化邏輯就是適當增加ping的耗時和增加ping的次數，這個過程中也要有所取舍，即要很快的發現問題，又不能因為高耗時命令而誤判進行切換
從結點
從結點主要用來保證數據安全性，并在主結點死掉后快速恢復成主結點并提供服務，在作為從結點的時候需要打開rdb和aof，并按照一定的時間規則把用戶的rdb放入到冷備中心，
在提升為主節點后，相關設置要立刻恢復到和主節點一樣的配置