缓存数据库双写一致性问题

无论是先写缓存后写数据库，还是写些数据库在写缓存都可能会有一致性问题，可以考虑用以下方式：

• 方式一：采用延迟双删策略

写操作：1、先删除缓存；2、更新数据库；3、再次删除缓存

读操作：先读缓存，缓存没有在读数据库，然后写入缓存

写操作双删解释： 第一次删除缓存的原因:第一次之所以要选择先删除缓存，而不是直接更新数据库，主要是因为先写数据库会存在一个比较关键的问题，那就是缓存的更新和数据库的更新不是一个原子操作，那么就存在失败的可能性。如果写数据库成功了，但是删缓存失败了!那么就会导致数据不一致。第二次删除缓存的原因，是为了防止并发较大时，在写操作写入数据库过程中，读操作又将旧值写入了缓存，导致的不一致情况

一般来说，一些并发量不大的业务，这么做就已经可以了，先删除缓存，后更新数据(如果业务量不大，其实先更新数据库，再删除缓存其实也可以)，基本上就能满足业务上的需求了。
但是如果是并发量比较高的话，那么就可能存在一定的问题。

这里采用删除而不是直接更新的原因：

举个例子，我们需要通过缓存进行扣减库存的时候，你可能需要从缓存中查出整个订单模型数据，把他进行反序列 自化之后，再解析出其中的库存字段，把他修改掉，然后再序列化，最后再更新到缓存中。
可以看到，更新缓存的动作，相比于直接删除缓存，操作过程比较的复杂，而且也容易出错

• 方式二：基于消息中间件实现

如果更新Redis失败，同时在将数据发到MQ之前的时间，应用重启了，这时候MQ就没有需要更新的数据，如果Redis对所有数据没有设置过期时间（一般都会设置），同时在读多写少的场景下，只能通过人工介入来更新缓存

• 方式三：采用binlog方式解决一致性，客户端数据库与缓存解耦（而且这个方案虽然比较重，但却容易形成统一的解决方案）