消息队列与微服务高频追问
1. 为什么你的推广 ROI 线更适合 Kafka？
推荐回答
因为这条线本质上是事件流和数据链路，不是简单业务通知。 点击、激活、注册、支付、回传、报表刷新都有持续流量，而且高峰期吞吐很高，Kafka 更适合做高吞吐异步解耦和实时消费。
2. 那 RabbitMQ 适合什么？
推荐回答
RabbitMQ 更适合业务消息、任务分发、复杂路由、低到中等吞吐但对路由灵活性要求高的场景。 如果是订单通知、异步任务、广播/Topic 路由这类，它会更顺手。 所以不是谁更高级，而是场景不同。
3. Kafka 重复消费为什么是常态？
推荐回答
因为消费成功与 offset 提交之间可能出现各种异常，比如消费完了还没提交就挂了，重启后就会重新拉取。 所以消息系统设计时要默认会重复消费，幂等是必须的，不是补丁。
4. 你怎么做消息幂等？
推荐回答
先定义唯一业务键，再通过 Redis / 数据库唯一键 / 状态判断做幂等控制。 我的习惯是让消费逻辑本身就具备幂等性，而不是依赖“消息绝不重复”。
5. 消息积压了，你第一反应看什么？
推荐回答
我会先看：
- 消费逻辑是不是变重了
- 下游依赖是不是慢了
- 并发度是不是不够
- 分区设计是不是不合理
- 有没有异常消息卡住
我不会第一反应就“扩容”，因为扩容只是结果，不是诊断。
6. 微服务拆分最容易犯什么错？
推荐回答
最常见的错是：
- 按页面拆
- 按组织结构硬拆
- 服务边界不清
- 状态定义不统一
- 拆出来后没有超时、重试、trace、配置治理
拆服务本身不难，拆完还能稳定跑才难。
7. 一个需求涉及多个服务，你怎么推进？
推荐回答
我一般先统一 5 个东西：
- 业务链路
- 服务职责
- 接口契约
- 联调测试矩阵
- 日志和 trace 方案
这一步做好了，后面联调成本会低很多。
8. 跨服务一致性你怎么处理？
推荐回答
我不会默认所有事情都用大事务包起来。 核心主状态尽量本地事务落库，后续动作通过消息、补偿、幂等和状态判断推进。 真正需要的是“最终结果对”，不一定是“所有服务同时成功”。
9. 为什么微服务里超时和重试很重要？
推荐回答
因为调用链一长，任何一个下游抖动都会放大。 没有超时，上游会被拖死；没有重试，短暂抖动就直接失败；没有边界控制，重试还可能把系统打穿。 所以超时、重试、限流、熔断一定要一起考虑。
10. 技术总监如果问“你不是平台架构师，为什么说自己懂微服务”，你怎么答？
推荐回答
我不把自己包装成纯平台型架构师，但我长期在多服务链路里做方案和落地，像服务拆分、接口契约、异步解耦、状态一致性、联调治理这些我都实际做过。 我更偏业务系统架构和落地架构，而不是纯基础设施视角。