先写缓存，再写数据库这一方案在逻辑上直接且直观，但在实际应用中，可能会因网络异常导致写数据库失败，最终造成缓存中的数据与数据库数据不一致。这种“脏数据”不仅影响用户体验，更严重时可能导致数据库中不存在数据的情况。
为了保证数据库与Redis缓存一致，通常采用以下几种方法： 使用主从复制：在数据库中配置主从复制，使Redis从数据库中获取数据，从而实现与数据库数据一致。 使用发布订阅模型：Redis可以作为消息队列使用，将数据库中的更新信息发布到Redis中，所有的订阅者都会收到这个更新信息，从而实现数据的同步。
读取数据：当应用查询时，先检查缓存，无命中则从数据库获取并写入缓存，确保后续请求能直接命中。只读操作不会导致不一致，但读写结合时需注意。 写数据时，通常先删除缓存再更新数据库，避免缓存脏读。这是因为缓存更新成本高，且可能导致线程间的并发问题。
先删缓存再写数据库对于写多读少的情况，先删除缓存再写入数据库可以避免数据不一致，减少不必要的系统资源消耗。这种策略的关键在于确保在写操作完成后，旧值已从缓存中清除，而新值已存入数据库。
数据库与缓存最终一致性 确保数据库与缓存一致性不通过双写时，可采用canal + RocketMQ实现最终一致性。直接更新数据库，通过canal监控MySQL binlog日志，发送至RocketMQ，消费者解析binlog，过滤非增删改操作，获取需要操作的表和key，从Redis中删除旧缓存。
我们大多倾向于使用这种方式，也就是将数据库中的变化同步到Redis，这种更加可靠。Redis在这里只是做缓存。方案1 （推荐学习：Redis视频教程）做缓存，就要遵循缓存的语义规定：读：读缓存redis，没有，读mysql，并将mysql的值写入到redis。写：写mysql，成功后，更新或者失效掉缓存redis中的值。
实例配置、部署与测试等步骤。通过配置MySQL的binlog格式为ROW，创建Canal实例，并部署Canal服务器，实现对数据库操作的监听与数据同步。总结，数据同步策略需根据具体场景选择，结合业务需求与技术限制，合理选择同步方式，确保数据的一致性与实时性。通过Canal等工具，可以实现高效、解耦的数据同步解决方案。
在数据库系统生态中，数据同步机制对于支撑逻辑单元的数据冗余高可用至关重要。例如，Mysql、Redis和MongoDB等都支持多节点实例间的数据同步。当需要跨逻辑单元或跨数据中心的数据同步时，可以实现同城多机房的负载均衡、多机房互备、异地多数据中心容灾和多活。
缓存雪崩是当多个缓存同时失效时引发的问题，候选人提出通过分散缓存失效时间来降低集体失效的风险。当需要将MySQL数据与Redis同步以保持双写一致性时，候选人在项目中采用了读写锁和Redisson的解决方案。关于Redis的数据持久化，候选人提到了RDB和AOF两种方式，RDB适合快速恢复，AOF则提供了较低的丢失风险。
