关于消费端幂等性保障-redis实现探讨
来源：3-4 幂等性概念及业界主流解决方案
無缺
2018-08-20
关于第一套指纹码的方案，暂无异议。关于redis的实现，根据具体业务场景和复杂度，再选择是否落库这点无疑问。目前还有两点疑惑：
1、如果先落库，依旧可以采用分库分表的方式来解决数据库写入瓶颈，那么落库的目的是否只是做备份保证数据不丢失。另外就目前只是解决消息重复消费的幂等性问题，只需要写入消息的唯一，并读取判断即可，是否就不存在redis需要更新的问题，如果不存在，是否就意味着在数据库和redis服务均保证可用的情况下，并不会出现数据库与缓存双写导致数据不一致。
2、不落库的话，定时同步的方案。redis肯定做集群方案，首先保证redis服务的可用性。虽然redis也有持久化机制，但是redis集群宕机后的重启，数据加热都很耗时。目前想了两套方案：
2.1 将redis变更复制一份，再丢到队列中，给mysql消费。但是这种方案又回到最初的队列复杂问题。
2.2 定时刷新redis中的最新数据到mysql。那么问题又来了，无论定时任务的间距有多小，都会留下时间缝隙，如果发生宕机，故障等都会造成数据的不一致性。如果比较redis和数据库中的数据，同步那些需要同步的变化数据，又会加大计算量和程序的复杂度。
如上，tks!
1回答
-
1问题分库分表保证唯一是主流方案，难点在于要有一个统一ID生成的服务，保证ID全局唯一性，还要有合理的分库分表路由规则，保证ID通过某种算法，消息即使投递多次都落到同一个数据库分片上
2问题目前主流方案有两种，第一种为双缓存模式，异步写入到缓存中，这里可以参考rocketmq异步刷盘的双写策略，可以保证消息99.999%不丢失，也可以异步写到数据库咯，但是最终会有一个回调函数检查，这样能保障最终一致性，不能保证100%的实时性，但是做到准实时性已经足够，小概率事件可以做补偿。第二种是定时同步，比如databus同步，这一定会存在时间窗口的数据不一致问题，主要看业务是否允许。如果不允许则使用方案一122018-08-24
相似问题