Redis 簡單HA方案小結

策略摘要

主從各一台互備，不做讀寫分離，備庫只同步，不對外提供服務。主庫無持久化策略，備庫選用rdb。

HA方案

原有cache01做master，無需persistence以便提供最佳讀寫效能。

新申請cache02做slave，persistence採用RDB，同步自cache01的資料，不對外提供服務，僅作為backup。應用指向F5上的VIP，間接調用master。注1：設定檔無論主備統一使用master的配置（除記憶體使用量限制），啟動服務後通過執行相應命令切換到所屬角色。注2：RDB持久化的觸發策略為：A分鐘更新達N條或B分鐘內有更新。啟動命令為 config set save "B 1 A N"；關閉命令為 config set save ""。掛載slave的步驟：1、拷貝master的設定檔，並修改記憶體使用量限制配置項maxmemory。2、啟動slave的redis服務進程，執行命令 slaveof masterIP masterPort進行同步。3、啟動RDB持久化策略。4、執行驗證確認資料同步完畢。若master掛掉，需要執行以下步驟：1、原slave上執行命令  slaveof no one切斷同步並升級為新master2、F5改為指向原slave，以保證應用可繼續對外服務3、恢複原master後，啟動redis服務進程，並執行命令 slaveof 原slaveIP 原slavePort，從而降級為新slave，並從master同步資料。4、關閉master並開啟slave上的rdb，以保證master的讀寫效能。

Q&A

1、為什麼在master中不做持久化，但是在slave中卻要做持久化？slave中的持久化意義是什嗎？答：redis持久化支援兩種模式，RDB（記憶體快照）和AOF（類似於redo log），無論哪種都有一定的效能開銷。在高並發訪問的情況下，RDB模式會使服務的效能指標出現明顯抖動甚至驟停1秒；AOF在效能開銷上比RDB要好，但資料恢複時重新載入到記憶體的時間與資料量成正比。為了讓master有最佳效能表現，可將持久化關閉，因為有主從互備，資料安全不成問題。定期備份有額外的好處，例如可以很方便地將資料復原到某個時間點，也便於線下環境取線上真實資料測試。 2、主從同步的原理使用replication,其意義好像是用於讀寫分離提升效能，而不是災備？答： replication能同時提供災備和讀寫分離，兩者並不衝突。現階段應用程式層面並未給redis造成較大壓力，也就暫未考慮讀寫分離 。其實單機用持久化來災備也是可以的，只是這樣做可用性會差一些（資料重新載入到記憶體類似於PC從休眠狀態恢複需要一點時間），其次極端情況下如果硬碟壞了麻煩就大了。可以肯定的是redis的replication與持久化無關。一旦主從串連從斷開狀態恢複，slave並不關心這是否是第一次串連，始終會執行全量同步。因此正在同步的過程中，slave無法提供與master一致的資料。redis提供兩種策略供slave選擇：響應舊的資料或返回錯誤，提示同步進行中，不同應用對資料一致性有不同的容忍程度，可靈活選擇。