这是一个创建于 1519 天前的主题，其中的信息可能已经有所发展或是发生改变。
在How to do distributed ocking 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 的读已经过时了。
 | 1 2i2Re2PLMaDnghL 2021-10-22 11:08:56 +08:00 我所知范围内，CouchDB 在写入时需要提供之前的 rev，类似 CAS 乐观锁。 应当是两个不同的机制，你提的这个问题我直觉上觉得更经典一些 |
 | 2 lance6716 2021-10-22 17:54:28 +08:00 via iPhone （没看原文链接），client2 如果是先读取这个值，运算后提交的话（比如 x=x+1 ）如果它从 storage 中读取到了 client1 的写入自然就是预期行为 |
| 4 lance6716 2021-10-22 18:12:18 +08:00 via iPhone 先存进 storage，然后 client1 解锁，client2 拿到锁，client2 读取到了 client1 的写入，没毛病 |
| 5 lance6716 2021-10-22 18:15:35 +08:00 via iPhone 哦哦，lost 是 client2 的 write lost 了 |
 | 6 JasonLaw OP @lance6716 #4 这种就是顺序执行了，肯定没啥问题，也就是Client 1 获取到了锁，执行 read-modify-write，释放锁。接下来 Client 2 获取到了锁，执行 read-modify-write，释放锁”。 |
| 7 JasonLaw OP  1 @lance6716 #5 不是，我说的情况是 Client 2 最后会覆盖掉 Client 1 所做的改变，fencing token 也没用，因为 Client 2 的 token 就是比 Client 1 的大。 |
 | 8 Mikex88 2021-10-22 21:02:48 +08:00 @JasonLaw lost update 发生在 write 和之前的 read 不一致。client2 read(拿锁) 的时候 client1 已经存进 Storage 啊 |
| 9 JasonLaw OP @Mikex88 #8 你说“ client2 read(拿锁) 的时候 client1 已经存进 Storage 啊”，哪里看出来的？ |
 | 10 Brentwans 2022-01-02 16:49:43 +08:00 你说是有问题的，文章评论中有人提的。而且我个人觉得对于 token 这个算法就挺有问题的，都不需要边界场景。因为超期一旦当 client1 和 2 都申请到锁，大家都有所那就等于没有锁了呀。那如果这个 token 解决算法能弥补这个问题。是不是能够得出，我不要锁，直接用这个 token 算法就能解决安全问题了？ |
Select Language