APP
文章目錄
一、 主從數(shù)據(jù)一致性
1. 主多從少
主從網(wǎng)絡延遲時，主多從少情況下，進行部分重同步。
場景簡述：主多從少就是在網(wǎng)絡延遲的情況下，從服務器尚未把主服務器的數(shù)據(jù)全部復制過來。
解決方案：
第一種：這時，我們可以等延遲結束之后，讓從服務器進行部分重同步，就是我們說增量復制。
第二種：如果比較著急，向讓他立刻執(zhí)行重同步，需要任務干預。在從節(jié)點輸入
就可以實現(xiàn)部分重同步
第三種：人為斷開讓從節(jié)點和主節(jié)點重新建立連接，也會觸發(fā)部分重同步。
2. 主少從多
主少從多情況下，進行全量復制。
場景簡述(主少從多)：這種情況是從服務器開啟了寫的操作導致的，也就是我們的從服務器是讀寫模式，當從從服務器寫入，就會導致主從不一致。
解決方案:
把從服務器數(shù)據(jù)清空，讓從服務器和主服務器重新建立連接，進行去哪量數(shù)據(jù)復制即可。
3. 知識點補充
在redis2.8版本之前，如果從節(jié)點和主節(jié)點斷開重新連接，從節(jié)點就會全量復制，這無疑是一個降低性能的問題。
為了解決這個問題，redis在2.8版本之后，添加了一個特性；我們主從斷開重連的時候，可以進行一個邏輯判斷處理，來判斷從節(jié)點進行全量復制還是增量復制？
其實就是我們的主服務器在內(nèi)存中為每一個從服務器都維護了一個同步日志和同步標識，這三個同步日志就是backlog ，這個同步標識就是offset，每個從服務器在跟主服務器進行同步的時候，會攜帶同步標識和上次同步的位置，這樣就會判斷出這個復制，要做全量復制還是增量復制。
二、 數(shù)據(jù)延遲
2.1. 數(shù)據(jù)延遲因素
數(shù)據(jù)延遲，根據(jù)那些配置或者屬性決定的。在info replication返回的信息中有一個偏移量，其實，就是根據(jù)這個偏移量來決定當前數(shù)據(jù)的一個健康狀態(tài)，數(shù)據(jù)是否有延遲，我們的主節(jié)點在寫入命令的時候，比如：我寫入3000字節(jié)的一個偏移量，此時，我們的從節(jié)點只復制了1000，他們的差值比較大的時候，就說明數(shù)據(jù)延遲就很高了。
2.2. 解決方案
1.編寫外部程序監(jiān)聽主從節(jié)點的復制偏移量，延遲較大時發(fā)出報警或者通知客戶端，切換到主節(jié)點或者其他節(jié)點。
2設置從節(jié)點???slave-serve-stale-data??為no 除INFO SLAVEOF命令之外的任何請求都會返回一個錯誤“SYNC with master in progress”
三、 臟數(shù)據(jù)
3.1. 臟數(shù)據(jù)產(chǎn)生的場景
- 惰性：現(xiàn)在有一個key已經(jīng)過期了，現(xiàn)在沒有人活著客戶端訪問，就不會刪除這個過期的key；在訪問的時候在判斷這個key是否過期，過期了就會刪除，導致一個過期的key如果不被訪問就會永遠存在內(nèi)存中。
- 定時：解決惰性缺點，內(nèi)部有一個定時任務，隔一段時間就會判斷一批key是否過期，過期了就刪除掉。
- 主動刪除：當前數(shù)據(jù)存儲超過了redia的存儲上限，然后，觸發(fā)主動刪除，正是因為rerdis刪除機智的原因?qū)е掠信K數(shù)據(jù)的產(chǎn)生。
從節(jié)點可寫導致的，從節(jié)點一般都是只讀模式，如果你開啟了讀寫模式，這個數(shù)據(jù)從從節(jié)點誤寫入，可能導致產(chǎn)生臟數(shù)據(jù)。
3.2. 解決方案
- 忽略：比如：12306查詢票，雙11查詢庫存，當你去查詢這些信息的時候，我并沒有去做一個寫操作，這樣業(yè)務場景允許你出現(xiàn)一定的的錯誤，有一定的容錯。我么可以選擇忽略。
- 強制讀主：當我們買一張車票，下單呢？秒殺搶購這個商品，這個時候數(shù)據(jù)一定要是準確的，我們可以采用強制讀主的方式，從節(jié)點間接變?yōu)榱藗浞莘掌?某個業(yè)務)
- 從節(jié)點只讀：規(guī)避從節(jié)點寫入臟數(shù)據(jù)
目前redis6.x之后，讀取數(shù)據(jù)之前檢查鍵過期時間來決定是否返回數(shù)據(jù)
四、 數(shù)據(jù)安全性
4.1. 場景
關閉主節(jié)點持久化會提升性能，同時會帶來復制的安全性問題。
4.2. 解決方案
主節(jié)點不自動重啟，不是用shell腳本手段監(jiān)控主節(jié)點自動觸發(fā)重啟
五、 規(guī)避全量復制
5.1. 低峰時段
第一次全量復制解決方案：低峰時段掛載slave節(jié)點，比如：晚上12點
5.2. 主節(jié)點變更
選舉slave為主節(jié)點
待補充
5.3. 增大復制緩沖區(qū)
六、 規(guī)避復制風暴
5.1. 單主節(jié)點
單主節(jié)點復制風暴：主節(jié)點重啟，從節(jié)點全量復制
解決方案：
選舉slave為主節(jié)點、樹狀復制結構
5.2. 單機多主
單機多主復制風暴：一臺機器，多個主節(jié)點(樹狀復制架構)
解決方案：把主節(jié)點分散在多臺機器上
本文摘自 ：https://blog.51cto.com/g
