dongfuye1 最近的时间轴更新
dongfuye1

dongfuye1

V2EX 第 508556 号会员,加入于 2020-09-17 16:49:08 +08:00
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 非常正确
@cocong 乱序不一致这一节,就已经回答了最终版本一致的原理了哈。其他强一致的原理也在相关章节讲述了。
有些场景是并发比较大,数据库扛不住,但是在数据写入时,响应时长变大是可接受的,那么这个时候强一致方案就能解决问题
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2634 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 11:08 · PVG 19:08 · LAX 04:08 · JFK 07:08
Developed with CodeLauncher
♥ Do have faith in what you're doing.