消息队列方案设计提示词（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 条评论
还没有评论，来抢沙发～