在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 的读已经过时了。
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 @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 算法就能解决安全问题了?
|