主結(jié)點(diǎn)

在非集群環(huán)境的情況下，使用redis主從模式來(lái)保證業(yè)務(wù)的高可用性册踩，因此在此種模式下帘睦，讀寫都在主機(jī)，要保證主機(jī)高性能必須在主機(jī)上盡量少的IO操作同時(shí)又要兼顧網(wǎng)絡(luò)導(dǎo)致的主從斷鏈而帶來(lái)的頻繁的fullsync音诫，因此針對(duì)主機(jī)優(yōu)化要點(diǎn)如下：

關(guān)閉主結(jié)點(diǎn)aof

關(guān)閉主aof比較簡(jiǎn)單，可以通過(guò)如下命令進(jìn)行關(guān)閉雪位，在主結(jié)點(diǎn)上執(zhí)行
config set appendonly no

關(guān)閉主結(jié)點(diǎn)save

關(guān)閉主上的save原因是避免save的規(guī)則導(dǎo)致的bgsave而引起業(yè)務(wù)波動(dòng)竭钝，bgsave是非常消耗性能的，redis的默認(rèn)save規(guī)則為" 900 1 "," 300 10 ","," 60 10000 ",在此規(guī)則下寫入量大的情況下會(huì)導(dǎo)致主機(jī)頻繁的bgsave而導(dǎo)致性能急劇下降雹洗，可以通過(guò)命令config set save關(guān)閉主機(jī)上因?qū)懭攵|發(fā)的bgsave香罐，數(shù)據(jù)的完整性交給備機(jī)完成，即使這樣也無(wú)法完全杜絕bgsave时肿，在從機(jī)第一連上來(lái)或者從機(jī)斷開過(guò)久的情況下還是會(huì)觸發(fā)bgsave

主從同步后key數(shù)量不一致問(wèn)題

因?yàn)閞edis只會(huì)在主上進(jìn)行定期key淘汰并命令傳播到從機(jī)庇茫，因此在key數(shù)量很多而且很多key又帶有過(guò)期時(shí)間的情況下，因?yàn)樘蕴瓩C(jī)制問(wèn)題會(huì)導(dǎo)致主從同步后從機(jī)的key數(shù)量和主機(jī)的key數(shù)量不一致（過(guò)期的key不會(huì)同步到從機(jī)）
最根本原因是主機(jī)在在serverCron函數(shù)中進(jìn)行淘汰的時(shí)候一次默認(rèn)只會(huì)淘汰20個(gè)key
默認(rèn)值在redis.h中#define ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 /* Loopkups per loop. */
解決該問(wèn)題的方式一是修改該數(shù)量重新編譯螃成，二是修改redis.conf中的hz屬性旦签，加快serverCron執(zhí)行頻率

發(fā)送緩沖區(qū)滿導(dǎo)致主從斷開頻繁fullsync問(wèn)題

redis為每一個(gè)鏈接的客戶端維護(hù)了一個(gè)發(fā)送緩沖區(qū)，并限定了大写绾辍（有軟硬之分）宁炫，當(dāng)發(fā)送緩沖區(qū)滿后（超過(guò)了設(shè)定的值）redis即會(huì)斷開該鏈接從而實(shí)現(xiàn)自我保護(hù)功能
但是問(wèn)題也出現(xiàn)了，當(dāng)寫入量非常大的時(shí)候而該值又設(shè)置的不合理會(huì)導(dǎo)致主從頻繁斷連
而且因?yàn)閷懭肓烤薮笮逻B接上來(lái)的從機(jī)不能進(jìn)行部分同步而觸發(fā)全量同步
為了避免該問(wèn)題可以根據(jù)redis實(shí)際的寫入數(shù)據(jù)以及網(wǎng)絡(luò)情況綜合來(lái)修改參數(shù)client-output-buffer-limit氮凝，具體修改多大要結(jié)合實(shí)際寫量和網(wǎng)絡(luò)情況而定羔巢，設(shè)置方式為：

config set client-output-buffer-limit "slave 4295000768 4295000768 0"

slave 表示從機(jī)鏈接，普通客戶端為normal，發(fā)布訂閱客戶端為：pubsub

復(fù)制積壓緩沖區(qū)repl-backlog-size

復(fù)制積壓緩沖區(qū)緩存了最近的寫命令竿秆，在有從機(jī)鏈接的時(shí)候創(chuàng)建启摄，該緩沖區(qū)大小默認(rèn)為1M，改值決定了從機(jī)斷開在重新鏈接上來(lái)后是全量同步還是部分同步幽钢，如果復(fù)制偏移量在復(fù)制積壓緩沖區(qū)內(nèi)為部分同步歉备，小于或者大于復(fù)制積壓緩沖區(qū)那么就行全量同步，可以根據(jù)實(shí)際情況通過(guò)config set 命令重新設(shè)定repl-backlog-size

節(jié)點(diǎn)死活判定

在高可用系統(tǒng)中搅吁，節(jié)點(diǎn)的死活檢查非常重要威创，檢測(cè)邏輯要快速發(fā)現(xiàn)問(wèn)題并迅速切換落午，檢測(cè)手段也是多重多樣谎懦， redis檢測(cè)節(jié)點(diǎn)死活采用了進(jìn)程探測(cè)加服務(wù)ping的方式進(jìn)行，進(jìn)程探測(cè)是為了確認(rèn)目標(biāo)進(jìn)程存在溃斋，但是目標(biāo)進(jìn)程存在也不一定確認(rèn)服務(wù)可用界拦，所以另加了去ping指定服務(wù)節(jié)點(diǎn)的方式。

在實(shí)際使用過(guò)程中發(fā)現(xiàn)某些節(jié)點(diǎn)會(huì)奇怪的進(jìn)行切換梗劫，而去看機(jī)器的內(nèi)存享甸、網(wǎng)絡(luò)、以及IO都很低梳侨，除了某些CPU核在切換的時(shí)刻被跑滿蛉威，然后分析切換節(jié)點(diǎn)的slowlog發(fā)現(xiàn)，用戶在那個(gè)時(shí)間點(diǎn)提交了耗時(shí)高達(dá)幾分鐘的查詢走哺，因?yàn)閞edis是單線程處理蚯嫌，因?yàn)槟骋粋€(gè)耗時(shí)高的命令而導(dǎo)致了ping超時(shí)導(dǎo)致了切換，優(yōu)化邏輯就是適當(dāng)增加ping的耗時(shí)和增加ping的次數(shù)丙躏，這個(gè)過(guò)程中也要有所取舍择示，即要很快的發(fā)現(xiàn)問(wèn)題，又不能因?yàn)楦吆臅r(shí)命令而誤判進(jìn)行切換