6.mysql与Redis保持一致.txt

1.db发生变动后，删除Redis。查询时发现没有，重新查询db最新值
	影响接口响应，耦合性大
2.db修改以后发送dmq消息，消费消息同步redis
	延迟概率较大，但解耦
3.基于订阅mysql binlog，采用mq异步将数据同步到redis（较好的方式）
	使用canal伪装成mysql集群的一个子节点，当db发生数据修改时，监听到binlog变化，单独使用一个服务将数据同步到redis（mysql子节点只做查询，主节点做增删改）
	优点是人工对db的修改都可以被同步到redis，而上面两个方法只能同步业务的修改；缺点是同步数据的服务如果较少，可能增大延迟	
	!!@@202501313.img_732_422_1@@!!


4.延迟双删策略
	有一种同步方式为：修改时先删除redis，再更新db；查询时如果redis不存在，则查询db再写入redis
	高并发情况下可能将旧数据再次写入redis：
		线程1删除Redis→线程2查询redis，发现没有重新查询db，写入旧值到redis→线程1更新db→线程3查询时，仍是旧值
	延迟双删就是在更新完db后隔一段时间，再次主动删除redis，强制后续的查询重新查询最新数据
	但是一般不推荐使用该方式，因为延迟的时间不好把控
		!!@@202501314.img_673_164_1@@!!

5.双写一致性
	这种同步方式为：更新db后同步更新redis，不是上面那种直接删除
	为了防止多线程问题，需要将更新db和redis放在一个事务里
		浏览器的三方热榜，数据更新较频繁，每5min一次且需要同步资源的消费者很多，所以每次更新完db后直接写入缓存，加快查询。于此略有不同，但是差不多