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