使用Kafka与MongoDB Connector同步微服务事件的存储方案选型咨询

你倾向选择的独立UserEvents集合存储方案是合理的，契合你的技术栈和业务场景，除了你已经考虑到的Kafka Connect配置简化优势外，还有不少额外收益：

• 避免单文档膨胀：MongoDB单文档有16MB的大小上限，如果后续业务迭代新增UserUpdatedEvent、UserDisabledEvent等更多用户事件，内嵌数组的方案很容易随着事件积累触发大小限制，同时大文档也会拖慢用户表的常规查询性能，独立集合完全没有这个问题
• 事件查询和排查效率更高：后续如果需要统计事件触发量、排查同步链路异常，直接对UserEvents集合做条件查询即可，不需要遍历所有User文档解析嵌套的事件数组，排查成本低很多
• 符合事件溯源的标准落地模式：业界绝大多数事件溯源的实现都会选择独立事件表/集合的方案，后续如果要做全量事件回溯、状态重建，独立集合的实现成本远低于内嵌方案

你顾虑的事务成本问题不需要过于担心，MongoDB 4.0及以上版本对副本集、4.2及以上版本对分片集群的分布式事务支持已经非常成熟，用户创建属于低频操作，事务带来的性能损耗完全在可接受范围内。

另外补充几个你可能遗漏的注意点：

• 配置MongoDB Kafka CDC连接器时，建议开启full.document配置为updateLookup，避免同步的事件消息丢失字段
• ShoppingService消费同步过来的事件时，要做好幂等校验，建议以UserCreatedEvent的事件ID作为唯一键去重，避免CDC重试、Kafka消息重发导致的重复数据问题
• 可以给UserEvents集合增加event_type、user_id的联合索引，既可以加速本地事件查询，也能提升CDC连接器拉取变更的效率

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