redis的場景應用多角度簡單分析

redis的應用場景很多，不管是在資料儲存還是分散式鎖等方面，本篇文章主要對主從、哨兵、分片叢集做一個簡單的分析，不會講的太深。

redis的應用場景很多，不管是在資料儲存還是分散式鎖等方面，本篇文章主要對主從、哨兵、分片叢集做一個簡單的分析，不會講的太深。

主從模式的應用場景有點類似於資料庫的主從叢集，主從往往是為了讀寫分離、backup 等目的才使用的，所謂主從模式簡單的說就是有多個節點，裡面包含主節點和從節點，結構如下圖：

從節點在保持連線後每隔一個時間節點會主動的和主節點通訊併傳送同步請求，而後進行同步。

其實在整個流程中，最需要主要的就是資料間的同步，主要的同步方式有兩種也就是全量同步和增量同步。

全量同步：全量同步一般使用在從節點剛接入主節點時進行全量複製，當然你也可以根據你的需求進行主動的全量同步

增量同步：Redis增量複製是指從節點初始化後開始正常工作時主伺服器發生的寫操作同步到從伺服器的過程。 增量複製的過程主要是主伺服器每執行一個寫 命令就會向從伺服器傳送相同的寫 命令，從伺服器接收並執行收到的寫命令，一般使用緩衝區、佇列(先進先出)等方式輔助進行增量的同步。

哨兵模式是為了保證redis的高可用產生的架構，簡單地說就是通過構建1個或多個哨兵對節點進行監控，如果master發生故障下線之後，哨兵之間會進行投票，在2.8之後使用的是Raft演算法進行master選舉，關於這個演算法其實這個演算法也應用於zookeeper和某些網路拓撲中，簡單說就是在選舉的過程可通訊節點達成共識後那個投票選舉master，而後進行故障轉移操作。

哨兵是作為一個程式單獨執行在redis中，哨兵之間也是通過該程式進行通訊的，這一點和zookeeper的原理也是類似的，假設一個6節點3個哨兵的叢集的結構應該如下圖：

那麼哨兵是如何監控master下線的呢?

前面也有看到哨兵之間會進行叢集的檢測和哨兵之間的互相監測，但是哨兵不用做什麼配置，因為哨兵巧妙的利用了master的釋出/訂閱機制去自動發現其它也監控了統一master的sentinel節點，在監測master方面一般分為兩種：

主觀下線(Subjectively Down， 簡稱 SDOWN)指的是單個 Sentinel 例項對伺服器做出的下線判斷。

客觀下線(Objectively Down， 簡稱 ODOWN)指的是多個 Sentinel 例項在對同一個伺服器做出 SDOWN 判斷， 並且通過命令互相交流之後， 得出的伺服器下線判斷。 一個 Sentinel 可以通過向另一個 Sentinel 傳送命令來詢問對方是否認為給定的伺服器已下線。

在上面的部分不管redis主從，還是高可用的 sentinel 哨兵模式。我們所做的這些工作只是保證了資料備份以及高可用，目前為止我們的程式一直都是向1臺redis寫資料，其他的redis只是備份而已。在實際使用中一般分片叢集使用較多，我為什麼要特意強調是分片叢集呢，其實上面所說的主從和哨兵都是叢集但是他們都是備份式的叢集，實際資料是由一臺進行控制的，所謂分片其實是將不同的資料按照一定的分佈規則分佈在不同的機器上

在redis中，我們的應用在存取資料的時候需要根據一定的演算法(一致性hash)進行計算和存取 ，那麼在redis中如何實現資料分片的呢? 首先Redis至少存在三個資料分片，每個分片稱為master，假設整個cluster有N個節點，那麼每個節點都和其他N-1個節點保持連線和心跳，節點之間相互通訊主要確認節點是否存活、節點的資料版本、投票選擇新的master等

那麼我們最終的叢集結構大致如下：

原文連結： https://www.linuxprobe.com/application-scenarios-redis.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2657870/，如需轉載，請註明出處，否則將追究法律責任。