Redis單機(jī)主從高可用性優(yōu)化是怎樣的

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

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

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

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

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

關(guān)閉主aof比較簡單，可以通過如下命令進(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ù)波動，bgsave是非常消耗性能的，redis的默認(rèn)save規(guī)則為" 900 1 "," 300 10 ","," 60 10000 ",在此規(guī)則下寫入量大的情況下會導(dǎo)致主機(jī)頻繁的bgsave而導(dǎo)致性能急劇下降，可以通過命令config set save關(guān)閉主機(jī)上因?qū)懭攵|發(fā)的bgsave，數(shù)據(jù)的完整性交給備機(jī)完成，即使這樣也無法完全杜絕bgsave，在從機(jī)第一連上來或者從機(jī)斷開過久的情況下還是會觸發(fā)bgsave

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

因為redis只會在主上進(jìn)行定期key淘汰并命令傳播到從機(jī)，因此在key數(shù)量很多而且很多key又帶有過期時間的情況下，因為淘汰機(jī)制問題會導(dǎo)致主從同步后從機(jī)的key數(shù)量和主機(jī)的key數(shù)量不一致（過期的key不會同步到從機(jī)），而最根本原因是主機(jī)在在serverCron函數(shù)中進(jìn)行淘汰的時候一次默認(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為每一個鏈接的客戶端維護(hù)了一個發(fā)送緩沖區(qū)，并限定了大?。ㄓ熊浻仓郑?dāng)發(fā)送緩沖區(qū)滿后（超過了設(shè)定的值）redis即會斷開該鏈接從而實(shí)現(xiàn)自我保護(hù)功能，但是問題也出現(xiàn)，當(dāng)寫入量非常大的時候而該值又設(shè)置的不合理會導(dǎo)致主從頻繁斷連，而且因為寫入量巨大新連接上來的從機(jī)不能進(jìn)行部分同步而觸發(fā)全量同步，因此為了避免該問題可以根據(jù)redis實(shí)際的寫入數(shù)據(jù)以及網(wǎng)絡(luò)情況綜合來修改參數(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ī)鏈接的時候創(chuàng)建，該緩沖區(qū)大小默認(rèn)為1M，改值決定了從機(jī)斷開在重新鏈接上來后是全量同步還是部分同步，如果復(fù)制偏移量在復(fù)制積壓緩沖區(qū)內(nèi)為部分同步，小于或者大于復(fù)制積壓緩沖區(qū)那么就行全量同步，可以根據(jù)實(shí)際情況通過config set 命令重新設(shè)定repl-backlog-size

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

在高可用系統(tǒng)中，節(jié)點(diǎn)的死活檢查非常重要，檢測邏輯要快速發(fā)現(xiàn)問題并迅速切換，檢測手段也是多重多樣， redis檢測節(jié)點(diǎn)死活采用了進(jìn)程探測加服務(wù)ping的方式進(jìn)行，進(jìn)程探測是為了確認(rèn)目標(biāo)進(jìn)程存在，但是目標(biāo)進(jìn)程存在也不一定確認(rèn)服務(wù)可用，所以另加了去ping指定服務(wù)節(jié)點(diǎn)的方式，在實(shí)際使用過程中發(fā)現(xiàn)某些節(jié)點(diǎn)會奇怪的進(jìn)行切換，而去看機(jī)器的內(nèi)存、網(wǎng)絡(luò)、以及IO都很低，除了某些CPU核在切換的時刻被跑滿，然后分析切換節(jié)點(diǎn)的slowlog發(fā)現(xiàn)，用戶在那個時間點(diǎn)提交了耗時高達(dá)幾分鐘的查詢，因為redis是單線程處理，因為某一個耗時高的命令而導(dǎo)致了ping超時導(dǎo)致了切換，優(yōu)化邏輯就是適當(dāng)增加ping的耗時和增加ping的次數(shù)，這個過程中也要有所取舍，即要很快的發(fā)現(xiàn)問題，又不能因為高耗時命令而誤判進(jìn)行切換

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

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

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

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