共计 1443 个字符，预计需要花费 4 分钟才能阅读完成。
在高并发的业务场景下，数据库大多数状况都是用户并发拜访最单薄的环节。所以，就须要应用 redis 做一个缓冲操作，让申请先拜访到 redis，而不是间接拜访 Mysql 等数据库。这样能够大大缓解数据库的压力。具体业务流程如下：
读取缓存步骤个别没有什么问题，然而一旦波及到数据更新：数据库和缓存更新，就容易呈现缓存和数据库间的数据一致性问题。不论是先写数据库，再删除缓存；还是先删除缓存，再写库，都有可能呈现数据不统一的状况。举个例子：
1. 如果删除了缓存 Redis，还没有来得及写库 MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
2. 如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会呈现数据不统一状况。
因为写和读是并发的，没法保障程序, 就会呈现缓存和数据库的数据不统一的问题。如何解决？这里给出两个解决方案，先易后难，联合业务和技术代价抉择应用。
一、延时双删策略
在写库前后都进行 redis.del(key) 操作，并且设定正当的超时工夫。具体步骤是：
1）先删除缓存
2）再写数据库
3）休眠 500 毫秒（依据具体的业务工夫来定）
4）再次删除缓存。
那么，这个 500 毫秒怎么确定的，具体该休眠多久呢？
须要评估本人的我的项目的读数据业务逻辑的耗时。这么做的目标，就是确保读申请完结，写申请能够删除读申请造成的缓存脏数据。
当然，这种策略还要思考 redis 和数据库主从同步的耗时。最初的写数据的休眠工夫：则在读数据业务逻辑的耗时的根底上，加上几百 ms 即可。比方：休眠 1 秒。
二、设置缓存的过期工夫
从实践上来说，给缓存设置过期工夫，是保障最终一致性的解决方案。所有的写操作以数据库为准，只有达到缓存过期工夫，则前面的读申请天然会从数据库中读取新值而后回填缓存
联合双删策略 + 缓存超时设置，这样最差的状况就是在超时工夫内数据存在不统一，而且又减少了写申请的耗时。
三、如何写完数据库后，再次删除缓存胜利？
上述的计划有一个毛病，那就是操作完数据库后，因为种种原因删除缓存失败，这时，可能就会呈现数据不统一的状况。这里，咱们须要提供一个保障重试的计划。
1、计划一具体流程
（1）更新数据库数据；
（2）缓存因为种种问题删除失败；
（3）将须要删除的 key 发送至音讯队列；
（4）本人生产音讯，取得须要删除的 key；
（5）持续重试删除操作，直到胜利。
然而，该计划有一个毛病，对业务线代码造成大量的侵入。于是有了计划二，在计划二中，启动一个订阅程序去订阅数据库的 binlog，取得须要操作的数据。在应用程序中，另起一段程序，取得这个订阅程序传来的信息，进行删除缓存操作。
2、计划二具体流程
（1）更新数据库数据；
（2）数据库会将操作信息写入 binlog 日志当中；
（3）订阅程序提取出所须要的数据以及 key；
（4）另起一段非业务代码，取得该信息；
（5）尝试删除缓存操作，发现删除失败；
（6）将这些信息发送至音讯队列；
（7）从新从音讯队列中取得该数据，重试操作。
