V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  dongfuye1  ›  全部回复第 1 页 / 共 5 页
回复总数  87
1  2  3  4  5  
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 乱序不一致这一节,就已经回答了最终版本一致的原理了哈。其他强一致的原理也在相关章节讲述了。
有些场景是并发比较大,数据库扛不住,但是在数据写入时,响应时长变大是可接受的,那么这个时候强一致方案就能解决问题
https://github.com/dtm-labs/rockscache
确保缓存与数据库一致的 redis 库
2022-05-19 18:28:17 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@lookStupiToForce DB 可以告诉缓存最终版本是多少,但是缓存两次拿到的都是最新版本,但是进程暂停等问题会导致缓存写入的版本存款
2022-05-19 18:22:22 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@lookStupiToForce 目前没看到 mysql 等数据库提供自动维护 update time 的功能,基本都是 orm 库维护的。
你提出的版本问题,在分布式数据库中已解决,采用的是共识算法,你可以研究一下
2022-05-19 17:21:35 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@lookStupiToForce 我看到 update_time 的维护者都是应用程序,不是 DB 。假如机器 A 和机器 B 的时钟差了 2s ,那么部署在这两台机器上的进程,就很容易发生 update_time 与实际版本相悖的情况,即使时钟只是差了 10ms ,那么也是会发生 v1 的 update_time > v2 的 update_time 。
2022-05-19 08:35:41 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@star7th 附言也不能添加了:(
2022-05-19 08:31:35 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@star7th 方法是通用的,目前实现了 go 语言的。目前没办法内容了,因此我把说明加到附言了
2022-05-19 08:29:48 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@lscbqr 方法是通用的,目前给出了 go 的实现,其他语言的实现工作量不大,照着 go 的改一改,比较快
2022-05-19 08:13:01 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@xuelu520 我也看过 N 种,但没有一种表明自己解决了图中的问题。本方案确实是首创,如果有疑问,还请帮忙提出讨论
2022-05-19 08:09:49 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@lookStupiToForce 如果采用更新时间,那么分布式应用下,时间是非精确的,非递增的,谷歌最先进的 truetime ,也有 7 毫秒的误差,非常困难。
如果采用版本号,要求数据库里的数据必须有这个版本号,大多数应用系统,都没有单独的版本字段,添加这个字段的开发量很大。
本方案既不依赖时间,又不依赖版本,不引入额外工作的情况下解决了这个问题
2022-05-12 19:11:05 +08:00
回复了 dongfuye1 创建的主题 分享创造 首个彻底解决缓存和数据库一致性问题的方案
@ily433664 dtm 恢复正常了之后,会轮询未结束的事务,找到这个事务,然后回查,发现已提交,然后去调用 update redis
1  2  3  4  5  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5533 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 73ms · UTC 06:39 · PVG 14:39 · LAX 23:39 · JFK 02:39
Developed with CodeLauncher
♥ Do have faith in what you're doing.