Redis持久化之RDB
RDB 即快照持久化方式，把redis當前某一時刻的數據全部存入磁盤當中。存在的問題，當redis在下一次快照執行點發生的時候崩潰，會造成數據的丟失，這是不可避免的
RDB 持久化的觸發方式
- 手動觸發 線上採用bgsave方式
- 自動觸發 通過在redis.conf 中進行配置save m n
例如 save 60 1000 即60秒內如果有1000次寫入就進行RDB持久化需要注意的bgsave，理論上是redis創建了一個子進程進行存儲邏輯，但現實場景中，bgsave也會導致redis的系統發生停頓。取決於硬件，數據量等因素。
例如：虛擬機場景下，redis每佔用一個GB內存，創建子進程會耗費200～300毫秒，
AOF 持久化
將被執行的寫命令寫到AOF文件的末尾，以此來記錄數據的變化
AOF的執行流程：
- 命令追加：將Redis的寫命令追加到緩衝區aof_buf
- 文件寫入和文件同步 根據不同的同步策略將內容刷寫到硬盤中
- 文件重寫 定期重寫AOF文件，達到壓縮的目的
總結：通過以上學習，我們都知道，如果是單個redis的實例，不管開啓哪個持久化的操作，在數據量極大的情況下，由於需要創建子進程，對redis服務的整體性能或多或少都會帶來影響。因此，我們爲了保證redis服務的高可用，一般會使用redis的複製特性
複製
所謂的複製功能，即橫向擴展redis的性能，通過主從服務架構，減少數據丟失的風險
2.8版本以前的主從複製流程分爲兩步驟：
- 從服務器會發送Sync命令給到主服務器（RDB的形式保持一致）
- Sync同步完成後，會進行命令傳播
注意：Sync命令是一個耗費資源的操作，所以redis有必要保證在真正有需要時才執行sync命令
新版本複製功能PSYNC
有兩個模式：
- 完整重同步 和Sync一致
- 部分重同步 用於主從服務器兩者斷線後的同步
實現原理
概念一 複製偏移量
主從服務器會維護一套自己複製偏移量，當兩邊的複製偏移量不相等，則肯定是出現了斷線等異常問題。那麼就會考慮進行部分重同步。
概念二 複製積壓緩衝區
由主服務器維護的一個固定長度先進先出FIFO隊列，默認大小爲1MB
- 複製積壓緩衝區的數據結構：FIFO 先進先出的隊列
- 主服務器再進行命令傳播的時候，會同時往復制積壓緩衝區中寫數據
- 複製積壓緩存區的每個字節值都會對應一個偏移量。正式有這個數據結構，給最後執行什麼同步方式提供了參考依據
概念三 服務器運行ID
即每個服務器運行的時候都會存在一個運行ID，從服務器再連接上主服務器的時候，會記錄下當前連接的主服務器的服務器運行ID。
當斷線重連的情況下，會進行判斷，重新連接的服務器是否是上一次的服務器運行ID
參考文章
redis 設計與實現第二版
redis 實戰