01 redis訂閱發布缺點(Redis哨兵機制原理淺析)

Redis發布訂閱和Stream

發布訂單系統是日常開發中經常會用到的功能。簡單來說，就是發布者發布消息，訂閱者就會接受到消息并進行相應的處理，如下圖所示。

Redis為我們提供了發布/訂閱的功能模塊PubSub，可以用于消息傳遞。

其中發布者publisher、訂閱者subscriber都是redis客戶端，channel則是redis服務器。

發布者publisher向channel發送消息，訂閱該channel的subscriber就會接收到消息。

發布消息publish

訂閱test1、test2的客戶端會收到消息

按照上述這種方式，如果 訂閱者subscriber想要訂閱多個channel 則需要同時指定多個channel的名稱，redis為了解決這個問題提供 psubscribe模式匹配 這種訂閱方式，可以通過通配符的方式匹配頻道。

發布消息

之前訂閱ch*的客戶端就會收到cha頻道和買粉絲頻道的消息，這樣就一次性訂閱多個頻道

redis服務端存儲了訂閱頻道/模式的客戶端列表

相當于如果客戶端訂閱一個頻道 ，那么服務端的 pubsub_channels 就會存儲一條數據， pubsub_channels 其實是一個鏈表，key對應channel，value對應客戶端列表，根據key訂閱的頻道，就可以找到訂閱該頻道的所有客戶端。

同時如果客戶端訂閱一個模式 ， pubsub_patterns 也會新增一條數據，記錄當前客戶端訂閱的模式， pubsub_patterns 也有自己的數據結構，其中就包含了客戶端以及模式。

當發布者向某個頻道發布消息時，就會遍歷 pubsub_channels 找到訂閱該頻道的客戶端列表，依次向這些客戶端發送消息。

然后遍歷 pubsub_patterns 找到符合當前頻道的模式，同時找到模式對應的客戶端，然后向客戶端發送消息。

雖然Redis提供了發布/訂閱的功能，但是并不完善，導致基本沒有合適的場景能夠使用。

PubSub缺點：

直到Redis5.0出現之后，出現了Stream這種數據結構，才終于完善了Redis的消息機制 。

Stream實際上就是一個消息列表，只是他幾乎實現了消息隊列所需要的所有功能，包括：

同時需要注意的是Stream只是一個數據結構，他不會主動把消息推送給消費者，需要消費者主動來消費數據 。

每個Stream都有唯一的名稱，它就是Redis的key，首次使用 xadd 指令追加消息時自動創建。

常見操作命令如下表：

如果客戶端希望知道自身消費到第幾條數據了，那么就需要記錄一下當前消費的消息ID，下次再次消費的時候就從上次消費的消息ID開始讀取數據即可。

消費組中多了一個游標 last_delivered_id ，表示當前消費到了哪一條數據。同時所有的數據都是待處理消息（ PEL ），只有消費者處理完畢之后使用 ack 指令告知redis服務器，數據才會從 PEL 中移除，確認后的消息就無法再次消費。

如果接收到的消息比較多，為了避免Stream過長，可以選擇指定Stream的最大長度，一旦到達了最大長度，就會從最早的消息開始清除，保證Stream中最新的消息。

Redis的優缺點

redis是一個key-value存儲系統，數據存儲在內存中，它的優點主要如下：

redis的缺點主要如下：

Redis哨兵機制原理淺析

上一篇文章Redis主從復制原理中簡要地說明了主從復制的一個基本原理，包含全量復制、復制積壓緩沖區與增量復制等內容，有興趣的同學可以先看下。

利用主從復制，可以實現讀寫分離、數據備份等功能。但如果主庫宕機后，需要運維人員手動地將一個從庫提升為新主庫，并將其他從庫slaveof新主庫，以此來實現故障恢復。

因此， 主從模式的一個缺點，就在于無法實現自動化地故障恢復 。Redis后來引入了哨兵機制，哨兵機制大大提升了系統的高可用性。

哨兵，就是站崗放哨的，時刻監控周圍的一舉一動，在第一時間發現敵情并發出及時的警報。

Redis中的哨兵（Sentinel）， 則是一個特殊的Redis實例 ，不過它并不存儲數據。也就是說，哨兵在啟動時，不會去加載RDB文件。

關于Redis的持久化，可以參考我的另外一篇文章 談談Redis的持久化——AOF日志與RDB快照

上圖就是一個典型的哨兵架構，由數據節點與哨兵節點構成，通常會部署多個哨兵節點。

哨兵主要具有三個作用， 監控、選主與通知 。

監控：哨兵會利用心跳機制，周期性不斷地檢測主庫與從庫的存活性

