对于读多写少的高并发场景，我们会经常使用缓存来进行优化。比如说支付宝的余额展示功能，实际上99%的时候都是查询，1%的请求是变更（除非是土豪，每秒钟都有收入在不断更改余额），所以，我们在这样的场景下，可以加入缓存，用户->余额。
以下这张图是我们读取数据的操作。
Redis缓存与数据一致性问题
那么基于上面的这个出发点，问题就来了，当用户的余额发生变化的时候，如何更新缓存中的数据，也就是说。
- 我是先更新缓存中的数据再更新数据库的数据；
- 还是先修改数据库中的数据再更新缓存中的数据
这就是我们经常会在面试遇到的问题，数据库的数据和缓存中的数据如何达到一致性？首先，可以肯定的是，redis中的数据和数据库中的数据不可能保证事务性达到统一的，这个是毫无疑问的，所以在实际应用中，我们都是基于当前的场景进行权衡降低出现不一致问题的出现概率。
此外我们还可以通过给缓存设置一个过期时间，无论以上的两种操作使用哪一种，都能够在理论上保持数据的最终一致性。这种方案下，在写数据的时候，都以数据库为主，先把数据库数据写入后，再更新缓存，如果失败了，那么原来的缓存无论是否存在，那么只要经过过期时间，那么读操作时，就会重新从数据库中读出，然后同步到缓存中。
我们接着讨论以上两种操作:
1.先删除缓存，再更新数据库。在大型分布式系统环境下，就需要考虑并发时的问题了。
这种处理方式，可能会有如下情况，线程A，写入(更新)数据时，先删除缓存后，同时，有一个线程B，此时去读数据，先去缓存中读，此时刚被线程A删除了，于是去数据库读还未被线程A更新的数据，这时候就会读到脏数据了。 紧接着，线程B会把脏数据写入缓存，而线程A会把更新后的数据写入数据库。导致缓存与数据不一致。
参考方式: 给缓存设置过期时间，否则会一直读到脏数据。
处理方式:
网上有几种处理方式:
- 双删策略
处理步骤: - 先删除缓存。
2.写入数据库
3.休眠一秒。执行删除缓存(目的是把1秒内产生的脏数据重新从缓存中删除)
缺点: 需要把控好休眠时间，同时时间可能会过长，当请求量很大时，再短的时间也会造成响应过长。其次这个请求时间是跟读操作时，会产生脏数据的时间有关的。
如果采用读写分离数据库的情况呢？ 跟以上情况的区别就在于，当线程B去读数据库时，可能读到的是还未更新到从库的脏数据，因为当我们休眠是，不仅需要考虑读操作的完整执行完的时间，还需要加主从复制这段时间的几百Ms。
还是继续这个问题，分为两次删除，如果第二次删除失败了呢？
先说下，第一次删除失败，是不影响什么的。所以说下第二次删除失败的情况，此时删除失败，还是会造成脏数据的问题，也就是缓存一致性问题。 继续说第二种解决方案
- 先修改数据库中的数据再更新缓存中的数据
同样存在这种情况，线程A查询操作(读操作)，线程B更新操作。
线程A先执行，线程B后执行。线程A先查询时，去缓存读取时，缓存失效了，此时继续去数据库读，这时候线程B修改数据库后，把数据写入缓存了。在此之后，线程A才执行把数据写入缓存中，此时缓存中的任然是脏数据。
分为以下几个步骤:
（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存
然而，发生这种情况的概率又有多少呢？
发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。
意思就是该情况下，只有当线程B的写步骤比线程比线程A的读数据库更快很多才会出现。
如果一定需要做控制的话，可以考虑以下几点:
- 做redis过期策略。(时间上不好控制)
- 上面说的延迟删除策略。(删除不一定成功)
基于第二种的话，如果删除失败，就会有一致性问题了。可以使用以下方案:
1: 可以使用消息队列做重试保障机制
缺点: 1. 对业务代码造成大量侵入。2. 造成不必要的请求冗余。
-
方案二
上述的订阅binlog程序在mysql中有现成的中间件叫canal，也可以使用定时任务等去控制。控制删除失败重试次数、时间、频率。
最后还有一种， 更新数据库，并且更新缓存。
但是这种情况基本上都不推荐，（线程安全角度）
同时有请求A和请求B进行更新操作，那么会出现
（1）线程A更新了数据库
（2）线程B更新了数据库
（3）线程B更新了缓存
（4）线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据。
