@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 非常正确

@cocong 乱序不一致这一节，就已经回答了最终版本一致的原理了哈。其他强一致的原理也在相关章节讲述了。
有些场景是并发比较大，数据库扛不住，但是在数据写入时，响应时长变大是可接受的，那么这个时候强一致方案就能解决问题

https://github.com/dtm-labs/rockscache
确保缓存与数据库一致的 redis 库

@lookStupiToForce DB 可以告诉缓存最终版本是多少，但是缓存两次拿到的都是最新版本，但是进程暂停等问题会导致缓存写入的版本存款

@lookStupiToForce 目前没看到 mysql 等数据库提供自动维护 update time 的功能，基本都是 orm 库维护的。
你提出的版本问题，在分布式数据库中已解决，采用的是共识算法，你可以研究一下

@lookStupiToForce 我看到 update_time 的维护者都是应用程序，不是 DB 。假如机器 A 和机器 B 的时钟差了 2s ，那么部署在这两台机器上的进程，就很容易发生 update_time 与实际版本相悖的情况，即使时钟只是差了 10ms ，那么也是会发生 v1 的 update_time > v2 的 update_time 。

@star7th 附言也不能添加了:(

@star7th 方法是通用的，目前实现了 go 语言的。目前没办法内容了，因此我把说明加到附言了

@lscbqr 方法是通用的，目前给出了 go 的实现，其他语言的实现工作量不大，照着 go 的改一改，比较快

@xuelu520 我也看过 N 种，但没有一种表明自己解决了图中的问题。本方案确实是首创，如果有疑问，还请帮忙提出讨论

@lookStupiToForce 如果采用更新时间，那么分布式应用下，时间是非精确的，非递增的，谷歌最先进的 truetime ，也有 7 毫秒的误差，非常困难。
如果采用版本号，要求数据库里的数据必须有这个版本号，大多数应用系统，都没有单独的版本字段，添加这个字段的开发量很大。
本方案既不依赖时间，又不依赖版本，不引入额外工作的情况下解决了这个问题