高并发下缓存与数据库双写不一致解决方案
1、最初级的缓存不一致问题以及解决方案
先删除缓存，再修改数据库，如果修改数据库的时候，别的线程查到旧数据并更新缓存，缓存中是旧数据，数据出现不一致。
先修改数据库，再删除缓存，如果删除缓存成功了修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致，因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中。
2、并发下数据缓存不一致问题分析
问题：
第一个请求数据发生变更，先删除了缓存，然后要去修改数据库，此时还没来得及去修改；
第二个请求过来去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中；
第三个请求读取缓存中的数据 (此时第一个请求已经完成了数据库修改的操作)。
完了，数据库和缓存中的数据不一样了。。。。
问题分析：
只有在对同一条数据并发读写的时候，才可能会出现这种问题。其实如果说你的并发量很低的话，特别是读并发很低，每天访问量就1万次，那么很少的情况下，会出现刚才描述的那种不一致的场景;但如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况。
解决思路
数据库的缓存更新与读取操作进行串行化，一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。
1. 首先我们的项目里维护一组线程池和内存队列。
2. 更新数据的时候，根据数据的唯一标识将请求路由到一个jvm队列中，去更新数据库,然后请求结束。
3. 读取数据的时候，先查缓存，如果发现数据不在缓存中，那么将根据唯一标识路由之后，也发送同一个jvm内部的队列中，重新读取数据库后更新缓存,最后请求结束。
这里有一个需要优化的点，比如一个队列中，连续存在多个更新缓存请求串在一起是没意义的，这样重复的查询数据库并更新缓存的操作应该优化：如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接让后面的读请求阻塞个200ms左右(这里只是举个例子，实际值可以根据服务的响应时间和机器的处理能力来计算)，然后再次查询缓存，如果缓存没有值就查数据库，拿到结果后不用更新缓存，直接返回给页面即可。
或者采用另一种方案：监听数据库的binlog，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。Canal 模拟 MySQL 主从复制的交互协议，把自己伪装成一个 MySQL 的从节点，向 MySQL 主节点发送 dump 请求，MySQL 收到请求后，就会开始推送 Binlog 给 Canal，Canal 解析 Binlog 字节流之后，转换为便于读取的结构化数据，供下游程序订阅使用。
