如何确保数据修改事件按正确顺序投递至SQS或Kinesis？

这个问题的核心是数据库操作顺序和消息投递顺序脱节——FIFO队列只能保证入队后的消费顺序，但没法解决业务线程被抢占导致的消息延迟投递问题。下面是几种工程实践中常用的解决方案：

1. 给业务记录加版本号，消费端做顺序校验 #

这是最轻量化的方案，不需要额外中间件，核心靠消息自身标识过滤旧消息：

• 数据库层改造：给目标业务表增加一个version字段，用自增整数或高精度时间戳（比如微秒级）。每次CRUD操作时同步更新这个版本号：
  • request1执行insert时，初始化version=1，提交事务后发送包含id=5, type=insert, version=1的消息
  • request2执行update时，将version自增为2，提交事务后发送id=5, type=update, version=2的消息
  • request3执行delete时，将version自增为3，提交事务后发送id=5, type=delete, version=3的消息
• 消费端逻辑：维护一个缓存（内存哈希表或Redis），存储每个业务ID对应的已处理最大版本号。收到消息时：
  • 如果消息的version大于缓存中该ID的最新版本，就执行消费逻辑，同时更新缓存版本号
  • 如果消息的version小于等于缓存中的最新版本，直接丢弃这条延迟的旧消息

以你的场景为例，队列消息顺序是update(v2)→delete(v3)→insert(v1)：

• 先处理update(v2)，缓存中id=5的初始版本为0，执行更新后缓存版本更新为2
• 接着处理delete(v3)，3>2，执行删除后缓存版本更新为3
• 最后收到insert(v1)，1<3，直接丢弃，最终效果等价于按insert→update→delete的顺序处理

2. 用数据库事务绑定消息日志，定时投递（强一致性方案） #

如果要求消息必须和数据库操作严格绑定（不能出现操作成功但消息丢失），同时从根源上避免投递乱序，可以用事务型消息日志方案：

• 新增事件日志表：创建event_log表，字段包括id, business_id, event_type, version, status（status标记消息是否已成功投递）
• 事务绑定操作：将业务CRUD操作和插入事件日志放在同一个数据库事务中：
  • request1执行insert user(id=5, version=1) + insert event_log(business_id=5, type=insert, version=1, status=0)，提交事务
  • request2执行update user set version=2 where id=5 + insert event_log(business_id=5, type=update, version=2, status=0)，提交事务
• 定时任务投递：启动独立的定时任务，批量读取status=0的事件日志，按business_id和version升序排序后，依次投递到SQS/Kinesis。投递成功后，将event_log的status改为1

这种方案从根源上保证了投递的消息顺序和业务操作顺序完全一致，因为事件日志是按操作顺序插入的，定时任务排序后投递不会出现乱序。

3. 结合SQS FIFO特性优化投递 #

针对SQS FIFO的特性，可以补充两个配置进一步强化顺序性：

• 消息组ID：给同一个业务ID（比如id=5）的消息设置相同的消息组ID（如group-id-5），SQS会保证同一消息组内的消息按入队顺序消费
• 消息去重ID：将version作为MessageDeduplicationId，即使因为重试等原因重复投递，SQS会自动过滤重复消息，避免重复消费

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