為什么不用kotlin 如何設計一個MQ消息隊列?
如何設計一個MQ消息隊列?1. 在上圖中定義發(fā)送和使用消息的過程2。首先定義消息協(xié)議,如ActiveMQ、stomp、XMPP等3。定義消息協(xié)議,定義消息隊列需要滿足的場景是否要保證消息的可靠性,必要
如何設計一個MQ消息隊列?
1. 在上圖中定義發(fā)送和使用消息的過程
2。首先定義消息協(xié)議,如ActiveMQ、stomp、XMPP等
3。定義消息協(xié)議,定義消息隊列需要滿足的場景
是否要保證消息的可靠性,必要時要保證存儲的高可用性
是否要支持同步和異步消息
是否要保證消息隊列例如rocketmq是高可靠性,卡夫卡是高吞吐量,但不高可靠性。
如何使用消息隊列解決分布式事務?
有兩種選擇。
Scheme 1 Local message transaction table
生產者需要添加一個事務消息表。具體步驟如下:[1。生產者執(zhí)行業(yè)務邏輯并將事務記錄插入到消息表中。這兩個操作在一個本地事務中
2。啟動后臺線程定期輪詢消息表并將消息發(fā)送到消息隊列
3。刪除消息表中的消息,直到發(fā)送成功。
方案2需要消息隊列支持,業(yè)務端提供回溯接口
1。生產端將準備好的消息發(fā)送到消息隊列
2。在本地事務中,業(yè)務邏輯
3。根據(jù)執(zhí)行結果確認或取消準備好的消息
4。消息隊列將確保準備好的消息被確認或取消,并且消息隊列將不斷地向生產端請求執(zhí)行結果,這要求生產端提供類似的回調函數(shù)。
在方案2中,消息隊列取代了方案1中的消息表和后臺線程輪詢功能,但并非所有消息隊列都支持此功能。支持Rocketmq。
方案1的開發(fā)工作量大,外部依賴性小
方案2的開發(fā)工作量小,但依賴于特定的消息隊列。