針對Redis主從復制

引言：對于使用Redis服務器存儲數據的大型網站來說，如果僅僅使用一臺Redis服務器的話，不僅數據存儲速度得不到保證，而且存在很大的風險，一旦該機出現問題（例如數據丟失，磁盤損壞等），就會對網站運行造成不利影響。搭建Redis服務器集群，可以很好的解決該問題。如果主服務器宕機，只需簡單修改Redis配置文件，就可以讓從服務器擔當數據管理任務。

Redis的持久化模式

從運維角度上看，需要了解Redis的持久化概念。持久化指的是將數據存儲到斷電后不會丟失的設備中，例如將內存中的數據保存到硬盤中等。Redis支持RDB和AOF兩種持久化方式。對于前者來說，是基于內存快照的持久化方式，其工作原理是每隔幾分鐘或者幾次寫操作后，在某一瞬間從內存DUMP數據形成RDB文件，并將其壓縮保存到指定的目錄。因為其存儲的是整體內存鏡像數據，所以在恢復時速度很快。RDB的配置信息保存在“redis.conf”文件中。

執行“vim redis.conf”命令，其中的“save 900 1”行表示在 900秒內，如果有1條寫入則產生快照。

“save 300 1000”行的作用是如果300秒內有1000次數據寫入則產生快照。“save 60 10000”行的作用是如果在60秒內有10000次數據寫入則產生快照。如果將以上三行配置全部屏蔽，則禁用RBD快照功能。

“stop-writes-onbgsave-error”行的作用是當后臺備份進程出錯時，主進程是否停止寫入，“yes”表示確認，“no”表示否認。

“rdbcompression”行的作用是是否對導出的rdb文件進行壓縮。

“Rdbchecksum”行的作用是當導入rbd鏡像進行數據恢復時，是否檢驗rdb的完整性。

“dbfilename”行的作用是指定導出的rdb文件名，“dir”行的作用是指定rdb文件的存儲路徑，默認放置在當前路徑。當Redis服務器運行出現故障時（例如斷電等），當重啟Redis服務時，其會自動從RDB文件中恢復數據。

使用RDB快照實現數據持久化，存在一個明顯的問題。因為其只能在指定的時間間隔內對從內存中DUMP數據形成RDB鏡像文件，如果在前一個快照完成但后一個快照沒有創建之間突然斷電，這期間的數據顯然無法保存。

為了實現更加精細的持久化，Redis提供了AOF日志記錄功能，可以將所有的操作命令記錄下來形成日志文件，這樣即使Redis出現異常情況，也可以利用日志進行數據的快速恢復。當然，RDB和AOF兩種方案可以并存。

執行“vim redis.conf”命令，將“appendonly”行的值設置為“yes”，表示啟用AOF功能，在“appendfilename”欄中可以更改日志文件存儲路徑。在“appendfsync”欄中設置同步方式，設置為“always”，表示將每一個命令都立即同步到aof日志中。設置為“everysec”表示每秒同步一次，設置為“no”，表示將入同步工作交給操作系統處理，由操作系統判斷緩沖區大小并統一寫入到aof日志文件中，其特點是同步頻率低但速度快。

在“no-appendfsync-onrewrite”欄中設置當正在導出rdb快照的過程中是否停止同步aof日志，在“autoaof-rewrite-percentage 100”欄中設置aof日志重寫條件，如果當前的aof文件大小比上次重寫時的大小增長率100%時，則執行重寫操作。

重寫是指把內存中的數據，逆化成命令寫入到aof日志中。之所執行重寫，為的是避免在aof日志中存儲大量的冗余數據。例如對某個變量累加了100次，如果執行重寫操作，則只記錄最有一次計算結果。利用重寫機制，可以大大減小aof文件的體積。在“auto-aofrewrite-min-size”欄中設置執行重寫操作時，aof的最小體積。默認為64MB，即當aof文件大于64MB時，必須執行重寫操作。

當啟動AOF日志記錄功能后，當Rides服務出現異常，當重啟Redis服務后，可以發現數據得到很好的恢復。同RDB快照機制相比，AOF的數據恢復速度較慢，因為RDB是數據的內存映射，直接載入到內存，而aof是命令記錄需要逐條執行。

搭建Redis群集

一般來說，Redis群集結構包括星形和線形等類型。對于前者來說，多臺Slave服務器共同為一臺Master服務器提供服務。對于后者來說，多臺Slave服務器之間也存在著從屬關系，例如當 Master宕 機 后，Slave1服務器可以變為主服務器，Slave2自動變為其從服務器。

