自学内容网 自学内容网

关于在分布式环境中RVN和使用场景的介绍4

简介

在前面的文档中,我们介绍了RVN的概念,通过RVN可以解决的某类问题和使用技巧,以及处理RVN的逻辑的具体实现。在本文中,我们将要介绍关于如何使用RVN解决另一种在分布式系统中常出现的问题。

问题

假设我们创建了一个service来维护某种record。我们的service允许client获取record,并且基于现有record的内容对record进行修改。举例说,假设我们的record记录了client一方的某种操作的数量。Client每完成一次操作就将service一侧的count加1。当然我们有其它的方法,但是我们现在要求count的计算部分在client一侧完成。具体来说,我们的record可以定义为:

Record {
    int ID;
    int count;
}

Service提供的API 为:

void updateRecord(Record record);

但是在分布式系统中,可能有多个client同时试图更新同一个record,这样这两个client的update就会互相覆盖,从而使最终的结果错误。例如在下图,我们数据库中保存的ID “1”的数量是10。现在有两个client同时获取了这个记录,然后同时试图将数量改为11。最终两个带有11的结果将互相覆盖,从而我们错误的保存了11,而不是12。我们将如何避免这个问题?

解决方法

这个问题同样可以使用RVN来解决。具体来说,我们在record里加入RVN,代表某条记录的版本号。对于每次更新,client都要先获取当前记录以及它的版本号,然后将版本号加1写入到update record的request里。而service端需要检查request的RVN,确保该RVN大于当前保存的保本好,最后再将该记录和RVN写入到数据库。我们详细描述该过程如下:

现在client1和client2都获取了RVN为1的记录,然后都将RVN更新为2,发送request去试图更新service一侧的数据。Service一侧的逻辑如下:

在这里我们需要特别说明几点。为了保证处理的正确性,service必须保证在处理record的过程中RVN一直是合理的,否则就可能出现两个thread都认为自己的RVN是正确的,从而仍然互相覆盖。这样我们可以使用lock住record的ID,并且在处理完record之后再unlock,来保证处理的正确性。我们也可以使用DynamoDB的condition update来达到相同的目的,具体可以参见《关于在分布式环境中RVN和使用场景的介绍3》。

在这种逻辑下,后获得锁的thread将会发现它所持有的RVN已经不是合理的RVN了,所以它会拒绝处理它持有的request,并且向client汇报这一情况(比如可以throw exception)。而client可以重新从service获得最新的RVN的record,再次尝试根据最新的记录进行更新。

问题扩展

在我们讨论的解决方案里,我们期望service和client可以遵守共同的规则在一起工作,比如期望所有的client都可以基于获取的RVN每次增加1。只有在这种情况下,我们的数据才能被维护正确。假如,我们的API是公开的API,也就是说client并不总是可信的。Client可能会破坏规则给RVN增加2或者更多来试图非法获取修改数据的规则。在这种情况下,我们可以给每一个record version生成一个UUID来代替RVN。Client必须提供当前version的UUID以获取修改当前record的资格。在每次record被改变时都生成新的UUID。

参考文档

《关于在分布式环境中RVN和使用场景的介绍1》

《关于在分布式环境中RVN和使用场景的介绍2》

《关于在分布式环境中RVN和使用场景的介绍3》


原文地址:https://blog.csdn.net/weixin_42325834/article/details/136223743

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!