redis單機(jī)主從高可用性?xún)?yōu)化是怎樣的，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

創(chuàng)新互聯(lián)是少有的網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、營(yíng)銷(xiāo)型企業(yè)網(wǎng)站、成都小程序開(kāi)發(fā)、手機(jī)APP,開(kāi)發(fā)、制作、設(shè)計(jì)、買(mǎi)鏈接、推廣優(yōu)化一站式服務(wù)網(wǎng)絡(luò)公司,成立與2013年,堅(jiān)持透明化,價(jià)格低,無(wú)套路經(jīng)營(yíng)理念。讓網(wǎng)頁(yè)驚喜每一位訪(fǎng)客多年來(lái)深受用戶(hù)好評(píng)

redis是一款高性能的內(nèi)存數(shù)據(jù)庫(kù)，本文側(cè)重描述redis在主從模式下遇到的一些問(wèn)題以及如何調(diào)優(yōu)，特別是在云環(huán)境下遇到的一些特殊問(wèn)題，至于redis如何使用以及數(shù)據(jù)結(jié)構(gòu)等，可以百度，網(wǎng)上有大量的資料。

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

在非集群環(huán)境的情況下，使用redis主從模式來(lái)保證業(yè)務(wù)的高可用性，因此在此種模式下，讀寫(xiě)都在主機(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ī)則下寫(xiě)入量大的情況下會(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ī)斷開(kāi)過(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ū)滿(mǎn)導(dǎo)致主從斷開(kāi)頻繁fullsync問(wèn)題

redis為每一個(gè)鏈接的客戶(hù)端維護(hù)了一個(gè)發(fā)送緩沖區(qū)，并限定了大?。ㄓ熊浻仓郑?，當(dāng)發(fā)送緩沖區(qū)滿(mǎn)后（超過(guò)了設(shè)定的值）redis即會(huì)斷開(kāi)該鏈接從而實(shí)現(xiàn)自我保護(hù)功能，但是問(wèn)題也出現(xiàn)，當(dāng)寫(xiě)入量非常大的時(shí)候而該值又設(shè)置的不合理會(huì)導(dǎo)致主從頻繁斷連，而且因?yàn)閷?xiě)入量巨大新連接上來(lái)的從機(jī)不能進(jìn)行部分同步而觸發(fā)全量同步，因此為了避免該問(wèn)題可以根據(jù)redis實(shí)際的寫(xiě)入數(shù)據(jù)以及網(wǎng)絡(luò)情況綜合來(lái)修改參數(shù)client-output-buffer-limit，具體修改多大要結(jié)合實(shí)際寫(xiě)量和網(wǎng)絡(luò)情況而定，設(shè)置方式為：
config set client-output-buffer-limit "slave 4295000768 4295000768 0"
slave 表示從機(jī)鏈接，普通客戶(hù)端為normal，發(fā)布訂閱客戶(hù)端為：pubsub

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

復(fù)制積壓緩沖區(qū)緩存了最近的寫(xiě)命令，在有從機(jī)鏈接的時(shí)候創(chuàng)建，該緩沖區(qū)大小默認(rèn)為1M，改值決定了從機(jī)斷開(kāi)在重新鏈接上來(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í)刻被跑滿(mǎn)，然后分析切換節(jié)點(diǎn)的slowlog發(fā)現(xiàn)，用戶(hù)在那個(gè)時(shí)間點(diǎn)提交了耗時(shí)高達(dá)幾分鐘的查詢(xún)，因?yàn)閞edis是單線(xiàn)程處理，因?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)行切換

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

從結(jié)點(diǎn)主要用來(lái)保證數(shù)據(jù)安全性，并在主結(jié)點(diǎn)死掉后快速恢復(fù)成主結(jié)點(diǎn)并提供服務(wù)，在作為從結(jié)點(diǎn)的時(shí)候需要打開(kāi)rdb和aof，并按照一定的時(shí)間規(guī)則把用戶(hù)的rdb放入到冷備中心，

在提升為主節(jié)點(diǎn)后，相關(guān)設(shè)置要立刻恢復(fù)到和主節(jié)點(diǎn)一樣的配置

看完上述內(nèi)容，你們掌握Redis單機(jī)主從高可用性?xún)?yōu)化是怎樣的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！