订单创建后不能直接调用库存服务，因为同步调用会导致单点阻塞、响应延迟、订单失败等架构反模式；应通过kafka异步解耦，提升吞吐与稳定性。
为什么订单创建后不能直接调用库存服务？
因为同步调用会让整个下单链路变成“单点阻塞”：库存服务一卡，用户就看到转圈；库存超时或宕机，订单直接失败。这不是设计问题，是架构反模式——Kafka 的核心价值，就是把 inventoryService.deductStock() 这种强依赖，换成发一条消息到 topic-order-events，让库存服务自己去消费，不耽误主流程。
常见错误现象：
• 接口响应时间从 200ms 突增至 2s+，监控显示 order-service 线程池频繁打满
• 日志里反复出现 ConnectTimeoutException 或 SocketTimeoutException，源头却是下游服务不稳定
• 新增一个积分服务，得改订单服务代码、发版、灰度，上线周期拉长
- 使用场景：只要涉及跨服务状态变更（扣库存、发通知、记日志、更新搜索索引），都该走异步
- 性能影响：同步调用下，TPS 受最慢环节拖累；Kafka 异步后，订单服务吞吐可提升 3–5 倍（实测 Gpmall 场景）
- 注意点：不是所有操作都能异步——比如支付结果必须实时返回给前端，但“支付成功后扣减优惠券”可以异步
Spring Boot 中 KafkaTemplate.send() 怎么配才不丢消息？
默认配置下，KafkaTemplate.send() 是“发完即忘”，网络抖动、Broker 挂掉、磁盘写满都可能导致消息静默丢失。生产环境必须显式加固。
-
spring.kafka.producer.acks=all：强制等所有 ISR 副本写入成功再返回，这是可靠性的底线 -
spring.kafka.producer.retries=2147483647（或设为最大整数）：避免因NotEnoughReplicasException导致消息被丢弃 - 禁用
spring.kafka.producer.idempotence=false：幂等性必须开，否则重试可能造成重复消息 - 别用
StringSerializer直接序列化对象——JSON 序列化更安全，反序列化失败时能快速定位字段缺失
容易踩的坑：
• 把 acks=1 当成“已确认”，其实只是 leader 写入成功，leader 挂了就丢数据
• 在 @PostConstruct 里调用 send()，此时 KafkaProducer 可能还没初始化完成，抛 NullPointerException
ConsumerGroup 分区分配出错：为什么消费者不收消息？
现象很典型：Kafka 集群正常、topic 存在、生产者能发，但消费者死活收不到——八成是 group.id 配置或分区分配逻辑出了问题。
- 检查
spring.kafka.consumer.group-id是否写错，大小写、下划线、空格都不能有；不同环境（dev/test/prod）必须隔离 group-id - 如果 topic 有 6 个分区，而你只启了 1 个消费者实例，那它会自动分配全部 6 个分区；但加到 3 个实例后，若没触发 rebalance（比如消费者没正确关闭），旧实例可能还占着分区
- 别手动设置
spring.kafka.consumer.properties.partition.assignment.strategy，除非你真懂RangeAssignor和CooperativeStickyAssignor的区别——Spring Boot 3.2+ 默认用后者，更稳定 - 首次启动时，
auto.offset.reset=earliest要设对，否则新 group 会从最新 offset 开始消费，错过历史消息
真实案例：Clawdbot 项目曾因测试环境和预发共用 group-id=clawdbot-prod，导致预发消费者把测试消息全消费了，测试同学查日志一脸懵。
Topic 命名和分区数怎么定？别等压测爆了才改
Topic 不是建了就能用，命名决定可维护性，分区数决定吞吐上限——而且 Kafka 不支持在线修改分区数（只能增不能减），必须一次规划到位。
- 命名规则要带业务域和用途，比如
order-created-v1、user-registered-internal，别用topic1或log这种名字 - 分区数按峰值 QPS × 平均处理延时预估：比如每秒 500 订单，每个订单平均处理 200ms，理论需至少 100 个分区（500 × 0.2）；但实际建议从 12 或 24 起步，留扩展余量
- 敏感数据走独立 topic（如
user-pii-events），配合 Kafka ACL 或端到端加密，避免和普通日志混在一个 topic 里 - 别为图省事把所有事件塞进一个 topic——
order-cancelled和payment-success语义不同、消费者不同、重试策略也不同，硬塞一起只会增加排查成本
最后提醒一句：Kafka 不是万能胶水。如果两个服务之间只有极低频、强事务一致性要求的交互（比如银行转账的最终一致性校验），用数据库表 + 定时任务反而更稳——别为了用 Kafka 而用 Kafka。
