redis：持久化和主從複製
Redis持久化
Redis 提供了2個不同形式的持久化方式。
-
RDB（ Redis DataBase）
-
AOF（Append Of File）
RDB
RDB是什麼
在指定的時間間隔內將記憶體中的資料集快照寫入磁碟， 也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡
- RDB是如何執行的
Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到 一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。 整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能 如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失
-
Fork
-
Fork的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等） 數值都和原程序一致，但是是一個全新的程序，並作為原程序的子程序
-
在Linux程式中，fork()會產生一個和父程序完全相同的子程序，但子程序在此後多會exec系統呼叫，出於效率考慮，Linux中引入了“寫時複製技術”
-
一般情況父程序和子程序會共用同一段實體記憶體，只有程序空間的各段的內容要發生變化時，才會將父程序的內容複製一份給子程序。
-
RDB的優勢
-
適合大規模的資料恢復
-
對資料完整性和一致性要求不高更適合使用
-
節省磁碟空間
-
恢復速度快
RDB的劣勢
-
Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮
-
雖然Redis在fork時使用了寫時拷貝技術,但是如果資料龐大時還是比較消耗效能。
-
在備份週期在一定間隔時間做一次備份，所以如果Redis意外down掉的話，就會丟失最後一次快照後的所有修改。
redis備份
先通過config get dir 查詢rdb檔案的目錄
將*.rdb的檔案拷貝到別的地方
rdb的恢復
-
關閉Redis
-
先把備份的檔案拷貝到工作目錄下 cp dump2.rdb dump.rdb
-
啟動Redis, 備份資料會直接載入
AOF(Append Of File)
- AOF是什麼
以日誌的形式來記錄每個寫操作（增量儲存），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)， 只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重新構建資料，換言之，redis 重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作
- AOF預設不開啟
可以在redis.conf中配置檔名稱，預設為 appendonly.aof
AOF檔案的儲存路徑，同RDB的路徑一致。
- AOF和RDB同時開啟，redis聽誰的？
AOF和RDB同時開啟，系統預設取AOF的資料（資料不會存在丟失）
- AOF檔案的修復
如遇到AOF檔案損壞，通過/usr/local/bin/redis-check-aof--fix appendonly.aof進行恢復
cd usr/local/bin/redis/
redis-check-aof --fix appendonly.aof
AOF持久化流程
- 客戶端的請求寫命令會被append追加到AOF緩衝區內；
- AOF緩衝區根據AOF持久化策略[always,everysec,no]將操作sync同步到磁碟的AOF檔案中；
- always：始終同步，每次Redis的寫入都會立刻記入日誌；效能較差但資料完整性比較好
- everysec：每秒同步，每秒記入日誌一次，如果宕機，本秒的資料可能丟失。
- no：每秒同步，每秒記入日誌一次，如果宕機，本秒的資料可能丟失。
- AOF檔案大小超過重寫策略或手動重寫時，會對AOF檔案rewrite重寫，壓縮AOF檔案容量；
- rewrite重寫的條件：初始基準值為64MB，達到基準值的100%進行重寫，將命令進行整合。
例如：檔案達到70MB開始重寫，降到50MB，下次什麼時候開始重寫？100MB
系統載入時或者上次重寫完畢時，Redis會記錄此時AOF大小，設為base_size,
如果Redis的AOF當前大小>= base_size +base_size*100% (預設)且當前大小>=64mb(預設)的情況下，Redis會對AOF進行重寫。
- Redis服務重啟時，會重新load載入AOF檔案中的寫操作達到資料恢復的目的；
優勢：
-
備份機制更穩健，丟失資料概率更低。
-
可讀的日誌文字，通過操作AOF穩健，可以處理誤操作。
劣勢：
-
比起RDB佔用更多的磁碟空間。
-
恢復備份速度要慢。
-
每次讀寫都同步的話，有一定的效能壓力。
-
存在個別Bug，造成恢復不能。
用哪個好
官方推薦兩個都啟用。
如果對資料不敏感，可以選單獨用RDB。
不建議單獨用 AOF，因為可能會出現Bug。
如果只是做純記憶體快取，可以都不用。
主從複製
- 主從複製是什麼
主機資料更新後根據配置和策略， 自動同步到備機的master/slaver機制，Master以寫為主，Slave以讀為主
-
主從複製能幹嘛
- 讀寫分離，效能擴充套件
- 容災快速恢復（當一臺伺服器壞掉了，可以快速切換到其其他伺服器。主從複製是一主多從。）
操作
- 建立多個配置檔案進行一些修改
- 啟動三個redis服務
進入redis可以使用命令檢視當前主機狀態
info replication
在從機上使用命令
slaveof
slaveof 127.0.0.1 6379
info replication
將6380和6381變為從機。此時的主機狀態：
主機寫，從機讀。不能使用從機進行寫的操作！
(error) READONLY You can't write against a read only replica.
shutdowd問題
- 主伺服器掛掉
從伺服器仍然是從伺服器，並且知道主服務掛掉。當主伺服器重新連線，主伺服器仍然可以檢視到兩個從伺服器
- 從伺服器掛掉
從伺服器重新連線後變為主伺服器，當從伺服器重新變為主伺服器期間，如果主伺服器想資料庫從存值，從伺服器也能獲取。
原理：
-
Slave啟動成功連線到master後會傳送一個sync命令
-
Master接到命令啟動後臺的存檔程序，同時收集所有接收到的用於修改資料集命令， 在後臺程序執行完畢之後，master將傳送整個資料檔案到slave,以完成一次完全同步
-
全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中。
-
增量複製：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步
-
但是隻要是重新連線master,一次完全同步（全量複製)將被自動執行
薪火相傳模式
使用一種鏈的結構：主——從——從。
缺點：中間的從機掛掉，就可能會直接癱瘓。
反客為主模式
當主機掛掉，選擇其中的一個從機成為主機。
使用命令
slaveof no one
缺點：仍然需要手動的進行操作。
哨兵模式
哨兵模式是反客為主模式的增強版。當主機掛掉後，哨兵會監測到，然後哨兵就行選舉，選舉一個從機成為新的主機。老的主機重新連線後，會變為新主機的從機。
- 配置哨兵，建立sentinel.conf
cd /myredis/
vi sentinel.conf
- 填寫內容
sentinel monitor mymaster 127.0.0.1 6379 1
# 其中mymaster為監控物件起的伺服器名稱， 1 為至少有多少個哨兵同意遷移的數量。
- 啟動哨兵
redis-sentinel /myredis/sentinel.conf
選舉的規則、
- 選擇優先順序靠前的從機
在redis.conf中有一個叫做replica-priority的欄位控制著優先順序，數字越小，優先順序越高
- 選擇偏移量最大的從機
哪一個從機和主機的資料最接近，就選擇誰
- 選擇runid最小的從機
每個redis例項啟動後都會隨機生成一個40位的runid