選主：哨兵檢測到主庫宕機后，選擇一個從庫將之切換為新主庫

通知：哨兵會將新主庫的地址通知到所有從庫，使得所有從庫與舊主庫slaveof新主庫，也會將新主庫的地址通知到客戶端上

我會在下文詳細講一下監控與選主的過程

哨兵系統是通過3個定時任務，來完成對主庫、從庫與哨兵之間的探活。

首先我們會在配置文件中配置主庫地址，這樣哨兵在啟動后，會以 每隔10秒 的頻率向主庫發送info命令，從而獲得當前的主從拓撲關系，這樣就拿到了所有從庫的地址。

接著 每隔2秒 ，會使用pub/sub（發布訂閱）機制，在主庫上的 sentinel :hello的頻道上發布消息，消息內容包括哨兵自己的ip、port、runid與主庫的配置。

每個哨兵都會訂閱該頻道，在該頻道上發布與消費消息，從而實現哨兵之間的互相感知。

利用啟動配置與info命令可以獲取到主從庫地址，利用發布訂閱可以感知到其余的哨兵節點。

在此基礎上，哨兵會 每隔1秒 向主庫、從庫與其他哨兵節點發送PING命令，因此來進行互相探活。

當某個哨兵在 **down-after-millise買粉絲nds（默認是30秒） **配置的連續時間內，仍然沒有收到主庫的正確響應，則當前哨兵會認為主庫 主觀下線 ，并將其標記為sdown（subjective down）

為了避免當前哨兵對主庫的誤判，因此這個時候還需要參考其他哨兵的意見。

接著當前哨兵會向其他哨兵發送 sentinel is-master-down-by-addr 命令， 如果有半數以上（由quorum參數決定）的哨兵認為主庫確實處于主觀下線狀態，則當前哨兵認為主庫客觀下線 ，標記為odown（objective down）

一旦某個主庫被認定為客觀下線時，這個時候需要進行哨兵選舉，選舉出一個領導者哨兵，來完成主從切換的過程。

哨兵A在向其他哨兵發送 sentinel is-master-down-by-addr 命令時，同時要求其他哨兵同意將其設置為Leader，也就是想獲得其他哨兵的投票。

在每一輪選舉中，每個哨兵僅有一票。投票遵循先來先到的原則，如果某個哨兵沒有投給別人，就會投給哨兵A。

首先獲得半數以上投票的哨兵，將被選舉稱為Leader。

這里的哨兵選舉，采用的是Raft算法。這里不對Raft做詳細的探討，有興趣的同學，可以參考我的另外一篇文章 22張圖，帶你入門分布式一致性算法Raft

該文章采用大量的圖例，相信你可以從中學習到全新的知識，從而打開分布式一致性算法的大門，大伙們記得等我搞完Paxos與Zab。

過半投票機制也常用于很多算法中，例如RedLock，在半數以上的節點上加鎖成功，才代表申請到了分布式鎖，具體可參考這篇文章的最后 我用了上萬字，走了一遍Redis實現分布式鎖的坎坷之路，從單機到主從再到多實例，原來會發生這么多的問題

在Zookeeper選舉中，同樣也用到了過半投票機制，在這篇文章中 面試官：能給我畫個Zookeeper選舉的圖嗎？ 我從源碼角度分析了Zookeeper選舉的過程。

在選舉到領導者哨兵后，將由該哨兵完成故障恢復工作。

故障恢復分為以下兩步：

詳細說一下第一步，挑選是有條件的。首先要過濾出不健康的節點，再按某種規則排序，最后取第一個從庫，我們直接從源碼入手：

因此，以下從庫會被過濾出：

剩下的節點，就是健康的節點，此時再執行一次快速排序，排序的規則如下：

本文算是Redis哨兵的一個入門文章，主要講了哨兵的作用，例如監控、選主和通知。

在Redis讀寫分離的情況下，使用哨兵可以很輕松地做到故障恢復，提升了整體的可用性。

但哨兵無法解決Redis單機寫的瓶頸，這就需要引入集群模式，相應的文章也被列為明年的寫作計劃中。

</article>

Redis 和 Memcached 各有什么優缺點，主要的應用場景是什么樣的

Redis的作者Salvatore Sanfilippo曾經對這兩種基于內存的數據存儲系統進行過比較：

2、內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis采用hash結構來做key-value存儲，由于其組合式的壓縮，其內存利用率會高于Memcached。

3、性能對比：由于Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高于Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什么會出現上面的結論，以下為收集到的資料：

1、數據類型支持不同

與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息

很赞哦!（6）