基于最终收敛的分布式系统设计讨论2

基于最终收敛的分布式系统设计讨论2

问题描述

假如我们有一个service，提供了数据访问和修改的API。比如update() 来进行数据的修改，get()来进行数据的访问。现在我们仍然使用AWS来实现这个系统如下：

如果我们想要更新DDB中的一条记录时，我们一般仅仅更新部分信息。普遍的工作流程如下：

1. 使用get()从DDB读取一条记录
2. 根据读取的记录更新其中部分信息
3. 使用update()讲更新过的记录写回到DDB

现在我们假设仍然使用eventual consistency。那我们就会遇到一个问题，我们在读记录时无法保证一定读到最新的记录，这样我们在写回时可能会覆盖掉更新的记录。事实上我们再仔细想一想这个问题，即便使用了strong consistency来读取记录同样会有这样的问题，这是因为可能有多个client并行的对同一条记录进行更改。只是使用了eventual consistency会使这个更加严重而已。那么我们应该如何来解决这个问题呢？

解决方案讨论

我们在此仅仅讨论一种笔者心中的最佳解决方案。如果读者有其他解决方案，欢迎留言讨论交流。这里的解决方法是基于一种叫做RVN的机制，全称是record version number。也就是对于每条记录都会维护自己的版本号。而在每次更新时都将版本号加1。有了RVN之后，大体上更新一条记录的流程变为使用get()或者一条记录，然后基于获得的记录更新部分内容，同时将RVN加1，然后尝试将记录用update()写回。而service在执行update()时，则比较RVN是否比DDB中的RVN大1.是则执行更新操作，不是则抛出异常。而client在获得异常以后，可以重新尝试对DDB中的记录进行更新。Service端的流程图如下：

问题的扩充

在实际中，我们会发现这样的场景涉及到更多需要考虑的问题。比如，在client重新尝试update记录时，它怎么保证自己要更新的内容仍然是有效的呢？再比如，service如何可以在分布式环境中保证对记录的检查和更新是原子性的呢？另外还有很多于RVN应用有关的技巧，涉及到service的performance和availability。这些都需要不断地寻找更聪明的解决方案。