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中最新的消息。

spring-redis 發布訂閱模式：發布一條消息收到了兩條，重復監聽

當你看到這個文章時，想必已經了解了一些關于spring-redis發布訂閱方面的知識，如果你也遇到同樣的問題

那么請考慮spring在啟動時有沒有重復的加載配置文件

具體的方式可以在 AbstractApplicationContext 的 refresh() 方法中打斷點，如果走了兩次，說明配置文件加載了兩遍

而配置文件加載兩遍的原因是因為web.xml中DispatcherServlet和ContextLoaderLinistener 共用了 某些配置文件導致的。

redis頻道收到發布者信息后可以只推信息給一個訂閱者嗎

Redis 的 SUBSCRIBE 命令可以讓客戶端訂閱任意數量的頻道， 每當有新信息發送到被訂閱的頻道時， 信息就會被發送給所有訂閱指定頻道的客戶端。

作為例子， 下圖展示了頻道 channel1 ， 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關系：

redis怎么做消息隊列？

基于Redis消息隊列-實現短信服務化

1.Redis實現消息隊列原理，常用的消息隊列有RabbitMQ,ActiveMQ，個人覺得這種消息隊列太大太重，本文介紹下基于Redis的輕量級消息隊列服務。 一般來說，消息隊列有兩種模式，一種是發布者訂閱模式，另外一種是生產者和消費者模式。Redis的消息隊列，也是基于這2種原理的實現。 發布者和訂閱者模式：發布者發送消息到隊列，每個訂閱者都能收到一樣的消息。 生產者和消費者模式：生產者將消息放入隊列，多個消費者共同監聽，誰先搶到資源，誰就從隊列中取走消息去處理。注意，每個消息只能最多被一個消費者接收。

Redis中的哨兵模式

哨兵模式是一種自動選擇老大的模式，即在老大宕機之后，哨兵模式會根據哨兵們的內部投票，自動的重新選出一個新的老大。哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，如果Redis服務器一直沒有響應，說明這個Redis服務器可能已經宕機了，從而監控運行的多個Redis實例。

這里的哨兵有兩個作用

1、通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。

2、當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。

然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。

用文字描述一下故障切換(failover)的過程。假設主服務器宕機，哨兵1先檢測到這個結果，系統并不會馬上進行failover過程，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用，并且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作。切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱為客觀下線。這樣對于客戶端而言，一切都是透明的。如果有三個哨兵，不僅每個哨兵會監視主機和從機，而且哨兵之間也會互相監視，如下圖：

配置哨兵配置文件sentinel.買粉絲nf，如下

當哨兵模式的配置文件配置好之后，就可以啟動哨兵模式了，如下圖

測試在哨兵模式下如果主機崩了的話會不會從從機中自動選出一個老大，先關閉主機，讓主機宕機，如下圖：

看看主機宕機之后，哨兵模式中輸出日志的新的內容是什么，如下圖：

哨兵模式自動選舉一個主機這個過程是怎樣實現自動化的？哨兵自動選舉之前的某個從機為老大，所有的從機都會稱新選出的從機為老大，以及原本的老大也會稱新選出的老大為老大，這個過程是怎么自動化實現的呢？是通過在對應的redis服務器的配置文件中寫內容來實現的，比方說，讓我們看一下新老大也即是端口號是6381的redis服務器的配置文件中是怎樣改寫的，如下圖：

再來看一下從機即端口號是6380的redis服務器對應的配置文件是怎樣改寫的，如下圖：

最后看一下原本的主機即端口號是6379的redis服務器的配置文件是怎樣改寫的。我檢查了一下，發現在重新啟動原本的老大即重啟已經宕機的端口號是6379的redis服務器之前，它對應的配置文件中沒有發生任何改變，但是一旦重新啟動原本的老大，它對應的配置文件就會發生變化，如下圖：

哨兵模式中的主機關閉之后需要特別注意的一個易錯點：就是因為現在老大已經換了，所以老大的認證密碼也換了，因此需要在現任老大的所有從機里面配置主機的認證密碼，這個哨兵模式是不會幫我們自動配置的，需要我們自動配置，如下圖：

測試哨兵模式結果，如下圖：

1、哨兵集群，基于主從復制模式，所有的主從配置優點，它全有。

2、主從可以切換，故障可以轉移，系統的可用性就會更好。

3、哨兵模式就是主從模式的升級，手動到自動，更加健壯。

1、集群容量一旦到達上限，在線擴容十分麻煩。

2、實現哨兵模式的配置其實是很麻煩的，里面有很多選擇。

當Redis集群的主節點故障時，Sentinel集群將從剩余的從節點中選舉一個新的主節點，有以下步驟：

Sentinel集群的每一個Sentinel節點會定時對Redis集群的所有節點發心跳包檢測節點是否正常。如果一個節點在down-after-millise買粉絲nds時間內沒有回復Sentinel節點的心跳包，則該Redis節點被該Sentinel節點主觀下線。

當節點被一個Sentinel節點記為主觀下線時，并不意味著該節點肯定故障了，還需要Sentinel集群的其他Sentinel節點共同判斷為主觀下線才行。

該Sentinel節點會詢問其他Sentinel節點，如果Sentinel集群中超過quorum數量的Sentinel節點認為該Redis節點主觀下線，則該redis客觀下線。

如果客觀下線的redis節點是從節點或者是Sentinel節點，則操作到此為止，沒有后續的操作了；如果客觀下線的Redis節點為主節點，則開始故障轉移，從從節點中選舉一個節點升級為主節點。

如果需要從redis集群選舉一個節點為主節點，首先需要從Sentinel集群中選舉一個Sentinel節點作為Leader。

每一個Sentinel節點都可以成為Leader，當一個Sentinel節點確認redis集群的主節點主觀下線后，會請求其他Sentinel節點要求將自己選舉為Leader。被請求的Sentinel節點如果沒有同意過其他Sentinel節點的選舉請求，則同意該請求(選舉票數+1)，否則不同意。

如果一個Sentinel節點獲得的選舉票數達到Leader最低票數(quorum和Sentinel節點

很赞哦!（347）