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

在分布式系统中，CAP理论是最为基础的指导性理论。该理论可以概括为consistency，availability，和tolerance to network partitions，一个基于shard的分布式系统最多可以拥有其中的两点。在大多数情况下，我们会保留availability和tolerance to network partitions，然后使用eventual consistency代替strong consistency。现在我们考虑一个问题，如果一个分布式系统使用event bus向外界提供内部数据的更新，可不可以使用eventual consistency来实现呢？

问题描述：

在这里我们不妨以AWS DynamoDB为例。DDB提供的是读时一致性。也就是说当有多个对数据的更新操作时，DDB的使用者在读取数据时可以指定是以eventual consistency的方式读还是以strong consistency的方式读。现在我们有一个如下的分布式系统：

其中黑色的实线表示的是调用流，绿色的虚线表示的是数据流。整个系统的按照如下的方式工作：

1. Client可以更新DDB里的内容；
2. Client在更新内容以后向一个SQS的消息队列里发送一条通知，表示DDB的内容被更新了；
3. ECS Service会定期轮询该消息队列的内容
4. 如果ECS Service收到了消息队列的通知就重新读取DDB的内容，然后把DDB的内容格式化定义好的消息，通过SNS发送出去。

假如ECS Service使用最终一致性的方式读取DDB，那么我们没有办法保证该service可以将DDB中的最终一致状态发出去，因为在读取DDB时读到的结果可能是不一致的，而在DDB达到一致状态后，该service却没有事件通知它重新发送。

解决方案讨论：

1. 使用polling机制。ECS Service可以使用某种时间区间对DDB里的数据进行检查。一旦发现数据改变了，就重新发送一个event。这种方法在DDB里数据比较少时是可行的。而对于数据比较多的情况明显不可行。一个改进的方法是可以将message queue里的数据存在一个地方以作为polling的数据源。而在安全的eventual consistency的时间过后将该数据删除。
2. 使用比较机制。比如我们可以给每一个update分配一个唯一的版本号。这样在我们处理消息队列的消息时，我们可以比较消息队列中希望的版本和DDB里的版本号，只有在DDB里的版本号大于消息队列的版本号时我们才处理该消息。否则，我们不出消息队列的消息，而是等待一段时间后再回来尝试处理消息队列的消息。