关于第一套指纹码的方案,暂无异议。关于redis的实现,根据具体业务场景和复杂度,再选择是否落库这点无疑问。目前还有两点疑惑:
1、如果先落库,依旧可以采用分库分表的方式来解决数据库写入瓶颈,那么落库的目的是否只是做备份保证数据不丢失。另外就目前只是解决消息重复消费的幂等性问题,只需要写入消息的唯一,并读取判断即可,是否就不存在redis需要更新的问题,如果不存在,是否就意味着在数据库和redis服务均保证可用的情况下,并不会出现数据库与缓存双写导致数据不一致。
2、不落库的话,定时同步的方案。redis肯定做集群方案,首先保证redis服务的可用性。虽然redis也有持久化机制,但是redis集群宕机后的重启,数据加热都很耗时。目前想了两套方案:
2.1 将redis变更复制一份,再丢到队列中,给mysql消费。但是这种方案又回到最初的队列复杂问题。
2.2 定时刷新redis中的最新数据到mysql。那么问题又来了,无论定时任务的间距有多小,都会留下时间缝隙,如果发生宕机,故障等都会造成数据的不一致性。如果比较redis和数据库中的数据,同步那些需要同步的变化数据,又会加大计算量和程序的复杂度。
如上,tks!