1、redis 持久化機制redis 提供了兩種持久化策略RDBRDB 的持久化策略： 按照規則定時講內從的數據同步到磁盤snapshotredis 在指定的情況下會觸發快照1.自己配置的快照規則save save 900 1當在 900 秒內被更改的key 的數量大于 1 的時候，就執行快照save 300 10save 60 100002.save 或者bgsavesave: 執行內存的數據同步到磁盤的操作，這個操作會阻塞客戶端的請求bgsave: 在異步執行快照操作，這個操作不會阻塞客戶端的請求3.執行 flushall 的時候清除內存的所有數據，只要快照的規則不為空，也就是第一個規則存在。

2、那么redis 會執行快照4. 執行的時候快照的實現原理1：redis 使用 fork 函數一份當前進程的副本(子進程)2：父進程繼續接收并處理客戶端發來令，而子進程開始將內存中的數據寫入硬盤中的臨時文件3：進程寫入完所有數據后會用該臨時文件替換舊的 RDB文件，至此，一次快照操作完成。注意：redis 在進行快照的過程中不會修改RDB 文件，只有快照結束后才會將舊的文件替換成新的，也就是說任何時候 RDB文件都是完整的。 這就使得可以通過定時備份 RDB 文件來實現redis 數據庫的備份， RDB 文件是經過壓縮的二進制文件，占用的空間會小于內存中的數據，更加利于傳輸。RDB 的優缺點使用

3、RDB 方式實現持久化，一旦Redis 異常退出，就會丟失最后一次快照以后更改的所有數據。這個時候就需要根據具體的應用場景，通過組合設置自動快照條 件的方式來將可能發生的數據損失控制在能夠接受范圍。如果數據相對來說比較重要，希望將損失降到最小，則 可以使用 AOF 方式進行持久化RDB 可以最大化Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無序執行任何磁盤 I/O 操作。同時這個也是一個缺點，如果數據集比較大的時候，fork 可以能比較耗時，造成服務器在一段時間內停止處理客戶端的請求；實踐修改redis

4、.conf 中的 appendonly yes ; 重啟后執行對數據的變更命令， 會在 bin 目錄下生成對應的.aof 文件， aof 文件中會所有的操作命令如下兩個參數可以去對aof 文件做優化auto-aof-rewrite-percentage 100表示當前 aof 文件大小超過上一次aof 文件大小的百分之多少的時候會進行重寫。如果之前沒有重寫過，以啟動時aof 文件大小為準auto-aof-rewrite-min-size 64mb限制允許重寫最小 aof 文件大小，也就是文件大小小于 64mb 的時候，不需要進行優化AOFAOF 可以將Redis 執行的每一條寫命令追加到硬盤文

5、件中，這一過程顯然會降低 Redis 的性能，但大部分情況下這個影響是能夠接受的，另外使用較快的硬盤可以提高 AOF 的性能實踐默認情況下 Redis 沒有開啟 AOF（append only file）方式的持久化，可以通過 appendonly 參數啟用，在 redis.conf中找到 appendonly yes開啟 AOF 持久化后每執行一條會更改 Redis 中的數據令后，Redis 就會將該命令寫入硬盤中的 AOF 文件。AOF文件的保存位置和 RDB 文件的位置相同，都是通過 dir 參數設置的，默認的文件名是 ndonly.aof. 可以在redis.conf 中的屬性 app

6、endfilename appendonlyh.aof 修改aof 重寫的原理Redis 可以在 AOF 文件體積變得過大時，自動地在對AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令 追加到現有的 AOF 文件里面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建 完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并 開始對新 AOF 文件進行追加操作。AOF 文件有序地保存 了對數據庫執行的所有寫入操作， 這些寫入操作

