相信大家都听过缓存一致性，随便百度一下就有各种文章，无非就是更新数据库和缓存的先后顺序及策略。一般有3种方案：先更新数据库再更新缓存；先删除缓存再更新数据库；先更新数据库再删缓存。但是无论哪种方案都是在缓存不宕机这个前提下的，也许有的人会说缓存有高可用架构，是的，但是无论是切到从服务或者等主服务恢复都有可能丢失数据。所以缓存不要用在需要保证原子性和持久性的场景下，比如扣库存。
记得数据库的ACID吗，缓存可以做到原子性和一致性，但是做不到持久性，试想缓存也有持久性，那不就变数据库了么，一旦涉及到磁盘IO整体的性能就会降一大截。也许有人会说缓存不也有持久化方案吗，是的，但那都是异步的日志或者dump方案，一旦变成同步原子操作，那就变成我上面说的了。再回到缓存一致性上来，因为数据库操作和缓存操作一定不是原子的，所以没有严格意义上的一致性之说，所以缓存不要用在需要严格一致的场景下。
再拿扣库存举例子，无论先扣缓存还是先扣数据库，哪个操作算是整个事务的提交？一定是数据库事务。缓存的宕机不应该影响数据库事务。比如先扣缓存，然后执行数据库，这个时候缓存挂了，但是单子已经建了，库存也扣了，整个事务就算是完成的，即便缓存恢复回滚也不应该影响结局，这个时候就有可能是不一致的。那是不是就不需要缓存了呢，当然不是，读的时候可以用缓存，一般情况下的业务都是读多写少的场景，比如页面上展示的库存数等这些读的场景都可以用缓存来减少数据库压力。那么如果缓存数据和数据库不一致会有问题吗？我们先看会有哪些情况。
1，数据库更新完后，缓存宕机，这个时候切到从服务但是数据还未同步，缓存数据可能比数据库多。那么用户会看到1个库存，但是下单的时候提示已经卖完了。虽然用户体验上会差一点，但是大部分都是可以理解的，相信买过双11或秒杀的用户都知道。
2，缓存执行完后，数据库执行失败，缓存又没有回滚，缓存数据比数据库少。这个时候用户会看到0个库存，但是还可以下单，当然一般库存为0的情况下前面的链路就会卡住下单了。可能的结果就是最后几个库存没有卖掉，虽然也算bug，但至少没有资损。
做过电商的都知道，超卖资损才是大问题，一般事故定级分两种，舆情和资损。资损超过一定金额那就是一级一级的事故等级了，所以一般在设计的时候宁愿牺牲一些性能也要保证不资损。
当然99.9....9%的情况下缓存数据和数据库数据是一致的，多少个9就看架构了，如果你为了性能放弃这0.0...01%的故障率，当然可以将缓存作为完整事务，像redis这种缓存本身就支持了原子操作，完全可以只扣缓存，然后刷到数据库中。最好的方案也许是不同场景用不同实现，日常情况下用数据库，秒杀等情况下直接用缓存，因为秒杀的时间段短，在这1，2分钟内缓存宕机的概率更低，当然这势必增加了系统复杂度。至于如何取舍就看你怎么选择了。
再回过头来看缓存一致性，首先我们要明确不管开头说的3种方案中哪种，数据库必须执行成功的，一旦数据库执行失败缓存要么回滚要么清空。那么实际情况下会用哪种呢，首先说并发不高的情况，其实哪种都可以，因为并发不高，完全可以通过加锁要把数据重新load到缓存就行了。再说高并发的情况，一旦把缓存删除，那就出现缓存击穿问题，又要用一套方案来解决缓存击穿，所以实际场景中，不会允许在高并发的时候还允许改数据。比如双11搞活动的时候，是不允许修改商品信息的，一般提前几个小时就会锁定修改入口，所有缓存都会预热固定下来。
