對於消息的生產端的可靠投遞,我們常見的解決方案有兩種
1.消息落庫,對消息狀態進行打標
2.消息的延遲投遞,做二次確認,回調檢查
1、消息落庫,對消息狀態進行打標
上面圖片爲消息落庫,對消息狀態進行打標的常見步驟(狀態0表示已發送,1表示已消費,2表示失敗)
- 首先將將要發送的數據持久化到BIZ數據庫中,並且創建一個存儲着消息狀態的數據持久化到MSG數據庫中。
- 將數據發送至MQ。
- 消費者接收到數據,對數據進行消費然後將MSG在數據庫中的狀態修改爲1。
- 在此之外,我們還存在一個分佈式定時任務線程,用於定時查看是否有超時失敗任務,當發現MSG數據庫中存在着狀態爲0的數據則對數據進行重發,當數據多次重發失敗後則將消息狀態修改爲2。
由於這個方式需要進行兩個數據的數據落庫容易產生數據庫的性能瓶頸,所以我們更多的使用的是下一個可靠性投遞的解決方式
消息的延遲投遞,做二次確認,回調檢查
上面圖片時延遲投遞的流程(upstream上游服務,downstream下游服務(消費端))
- 首先將需要發送的數據持久化到BIZ數據庫。
- 將數據發送至MQ中。
- 消費者消費數據,並新建一個消費成功的消息進入MQ。
- Callback服務獲取到消費者消費成功的消息後將消息持久化到MSG數據庫。
- 生產者將延遲投遞消息發送至MQ。
- Callback獲取到延遲投遞消息後進入MSG數據庫查詢是否投遞成功,如果投遞失敗則進行失敗補償,這是向上遊服務發送消息,讓上游服務的查詢BIZ數據庫然後進行消息重發。