ASP.NET Core应用中如何提升EventStoreDB到PostgreSQL的投影同步速度

你使用的后台订阅Worker是异步消费模型：EventStoreDB写入事件成功并返回响应时，仅代表事件已经持久化到EventStoreDB本身。订阅服务的事件拉取、投影计算、PostgreSQL落盘整个链路是后台异步执行的，因此写入后立刻查询PostgreSQL会出现数据不存在的情况。

如果业务要求写入成功后必须立刻能查询到数据，直接在写请求链路中同步执行投影逻辑，不依赖后台订阅：

• 写入EventStoreDB事件成功后，立刻在当前请求中调用Marten的IDocumentSession执行投影更新，调用Store()写入投影对象后同步调用SaveChangesAsync()完成PostgreSQL落盘，再返回请求响应
• 必须做幂等校验：避免后台订阅重复消费同一事件导致重复更新，可以给事件加唯一EventId，在投影表加唯一索引约束，或直接开启Marten的事件幂等处理配置
• 极端一致性要求场景下，可将EventStoreDB写入和PostgreSQL投影写入纳入分布式事务，保证两边数据同时成功或失败，缺点是会损耗部分写入性能

如果业务可接受毫秒级的延迟，不需要强制同步，可从以下维度优化链路性能：

• 调整EventStoreDB订阅配置：调大SubscribeToAll的bufferSize参数到50~200区间（根据单事件大小调整），增加单次拉取的事件批量大小，减少和EventStoreDB的交互次数
• 优化Marten写入逻辑：
  • 开启Marten批量写入能力，攒一批事件的投影更新后批量提交到PostgreSQL，避免单事件单提交的额外IO开销
  • 关闭Marten运行时非必要特性：将自动创建schema配置改为AutoCreate.None，提前预创建所有需要的索引，关闭不需要的审计、变更追踪特性
  • 若使用Marten异步投影，调优AsyncOptions的批量大小和提交间隔参数
• 优化PostgreSQL写入配置：调高wal_buffers、适当设置commit_delay参数，针对高频写入场景优化WAL落盘策略，降低单次提交的延迟
• 消费端横向扩展：事件量级大的场景下，可将订阅按流分区，启动多个消费者实例并行消费不同分区的事件，提升整体消费速度

如果不想改动现有订阅和写入逻辑，可在写入后的查询逻辑中增加轻量重试机制：

首次查询不到目标数据时，间隔10_50ms重试23次，绝大多数场景下可以覆盖异步消费的延迟窗口，适合对一致性要求不高的业务场景

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