现在将高速缓存应用于业务当中已经十分常见了，甚至可能跟数据库的频率不相上下。你的用户量如果上去了，直接将一个裸的 MySQL 去扛住所有压力明显是不合理的。这里的高速缓存，目前业界主流的就是 Redis 了，如何保证缓存与数据库的双写一致性?

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题?

上亿高并发，如何保证缓存与数据库的双写一致性?

1、最初级的缓存不一致问题以及解决方案

问题：先修改数据库，再删除缓存，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致。

解决思路：

先删除缓存，再修改数据库，如果删除缓存成功了修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致，因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中。

2、并发下数据缓存不一致问题分析

问题：

第一个请求数据发生变更，先删除了缓存，然后要去修改数据库，此时还没来得及去修改;

第二个请求过来去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中;

第三个请求读取缓存中的数据 (此时第一个请求已经完成了数据库修改的操作)。

完了，数据库和缓存中的数据不一样了。。。。

问题分析：

只有在对同一条数据并发读写的时候，才可能会出现这种问题。其实如果说你的并发量很低的话，特别是读并发很低，每天访问量就1万次，那么很少的情况下，会出现刚才描述的那种不一致的场景;但如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况。

解决思路：

数据库的缓存更新与读取操作进行串行化，一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。

1. 首先我们的项目里维护一组线程池和内存队列。

2. 更新数据的时候，根据数据的唯一标识将请求路由到一个jvm队列中，去更新数据库,然后请求结束。

3. 读取数据的时候，先查缓存，如果发现数据不在缓存中，那么将根据唯一标识路由之后，也发送同一个jvm内部的队列中，重新读取数据库后更新缓存,最后请求结束。

这里有一个需要优化的点，比如一个队列中，连续存在多个更新缓存请求串在一起是没意义的，这样重复的查询数据库并更新缓存的操作应该优化：如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接让后面的读请求阻塞个200ms左右(这里只是举个例子，实际值可以根据服务的响应时间和机器的处理能力来计算)，然后再次查询缓存，如果缓存没有值就查数据库，拿到结果后不用更新缓存，直接返回给页面即可。

高并发解决方案：http://www.hkt4.com/dedicated/hkcdn.html