如何設(shè)計一個MQ消息隊列？1. 在上圖中定義發(fā)送和使用消息的過程2。首先定義消息協(xié)議，如ActiveMQ、stomp、XMPP等3。定義消息協(xié)議，定義消息隊列需要滿足的場景是否要保證消息的可靠性，必要

如何設(shè)計一個MQ消息隊列？

1. 在上圖中定義發(fā)送和使用消息的過程

2。首先定義消息協(xié)議，如ActiveMQ、stomp、XMPP等

3。定義消息協(xié)議，定義消息隊列需要滿足的場景

是否要保證消息的可靠性，必要時要保證存儲的高可用性

是否要支持同步和異步消息

是否要保證消息隊列例如rocketmq是高可靠性，卡夫卡是高吞吐量，但不高可靠性。

日志采集系統(tǒng)flume和kafka有什么區(qū)別及聯(lián)系？

flume和Kafka的一些功能是相同的，但總的來說，它們是完全不同的；它們的場景是不同的，但它們可以一起使用。

簡而言之，flume是一個分布式日志收集系統(tǒng)，它從各種服務(wù)器收集日志并將其傳輸?shù)街付ǖ奈恢?，如HDFS。

Kafka是一個分布式消息中間件，有自己的存儲，提供推拉數(shù)據(jù)訪問功能。

整個過程如下：

登錄服務(wù)器<--flume-->kafka-->hdfs-->離線計算

登錄服務(wù)器<--flume-->kafka-->storm

希望我的回答能對您有所幫助

如何使用消息隊列解決分布式事務(wù)？

有兩種選擇。

Scheme 1 Local message transaction table

生產(chǎn)者需要添加一個事務(wù)消息表。具體步驟如下：[1。生產(chǎn)者執(zhí)行業(yè)務(wù)邏輯并將事務(wù)記錄插入到消息表中。這兩個操作在一個本地事務(wù)中

2。啟動后臺線程定期輪詢消息表并將消息發(fā)送到消息隊列

3。刪除消息表中的消息，直到發(fā)送成功。

方案2需要消息隊列支持，業(yè)務(wù)端提供回溯接口

1。生產(chǎn)端將準備好的消息發(fā)送到消息隊列

2。在本地事務(wù)中，業(yè)務(wù)邏輯

3。根據(jù)執(zhí)行結(jié)果確認或取消準備好的消息

4。消息隊列將確保準備好的消息被確認或取消，并且消息隊列將不斷地向生產(chǎn)端請求執(zhí)行結(jié)果，這要求生產(chǎn)端提供類似的回調(diào)函數(shù)。

在方案2中，消息隊列取代了方案1中的消息表和后臺線程輪詢功能，但并非所有消息隊列都支持此功能。支持Rocketmq。

方案1的開發(fā)工作量大，外部依賴性小

方案2的開發(fā)工作量小，但依賴于特定的消息隊列。

redis怎么實現(xiàn)將消息隊列持久化到數(shù)據(jù)庫中？

Redis僅提供具有原子操作的高性能分布式隊列實現(xiàn)。具體業(yè)務(wù)需要定制化。

您的需求實際上是一種畸形的生產(chǎn)者-消費者意識。

對于此類需求，主要目的是將請求與實際處理過程解耦。一般來說，請求者是異步通知的，這與是否使用redis關(guān)系不大。一般的實現(xiàn)方法是

將用戶的請求封裝成一個任務(wù)，然后將任務(wù)推送到redis隊列，再推送到后端工人.php任務(wù)可以由多進程、多線程并發(fā)處理，處理結(jié)果可以回調(diào)給請求者。這里唯一的問題是任務(wù)的設(shè)計，它需要包含請求信息（請求內(nèi)容、請求者ID等）