返回信息流延迟双删
这是一条镜像帖。来源：北邮人论坛 / iwhisper / #7458630同步于 2024/8/5
该镜像源已超过 30 天没有更新，可能在源站已被删除。
IWhisper机器人发帖
求问一个缓存和数据库一致性的问题
IWhisper#615
2024/8/5镜像同步13 回复
订阅后，新回复会通过你的通知中心匿名送达。
13 条回复
面试的时候面试官拷打问我的项目黑马点评：就是redis里面存的数据，在update后，还没有来得及删除redis上旧的缓存，这个时候新来了一个select请求会返回旧的数据 这样的不一致问题如何解决呢？
当时没有答上，因为确实想不到好的办法，只能说我解决不了一致性问题，黑马点评也没有给出解决方案，请问技术大佬们这个如何解决呢 谢谢了[ema23][ema23][ema23]
面试官提出的问题涉及到缓存与数据库数据一致性的常见问题。以下是一些解决这种不一致问题的策略：
1. **延时双删策略**：
- 在更新数据库后，先删除Redis中的缓存。
- 稍后（例如几百毫秒后）再次执行删除操作，确保缓存已经被清除。这段时间足以让正在进行中的查询操作使用新数据更新缓存。
2. **设置缓存过期时间**：
- 给Redis中的缓存数据设置合理的过期时间（TTL），即使更新操作未能及时清除缓存，过期的缓存也会被自动删除。
- 缺点是缓存过期时间内可能会出现数据不一致。
3. **使用发布/订阅模式**：
- 当数据库更新操作发生时，发布一个消息。
- Redis订阅这个消息，并在接收到消息后，主动删除对应的缓存。
4. **分布式锁**：
- 在更新数据库之前，先获取一个分布式锁。
- 更新数据库后，释放锁之前删除缓存。
- 其他查询操作在读取缓存前必须尝试获取同一个锁，如果获取不到则直接查询数据库并更新缓存。
5. **异步更新缓存**：
- 数据更新操作不直接更新缓存，而是将更新操作放入消息队列。
- 由另一个服务消费消息队列中的消息，并负责更新缓存。
6. **乐观锁或版本号**：
- 为数据增加版本号或时间戳。
- 缓存不仅存储数据，还存储版本号或时间戳。
- 查询时比对版本号或时间戳，如果不一致则从数据库加载最新数据并更新缓存。
7. **业务折衷**：
- 分析业务对数据一致性的要求，如果某些场景下短暂的不一致是可以接受的，则可以不采取复杂的同步策略。
以下是你可以对面试官表述的答案：
"针对您提出的Redis缓存与数据库数据不一致的问题，我们可以采用以下几种策略来解决：
首先，可以实施延时双删策略，即在更新数据库后立即删除缓存，并在短时间内再次执行删除操作，以确保缓存数据的一致性。
其次，为缓存数据设置合理的过期时间，这样即使缓存未能及时更新，数据也不会在缓存中驻留太久。
另外，可以使用发布/订阅模式，在数据库更新时发布消息，由Redis订阅并清除对应的缓存。
分布式锁也可以用来保证更新操作的原子性，在更新数据库并删除缓存后才释放锁。
如果业务场景允许，还可以采用异步更新缓存的方式，通过消息队列来同步缓存。
最后，还可以通过为数据增加版本号或时间戳，使得每次查询时都能验证数据的一致性。
以上方法可以根据具体的业务需求和系统架构来选择合适的策略。"
如果是强一致，阻塞。
数据加字段
isdeleted的
update改true。更新完了改false。
如果是true就阻塞，false了通知返回
: 当时没有答上，因为确实想不到好的办法，只能说我解决不了一致性问题，黑马点评也没有给出解决方案，请问技术大佬们这个如何解决呢 谢谢了[ema23][ema23][ema23]
有道理！当时面试官提醒了加一个字段 但是我说我没实现[ema12]项目没有给出解决方案 感谢！
: 数据加字段
: isdeleted的
: ............
解决不了，除非加锁
: 当时没有答上，因为确实想不到好的办法，只能说我解决不了一致性问题，黑马点评也没有给出解决方案，请问技术大佬们这个如何解决呢 谢谢了[ema23][ema23][ema23]