dongfuye1 最近的时间轴更新
dongfuye1

dongfuye1

V2EX 第 508556 号会员,加入于 2020-09-17 16:49:08 +08:00
首个彻底解决缓存和数据库一致性问题的方案
分享创造  •  dongfuye1  •  2022-06-21 16:39:33 PM  •  最后回复来自 hsymlg
44
分布式事务客户端 PHP -client v0.1.1 发布,支持 Saga, Tcc,二阶段消息
PHP  •  dongfuye1  •  2022-05-09 23:01:55 PM  •  最后回复来自 ywisax
1
消息最终一致性的架构革命
  •  2   
    分享创造  •  dongfuye1  •  2022-05-10 14:16:07 PM  •  最后回复来自 fatyoung
    56
    分布式事务的这些常见用法都有坑,来看看正确姿势
    推广  •  dongfuye1  •  2021-12-10 17:07:34 PM  •  最后回复来自 tienyc
    1
    深度剖析 Saga 分布式事务
    推广  •  dongfuye1  •  2021-11-25 09:50:11 AM
    5 个月 3.6K⭐,我的开源项目 DTM 成了微服务架构的关键中间件
    推广  •  dongfuye1  •  2021-11-12 14:25:02 PM  •  最后回复来自 BeijingBaby
    3
    深度剖析分布式事务性能
  •  1   
    分享创造  •  dongfuye1  •  2021-10-11 12:07:07 PM  •  最后回复来自 jinwu
    1
    用 PHP 轻松完成一个分布式事务 TCC,保姆级教程
  •  1   
    推广  •  dongfuye1  •  2021-10-12 15:29:22 PM  •  最后回复来自 momocraft
    7
    dongfuye1 最近回复了
    2022-05-31 07:53:15 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @swulling 分布式锁无法避免版本一致性的问题,这个问题可以参见 ddia 作者关于 redis 锁的论述,他提出的通用方案是应用层引入版本,但本文针对 redis 缓存场景,提出了无需应用层引入版本的方案,这样的方案会更通用
    2022-05-31 07:48:47 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @swulling 你说的删除方案无法解决本文开头提出的问题哈,因为你删除了所有数据,那么你的 ver 重新计数,因此出问题的 5 写入 redis 时,查到的 ver 有可能跟读取数据之前的 ver 碰巧相同而写入,导致一致性问题
    2022-05-30 22:27:48 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @swulling 那么当数据库的数据更新时。你的这个方案需要怎么操作呢?直接删除数据的话,会导致你的版本重复,导致不一致
    2022-05-30 22:06:09 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @hobochen 首先您笼统的说槽点太多,而不能指出任何一个与原理相关的问题,这不是讨论问题的态度。
    其次,我看了许多论文,如果你认为文章内容与某篇论文相悖,或者抄袭某篇论文,请指出。
    另外,这个库本身代码量不大,目前就是我一人开发,而我的另一个开源库 dtm ,则有三十多贡献者
    2022-05-30 21:56:27 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @swulling 你的这个 idea 和文中做法有相近的地方,但对于中间进程 crash ,自动解除锁定等情况,还是不够的
    2022-05-23 16:37:16 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @Citrus 标题起的有些大,是希望能够吸引更多的读者,但实际内容,确实对得起“首个”“彻底解决”这些词
    我从全网搜索的结果来看,是首个。在这方面,关于一致的方案,看到有一篇很深入的,也就是文中给出链接介绍携程的,但是该文中的 update_time 字段方案不够通用,对业务有要求,并且是全量更新缓存,代价大;而锁方案,其实依旧存在问题,参见 https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html 。本文提出的方案,无需对应用层模型施加限制,按需计算缓存,适用所有的应用模型。
    如果您有类似的方案,欢迎讨论,或者给出链接。
    性能方面,因为跟常见的缓存方案差不多,没有给详细的分析过程。实际的分析过程其实很简单,对于最终一致方案,每个数据库的数据更新操作,跟常见方案相同,只是把删除缓存变成了使用一个 lua 脚本来删除,对于读取缓存和写缓存的操作,变成了两个 lua 脚本操作,其他不变,因此是高效的。您可以参考文末给出的开源库进行验证哈。
    2022-05-23 10:12:05 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    进程内部的锁,加 redis 锁,保证每个时刻只有一个查询到 db
    2022-05-22 21:50:01 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @JRyan 这个锁定时间默认 3s ,可配置。已考虑锁定时间过期的情况,两个进程同时更新缓存时,会查看缓存中的锁,只有还拥有锁的那一个进程(即最后锁缓存的进程,会查询到最新的数据)能够更新成功
    2022-05-22 09:54:44 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @ztjryg4 非常正确
    2022-05-20 18:07:51 +08:00
    回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
    @cocong 乱序不一致这一节,就已经回答了最终版本一致的原理了哈。其他强一致的原理也在相关章节讲述了。
    有些场景是并发比较大,数据库扛不住,但是在数据写入时,响应时长变大是可接受的,那么这个时候强一致方案就能解决问题
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2716 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 15:32 · PVG 23:32 · LAX 08:32 · JFK 11:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.