一、簡介

Redis是一個基於鍵值（K-V）的快取記憶體軟體，和他具有相同功能的軟體有memcached，但其支援更為複雜的資料結構，例如：List,set,sorted set,同時redis具有永續性功能。redis究竟是什麼？對於不同的應用場合，對redis的理解也不相同，如下有三種不同的理解。  

    ①key value store(鍵值儲存),是一個以鍵值形式儲存的資料庫，用來作為唯一的儲存系統，同時藉助於sentinel實現一定意義上的高可用。

    ②memory cached(記憶體快取),是一個把資料儲存在記憶體中的快取記憶體，在應用中用來實現高效的響應使用者請求。

    ③data structrue server(資料結構服務),支援對複雜資料庫結構的高速操作例如：list,string,hash,set,stored等，提供某特殊業務操作。

redis的優勢：

    ①豐富的操作，例如：hash,list,set,stored,sets.

    ②內建複製(replication)及其叢集(cluster)

    ③就地更新操作，而無需停機重啟生效

    ④支援持久快取，常用的有RDB和AOF

基本架構圖：  

原理：redis工作時，將啟動一個fork函式建立一個子程序，複製當前程序，存為副本，父程序任然接受並處理客服端請求，而子程序則將記憶體中的資料檔案寫入磁碟中的臨時檔案，當子程序完成所有的寫入操作時會將原來的件替換成最新生成的臨時檔案。

二、redis永續性介紹

redis永續性分為兩種：RDB(Redis datebase)和AOF(append only file),同時，RDB和AOF可同時使用，但BGSAVE和BGWRITEAOF不會同時執行，在redis伺服器啟動用於恢復資料時將會優先使用AOF。持久的功能是用於恢復，但持久本身不能取代備份，還應該制定備份策略，對redis進行資料庫備份，保證資料的完整性。

RDB:此方式基於快照實現，該持久化方式是在redis內部有一個定時器，每隔固定時間去檢查當前資料發生改變的次數與時間是否滿足配置的永續性觸發的條件，如果滿足則通過作業系統啟動一個fork函式呼叫來創建出一個字程序，這個子程序預設會與父程序共享相同的地址空間，這時就可以通過子程序來遍歷整個記憶體來進行儲存操作，而主程序則仍然可以提供服務，當有寫入時由作業系統按照記憶體頁(page)為單位來進行copy-on-write保證父子程序之間不會互相影響。該持久化的主要缺點是定時快照只是代表一段時間內的記憶體映像，所以系統重啟會丟失上次快照與重啟之間所有的資料。

編輯/etc/redis.conf可檢視相應的配置引數及其意義

AOF:redis主程序通過fork建立子程序，子程序根據redis記憶體中的資料庫重構後將此儲存於臨時檔案中，父程序繼承客服端的請求，並會把這些請求中的操作繼續追加至原來的AOF檔案，額外的這些新的寫請求還會被放置於一個緩衝佇列中，父程序把緩衝中的命令寫到臨時檔案中，子程序重寫完成會通知父程序，父程序用臨時檔案替換原來的AOF老檔案。

AOF方式實際類似mysql的基於語句的binlog方式，即每條會使Redis記憶體資料發生改變的命令都會追加到一個log檔案中，也就是說這個log檔案就是Redis的持久化資料。

AOF的方式的主要缺點是追加log檔案可能導致體積過大，當系統重啟恢復資料時如果是aof的方式則載入資料會非常慢，幾十G的資料可能需要幾小 時才能載入完，當然這個耗時並不是因為磁碟檔案讀取速度慢，而是由於讀取的所有命令都要在記憶體中執行一遍。另外由於每條命令都要寫log,所以使用aof 的方式，Redis的讀寫效能也會有所下降。

AOF對日誌檔案的寫入操作時採用追加的模式進行，因此寫入的過程中如果發生斷電，機器宕機等情況發生，也不會對已存在資料檔案造成破壞。

Redis持久化磁碟IO方式及其帶來的問題

有Redis線上運維經驗的人會發現Redis在實體記憶體使用比較多，但還沒有超過實際實體記憶體總容量時就會發生不穩定甚至崩潰的問題，有人認為是基於快照方式持久化的fork系統呼叫造成記憶體佔用加倍而導致的，這種觀點是不準確的，因為fork用的copy-on-write機制是基於作業系統頁這個單位的，也就是隻有有寫入的髒頁會被複制，但是一般你的系統不會在短時間內所有的頁都發生了寫入而導致複製，那麼是什麼原因導致Redis崩潰的呢？

