DynamoDB同步Elasticsearch数据一致性确认及Lambda通信方案问询

1. 100%确认DynamoDB数据已持久化到Elasticsearch的实现方法 #

• 新增同步状态标记字段：在DynamoDB表中新增es_sync_status字段，业务写入DDB时默认赋值为pending。Lambda同步ES操作成功后，反向更新DDB对应记录的该字段为success；如果同步失败则更新为failed，同时可追加错误日志字段方便排查。
• 搭配ES强持久化配置：Lambda向ES写入数据时，指定refresh=wait_for参数，确保写入请求落地到ES磁盘、对查询可见后再返回成功，避免ES内存缓存未持久化导致的状态误判。
• 补充兜底校验逻辑：定期执行增量/全量数据校验任务，对比同主键下DynamoDB和ES的字段值，不一致的记录触发重试同步，覆盖极端场景下的链路异常漏同步问题。

2. 业务写函数等待同步结果再返回的实现方案 #

该需求可实现，两种常用方案如下：

• 轮询查询方案：业务函数写入DDB成功后，不直接返回，按固定间隔（比如500ms）轮询对应记录的es_sync_status字段，直到状态变为success/failed后再返回对应响应。需要设置最大等待阈值（比如30s），超过阈值则返回「处理中」，引导用户后续主动查询结果。
• 异步通知方案：业务函数写入DDB前，先注册一个临时的通知通道（可用SQS、Redis Pub/Sub等实现），写入成功后订阅该通道等待消息。Lambda完成ES同步后，向对应通道推送同步结果，业务函数收到结果后再返回响应。该方案比轮询性能更高，适合对接口延迟敏感的场景。

注意：双确认模式会明显拉长接口响应时长，且如果ES同步出现异常重试，会大幅提升接口超时概率。如果业务可接受最终一致性，建议优先选择异步告知用户「提交成功，处理中」、后续主动推送或引导用户查询结果的方案，性能和稳定性表现会更好。

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