dongfuye1

@swulling 分布式锁无法避免版本一致性的问题，这个问题可以参见 ddia 作者关于 redis 锁的论述，他提出的通用方案是应用层引入版本，但本文针对 redis 缓存场景，提出了无需应用层引入版本的方案，这样的方案会更通用

@swulling 你说的删除方案无法解决本文开头提出的问题哈，因为你删除了所有数据，那么你的 ver 重新计数，因此出问题的 5 写入 redis 时，查到的 ver 有可能跟读取数据之前的 ver 碰巧相同而写入，导致一致性问题

@swulling 那么当数据库的数据更新时。你的这个方案需要怎么操作呢？直接删除数据的话，会导致你的版本重复，导致不一致

@hobochen 首先您笼统的说槽点太多，而不能指出任何一个与原理相关的问题，这不是讨论问题的态度。
其次，我看了许多论文，如果你认为文章内容与某篇论文相悖，或者抄袭某篇论文，请指出。
另外，这个库本身代码量不大，目前就是我一人开发，而我的另一个开源库 dtm ，则有三十多贡献者

@swulling 你的这个 idea 和文中做法有相近的地方，但对于中间进程 crash ，自动解除锁定等情况，还是不够的

@Citrus 标题起的有些大，是希望能够吸引更多的读者，但实际内容，确实对得起“首个”“彻底解决”这些词
我从全网搜索的结果来看，是首个。在这方面，关于一致的方案，看到有一篇很深入的，也就是文中给出链接介绍携程的，但是该文中的 update_time 字段方案不够通用，对业务有要求，并且是全量更新缓存，代价大；而锁方案，其实依旧存在问题，参见 https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html 。本文提出的方案，无需对应用层模型施加限制，按需计算缓存，适用所有的应用模型。
如果您有类似的方案，欢迎讨论，或者给出链接。
性能方面，因为跟常见的缓存方案差不多，没有给详细的分析过程。实际的分析过程其实很简单，对于最终一致方案，每个数据库的数据更新操作，跟常见方案相同，只是把删除缓存变成了使用一个 lua 脚本来删除，对于读取缓存和写缓存的操作，变成了两个 lua 脚本操作，其他不变，因此是高效的。您可以参考文末给出的开源库进行验证哈。

进程内部的锁，加 redis 锁，保证每个时刻只有一个查询到 db

@JRyan 这个锁定时间默认 3s ，可配置。已考虑锁定时间过期的情况，两个进程同时更新缓存时，会查看缓存中的锁，只有还拥有锁的那一个进程（即最后锁缓存的进程，会查询到最新的数据）能够更新成功

@ztjryg4 非常正确