解决方案
那么我们这里列出来所有策略，并且讨论他们优劣性。
- 先更新数据库，后更新缓存
- 先更新数据库，后删除缓存
- 先更新缓存，后更新数据库
- 先删除缓存，后更新数据库
先更新数据库，后更新缓存
这种方法是不推荐使用的，因为在更新缓存那一步有的业务需求缓存中的值并不是从数据库查，而是需要一系列计算而拿到缓存值，那这时候更新缓存的代价是非常大的。当有大量对数据库进行写的请求时，读的并不多，写一次请求就要更新一下缓存，那性能损耗真的很大，因为Redis是针对内存的。
比如：当数据库有个值为100数值，我们有十个请求是要对其每次减五，这个期间完全没进行读的操作，那么先更新数据库，那会有十个请求对缓存更新，从而产生大量的冷数据，当不更新缓存而失去删除缓存，那么有读请求时只会更新一次。
先更新缓存，后更新数据库
这种方法不需要我们考虑了吧，和第一种方法是一样的。
先删除缓存，后更新数据库
该方法也会有问题，具体出现的原因：
这时来了两个请求，请求 A（更新） 和请求 B（查询）
- 请求 A 会先删除 Redis 中的数据，然后去数据库进行更新操作
- 此时请求 B 看到 Redis 中的数据时空的，会去数据库中查询该值，补录到 Redis 中
- 但是此时请求 A 并没有更新成功，或者事务还未提交
那么这时候就会产生数据库和 Redis 数据不一致的问题。如何解决：其实最简单的解决办法就是延时双删的策略。
上述的保证事务提交完以后再进行删除缓存还有一个问题，就是如果你使用的是 Mysql 的读写分离的架构的话，那么其实主从同步之间也会有时间差。
此时来了两个请求，请求 A（更新） 和请求 B（查询）
- 请求 A 更新操作，删除了 Redis
- 请求主库进行更新操作，主库与从库进行同步数据的操作
- 请 B 查询操作，发现 Redis 中没有数据
- 去从库中拿去数据
- 此时同步数据还未完成，拿到的数据是旧数据
解决办法就是如果是对 Redis 进行填充数据的查询数据库操作，就强制将其指向主库进行查询。
先更新数据库，后删除缓存
这一种方法也会出现问题，当更新数据库成功了，但在删除缓存的阶段出错了没有删除成功，那此时再读取缓存的时候每次都是错误的数据了。
解决方案就是利用消息队列进行删除的补偿。具体的业务逻辑如下：
- 请求 A 先对数据库进行更新操作
- 在对 Redis 进行删除操作的时候发现报错，删除失败
- 此时将Redis 的 key 作为消息体发送到消息队列中
- 系统接收到消息队列发送的消息后再次对 Redis 进行删除操作
但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起，所以这时会有一个优化的方案，我们知道对 Mysql 数据库更新操作后再 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。
总结
这些方法都有利弊，如在第二种先删除缓存，后更新数据库这个方法最后讨论了要更新 Redis 的时候强制走主库查询就能解决问题，那么这样的操作会对业务代码进行大量的侵入，但不需要增加的系统，不需要增加整体的服务的复杂度。最后一种方法我们最后讨论了利用订阅 binlog 日志进行搭建独立系统操作 Redis，这样的缺点其实就是增加了系统复杂度。
所有的选择都需要我们对业务处理的评估来进行选择，没有一种技术是对所有业务通用的。没有最好的技术，只有最适合我们的。
