02 redis發布訂閱模式和kafka(Kafka，Mq和Redis作為消息隊列使用)

e）和死信交換機DLE（Dead Letter Exchanges）實現

a、TTL：RabbitMQ支持對隊列和消息各自設置存活時間，取二者中較小的值，即隊列無消費者連接或消息在隊列中一直未被消費的過期時間

b、DLE：過期的消息通過綁定的死信交換機，路由到指定的死信隊列，消費者實際上消費的是死信隊列上的消息

3）缺點：

a、配置麻煩，額外增加一個死信交換機和一個死信隊列的配置

b、脆弱性，配置錯誤或者生產者消費者連接的隊列錯誤都有可能造成延遲失效

2、RocketMQ

1）簡介：來源于阿里，目前為Apache頂級開源項目，使用Java編寫，基于長輪詢的拉取方式，支持事務消息，并解決了順序消息和海量堆積的問題

a、Broker：存放Topic并根據讀取Procer的提交日志，將邏輯上的一個Topic分多個Queue存儲，每個Queue上存儲消息在提交日志上的位置

b、Name Server：無狀態的節點，維護Topic與Broker的對應關系以及Broker的主從關系

2）延遲隊列實現：RocketMQ發送延時消息時先把消息按照延遲時間段發送到指定的隊列中(rocketmq把每種延遲時間段的消息都存放到同一個隊列中)，然后通過一個定時器進行輪訓這些隊列，查看消息是否到期，如果到期就把這個消息發送到指定topic的隊列中

3）缺點：延遲時間粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）

3、Kafka

1）簡介：來源于Linkedin，目前為Apache頂級開源項目，使用Scala和Java編寫，基于zookeeper協調的分布式、流處理的日志系統，升級版為Jafka

2）延遲隊列實現：Kafka支持延時生產、延時拉取、延時刪除等，其基于時間輪和JDK的DelayQueue實現

a、時間輪(TimingWheel)：是一個存儲定時任務的環形隊列，底層采用數組實現，數組中的每個元素可以存放一個定時任務列表

b、定時任務列表(TimerTaskList)：是一個環形的雙向鏈表，鏈表中的每一項表示的都是定時任務項

c、定時任務項(TimerTaskEntry)：封裝了真正的定時任務TimerTask

d、層級時間輪：當任務的到期時間超過了當前時間輪所表示的時間范圍時，就會嘗試添加到上層時間輪中，類似于鐘表就是一個三級時間輪

e、JDK DelayQueue：存儲TimerTaskList，并根據其expiration來推進時間輪的時間，每推進一次除執行相應任務列表外，層級時間輪也會進行相應調整

3）缺點：

a、延遲精度取決于時間格設置

b、延遲任務除由超時觸發還可能被外部事件觸發而執行

4、ActiveMQ

1）簡介：基于JMS協議，Java編寫的Apache頂級開源項目，支持點對點和發布訂閱兩種模式。

a、點對點（point-to-point）：消息發送到指定的隊列，每條消息只有一個消費者能夠消費，基于拉模型

b、發布訂閱（publish/subscribe）：消息發送到主題Topic上，每條消息會被訂閱該Topic的所有消費者各自消費，基于推模型

2）延遲隊列實現：需要延遲的消息會先存儲在JobStore中，通過異步線程任務JobScheler將到達投遞時間的消息投遞到相應隊列上

a、Broker Filter：Broker中定義了一系列BrokerFilter的子類構成攔截器鏈，按順序對消息進行相應處理

b、ScheleBroker：當消息中指定了延遲相關屬性，并且jobId為空時，會生成調度任務存儲到JobStore中，此時消息不會進入到隊列

c、JobStore：基于BTree存儲，key為任務執行的時間戳，value為該時間戳下需要執行的任務列表

d、JobScheler：取JobStore中最小的key執行（調度時間最早的），執行時間<=當前時間，將該任務列表依次投遞到所屬的隊列，對于需要重復投遞和投遞失敗的會再次存入JobStore中。

注： 此處JobScheler的執行時間間隔可動態變化，默認0.5s，有新任務時會立即執行（Object->notifyAll()）并設置時間間隔為0.1s，沒有新任務后，下次執行時間為最近任務的調度執行時間。

3）缺點：投遞到隊列失敗，將消息重新存入JobStore，消息調度執行時間=系統當前時間+延遲時間，會導致消息被真實投遞的時間可能為設置的延遲時間的整數倍

5、Redis

1）簡介：基于Key-Value的NoSQL數據庫，由于其極高的性能常被當作緩存來使用，其數據結構支持：字符串、哈希、列表、集合、有序集合

2）延遲隊列實現：Redis的延遲隊列基于有序集合，s買粉絲re為執行時間戳，value為任務實體或任務實體引用

3）缺點：

a、實現復雜，本身不支持

b、完全基于內存，延遲時間長浪費內存資源

6、消息隊列對比

1、公開課延遲隊列技術選型

1）業務場景：關閉超時未支付訂單、限時優惠活動、拼團

2）性能要求：訂單、活動、拼團 數據量可控，上述MQ均能滿足要求

3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作為延遲隊列更普遍

4）可用性：ActiveMQ、RocketMQ自身支持延遲隊列功能，且目前公開課業務中使用的中間件為ActiveMQ和Kafka

5）延遲時間靈活：活動的開始和結束時間比較靈活，而RocketMQ時間粒度較粗，Kafka會依賴時間格有精度缺失

結論： 最終選擇ActiveMQ來作為延遲隊列

2、業務場景：關閉未支付訂單

1）關閉買粉絲未支付訂單

2）關閉IOS未支付訂單

3、ActiveMQ使用方式

1）activemq.xml中支持調度任務

2）發送消息時，設置message的延遲屬性

其中：

a、延遲處理

AMQ_SCHEDULED_DELAY：設置多長時間后，投遞給消費者（毫秒）

b、重復投遞

AMQ_SCHEDULED_PERIOD：重復投遞時間間隔（毫秒）

AMQ_SCHEDULED_REPEAT：重復投遞次數

c、指定調度計劃

AMQ_SCHEDULED_CRON：買粉絲rn正則表達式

4、公開課使用中進行的優化

1）可靠性：針對實際投遞時間可能翻倍的問題，結合ActiveMQ的重復投遞，在消費者邏輯中做冪等處理來保證延遲時間的準確性

2）可追溯性：延遲消息及消費情況做數據庫冗余存儲

3）易用性：業務上定義好延遲枚舉類型，直接使用JmsDelayTemplate發送，無需關心數據備份和參數等細節

1、無論是基于死信隊列還是基于數據先存儲后投遞，本質上都是將延遲待發送的消息數據與正常訂閱的隊列分開存儲，從而降低耦合度

2、無論是檢查隊頭消息TTL還是調度存儲的延遲數據，本質上都是通過定時任務來完成的，但是定時任務的觸發策略以及延遲數據的存儲方式決定了不同中間件之間的性能優劣

張浩，2018年加入網易傳媒，高級Java開發工程師，目前在網易公開課主要做支付財務體系、版本迭代相關的工作。

很赞哦!（946）