旁路缓存模式
- 在读缓存时
- 如果命中缓存，则直接返回数据
- 如果没命中缓存，则从数据库中读取数据，并更新缓存
- 在写缓存时
- 先写入数据库数据，然后删除缓存
存在问题
问题1: 更新缓存失败，导致数据不一致
问题2:多个线程更新缓存，时序性问题导致数据不一致
旁路缓存容易造成数据不一致问题，在实践中，通常采用监听binlog的方式来写缓存。
监听数据库binlog写缓存
监听数据库binlog，同步缓存变更。读服务完全依赖redis缓存，无需感知DB DTS具有以下特性：
- 分片内数据保序
- 失败重试
这种方案的优点是将缓存和数据库的更新解耦。避免编码时新增sql忘记更新缓存导致数据不一致。
存在问题
这种方案也存在一些问题
- 链路上新增中间件依赖，如果DTS出现问题，则会导致DB和redis的数据不一致。
- 监听数据库binlog的方案不是同步写入缓存，通常存在秒级延迟。
针对以上问题，要进一步优化：
- 数据不一致告警
- DTS失败后，有兜底方案
- 为缓存同步方案提效，降低延迟
监听数据库binlog写缓存-优化DTS故障问题
我们加入数据一致性校验功能，用于校验DB和redis中的数据一致性。
定时任务流程
定时任务每分钟运行一次，每次运行读取最近数据库变更的数据，并取出相应的缓存数据进行对比。 如果缓存中的数据落后，则通过CAS机制更新缓存中的数据。
这种方式加入了一致性校验链路，可以作为DTS的兜底、监控，解决了DTS故障造成的数据不一致问题。
监听数据库binlog写缓存-优化DTS写入延迟
加入实时写入缓存链路。DTS链路作为兜底写入。这种方式可以极大改善缓存写入延迟。
业务或DTS写入流程
DTS和业务在更新数据时，采用相同的流程。首先读取缓存中的数据，如果写入数据比缓存中数据新，则采用CAS方式更新缓存。
这种方式加入了实时写入链路，解决了DTS造成的延迟偏高（秒级），适用于对延迟比较敏感的场景。
以上就是本期全部内容，创作不易，关注点赞鼓励一下吧～
关注我，后续会持续更新技术干货文章～
