高并发场景下的缓存+数据库双写不一致问题分析与解决方案设计

影者东升

　　
1、最初级的缓存不一致问题以及解决方案
　　问题：先修改数据库，再删除缓存，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致
解决思路:
先删除缓存，再修改数据库，如果删除缓存成功了，如果修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致,因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中

2、比较复杂的数据不一致问题分析
　　数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改
一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中
　　数据变更的程序完成了数据库的修改
　　完了，数据库和缓存中的数据不一样了。。。。

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

4、数据库与缓存更新与读取操作进行异步串行化
　　这块内容有待细究：
这里笔者给出自己的理解,为了解决复杂的数据不一致问题（本文大标题2已解释），就必须要保证读和写都是原子性，以免出现上述的第一个请求刚清除缓存，还没来得及更新数据库，另一个请求就来读，而出现的读写不一致问题的发生，我们在下图“库存服务”里面加了一个内存队列，在一个队列里面先来先执行，有顺序，从而不会互相干扰了，根据相同的商品id，进行hash取值，再对内存队列取模进而路由到其中一个内存队列里面去。
如果并发访问实在是太大到亿级，那么还要做集群，对于集群的话就是说每个机器上都有内存队列，同一个商品id的读写请求可能会被路由到不同的机器上去（不同的机器的内存队列），具体可参考下面的第二个图。