02 redis的發布訂閱是一種什么模式(redis頻道收到發布者信息后可以只推信息給一個訂閱者嗎)

e ISystemConfigService systemConfigService;

@Override

public void receiveMessage(String message) {

logger.info("消息接收："+message);

JSONObject object = JSONObject.parseObject(message);

String businessType = object.getString("businessType");

logger.info("處理業務類型：businessType="+businessType);

if(BusinessTypeEnum.UPDATE_SYSTEM_CONFIG.toString().equals(businessType)){ //處理SystemConfig緩存

String jsonStr = object.getString("jsonStr");

if(jsonStr!=null&&!"".equals(jsonStr)){

JSONObject json = JSONObject.parseObject(object.getString("jsonStr"));

for(String key:json.keySet()){

String value = json.getString(key);

SystemConfig systemConfig = SystemConfigContainer.instance().getSystemConfig(key);

if(systemConfig!=null){

systemConfig.setKeyValue(value);

SystemConfigContainer.instance().uptSystemConfig(systemConfig);

}else{

systemConfig = systemConfigService.selectByPrimaryJianMing(key);

systemConfig.setKeyValue(value);

SystemConfigContainer.instance().uptSystemConfig(systemConfig);

}

}

}

}

}

}

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 之間的關系：

RabbitMQ與redis的區別是什么呢？

首先說RabbitMQ，RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業級的開發。同時實現了Broker構架，這意味著消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

其次是Redis，Redis是一個基于Key-Value對的NoSQL數據庫，開發維護很活躍。雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高于RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

3.3ZeroMQ

ZeroMQ號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZeroMQ能夠實現RabbitMQ不擅長的高級/復雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的復雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因為你的應用程序將扮演這個服務器角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數據將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認使用ZeroMQ作為數據流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty作為傳輸模塊）。

3.4ActiveMQ

ActiveMQ是Apache下的一個子項目。 類似于ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現高級應用場景。

3.5Kafka/Jafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Procer、Consumer都原生自動支持分布式，自動實現負載均衡；支持Hadoop數據并行加載，對于像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制統一了在線和離線的消息處理。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統。

上圖中一個topic配置了3個partition。Partition

很赞哦!（9475）