数据一致性

• 读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
• 不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况：
  1. 如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
  2. 如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。
  3. 因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

方案：读写同步

1. 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
2. 更新的时候，先更新数据库，然后再删除缓存。

• 缺点：
  • 会产生数据一致性问题

方案：队列 + 重试机制

• 更新数据库数据；
• 缓存因为种种问题删除失败
• 将需要删除的key发送至消息队列
• 自己消费消息，获得需要删除的key
• 继续重试删除操作，直到成功
• 缺点
  • 对业务线代码造成大量的侵入

异步更新缓存(基于订阅binlog的同步机制)

1. 读Redis：热数据基本都在Redis
2. 写MySQL: 增删改都是操作MySQL
3. 更新Redis数据：MySQ的数据操作binlog，来更新到Redis

• 读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。
• 这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。
• 其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。
• 这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。
• 当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis。#