DB和缓存为什么会出现不一致：
场景：读请求 + 写请求并发
A：第一步：线程查询缓存，没命中
A：第二步：线程去 DB 查询，拿到旧数据
B 第三步：线程更新 DB，变成新数据
B 第四步：线程回写缓存
A 第五步：线程把旧数据写回缓存
读请求比写请求慢，两个事件之间没有办法满足 Happens before，无法确定谁先谁后的问题，为什么第四步要回写缓存，而不是删除缓存呢，因为在高并发场景下，删除缓存会引起抖动，在QPS很大的情况下会有问题，当前我们也可以使用 singleflight 同一事件一个请求查询DB,回写缓存
如何解决
其实本质上 第四步和第五步，如果有优先级是不是就可以了，第四步的优先级比第五步高，第四步可以用Redis 的 SET EX, 覆盖已存在的 key, 第五步使用SET NX 不存在才进行设置，这样就保证了更新缓存的请求大于读缓存的请求，这样就不会覆盖了。
工业化的解决方案：
中间利用了 CANAL 监听 MySQL binlog 的变化，然后将同一个key hash 然后消费到同一个job 中进行消费，保证了同一个key 的时序性
扩展：
MySQL 同步ES 使用CANAL 然后使用job消费写入到ES中，如果遇到超时3次的消息放入到死信队列中，然后定时JOB 去消费，如果还是失败告警出来，人共介入进行检查