7、以 Redis協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕松同步磁盤數據redis 每次更改數據的時候，aof 機制都會講命令到aof 文件，但是實際上由于操作系統的緩存機制，數據并沒有實時寫入到硬盤，而是進入硬盤緩存。再通過硬盤緩存機制去刷新到保存到文件# appendfsync always每次執行寫入都會進行同步， 這個是最安全但是是效率比較低的方式appendfsync everysec每一秒執行# appendfsync no不主動進行同步操作，由操作系統去執行，這個是最快但是最不安全的方式aof 文件損壞以后如何修復服務器可能在程

8、序正在對 AOF 文件進行寫入時停機， 如果停機造成了 AOF 文件出錯（corrupt），那么 Redis 在重啟時會載入這個 AOF 文件， 從而確保數據的一致性不會被破壞。當發生這種情況時， 可以用以下方法來修復出錯的 AOF文件：為現有的 AOF 文件創建一個備份。使用 Redis 附帶的 redis-check-aof 程序，對原來的AOF 文件進行修復。redis-check-aof -fix重啟 Redis 服務器，等待服務器載入修復后的 AOF 文件，并進行數據恢復。RDB 和 AOF ,如何選擇一般來說,如果對數據的安全性要求非常高的話，應該同時使用兩種持久化功能。如果可以承

9、受數分鐘以內的數據丟失，那么可以只使用 RDB 持久化。有很多用戶都只使用AOF 持久化， 但并不這種方式： 因為定時生成 RDB快照（snapshot）非常便于進行數據庫備份， 并且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快 。兩種持久化策略可以同時使用，也可以使用其中一種。如果同時使用的話， 那么 Redis 重啟時，會優先使用AOF 文件來還原數據集群（master、slave）配置過程修改 11.140 和 11.141 的redis.conf 文件，增加 slaveof masteripmastortslaveof 192.168.11.138 6379實現原理1. s

10、lave 第一次或者重連到 master 上以后，會向 master 發送一個SYNC令2. master 收到SYNC 的時候，會做兩件事a) 執行bgsave（rdb 的快照文件）b) master 會把新收到的修改命令存入到緩沖區缺點沒有辦法對master 進行動態的方式1.基于rdb 文件的（第一次連接或者重連的時候）2.無硬盤3.增量PSYNC master run id. offset哨兵機制sentinel1.master 和salve 是否正常運行2. 如果master 出現故障，那么會把其中一臺 salve 數據升級為master集群（redis3.0 以后的功能）根據key

11、 的hash 值取模 服務器的數量 。hash集群的原理Redis Cluster 中，Sharding 采用 slot(槽)的概念，一共分成16384 個槽，這有點兒類似前面講的 pre sharding 思路。對于每個進入 Redis 的鍵值對，根據 key 進行散列，分配到這 16384 個 slot 中的某一個中。使用的 hash 算法也比較簡單，就是 CRC16 后 16384 取模。Redis 集群中的每個 node(節點)負責分攤這 16384 個 slot 中的一部分，也就是說，每個 slot 都對應一個 node 負責處理。當動態添加或減少 node 節點時，需要將 1638

12、4 個槽做個再分配，槽中的鍵值也要遷移。當然，這一過程，在目前實現中，還處于半自動狀態，需要人工介入。Redis 集群，要保證 16384 個槽對應的 node 都正常工作，如果某個 node 發生故障，那它負責的 slots 也就失效，整個集群將不能工作。為了增加集群的可性，的方案是將 node 配置成主從結構，即一個 master 主節點，掛 n 個 slave 從節點。這時，如果主節點失效，Redis Cluster 會根據算法從 slave 節點中選擇一個上升為主節點，整個集群繼續對外提供服務。這非常類似服務器節點通過Sentinel架主從結構，只是Redis Cluster 本身提供了故障轉移容錯的能力。slot（槽）的概念，在redis 集群中一共會有 16384 個槽，根據 key 的 CRC16 算法，得到的結果再對 16384 進行取模。假3 個節點node10 5460node25461 10922node310923 16383節點新增node40-1364,5461-6826,10923-12287刪除節點先將節點的數據移動到其他節點上，然后才能執行刪除市面上提供了集群方案1.redis sharddi