这又是一个高频的场景面试题，同时，它也是一个没有标准答案的、可以跟面试官讨论很久的面试题。
对于这个面试题，我的观点是：”没有完美的方案，只有最适合某场景的方案。 “
这个问题表面上看是数据一致性的问题，其实根本上，又是数据一致性、系统性能和系统复杂度的选择与取舍。
下面我们先历数一下各种技术方案，环肥燕瘦两相宜，总有一款适合你。
1、先更新MySQL，再更新Redis
这个方案存在如下问题：
（1）如果先更新MySQL成功了，还未对Redis进行更新的间隙期，这时如果请求过来，读到的都是Redis的更新前数据。
（2）如果先更新MySQL成功了，再更新Redis失败了的话，后面的请求读到的都是Redis的更新前数据，并且后续的补救方案很难做。
补救方案一：为Redis更新失败，将MySQL中的对应数据也回滚了，以此达到两者数据的一致性。但MySQL是主数据源，它代表的是数据的“权威性”，这样做显然并不合理。
补救方案二：通过Redis重试更新的方式进行补救。但如果重试也失败了，还要继续重试吗？是设置固定的重试次数，还是一直重试到成功为止？
另外，重试时间间隔设置多少？时间间隔设置长了，影响业务的时间也会变长；时间间隔设置短了，重试成功率又会降低。这些其实都是问题。
（3）两个线程同时更新的并发问题，如下：
2、先更新Redis，再更新MySQL
这个方案，要比方案一的“先更新MySQL，再更新Redis”合理一些。原因在于更新完Redis的话，哪怕还没更新MySQL，这时如果请求过来，读到的都是Redis更新后的新数据。
另外，先更新Redis成功，再更新MySQL失败，可以通过再删除Redis所对应的数据进行补救。
但其依然存在如下问题：
（1）如果先更新Redis成功了，再更新MySQL失败了的话，还未对Redis所对应的数据进行删除补救的间隙期，这时如果请求过来，读到的都是Redis未生效的新数据。
（2）如果先更新Redis成功了，再更新MySQL失败了的话，然后再删除Redis对应的数据也失败的时候，应该如何处理？如果通过重试机制继续进行删除Redis的话，又会面临之前说的重试次数和间隔期的问题。
（3）两个线程同时更新的并发问题，如下：
3、先更新MySQL，再删除Redis
这个方案可以解决“并发更新”的问题，但依然会存在下面的两个问题：
（1）如果先更新MySQL成功了，还未对Redis进行删除的间隙期，这时如果请求过来，读到的都是Redis的删除前数据。
（2）如果先更新MySQL成功了，再删除Redis失败了的话，后面的请求读到的都是Redis的删除前数据，并且后续的补救方案很难做。
4、先删除Redis，再更新MySQL
这个方案能解决方案3中遗留的两个棘手的问题：
（1）如果先删除Redis成功了，还未对MySQL进行更新的间隙期，此时对于该条数据而言，只存在于MySQL一个存储载体中，也就没有了数据一致性的问题。
（2）如果先删除Redis成功了，再更新MySQL失败了的话，此时对于该条数据而言，只存在于MySQL一个存储载体中，所谓的补救方案也就不需要了，直接当这条数据没更新成功。
OK，整体看起来似乎“天下无贼”了，但真的如此吗？其实不然，如果配合上Redis的“读策略”，还是会有数据一致性的问题。
4.1 先删除Redis，再更新MySQL + Redis读策略
Redis的读策略：
- 如果读取的数据在Redis中存在，则直接返回数据；
- 如果读取的数据在Redis中不存在，则从MySQL中读取数据，然后将数据写入到Redis，并返回数据。
这样一来，就会存在如下问题：
某商品的库存数为10个，用户A购买一件商品时进行库存扣减，因此第一步先删除了Redis中的库存数。
这时，用户B查询该商品的库存，发现Redis中并没有该商品的库存，于是从MySQL中读取库存数后，写入到了Redis中（10个）。
然后，用户A更新数据库，将库存数从10个扣减为9个。
最终，Redis中的库存数是10个，MySQL中的库存数是9个。
4.2 先删除Redis，再更新MySQL + Binlog同步
该方案将填充Redis的操作，改为通过DataBus和Canal同步Binlog的方式，这样可以解决方案4.1中的Redis读策略带来的数据一致性问题。
但是，这种方案的适用于数据量不大，可以完全吃进Redis缓存中，并设置为永不过期的场景。
而那种数据量庞大到不能全部吃进Redis缓存中，需要在数据读取的时机来写入Redis，长时间未被读取的数据则过期淘汰的场景，就不适合了。
因为这种方案的缓存命中率太低了，也就失去了其应有的价值。
4.3 先删除Redis，再更新MySQL + Redis读策略 + 延时双删
这个方案稍复杂了一些，是在方案4.1中“先删除Redis，再更新MySQL + Redis读策略”，又增加了最后一步Redis删除的操作。
它可以解决“最终，Redis中的库存数是10个，MySQL中的库存数是9个”的数据一致性场景。
也可以跟方案4.2中 “数据量庞大到不能全部吃进Redis缓存中，需要在数据读取的时机来写入Redis，长时间未被读取的数据则过期淘汰”的不适合场景进行互补。
有人会说，这种方案也不能100%保证解决数据一致性的问题，如果最后一步删除操作失败了怎么办？
确实，它并不能保证100%。
但如果第一步删除Redis成功了，第二步Redis读策略恰好在这个间隙期发生并写入Redis成功了，而第三步删除Redis又失败了，这种概率有多大？0.0000001%的可能性有没有？
btw：此处请杠精留言，我最喜欢看到你们面红耳赤、声嘶力竭地杠的样子，很性感。
5、分布式锁
有人说，直接用分布式锁，不就把问题都解决了吗？干吗叽叽歪歪地写这么多字？
是的，分布式锁完全可以解决一致性问题，但你别忘了，引入锁机制的最大弊端是什么？是性能。
而我们用Redis当缓存的初衷是什么？还是性能。有句话怎么说的来着？勿忘初心，方得始终。
结语
还是那句话，系统架构设计中，没有银弹，也没有完美的方案，只有最适合某场景的方案。