要想搭建Redis集群，必須了解集群的主從通信原理，即主動服務器之間是如何進行同步的。當Slave服務器啟動后，確定了其從屬的Master服務器，其會自動連接到Master主機，并發出同步請求，Master主機通過Dump操作從內存中抓取RDB鏡像，并將其該RDB鏡像傳送給Slave主機，Slave主機直接在內存中恢復該鏡像，這樣兩者的內存數據實現了同步。

當 然，Master主 機 的Redis中的命令和數據是不斷變化的，這些數據會緩存到內存中的AOF隊列中，之后將AOF數據同步到Slave主機上。這樣，就實現了主從復制操作。以后當Mater主機數據發生變動后，就會通過ReplicationFeedSlaves進程通知Slave主機及時進行同步。

在本例中，使用了星形的群集結構，一臺名為Master的服務器，兩臺名稱分別為Slave1和Slave2的從服務器。在這三臺主機上都安裝好Redis。

在Slave1上 執 行“vim redis.conf” 命 令，打開其配置文件，在其中的“dbfilename”欄中可以更改RDB文件的存儲路徑。刪除“slave of ”一行前面的“#”字符，激活其從服務器功能，并將其修改為“slave of 192.168.1.10 6379”，其 中 的“192.168.1.10”為Master服務器的IP，TCP 6379為通訊端口。在“slave-read-only” 行 中確保其值 為“yes”，即 讓Slave1處于只讀狀態。將“appendonly”行的值修改為“no”，禁止其執行AOF日志功能。其余的設置保持不變，保存該配置文件。在Slave2上執行同樣的命令，對Redis配置文件進行同樣的修改，所不同的是，需要將其中的“save 900”，“save 300 10”，“save 60 3000”等 行的前面添加“#”符號，將其屏蔽掉，這樣就關閉了其RDB功能，即不允許其抓起內存快照。

因為創建RDB快照比較消耗IO資源，既然Slave1已經默認開啟了創建RDB快照的功能，Slave2就沒有必要執行相同的操作了。這樣，兩臺從服務器就配置完成了。對于Master服務器來說，執行“vim redis.conf”命令，按照同樣的方法，禁用RDB功能，因為創建RDB快照的功能已經交由Slave1完成。在主從服務器上分別執行“./bin/redisserver redis.conf”命令，來啟動Redis服務。這樣，Redis群集就已經開始運作了。之后可以對其進行測試，在Master上 執 行“./bin/redis-cli”命令，連接完成后，執行“set name xxx”命令，創建一個Key變量。當連接到上述Slave服務器，執行“keys *”命令，可以發現上面建立的Key值。

但是，當試圖在從服務器上對指定的Key值進行修改時，系統會顯示“(error)Readonly You cant’t write against a read only slave”內容，禁止執行寫操作，防止主從服務器之間出現數據不一致的情況。由此看出，Redis群集的搭建可謂簡單，對于Master服務器來說，可以關閉RDB快照功能，將數據備份工作交給從服務器完成，可以根據需要開啟AOF日志功能。

對于Slave從服務器來說，需要聲明其從屬身份，針對某個Slave主機開啟RDB快照功能，并將其設置為只讀功能。

為了提高安全性，可以根據需要為群集配置密碼。其方法是在主從服務器上分別打開Redis配置文件，將其中的“requirepass foobared”行前面的“#”符號刪除，激活其密碼保護功能，將默認的“foobared”的密碼修改為所需的密碼。

設置了密碼后，當連接到主Redis服務器后，需要執行“Auth xxxx”命令，其中的“xxxx”表示具體的密碼，授權通過后，才可以執行各種指令。對于從服務器來說，則直接使用該密碼和主服務器進行通訊。

對于Redis群集來說，其實際上是存在某些缺陷的。即當Slave主機因為各種原因和主服務器斷開后，當其再次連接Master主機時，都要再次通過Dump操作從Master主機內存中抓取RDB鏡像，并將其該RDB鏡像傳送給Slave主機，Slave主機直接在內存中恢復該鏡像。同時將Master主機上AOF數據同步到Slave主機上。

在這種情況下，不要將所有的Slave服務器全部啟動起來，否則很可能導致Master主機的IO吞吐量劇增，處理方法是分時逐臺啟動Slave服務器，以降低Master主機的工作壓力。