mq消费幂等总结

mq消费幂等总结
针对mq新增场景：
1、单个新增：
1）首先查本地db是否已存在，存在则幂等
2）加redis乐观锁，加锁失败重试mq，
3）理论上上边2步可以解决大部分数据重复新增的问题，但是针对并发情况下，乐观锁超时释放的情况，数据库需要加唯一索引（outId, outType）进行兜底
2、批量新增：
1）单条加锁处理（推荐）：i.每次处理一个，处理前检查本地是否存在，存在则跳过；
单条加redis乐观锁，加锁失败重试mq；执行插入db
2）批量一起处理（不加锁）：i.批量校验是否存在，比较数量，相等则幂等，不相等则可能有缺失，计算出缺失的数据，然后进行插入db
ii.不存在：每次处理单条，加redis乐观锁，加锁失败重试mq，执行插入db
针对mq更新场景：
1、单个更新：与新增类似
2、批量更新：
1）每次处理单条主数据，每条失败都会重试全部
2）加redis乐观锁，加锁失败重试mq，
3）针对新增的数据进行db幂等校验，幂等则结束此条数据处理（for 循环 continue）
4）针对更新的数据,通过加数据库version条件进行db更新
5）针对删除的数据进行处理，如果没有要删除的，则结束此条数据处理（for 循环 continue）;
如果有要删除的，则需要进行db操作，一般的做法是变更db的状态为删除状态；
6）执行db操作
针对mq删除场景：
1、单个删除：与新增类似
2、批量删除：
1）不加锁的情况（推荐）：判断逻辑：批量查询是否已删除，删除则幂等，未全部删除，则进行变更db；
i.每次更新时因为带了version条件，所以并发情况下可能更新失效，因为已经db数据被变更，这种情况需要人工修数据；
ii.失败的情况下，全量回滚db操作；
2）加锁的情况：1、锁批量消息范围太广，导致锁失效，不推荐
2、锁单个消息（不推荐）：
i.先校验db的数据状态是否为已删除，删除则跳过；
ii.并发情况下，因为某个处理失败，可能出现mq重试的情况
总结
不论哪种场景：
场景1：消息体是主表idList,实际插入db的是子表的记录，
场景2：消息体的idList对应实际插入db的idList；
批量操作新增、更新时，推荐单条加锁处理，每次锁一条；
操作逻辑：1）判断单条是否已操作过
2）加redis乐观锁，加锁失败重试mq，
3）对于新增：数据库要加唯一索引来进行兜底
对于更新：需要判断3种操作情况（主子表结构）：判断是新增、编辑、删除
4）对于单条失败处理：新增、更新：mq重试时会重试，重试之前需要判断是否已变更（更新可不判断）
5）对于单条已处理的幂等判断：
对于更新、删除数据单条幂等的判断时，可以不加redis乐观锁，但是要加数据库version；
i.新增：1）首先查本地db是否已存在，存在则幂等
2）加redis乐观锁，加锁失败重试mq，
3）理论上上边2步可以解决大部分数据重复新增的问题，但是针对并发情况下，乐观锁超时释放的情况，数据库需要加唯一索引（outId, outType）进行兜底
ii.更新：不用判断幂等，只需判断版本号是否等于db的版本号，在更新sql时加version做条件
iii.删除：判断是否已删除，已删除则幂等，未删除则进行db变更，在更新sql时加version做条件（数据库仍存在，但状态为已删除）

数据库设计时注意事项：
1）需要对outId,outType加唯一索引
2）要有version字段，并维护好
3）要有删除状态字段，用于进行删除时变更