最终一致性
理论上来说，给缓存设置过期时间，就可以保证最终一致性了。具体其实就是写入数据的时候，直接写入数据库，然后缓存设置过期时间，等到过期时间到了，就会从数据库中读取最新的数据。
应用场景： 可能就是电商网页的一些详细信息什么的，可以允许出错，等过期时间到了，再更新为最新的数据展示，但是例如金融行业，计算金钱的就不可能要最终一致性了，必须实时一致性。
实时一致性
先写数据库，后写缓存
先写数据库，后写缓存，如果写缓存失败，就会出现数据库和缓存不一致的情况
解决方案：很简单，写数据的时候，先删除缓存，再更新数据库就可以了
其实就是从两个操作失败的场景来分析就会明白了
- 删除缓存失败，那么就会再次执行删除缓存的操作，可以自定义重试几次，删除换缓存失败的情况，缓存和数据库数据一直，删除缓存成功，会以数据库数据为主，将相应数据写入数据库，等到再次请求缓存，用到这个数据的时候，再将数据放入到缓存中
- 更新数据库失败，更新数据库失败就会回滚，此时缓存中没有数据，以数据库的数据为主，无非就是多次重试执行sql，直到成功或者说规定重试几次，返回更新数据失败的提示
先删除缓存，再写数据库
看完上面的解释，你是不是以为使用了先删除缓存，再写数据库的方式就可以避免数据库和缓存数据不一致的情况，我在这里告诉你，不是的！
有一种场景，在一个线程删除缓存成功，准备将数据写数据库的时候，此时另外一个线程来请求这个数据，发现缓存中没有，直接去请求数据库，将数据库的数据读入到了缓存中，然后第一个线程才将数据写入数据库，此时缓存和数据库的数据出现了不一致的情况，数据库中是最新的数据，而缓存中是原来的数据。你以为已经给它删除了，但是如果一个线程出现上述这场景，就和没有删除的情况一样，仍然出现了缓存和数据库数据不一致的问题
解决方案：
延时双删
- 删除缓存
- 更新数据库
- 休眠一定时间之后，再次删除缓存
这个一定时间是根据什么来考虑的那？
其实就是考虑到上述的读请求的情况，你应该自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
如果你用了mysql的读写分离架构怎么办？
ok，在这种情况下，造成数据不一致的原因如下，还是两个请求，一个请求A进行更新操作，另一个请求B进行查询操作。
（1）请求A进行写操作，删除缓存
（2）请求A将数据写入数据库了，
（3）请求B查询缓存发现，缓存没有值
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
（5）请求B将旧值写入缓存
（6）数据库完成主从同步，从库变为新值
上述情形，就是数据不一致的原因。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。
采用这种同步淘汰策略，吞吐量降低怎么办？
ok，那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。
第二次删除,如果删除失败怎么办？
这是个非常好的问题，因为第二次删除失败，就会出现如下情形。还是有两个请求，一个请求A进行更新操作，另一个请求B进行查询操作，为了方便，假设是单库：
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
（6）请求A试图去删除请求B写入对缓存值，结果失败了。
ok,这也就是说。如果第二次删除缓存失败，会再次出现缓存和数据库不一致的问题。
如何解决呢？
具体解决方案，且看博主对第(3)种更新策略的解析。
数据库与缓存更新与读取操作进行异步串行化
更新数据的时候，根据数据的唯一标识，将操作路由之后，发送一个jvm内部的队列中
读取数据的时候，如果发现数据不在缓存中，那么将重新拉取数据+更新缓存的造作，根据唯一标识路由之后，也发送同一个jvm内部的队列中
一个队列对应一个工作线程
每个工作线程串行拿到对应的操作，然后一条一条的执行选择的话，一个数据变更的操作，先执行，删除缓存，然后再去更新数据库，但是还米有完成更新
此时如果一个读请求过来，读到了空的缓存，那么可以优先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成
这有有一个优化的点，一个队列中，其实多个更新缓存请求串在一个是没有意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的队列了，那么就不用再放一个更新的操作了，直接等待前面的更新操作完成
待那个队列对应的工作线程完成了上一个操作的数据的数据库的修改之后，才会去执行下一个操作，此时会从数据库获取最新的值，然后写入缓存，如果请求还在等待时间范围，不断轮询可以发现可以直接取到值了，那么直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的值
先更新数据库，再删缓存
首先，先说一下。老外提出了一个缓存更新套路，名为《Cache-Aside pattern》。其中就指出
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。
另外，知名社交网站facebook也在论文《Scaling Memcache at Facebook》中提出，他们用的也是先更新数据库，再删缓存的策略。
这种情况不存在并发问题么？
不是的。假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生
（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存
ok，如果发生上述情况，确实是会发生脏数据。
然而，发生这种情况的概率又有多少呢？
发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。
假设，有人非要抬杠，有强迫症，一定要解决怎么办？
如何解决上述并发问题？
首先，给缓存设有效时间是一种方案。其次，采用策略（2）里给出的异步延时删除策略，保证读请求完成以后，再进行删除操作。
还有其他造成不一致的原因么？
有的，这也是缓存更新策略（2）和缓存更新策略（3）都存在的一个问题，如果删缓存失败了怎么办，那不是会有不一致的情况出现么。比如一个写数据请求，然后写入数据库了，删缓存失败了，这会就出现不一致的情况了。这也是缓存更新策略（2）里留下的最后一个疑问。
如何解决？
提供一个保障的重试机制即可，这里给出两套方案。
注意
在进阶中的方案仍然有有一些问题需要实际考虑
由于读请求进行了非常轻度的异步化，所以一定要注意超时时间的问题，每个读请求必须在超时时间内返回
该解决方案最大的风险点在于，可能数据更新很频繁，导致队列中积压了大量更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库
务必通过一些模拟真实的测试，看看更新数据的频繁是怎样的
另外一点，因为在 一个队列中，可能会积压针对多个数据项的更新操作，因此要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据更新的操作，如果一个内存队列里居然会积压100个商品的库存修改操作，每个库存修改都要豪飞10ms完成，那么最后一个商品的去请求，可能要等待1s，这个时候就导致读请求长时间的阻塞
一定要根据实际业务系统的运行情况，去做一些压力测试，和模拟线上环境，去看看罪犯满给的时候，内存队列可能会挤压多少更新操作，如果读请求在200ms内返回，那还是可以接受的
如果一个内存队列中可挤压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的机器，那么就会提高读请求的响应时间
其实根据之前的项目经验，一般数据的写频率都是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的
多实例部署的请求路由
可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过nginx服务器路由到相同的服务实例上
热点商品问题，导致请求的倾斜
对某一个商品的请求特别高，全部请求到相同机器的相同的队列去了，可能会造成某台机器压力过大