共計 1613 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章主要介紹“redis 的場景應用有哪些”，在日常操作中，相信很多人在 redis 的場景應用有哪些問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”redis 的場景應用有哪些”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

主從模式

主從模式的應用場景有點類似于數據庫的主從集群，主從往往是為了讀寫分離、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 等

那么我們最終的集群結構大致如下：

到此，關于“redis 的場景應用有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！