采取最简单的例子：
首先要问一个具体的问题，我希望可以通过指向正确的URL来快速给出一个答案：这是由某些规则定义的复制的结果，例如文档总是按照保存的顺序复制，或者第一个文档的成功复制取决于设计文档是否恰好首先到达目的地？在我做的快速实验中，两个文档都成功验证了，但我试图找出是否在某个规范中定义了该结果，或者它是否依赖于实现。
要问一个更随意的后续问题，可能没有一个答案，还有什么可以发生以及出现了哪些解决方案来解决这些问题？很明显，不同服务器可以同时（并且我犹豫地使用该词）具有不同版本的验证功能。我认为验证器可以向后兼容，其中每个新版本都会向switch语句添加一个case，它会查找文档的schema_version属性。然后，如果版本2文档到达版本3验证器是网守的服务器，它将被允许进入。如果版本3文档到达版本2验证器，它有点棘手，它可能取决于是否严格或宽大是适用于申请的默认值。但是，这些事情中的任何一个都可能发生，或者复制规则是否确保即使服务器上下移动，更新和删除都在整个地方进行，复制连接是间歇性的和间接的，文档永远不会到达在适当的验证函数之前的给定服务器上，并且验证函数永远不会到达太迟来处理它应该检查的文档之一？
我很可能会过度复杂或忽略了一些禅宗的洞察力，但痛苦的经历告诉我，我不够聪明，无法预测什么样的状态并发系统可以进入。
编辑：
正如Marcello在评论中所说，单个服务器上的更新具有序列号，复制按序列号顺序应用更新。我有一个模糊的想法，就是这样，但我对细节仍然很模糊。我正在尝试找到最简单的模型，让我了解在复杂的CouchDB系统中能够和不可能发生的事情。
假设我将服务器A的状态设置为空，并对其进行了三次文档写入。所以它的状态可以表示为以下字符串： A1，A2，A3
假设服务器B还有三个写入：B1,B2,B3
我们将A复制到B，因此B的状态现在为：B1,B2,B3,A1,A2,A3。虽然可能是A更新在进入B时采用了序号，因此状态现在为：B1, B2, B3, B4(A1), B5(A2), B6(A3)。
如果我理解正确的话，复制器还记录了A3的所有内容都已复制到B的事实，并且它恰好将此记录存储为B内部状态的一部分，但我想知道这是否是一个可以在简单模型中忽略的实现细节。
如果您运行这些规则集，A更新和B更新将保留在它们被复制到的任何服务器上。也许他们唯一可能失序的方法是你做了一些事情，比如复制A到B，删除A上的A1和B上的A2，将A复制到C，然后将B复制到C，在C上留下一个状态：{{ 1}}。
这有什么意义吗？也许字符串不是可视化它的正确方法，也许最好想到，我不知道，机场中的一堆队列（服务器），机场工作人员（复制者）根据某些特定方式将人员从队列移动到队列规则，并将自己置于试图跳过队列的人的脑海中，即以某种方式在当前队列中领先于他们的人之前进入队列。这具有个性化模型的优势，但我们可能不希望在机场复制人员。
或许有一些方法可以将它作为河内式游戏的塔式游戏，虽然使用FIFO队列代替LIFO堆栈。
这是我希望找到的模型 - 就行为而言绝对精确，所有不相关的实现细节都被剥夺了，使用任何隐喻或图像使其最容易直观。
答案 0 :(得分：2)
基本用例很简单。 CouchDB uses sequence numbers索引数据库更改并询问需要复制哪些更改。顺序隐含在此算法中，您不应该发生什么。作为旁注，the replication process only copies the last revision of a document，但这不会改变任何有关订单的内容。