木木夕2023-09-07 来自广东现在面试都这样用一些在生产不切实际的方案吗？Cache Aside 就能满足百分之99的场景了。你们真的会在项目中这样应用嘛？作者回复: 我从实践和面试上来讲这个问题。 实践中用不用？答案是基本不用，你说 99% 的比例我也差不多赞同。但是你说我有没有用过，我确实用过，各种骚操作。 面试中呢？答案就更加简单了，Cache Aside 大家都会，我凭什么给你 offer 呢？ 我个人认为，即便公司用不着，你自己也应该尝试一下，毕竟还是那句话，简单的东西大家都会，你凭什么在面试中拿到 offer 呢？
1
stevensafin
2023-09-06 来自广东实际有应用吗作者回复: 嘿嘿，都搞过。
1
好运来
2023-09-13 来自广东回查请求加分布式锁图中 右边加分布式锁 -》读数据a=2 -》更新缓存a=1 这里是不是错了，应该是 右边加分布式锁 -》读数据a=2 -》更新缓存a=2 这样吧？作者回复: 嗯嗯，感谢勘误。
peter2023-09-06 来自河南“同一个 key 的请求都落在同一个节点上，依旧存在并发更新的问题”，既然是同一个key的请求，为什么还会有并发问题？作者回复: 没有 singleflight 的时候，你多个线程更新数据库和缓存这种场景。
penbox2023-09-06 来自四川1. 分布式方案的思路二里面，是先提交事务再释放分布式锁，顺序能反过来吗？ 不可以。释放分布式锁之后，读请求就能直接从数据库加载数据了，此时更新事务可能还没有提交，读到的就会是旧的数据。 2. 有一种使用分布式锁的方案是先加分布式锁，再执行本地事务并提交，最后删除缓存，释放分布式锁。这种方案有什么缺点？有没有可能出现数据不一致？ 分布式锁的占用时间也会很长，还不能保证一致性。 在失败的情况下：如果事务提交失败，不会删除缓存，数据还是一致的；如果事务提交成功，但是缓存删除失败了，那么数据就不一致了。作者回复: 赞！