redis筆記3

redis持久化機制

redis提供了兩種持久化策略

RDB

RDB的持久化策略： 按照規則定時將內存的數據同步到磁盤

snapshot

redis在指定的狀況下會觸發快照

1. 本身配置的快照規則

save <seconds> <changes>

默認配置規則

save 900 1  當在900秒內被更改的key的數量大於1的時候，就執行快照

save 300 10

save 60 10000

1. 手動執行save或者bgsave

save: 執行內存的數據同步到磁盤的操做，這個操做會阻塞客戶端的請求

bgsave: 在後臺異步執行快照操做，這個操做不會阻塞客戶端的請求

1. 執行flushall的時候

清除內存的全部數據，只要快照的規則不爲空，也就是第一個規則存在。那麼redis會執行快照

1. 執行復制的時候

快照的實現原理

1：redis使用fork函數複製一份當前進程的副本(子進程)

2：父進程繼續接收並處理客戶端發來的命令，而子進程開始將內存中的數據寫入硬盤中的臨時文件

3：當子進程寫入完全部數據後會用該臨時文件替換舊的RDB文件，至此，一次快照操做完成。  

 注意：redis在進行快照的過程當中不會修改RDB文件，只有快照結束後纔會將舊的文件替換成新的，也就是說任什麼時候候RDB文件都是完整的。 這就使得咱們能夠經過定時備份RDB文件來實現redis數據庫的備份， RDB文件是通過壓縮的二進制文件，佔用的空間會小於內存中的數據，更加利於傳輸。

RDB的優缺點

1. 使用RDB方式實現持久化，一旦Redis異常退出，就會丟失最後一次快照之後更改的全部數據。這個時候咱們就須要根據具體的應用場景，經過組合設置自動快照條件的方式來將可能發生的數據損失控制在可以接受範圍。若是數據相對來講比較重要，但願將損失降到最小，則可使用AOF方式進行持久化
2. RDB能夠最大化Redis的性能：父進程在保存RDB文件時惟一要作的就是fork出一個子進程，而後這個子進程就會處理接下來的全部保存工做，父進程無序執行任何磁盤I/O操做。同時這個也是一個缺點，若是數據集比較大的時候，fork能夠能比較耗時，形成服務器在一段時間內中止處理客戶端的請求；

實踐

修改redis.conf中的appendonly yes ; 重啓後執行對數據的變動命令， 會在bin目錄下生成對應的.aof文件， aof文件中會記錄全部的操做命令

以下兩個參數能夠去對aof文件作優化

auto-aof-rewrite-percentage 100  表示當前aof文件大小超過上一次aof文件大小的百分之多少的時候會進行重寫。若是以前沒有重寫過，以啓動時aof文件大小爲準

auto-aof-rewrite-min-size 64mb   限制容許重寫最小aof文件大小，也就是文件大小小於64mb的時候，不須要進行優化

AOF

AOF能夠將Redis執行的每一條寫命令追加到硬盤文件中，這一過程顯然會下降Redis的性能，但大部分狀況下這個影響是可以接受的，另外使用較快的硬盤能夠提升AOF的性能

實踐

默認狀況下Redis沒有開啓AOF（append only file）方式的持久化，能夠經過appendonly參數啓用，在redis.conf中找到 appendonly yes

開啓AOF持久化後每執行一條會更改Redis中的數據的命令後，Redis就會將該命令寫入硬盤中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是經過dir參數設置的，默認的文件名是apendonly.aof. 能夠在redis.conf中的屬性 appendfilename appendonlyh.aof修改

aof重寫的原理

Redis 能夠在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操做是絕對安全的，由於 Redis 在建立新 AOF 文件的過程當中，會繼續將命令追加到現有的 AOF 文件裏面，即便重寫過程當中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件建立完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操做。AOF 文件有序地保存了對數據庫執行的全部寫入操做， 這些寫入操做以 Redis 協議的格式保存， 所以 AOF 文件的內容很是容易被人讀懂， 對文件進行分析（parse）也很輕鬆

同步磁盤數據

redis每次更改數據的時候， aof機制都會講命令記錄到aof文件，可是實際上因爲操做系統的緩存機制，數據並無實時寫入到硬盤，而是進入硬盤緩存。再經過硬盤緩存機制去刷新到保存到文件

