Redis数据更新，是先更新数据库还是先更新缓存?

什么是写时更新和读时更新

写时更新：当我们往数据库写数据的时候我们去更新缓存，包括先更新缓存再更新数据库和先更新数据库再更新缓存。
读时更新：当我们往数据库写数据的时候我们直接删除缓存，然后其他请求读数据的时候更新缓存。包括先删除缓存再更新数据和先更新数据库再删除缓存。

缓存更新到底是读更新好还是写更新好？

读更新好，为什么？

1. 如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
2. 同时有请求A和请求B进行更新操作，那么会出现 （1）线程A更新了数据库 （2）线程B更新了数据库 （3）线程B更新了缓存 （4）线程A更新了缓存。这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。

那么也就是说，如果是写更新的话，不管从性能的角度还是从线程安全的角度来说这种方案都不好。

读时更新有没有什么问题？

前面我们说了，如果是写更新，会有效率和线程安全性的问题，那如果是读更新又会有什么问题呢？
读时更新：当我们往数据库写数据的时候我们直接删除缓存，然后其他请求读数据的时候更新缓存。包括先删除缓存再更新数据库和先更新数据库再删除缓存。

先更新数据库再删除缓存

问题一、如果在高并发的场景下，会出现数据库与缓存数据不一致

1. 缓存刚好失效 线程 A 查询数据库，得一个旧值
2. 线程 B 将新值写入数据库
3. 线程 B 删除缓存
4. 线程 A 将查到的旧值写入缓存

但出现的概率特别低，为什么呢？

我们需要线程A读操作必需在B线程写操作前进入数据库操作，而又要晚于B写操作更新缓存，所有的这些条件都具备的概率基本并不大。那么如何解决这个低概率问题呢？
设置缓存的过期时间，这样可以达到最终一致性

问题二、如果删除缓存失败或更新数据库失败了会怎样？

• 第一步操作数据库成功，第二步删除缓存失败，会导致数据库里是新数据，而缓存里是旧数据。
• 第一步操作数据库就失败了，第二步更新缓存不会执行，不会出现数据不一致。

如何解决删除缓存失败的问题？

将需要删除的 key 发送到消息队列中 自己消费消息，获得需要删除的 key 不断重试删除操作，直到成功

先删除缓存再更新数据库

问题一、如果在高并发的场景下，会出现数据库与缓存数据不一致

1. 线程 A 删除了缓存 线程 B 查询，发现缓存已不存在
2. 线程 B 去数据库查询得到旧值
3. 线程 B 将旧值写入缓存
4. 线程 A 将新值写入数据库

如何解决？设置缓存的过期时间，这样可以达到最终一致性

问题二、如果删除缓存失败或更新数据库失败了会怎样？

• 第一步删除缓存成功，第二步更新数据库失败，数据库和缓存的数据还是一致的。
• 第一步删除缓存就失败了，第二步更新数据库不会去执行，数据库和缓存的数据还是一致的。

也就是说并不会导致数据不一致问题。

小总结：对比两种策略

先删除缓存，再更新数据库：在高并发下相对更容易出现数据不一致问题，但在原子性被破坏时（删除缓存失败或更新数据库失败）并不会出现数据一致性问题
先更新数据库，再删除缓存：在高并发下相对出现数据不一致问题概率很低，但在原子性被破坏时（删除缓存失败或更新数据库失败）会出现数据一致性问题

要解决这一切的比较简单的解决方案就是要给KEY设置过期时间