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

我们首先介绍一下分布式环境中开发会遇到的一类问题，然后介绍什么是RVN以及怎么样使用RVN来解决该类问题。最后我们会介绍一下RVN的典型使用用例。

问题

假设我们在分布式环境中发布notification。对于该notification感兴趣的用户可以订阅该notification的主题，然后就可以收到所有发布的消息。但是因为我们是基于分布式环境的，所以notification的接受顺序不能保证和发送顺序一致。下图展现了使用AWS实现的一个实例。

该用例展示的细节如下：

1. Client可以subscribe一个SNS topic来接收通过该topic发送的notification；
2. 一个ECS service通过该SNS topic发送notification；
3. SNS端发送的顺序为1和2；
4. Client端接收的顺序为2和1.

如果不进行处理，这种不一致的消息顺序可能会带来麻烦。比如，client使用notification来更新某个app的显示内容，那么就有可能使用旧的消息来覆盖新的消息从而向用户展示了过时的消息。

于消息顺序不一致问题类似的还有消息丢失，消息重复等。

相关的概念

在描述解决方法前先介绍一些有关的概念。

• Idempotent：幂等。一个操作是幂等的以为该操作可以执行多次，执行的结果和执行一次是相同的。在这里我们可以延伸一下这个定义，我们追求的操作是可以多次，可以乱序，可以丢失中间的部分操作，但是最终的执行的结果仍然是相等的。
• RVN (Record Version Number)：对同一个key的消息维护的单调递增版本号。

RVN和其使用的介绍

我们对同一个key的消息维护一个单调递增的版本号。也就是说同一个key的消息，每次更新时的版本号加1。这样RVN就代表了发送端的消息顺序。

使用RVN的一个要求是发送的消息必须包含全部信息，而不是基于前面版本的增量信息。在此条件下，client通过在本地维护接收到的最后一个RVN可以保持消息的处理结果是“幂等”的。Client处理逻辑如下：

对于各种的详细介绍如下：

• 消息乱序：client会发现接收到的消息的RVN小于已经处理过的RVN，也就是说接收到的RVN是一个已经过时的消息。Client可以选择直接忽略该消息的处理。
• 消息丢失：client会发现接收到的消息的RVN大于已经处理过的RVN，但是不连续。因为每一个消息都包含全部的信息，所以client只要继续处理新收到的消息就可以。
• 消息重复：client会发现接收到的消息的RVN等于已经处理过的RVN。这种情况client可以选择继续处理该接收到的消息，因为消息的处理是保证幂等的。

对于消息重复需要特别说明一下，一般都会选择处理重复的消息，这是因为处理重复的消息结果仍然是对的，而且重复消息可能是因为上一次处理失败而再次尝试该消息。

以上是对RVN的基本介绍。RVN还会有一些特殊的用途，放在以后的文章里介绍。