# appendfsync always  每次執行寫入都會進行同步  ， 這個是最安全可是是效率比較低的方式

appendfsync everysec   每一秒執行

# appendfsync no  不主動進行同步操做，由操做系統去執行，這個是最快可是最不安全的方式

aof文件損壞之後如何修復  

服務器可能在程序正在對 AOF 文件進行寫入時停機， 若是停機形成了 AOF 文件出錯（corrupt）， 那麼 Redis 在重啓時會拒絕載入這個 AOF 文件， 從而確保數據的一致性不會被破壞。

當發生這種狀況時， 能夠用如下方法來修復出錯的 AOF 文件：

1. 爲現有的 AOF 文件建立一個備份。
2. 使用 Redis 附帶的 redis-check-aof 程序，對原來的 AOF 文件進行修復。

redis-check-aof --fix

重啓 Redis 服務器，等待服務器載入修復後的 AOF 文件，並進行數據恢復。

RDB 和 AOF ,如何選擇

通常來講,若是對數據的安全性要求很是高的話，應該同時使用兩種持久化功能。若是能夠承受數分鐘之內的數據丟失，那麼能夠只使用 RDB 持久化。有不少用戶都只使用 AOF 持久化， 但並不推薦這種方式： 由於定時生成 RDB 快照（snapshot）很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快 。

兩種持久化策略能夠同時使用，也可使用其中一種。若是同時使用的話， 那麼Redis重啓時，會優先使用AOF文件來還原數據

 

集羣

複製（master、slave）

 

配置過程

修改11.140和11.141的redis.conf文件，增長slaveof masterip masterport

增長這條slaveof 192.168.11.138 6379 就能將redis服務器設爲slave從服務器

在客戶端中輸入info replication 查看服務器狀態

實現原理

1. slave第一次或者重連到master上之後，會向master發送一個SYNC的命令
2. master收到SYNC的時候，會作兩件事

a)   執行bgsave（rdb的快照文件）

b)   master會把新收到的修改命令存入到緩衝區

缺點
沒有辦法對master進行動態選舉

複製的方式

1. 基於rdb文件的複製（第一次鏈接或者重連的時候）
2. 無硬盤複製
3. 增量複製

PSYNC master run id. offset

哨兵機制

sentinel

1. 監控master和salve是否正常運行
2. 若是master出現故障，那麼會把其中一臺salve數據升級爲master

集羣（redis3.0之後的功能）

根據key的hash值取模 服務器的數量 。

hash

集羣的原理

Redis Cluster中，Sharding採用slot(槽)的概念，一共分紅16384個槽，這有點兒相似前面講的pre sharding思路。對於每一個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一箇中。使用的hash算法也比較簡單，就是CRC16後16384取模。Redis集羣中的每一個node(節點)負責分攤這16384個slot中的一部分，也就是說，每一個slot都對應一個node負責處理。當動態添加或減小node節點時，須要將16384個槽作個再分配，槽中的鍵值也要遷移。固然，這一過程，在目前實現中，還處於半自動狀態，須要人工介入。Redis集羣，要保證16384個槽對應的node都正常工做，若是某個node發生故障，那它負責的slots也就失效，整個集羣將不能工做。爲了增長集羣的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。這時，若是主節點失效，Redis Cluster會根據選舉算法從slave節點中選擇一個上升爲主節點，整個集羣繼續對外提供服務。這很是相似服務器節點經過Sentinel監控架構成主從結構，只是Redis Cluster自己提供了故障轉移容錯的能力。

 

slot（槽）的概念，在redis集羣中一共會有16384個槽，

根據key 的CRC16算法，獲得的結果再對16384進行取模。 假若有3個節點

node1  0 5460

node2  5461 10922

node3  10923 16383

節點新增

node4  0-1364,5461-6826,10923-12287

刪除節點

先將節點的數據移動到其餘節點上，而後才能執行刪除

 

市面上提供了集羣方案

1. redis shardding   並且jedis客戶端就支持shardding操做  SharddingJedis ； 增長和減小節點的問題； pre shardding

3臺虛擬機 redis 。可是我部署了9個節點 。每一臺部署3個redis增長cpu的利用率

9臺虛擬機單獨拆分到9臺服務器

1. codis基於redis2.8.13分支開發了一個codis-server
2. twemproxy  twitter提供的開源解決方案