微服务中何时选用Kafka Streams GlobalKTable替代常规数据库？

GlobalKTable（基于Kafka压缩主题）适合在以下场景替代常规数据库做数据持久化：

• 跨微服务共享只读基础主数据：比如用户、商品这类核心静态/慢变更数据，多个服务只需要查询最新状态，不需要修改
• 追求数据实时一致性：压缩主题能保证数据最终一致，GlobalKTable可实时同步最新快照，比数据库定期同步更及时
• 降低主数据库查询压力：高并发场景下，直接从GlobalKTable读数据，避免频繁访问业务主库
• 简化数据同步逻辑：无需自行开发事件消费、本地存储更新的代码，依赖Kafka Streams内置机制即可完成数据同步

方案1：双数据库+事件同步（service-users存库发事件，service-orders存本地） #

适用场景 #

• service-orders需要对用户数据做本地加工或扩展：比如要添加订单专属的用户标签、消费统计数据，本地存储更灵活
• 有离线查询或复杂分析需求：service-orders的数据库要支持复杂SQL、报表查询，而GlobalKTable仅支持主键查询
• 网络或Kafka不稳定场景：需要本地缓存全量用户数据，即使Kafka故障也能正常提供服务

优点 #

• 完全符合微服务数据隔离原则：每个服务掌控自己的数据库，可独立选择schema、存储引擎
• 本地查询性能高：数据库可针对性做索引优化，适合复杂条件查询
• 服务自治性强：不依赖Kafka可用性，单个服务故障不影响其他服务的数据访问

缺点 #

• 数据同步复杂度高：需维护事件消费、数据更新逻辑，还要处理重复消费、数据冲突、重试等问题
• 数据一致性风险：事件延迟或丢失可能导致两个数据库数据不一致，需额外开发校验、补偿机制
• 存储成本高：相同用户数据在两个数据库重复存储，增加存储开销

方案2：GlobalKTable共享用户数据（service-users发快照到Kafka，双服务通过GlobalKTable读取） #

适用场景 #

• service-orders仅需读取用户基础数据（如用户名、收货地址），不需要修改或扩展
• 对数据实时性要求高：比如下单时必须获取用户最新的收货地址，不能接受同步延迟
• 想降低架构复杂度：不想维护多份用户数据，减少同步逻辑的开发和运维成本
• 高并发读场景：利用Kafka Streams的分片和缓存能力，支持大规模用户数据查询

优点 #

• 数据一致性有保障：基于压缩主题的GlobalKTable能保证所有服务拿到的是最新用户快照，天然实现最终一致
• 架构简化：不需要维护service-orders的用户数据存储，减少数据库运维和同步代码开发
• 实时性强：用户数据更新后，GlobalKTable可在毫秒级同步到所有消费服务
• 节省存储成本：仅在Kafka压缩主题中存储一份用户数据，避免重复存储

缺点 #

• 依赖Kafka可用性：如果Kafka集群故障，service-orders无法获取用户数据，直接影响业务
• 查询能力受限：GlobalKTable仅支持主键查询，无法做复杂条件过滤、聚合查询
• 数据耦合风险：用户数据schema变更时，所有依赖GlobalKTable的服务都要同步调整，增加跨服务协调成本

不违反。微服务的核心原则是「数据所有权与自治性」——即每个服务负责自己的业务数据，而非禁止共享只读数据：

• service-users仍然是用户数据的唯一所有者，负责数据的写入、更新和schema管理
• service-orders只是通过GlobalKTable只读访问用户数据，没有修改权限，也不维护自己的用户数据持久化副本（本地缓存不属于持久化存储）
• 这种模式本质是「主数据共享」，属于微服务架构中常见的设计，只要保证数据所有权单一，就符合微服务原则

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