V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
JasonLaw
V2EX  ›  数据库

fencing token 还是解决不了 lost update 吧

  •  
  •   JasonLaw · 2021-10-21 17:31:25 +08:00 · 872 次点击
    这是一个创建于 1114 天前的主题,其中的信息可能已经有所发展或是发生改变。

    How to do distributed locking — Martin Kleppmann’s blog中,Martin Kleppmann 说以下代码是 broken 的。

    // THIS CODE IS BROKEN
    function writeData(filename, data) {
        var lock = lockService.acquireLock(filename);
        if (!lock) {
            throw 'Failed to acquire lock';
        }
    
        try {
            var file = storage.readFile(filename);
            var updated = updateContents(file, data);
            storage.writeFile(filename, updated);
        } finally {
            lock.release();
        }
    }
    

    因为 Client 1 会覆盖掉 Client 2 所写的东西,如下图所示:

    然后他说可以使用 fencing token 解决 lost update 问题,如下图所示,因为 Client 1 的 fencing token 小于 Storage 中的 token 。

    但是如果 Client 1 先存进 Storage 呢? Client 2 最后会覆盖掉 Client 1 所做的改变,这样不是还是存在 lost update 问题吗?因为 Client 2 所做的修改是基于旧的数据,在提交修改时,Client 2 的读已经过时了。

    11 条回复    2022-01-02 16:50:38 +08:00
    2i2Re2PLMaDnghL
        1
    2i2Re2PLMaDnghL  
       2021-10-22 11:08:56 +08:00
    我所知范围内,CouchDB 在写入时需要提供之前的 rev,类似 CAS 乐观锁。
    应当是两个不同的机制,你提的这个问题我直觉上觉得更经典一些
    lance6716
        2
    lance6716  
       2021-10-22 17:54:28 +08:00 via iPhone
    (没看原文链接),client2 如果是先读取这个值,运算后提交的话(比如 x=x+1 )如果它从 storage 中读取到了 client1 的写入自然就是预期行为
    JasonLaw
        3
    JasonLaw  
    OP
       2021-10-22 18:06:50 +08:00
    @lance6716 #2 啥意思?不太明白,能够具体描述一下吗?
    lance6716
        4
    lance6716  
       2021-10-22 18:12:18 +08:00 via iPhone
    先存进 storage,然后 client1 解锁,client2 拿到锁,client2 读取到了 client1 的写入,没毛病
    lance6716
        5
    lance6716  
       2021-10-22 18:15:35 +08:00 via iPhone
    哦哦,lost 是 client2 的 write lost 了
    JasonLaw
        6
    JasonLaw  
    OP
       2021-10-22 18:18:33 +08:00
    @lance6716 #4 这种就是顺序执行了,肯定没啥问题,也就是“Client 1 获取到了锁,执行 read-modify-write,释放锁。接下来 Client 2 获取到了锁,执行 read-modify-write,释放锁”。
    JasonLaw
        7
    JasonLaw  
    OP
       2021-10-22 18:20:49 +08:00   ❤️ 1
    @lance6716 #5 不是,我说的情况是 Client 2 最后会覆盖掉 Client 1 所做的改变,fencing token 也没用,因为 Client 2 的 token 就是比 Client 1 的大。
    Mikex88
        8
    Mikex88  
       2021-10-22 21:02:48 +08:00
    @JasonLaw lost update 发生在 write 和之前的 read 不一致。client2 read(拿锁) 的时候 client1 已经存进 Storage 啊
    JasonLaw
        9
    JasonLaw  
    OP
       2021-10-22 22:33:28 +08:00 via iPhone
    @Mikex88 #8 你说“ client2 read(拿锁) 的时候 client1 已经存进 Storage 啊”,哪里看出来的?🤐
    Brentwans
        10
    Brentwans  
       2022-01-02 16:49:43 +08:00
    你说是有问题的,文章评论中有人提的。而且我个人觉得对于 token 这个算法就挺有问题的,都不需要边界场景。因为超期一旦当 client1 和 2 都申请到锁,大家都有所那就等于没有锁了呀。那如果这个 token 解决算法能弥补这个问题。是不是能够得出,我不要锁,直接用这个 token 算法就能解决安全问题了?
    Brentwans
        11
    Brentwans  
       2022-01-02 16:50:38 +08:00
    @Brentwans 打错了,你说的没错,的确是有这个问题的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2720 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 14:40 · PVG 22:40 · LAX 06:40 · JFK 09:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.