微服务数据一致性风险 微服务数据同步方案

文章目录

• 多级缓存
• 49 缓存同步

• 49.1 数据同步策略

• 49.1.1 缓存同步策略

49 缓存同步

49.1 数据同步策略

49.1.1 缓存同步策略

OK，前面我们已经基本实现 了一个多级缓存架构，大大提高了 “查询商品的性能”

【但是】缓存在提高性能的同时，也带来了一致性的问题，比如说数据库发生 了修改

这个时候如果缓存还是旧的数据，那么就导致了 数据不一致的问题

【如何保证数据库 与 缓存数据的一致性？ 】【缓存同步问题】

缓存数据同步的常见方式有三种：

• 设置有效期：给缓存设置有效期，到期后自动删除。再次查询时更新【被动的缓存同步】【其实就相当于并没有做同步，只是到期了而已，下次再查的时候才能更新】

• 优势：简单、方便
• 缺点：时效性差，缓存过期之前可能不一致
• 场景：更新频率较低，时效性要求低的业务

• 同步双写：在修改数据库的同时，直接修改缓存

• 优势：时效性强，缓存与数据库强一致
• 缺点：有代码侵入，耦合度高；
• 场景：对一致性、时效性要求较高的缓存数据

• **异步通知：**修改数据库时发送事件通知，相关服务监听到通知后修改缓存数据【通知到位就行了】

• 优势：低耦合，可以同时通知多个缓存服务
• 缺点：时效性一般，可能存在中间不一致状态
• 场景：时效性要求一般，有多个服务需要同步

【基于MQ 的异步通知】

修改了商品信息，写入数据库后，发一个通知，业务就算结束了【但是还是需要在代码上面去做修改】

【今天要学的】 【基于Canal 的异步通知】

canal 可以直接监听MySQL 数据库的变化【代码 0 侵入】