如何保持AWS Cognito授权服务器与MySQL数据库的同步？

场景回顾 #

你的系统架构如下：

• AWS Cognito User Pool存储核心授权信息（用户ID、用户名、邮箱）
• MySQL存储非授权类业务数据（如好友关系）
• API层聚合两类数据提供给应用调用

为了减少用户资料查询的耗时，计划将Cognito中的用户个人信息同步到MySQL，但面临「Cognito更新成功、MySQL更新失败」导致的数据不一致风险。

以下是几种实用的解决思路：

1. 基于Cognito触发器做异步可靠同步 #

利用Cognito自带的用户生命周期触发器（如Post Confirmation、User Update触发器），触发Lambda函数完成数据同步：

• 用户在Cognito更新信息后，Cognito自动调用配置好的Lambda，由Lambda负责将最新数据写入MySQL
• 为避免同步失败导致数据丢失：
  • 给Lambda配置3次以内的重试机制
  • 重试仍失败时，将同步任务转入SQS死信队列，用专属Lambda消费队列做补偿
  • 给Lambda加幂等性处理：以用户ID+更新时间戳作为唯一标识，避免重复触发时重复写入

这种方案无需修改业务代码，把同步逻辑完全交由Cognito和后端服务处理，是最省心的实现方式。

2. 双写+同步重试+失败补偿 #

如果对数据一致性要求极高（需保证MySQL与Cognito实时一致），可在业务API层实现双写逻辑：

• 用户发起更新请求时，API先调用Cognito更新接口，确认成功后再调用MySQL更新接口
• 若MySQL更新失败，立即返回用户「更新失败」，同时将失败任务记录到补偿表/队列
• 后台运行定时任务，扫描补偿队列并重新尝试同步，直到任务成功
• 可额外提供手动同步入口，极端情况允许用户自行触发修复

这种方案能保证强一致性，但会增加业务代码复杂度，适合对数据一致性要求苛刻的场景。

3. 定期全量/增量同步兜底 #

无论采用哪种同步方案，都建议加一层定期同步的兜底机制：

• 增量同步：每日定时调用Cognito的ListUsers接口，用Filter参数过滤出最近N小时更新的用户，对比MySQL数据并同步差异
• 全量同步：每周执行一次全量校验，将所有用户信息与MySQL做比对，修复遗漏的同步记录
• 可通过Lambda定时任务、Airflow等工具实现该逻辑，作为数据一致性的最后一道防线

4. 查询时实时兜底修正 #

在用户查询个人资料的环节加入兜底校验：

• 优先从MySQL读取缓存的用户信息，同时异步调用Cognito接口获取最新数据
• 若发现两者数据不一致（如用户名、邮箱不匹配），立即更新MySQL数据，再将最新信息返回给用户
• 这种方式既能保证用户拿到最新数据，也能自动修复同步失败的记录

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