答案是Redis的持久化使用了Buffer IO造成的，所謂Buffer IO是指Redis對持久化檔案的寫入和讀取操作都會使用實體記憶體的Page Cache,而大多數資料庫系統會使用Direct IO來繞過這層Page Cache並自行維護一個數據的Cache，而當Redis的持久化檔案過大(尤其是快照檔案)，並對其進行讀寫時，磁碟檔案中的資料都會被載入到物理內 存中作為作業系統對該檔案的一層Cache,而這層Cache的資料與Redis記憶體中管理的資料實際是重複儲存的，雖然核心在實體記憶體緊張時會做 Page Cache的剔除工作，但核心很可能認為某塊Page Cache更重要，而讓你的程序開始Swap ,這時你的系統就會開始出現不穩定或者崩潰了。我們的經驗是當你的Redis實體記憶體使用超過記憶體總容量的3/5時就會開始比較危險了。

三、redis主從複製

redis主從複製和大部分主從類似，一個master可以有多個slave，支援鏈式複製，master以非阻塞的方式同步資料至slave。啟動一個slave後，slave會向主傳送同步命令，請求同步主庫上的資料，master將啟動一個後臺的子程序，將資料快照儲存至在資料檔案中，把資料檔案傳送給slave，slave將資料檔案儲存至本地中，在本地重建資料庫後載入記憶體，同步完成。   

redis主從的特點：

1、redis使用非同步複製，從伺服器會以每秒一次的頻率向主伺服器報告複製流的處理進度

2、一個主伺服器可以有多個從伺服器，從伺服器也可以有自己的從伺服器(級聯複製)

3、複製功能不會阻塞主伺服器，即使一個或多個從伺服器正在進行初次同步，主伺服器也可以繼續處理命令請求

4、複製功能可以用於資料冗餘，也可以通過讓多個從伺服器處理只讀命令請求來提升擴充套件性

5、Redis從節點預設為只讀，無須手動配置,redis的主從叢集可以實現分擔壓力的效果，但是無法做到高可用，如果master宕掉，服務就不可用了，所以使用redis的sentinel可以實現HA的功能。

主從實戰配置：

編輯/etc/redis.conf配置檔案，將bind改為本機IP地址，重啟服務即可。

主節點相關配置引數如下：

配置node2為從節點，並列印相關資訊

在主中插入資料，檢視從中是否已經同步完成

四、redis高可用管理工具sentinel

Sentinel是一個管理redis例項的工具，它可以對現有的redis進行監控、通知、故障自動轉移，sentinel不斷的檢測redis例項是否可以正常的工作，通過API向其他程式報告redis的轉檯，如redis master不能工作，則會自動啟動故障轉移程序，將其中一個slave提升為master，其他slave將從新設定新的master伺服器，而故障的master再次啟動後會被sentinel自動降級為slave。

基本架構圖：

Sentinel作用如下：

1、監控：sentinel會不斷的檢查你的主伺服器和從伺服器是否執行正常

2、當被監控的某個redis伺服器出現問題時，sentinel可以通過API向管理員或者其他應用程式傳送通知

3、故障自動轉移：當一個主伺服器不能正常工作時，sentinel會開始一次自動故障轉移操作，他會將其中一個從伺服器升級為新的主伺服器，並將其他從伺服器改為複製新的主伺服器；當客戶端試圖連線失效的主伺服器時，叢集也會向客戶端返回新主伺服器的地址，使得叢集可以使用新主伺服器代替失效伺服器。

redis sentinel在監控redis例項時有兩種redis宕機狀態S_DOWN和O_DOWN：

S_DOWN:當sentinel在指定的超時時間內沒有收到一個正確的ping回覆值，則認為是S_DOWN

O_DOWN:O_DOWN的條件是有足夠多的sentinel認為該redis例項是S_DOWN。

注意：O_DOWN只能是發生在主伺服器，sentinel和其他從伺服器不會發生O_DOWN

Sentinel監控管理redis實戰配置：

本實驗在一臺伺服器上可完成實驗，本實驗使用node1附加上面配合的主從完成sentinel高可用測試實驗。

分別使用不同的配置檔案啟動redis服務

使用slaveof命令把主節點設定為本機的6381埠

啟動sentinel監控器節點狀態

模擬redis-server 6381除故障可以將此程序kill掉，檢視主節點是否轉移

檢視redis-server的6380埠是否成為主節點

總結：Redis永續性中的RDB是基於快照方式，意外重啟會丟失資料，而AOF對日誌檔案的寫入操作時採用追加的模式進行，因此寫入的過程中如果發生斷電，機器宕機等情況發生，也不會對已存在資料檔案造成破壞。在考慮資料的完整性可根據自己的業務可同時使用AOF和RDB，保證了資料的完整性，但是redis永續性並不代表備份，還需制定相關的備份方案，對redis已有的資料進行備份。重新啟動Redis，在redis伺服器啟動用於恢復資料時，會優先考慮使用AOF。

來源：http://blog.51cto.com/mageedu/1891255