Apache Kafka使用场景、与REST差异及微服务应用相关疑问咨询

1. 先澄清poll机制的误解 #

你看到的ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));是Kafka消费者的长轮询机制，和你理解的REST无效短轮询完全不同：

• 这里的100ms是服务端无新消息时的最大等待时长，只要有新消息到达会立刻返回，不会频繁发送空请求产生无效流量
• 这种设计是为了兼顾消息消费的实时性和网络开销，本身不是Kafka适用场景受限的原因

2. Kafka在微服务中普及的核心价值 #

Kafka和REST是互补的技术，不是替代关系，REST适用于同步按需请求的场景，Kafka解决的是REST不擅长的分布式微服务痛点：

• 上下游解耦：比如订单服务生成订单后需要通知库存、积分、通知等多个下游服务，用REST调用的话订单服务需要感知所有下游的接口、处理下游故障的重试降级逻辑，新增下游还要修改订单服务代码。用Kafka的话订单服务只需要发送一次「订单创建完成」事件到对应topic，所有下游自行订阅消费即可，上下游完全无耦合
• 削峰填谷：遇到大促、活动等突增流量场景，用REST同步调用很容易把下游承载力低的服务打垮，Kafka可以先把消息暂存，下游服务按照自己的处理速度消费即可，避免服务雪崩
• 异步提速：用户下单不需要等扣库存、发短信、加积分等所有逻辑执行完才能得到响应，订单服务写完库、发送事件到Kafka就可以直接返回用户结果，后续操作异步执行，大幅降低接口响应耗时

3. 关于订单计算场景与Kafka和数据库的关系 #

你提到的计算上月订单的场景，确实直接调用get /orders/month/july的REST接口是更合理的选择，Kafka不是银弹，不需要所有场景都强行使用。
另外Kafka完全不会替代业务数据库：

Kafka的topic虽然支持数据持久化，但是它是面向日志流的存储系统，不支持随机查询、事务、复杂SQL检索等业务数据库必备的能力，业务的核心订单数据还是会存在MySQL、PostgreSQL这类关系型数据库中。Kafka的topic中一般存储的是订单创建、更新、删除这类变更事件，如果你需要做实时订单统计、数据同步这类场景，可以订阅Kafka的订单事件topic，把数据同步到计算服务本地存储，避免高频统计请求压垮订单服务的接口。

内容的提问来源于stack exchange，提问作者Toni26