缓存与数据一致性问题
缓存与数据一致性问题
在高并发业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以一般都使用Redis作为缓存，让请求先访问Redis，而不是直接访问MySQL等数据库。读取是没有问题的，但是一旦涉及到数据更新，就会出现缓存和数据库数据不一致的问题，出现读到脏数据的问题，一般采用以下两种解决方案：
- 采用延时双删策略保证缓存和mysql数据一致
- 异步更新缓存保证缓存和mysql数据一致
Cache Aside Pattern
- 读的时候, 先读缓存, 缓存没有的话, 那么就读数据库, 然后取出数据后放入缓存, 同时返回响应。
- 更新的时候, 先删除缓存, 然后再更新数据库。
实际就是用到缓存才会计算，lazy思想。
延时双删策略
在写库前后都进行redis.del(key)操作，并设定合理的超时时间。
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(500);
redis.delKey(key);
}
- 先删除缓存
- 再写数据库
- 休眠500毫秒
- 再次删除缓存
休眠时间的确定，需要评估项⽬的读数据业务逻辑的耗时。这么做的⽬的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
这种策略还要考虑redis和数据库主从同步的耗时。最后的的写数据的休眠时间：则在读数据业务逻辑的耗时基础上，加⼏百ms即可。⽐如：休眠1秒。
从理论上来说，给缓存设置过期时间，是保证最终⼀致性的解决⽅案。所有的写操作以数据库为准，只要到达缓存过期时间，则后⾯的读请求⾃然会从数据库中读取新值然后回填缓存。
弊端：结合双删策略+缓存超时设置，这样最差的情况就是在超时时间内数据存在不⼀致，⽽且⼜增加了写请求的耗时。
异步更新缓存
基于 binlog 的同步机制。
MySQL binlog 增量订阅消费 + 消息队列 + 增量数据更新到redis，整体思路分三步骤：
- 读Redis：热数据基本都在Redis
- 写MySQL：增删改都是操作MySQL
- 更新Redis数据：MySQL的数据操作binlog来更新Redis
Redis更新
- 数据库操作分两部分
- 一个是全量（将全部数据一次写入Redis）
- 一个是增量（实时更新）
增量指的是mysql的update,insert,delete变更数据。
- 读取binlog后分析，利用消息队列，推送更新各台的redis数据缓存
一旦MySQL中产生了新的写入，更新，删除等操作，就可以把binlog相关的信息推送到Redis，Redis再根据binlog中的记录，对Redis进行更新。
这种机制有点像MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现数据一致性的。
这里可以使用canal（阿里开源的），通过该框架可以对MySQL的binlog进行订阅，而canal就是模仿mysql的slave数据备份请求，使得Redis的数据更新达到了相同的效果。
消息推送工具可以使用第三方的，例如：kafka，rabbitMQ等来实现推送更新redis。
博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
