redis持久化

全部內容來自《redis實戰》

1. rdb持久化

1. bgsave 會調用有一個fork來建立一個子進程，而後子進程負責將快照寫進磁盤，而父進程則繼續處理命令請求。
2. 使用save命令的話，服務器會在快照處理完以前，不會再接收新的命令 ，是一個阻塞操做。
3. save 60 10000 會從最近一次快照算起，60秒內有10000寫入 就會自動觸發bgsave命令。 若是配置了多個save選項，只要知足條件就會執行bgsave。
4. 若是從服務器發起sync操做的話，主服務器沒有bgsave操做，或者並不是剛剛執行完bgsave操做，那麼主服務器就會執行一次bgsave操做。

若是系統真的發生崩潰，用戶將會丟失最近一次快照以後更改的全部數據。所以快照適用於那些即便丟失一部分數據也不會形成問題的應用程序，那系誒不能接受丟數據的， 不該考慮這種類型。

若是打算用快照持久化，最好將服務器運行在於生產服務器相同或者類似的機器上面，使用相同的save配置。

由於bgsave會形成卡頓，能夠考慮經過手動來執行bgsave和save命令。能夠控制卡頓發生的時間，能夠選擇在低峯來執行。能夠經過腳原本定時執行。

2. aof持久化

有三種選擇
always 每一個寫命令，都要同步到磁盤。
everysec 每秒來執行一次。
no 讓操做系統櫃來決定應該什麼時候來進行同步

選擇每秒來執行的話，能夠將損失降到1秒，這種模式和不使用持久化特性相差無幾。當硬盤寫數據的時候，redis還會優雅地放慢本身的速度以適應硬盤的最大寫速度。

由操做系統選擇來執行的話，通常不會對性能形成影響，可是系統奔潰的話，將致使使用這種選項的服務器丟失不定量的數據。另外，若是用戶的磁盤處理寫入操做的速度不夠快的話，那麼當緩衝區被等待寫入磁盤的數據填滿時，redis的寫入操做會被阻塞，並致使redis處理命令請求的速度變慢。

3. aof的缺陷

由於redis一直在寫命令的話，會致使aof的文件愈來愈大。極端狀況下回用完硬盤的空間。由於redis在重啓以後須要從新執行aof文件記錄的寫命令來還原數據集，若是文件特別大， 那麼還原操做作執行的時間可能就會很是長。

使用bgrewriteaof 會經過移除aof中的重複命令來重邪惡aof文件，使aof文件儘量的小。
auto-aof-rewrite-min-size 64m
auto-aof-rewrite-percentage 100
當aof的文件大小大於64m，而且aof文件的體積比上一次重寫以後的體積大了至少一倍，redis將執行bgrewriteaof命令。

複製

複製 可讓其餘服務器擁有一個不斷更新的數據副本，從而使得擁有數據副本的服務器能夠用於處理客戶端發送的讀請求。

redis經過ip地址和端口號來鏈接主服務器，對於一個正在運行的redis服務器，用戶能夠經過slaveof no one 來讓服務器終止複製操做，不在接受主服務器的數據更新，也能夠經過slaveof host port來讓服務器開始複製一個新的主服務器。

複製過程：

1. 創建鏈接， 先發送rdb，而後發送緩衝區數據，而後每次執行新的寫命令，也都會同步給從服務器。

判斷是否已經將已知全部的數據都保存到硬盤裏面了，能夠查看info aof_pending_bio_fsync 的值是否爲0.

系統故障處理

redis-check-aof 會刪除出錯的命令以及其後面的命令，保留出錯以前的命令。
Usage: redis-check-aof [--fix] <file.aof>
redis-check-dump 查看快照文件的狀態。
Usage: redis-check-dump <dump.rdb>

更換故障主服務器

A主服務器，B從服務器當A掛掉以後更換計劃：首先向機器B發送一個save命令，讓他建立一個新的快照文件，接着將這個快照文件發送給C，並在c上面啓動redis，最後讓機器B成爲機器C的從服務器。