北京
你在设计新系统。需要异步通信。有人喊"Kafka"，有人说"RabbitMQ更简单"，第三个声音插进来"直接用SQS算了"。
它们表面相似，实则天差地别，甚至不在同一赛道。选错工具、搞混概念，不仅让你加班熬夜，更会引入连锁故障——花几个月才能定位修复的那种。
写代码之前，四个核心概念必须吃透。搞错任意一个，下游服务稍有延迟，你的系统就会自我毁灭。
核心问题：同步耦合的陷阱
为什么用队列？为了干掉同步耦合。
想象结账服务直接调用库存服务的API。库存变慢了——可能是高负载，可能是数据库延迟——没崩溃，只是响应从50毫秒变成5秒。
但连接是同步的。结账服务的线程堆积等待，线程池耗尽，服务挂掉。依赖结账服务的一切跟着倒下。这就是连锁故障，野火般蔓延。真凶不是慢库存，是同步耦合让过载自我喂养：重试、超时、等待，恶性循环。
队列是缓冲层。库存变慢时，消息在队列里堆积。结账服务写下"订单已创建"，立刻继续干活。
解耦发生在三个维度：时间（不必同时运行）、可用性（一个维护停机不拖垮另一个）、速度（快的不用被慢的绑架）。
致命混淆：工作任务 vs 事件通知
某团队周五上线功能，周一早上每个用户收到50封重复的欢迎邮件。根源是一个概念错误：把"工作任务"（发这封邮件）丢进了"主题"（广播机制）。他们有50个 worker 进程，主题尽职地把消息复制50份发出去。
代码评审时多问一句就能拯救周末："这条消息该被处理一次，还是多个服务各自响应？"
处理一次的是点对点工作队列：压缩这张图片、扣这笔信用卡、发这封邮件。池子里任意 worker 能抢，但只有一个能执行，处理完消息消失。
多人响应的是发布订阅：订单已创建。邮件服务、物流服务、分析服务各自订阅，各自行动。事件是事实陈述，不是指令。
Kafka、RabbitMQ、SQS 在这个维度上设计截然不同。Kafka 的 partition 机制天然偏向广播；RabbitMQ 的 queue 偏向点对点；SQS 标准队列至少一次投递，FIFO 队列严格单消费者。工具选错，架构地基就歪了。
两个隐藏杀手
消息顺序：你的业务真的需要严格顺序吗？需要，就得接受吞吐量牺牲和分区复杂度。不需要，就别为"以防万一"买单。
投递语义：至少一次、恰好一次、最多一次——没有免费午餐。恰好一次需要幂等设计和去重机制，代码复杂度陡增。很多团队以为自己需要恰好一次，其实至少一次加幂等就够了。
四个支柱理清楚再选型：解耦目标、工作vs事件、顺序需求、投递语义。跳过这一步，生产环境的深夜告警迟早教你做人。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
