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

如何設計一個MQ消息隊列？

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

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

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

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

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

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

什么是買賣隊列？

銷售隊列中的數(shù)字顯示每個人有多少只手（一只手等于100股），并根據(jù)價格排列。例如，如果買入的最高價格是20元，如果有10只手掛20元，他們將被排在買入10的第一個顯示，如果有8只手掛20元，他們將被排在買入8的第二個顯示。銷售也是如此。如果最低售價是19元，一共有12手，第一個售價會顯示12手，第二個低價是19.20元。如果賣出價是14手，第二個賣出價將顯示14手。成交時，先成交買一或賣一，再成交買二或賣二。而同樣價格的申請書（如最高價20元的10手掛單），則是按照掛單時間順序成交。

消息隊列，如何保證消息不被重復消費？

現(xiàn)在消息機制一般是通過中間件實現(xiàn)的，如Kafka、ActiveMQ等。一般來說，有兩種消費策略：至少一次和最多一次。

首先，至少一次。在這種情況下，使用消息很重要，不能容忍丟失。使用者從中間件集群中提取消息，在內(nèi)部消費，并將消費結果通知集群。如果用戶計算機重新啟動或網(wǎng)絡丟失數(shù)據(jù)包，此時將提取重復的消息。一般的解決方案是保證對使用者業(yè)務邏輯進行冪等處理。

第二，至少再來一次。此時，消息可能會丟失，并且不會重復消費。

作為接收器，保持接口冪等是一項基本功能。它可以處理一些意外情況，例如群集故障，或者需要跟蹤消息數(shù)據(jù)的歷史以便重新處理等

Rabbitmq從未使用過。在ActiveMQ中，我剛剛測試了可以有多個消費者，消息按順序分發(fā)給不同的消費者，比如消息1到消費者a，消息2到消費者B，消息3到消費者a，消息4到消費者B。。其優(yōu)點是實現(xiàn)了負載均衡。如果消費者B突然掛斷，消費者a可以正常接收。

我明白，如果我說的是錯的，我希望有上帝來糾正它。非常感謝你。

rabbitMQ點對點，一個隊列可以多個消費者嗎？

作為一個服務層，由于其更好的性能，PHP適合上層業(yè)務開發(fā)，通信可以使用HTTP，編碼格式可以使用JSON或Pb