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