消息隊列方案設計提示詞（Kafka / RabbitMQ / RocketMQ 選型、消息不丟、順序消費、重複消費）
要在系統裏引入消息隊列做異步解耦、削峰或事件通知時用：讓 AI 根據場景選型，並從生產、存儲、消費三個環節設計「消息不丟、不重複處理、需要時保證順序」的方案，附上失敗重試與死信處理。
通用大模型 對話模型通用
你是一名精通消息中間件的後端架構師。請為下面的場景設計消息隊列方案。 場景： - 業務用途：[如訂單支付後通知積分、物流、短訊三個系統] - 消息量：[消息量]（例：平時每秒 200 條，峰值每秒 5000 條） - 對可靠性的要求：[如絕對不能丟、偶爾重複可以接受] - 是否需要順序：[如同一訂單的狀態變更必須按順序處理] - 現有基礎設施與團隊熟悉的中間件：[已有中間件與團隊經驗]（例：已有 Kafka 集群、團隊熟悉 RabbitMQ） - 語言與客戶端庫：[語言/客戶端庫] 請依次回答： 1. 是否真的需要消息隊列：同步調用、數據庫任務表、消息隊列三種方案在本場景下的對比。 2. 選型：結合消息量、順序要求、延遲消息需求、運維能力，在常見的幾種中間件之間給出建議；優先複用已有基礎設施，除非有明確的不適合理由。 3. 消息不丟（分三個環節）： - 生產端：發送確認機制；業務數據庫寫入與消息發送如何保持一致（如本地消息表 / 事務發件箱模式），避免「數據庫提交了但消息沒發出去」； - 存儲端：副本與持久化相關的關鍵配置； - 消費端：處理成功後再確認，處理失敗不確認或進入重試。 4. 重複消費：說明為什麼「恰好一次」通常無法單靠中間件實現，消費端如何做冪等（業務唯一鍵、去重表、狀態機）。 5. 順序：需要順序的消息怎麼路由到同一個分區或隊列；順序與並發吞吐之間的取捨；單條消息處理失敗時如何避免阻塞後續消息。 6. 失敗處理：重試次數與間隔、死信隊列、死信的告警和人工處理流程。 7. 消息格式：包含消息 ID、事件類型、發生時間、版本號、業務主鍵；消息體只放必要字段還是完整數據，說明取捨。 8. 給出生產端（含發件箱）和消費端（含冪等）的核心代碼。 9. 監控：消息積壓量、消費延遲、死信數量的告警閾值建議。
高亮處換成你自己的內容：[如訂單支付後通知積分、物流、短訊三個系統]、[消息量]、[如絕對不能丟、偶爾重複可以接受]、[如同一訂單的狀態變更必須按順序處理]、[已有中間件與團隊經驗]、[語言/客戶端庫]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[對可靠性的要求] 和 [是否需要順序] 決定了方案複雜度。通知類消息偶爾丟一條影響不大，扣款、發貨類消息絕對不能丟；只有同一個業務對象的消息需要順序，全局順序幾乎沒有必要，代價也很大。
常見坑：
- 在數據庫事務裏直接發消息：事務回滾了，消息卻已經發出去；或者事務提交了，發消息時網絡斷了。用事務發件箱模式把「寫業務數據」和「記錄待發消息」放在同一個事務裏。
- 消費端先確認再處理，處理過程中進程崩潰，消息就丟了。
- 以為開啟了某種「精確一次」配置就不用做冪等。跨系統的業務操作仍然需要消費端去重。
追問技巧：追問「假設消費者處理到一半時宕機、消息中間件某個節點故障、網絡分區，分別會發生什麼」，逐一確認方案的薄弱環節。
示例輸出
示例，僅供參考（事務發件箱，節選）
sql
-- 與訂單更新在同一個數據庫事務裏寫入
INSERT INTO outbox (id, aggregate_id, event_type, payload, created_at, sent)
VALUES (?, ?, 'OrderPaid', ?, NOW(), FALSE);後台任務定期掃描 sent = FALSE 的記錄發送到消息隊列，收到發送確認後再標記為已發送。由於可能重複發送，消費端必須冪等：
sql
INSERT INTO consumed_events (event_id) VALUES (?); -- event_id 為主鍵，衝突即說明已處理| 環節 | 措施 |
|---|---|
| 生產 | 事務發件箱 + 發送確認 |
| 存儲 | 多副本，寫入需多數副本確認 |
| 消費 | 處理成功後手動確認；失敗重試 5 次後進入死信隊列並告警 |
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～