基于Spring Boot+PostgreSQL+Kafka实现CRUD的使用问题咨询

1. Kafka能否与Spring Boot + PostgreSQL组合使用以实现CRUD，是否存在额外的处理流程？ #

可以组合使用，这是行业内非常成熟的后端技术栈搭配。常规CRUD场景下，基础流程和普通Spring Boot + PostgreSQL项目没有本质区别，仅需要额外处理Kafka相关的配置和可靠性逻辑：

• 提前在Spring Boot项目中引入spring-kafka依赖，配置Kafka集群地址、生产者/消费者的序列化/反序列化规则、ACK确认机制等核心参数
• 针对业务场景定义Kafka Topic的分区数、副本数、消息保留策略，避免消息丢失或异常堆积
• 如果需要保证消息和数据库操作的一致性，要额外处理分布式事务或者做最终一致性补偿，避免出现数据库操作成功但消息未发送、或者消息发送成功但数据库操作回滚的数据不一致问题。

2. 向PostgreSQL数据库插入数据时应当如何配合使用Kafka？ #

分两种常用的配合模式，可根据业务需求直接选择：

• 模式一：先写库，再发消息：接口收到写入请求后，先操作PostgreSQL完成数据插入，提交事务成功后再往Kafka发送写入完成的事件消息，下游服务监听Kafka消费该消息做后续业务处理，比如行为日志统计、缓存更新、跨服务业务通知等。该模式逻辑简单，一致性相对有保障，适合大多数普通业务场景。
• 模式二：先发消息，再消费写库：接口收到请求后直接把写入请求发到Kafka，自身不直接操作数据库，由专门的消费者服务监听对应Topic，拿到消息后统一往PostgreSQL插入数据。该模式可以承接高并发写入峰值，实现削峰填谷，适合写入量极大的业务场景，但需要额外处理消息重复消费的幂等性问题，避免重复插入脏数据。

3. 调用接口查询数据库数据时，是否需要先将数据写入Kafka，后续GET API仅从Kafka而非数据库拉取数据，这种Kafka使用方式是否正确？ #

这种使用方式绝大多数场景下是错误的，完全违背了Kafka的设计定位：

• Kafka是分布式消息流平台，不是结构化存储数据库，它的消息有固定保留周期，到期会自动删除，同时也不支持按业务主键做随机、高效的查询，要查询某条指定ID的数据从Kafka中检索的效率极低，甚至可能查不到已过期的消息。
• 常规GET查询直接从PostgreSQL读取即可，只有两种场景需要把查询事件或者查询结果发到Kafka：一是需要做查询行为的埋点统计，二是需要把查询结果同步给其他下游服务做数据更新，这两种场景和GET接口本身返回数据的逻辑没有关联，接口该查库还是查库。

4. 当用户调用save接口时，我是否需要同时从数据库拉取新保存的数据，以同步更新Kafka中的对应数据？ #

不需要主动拉库同步，两种常用的同步方案逻辑都更简洁，性能也更好：

• 如果你使用先写库再发消息的模式，写库成功前你手里已经有完整的待保存数据了，直接把该完整数据封装成消息发到Kafka即可，不需要写完再额外查一次库，白白增加数据库查询开销。
• 如果你要保证数据库和Kafka数据的绝对一致性，不想依赖业务代码发消息的逻辑，可以用PostgreSQL的CDC（变更数据捕获）工具，直接监听数据库的binlog变更，自动把新增/修改/删除的数据变更事件发到Kafka，完全不用业务代码干预，还能避免业务代码漏发、错发消息的问题。

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