什么是CouchDB复制协议？ 这是否像Git？
是否有技术文档描述两个沙发之间的复制是如何工作的？
CouchDB复制的基本概述是什么？ 有什么值得注意的特点呢？
不幸的是没有描述复制协议的详细文档。 CouchDB中只有内置的参考实现，Filipe Manana的重写也可能成为未来的新的实现。
但是，这是总体思路：
关键点
如果你知道Git，那么你知道Couch复制是如何工作的。 复制与使用Git这样的分布式源代码pipe理器进行推送或拉取非常相似。
CouchDB复制没有自己的协议。 复制器只是连接到两个DB作为客户端，然后从一个读取并写入另一个。 推送复制是读取本地数据并更新远程数据库; 拉复制反之亦然。
- 有趣的事实1 ：复制器实际上是一个独立的Erlang应用程序，在它自己的过程中。 它连接到两个沙发，然后从一个读取logging，并写入其他。
- 有趣的事实2 ：CouchDB 无法知道谁是普通客户端，谁是复制者（更不用说复制是推还是拉）。 这一切看起来像客户端连接。 其中一些读取logging。 其中一些人写logging。
一切都从数据模型stream出
复制algorithm是微不足道的，无趣的。 训练有素的猴子可以devise它。 这很简单，因为聪明是数据模型，它具有这些有用的特征：
- CouchDB中的每个logging都完全独立于其他所有logging。 如果你想要做一个
JOIN或者一个事务，这很糟糕，但是如果你想写一个复制器，这真是太棒了。 只要找出如何复制一个logging，然后重复每个logging。 - 像Git一样，logging有一个链接列表修订历史logging。 logging的修订ID是自己数据的校验和。 后续修订ID是：新数据的校验和，加上前一个的修订ID。
-
除了应用程序数据（
{"name": "Jason", "awesome": true}）之外，每条logging还存储所有先前版本ID的进化时间表。- 锻炼 ：静静思考一下。 考虑任何两个不同的logging，A和B.如果A的修订ID出现在B的时间轴上，那么B肯定从A发展而来。现在考虑Git的快速合并。 你听到了吗？ 这是你的头脑被吹的声音。
-
Git不是一个真正的线性列表。 当有一位家长有多个孩子的时候，它有叉子。 CouchDB也是如此。
-
练习 ：比较两个不同的loggingA和B.A的修订ID不出现在B的时间轴上; 但是，一个版本ID C在A和B的时间轴上。 因此A不是从B发展而来的。B不是从A发展而来的。而是A和B有一个共同的祖先C.在Git中，这是一个“分叉”。 在CouchDB中，这是一个“冲突”。
-
在Git中，如果两个孩子都独立开发时间表，那很酷。 福克斯完全支持这一点。
- 在CouchDB中，如果两个孩子都独立开发自己的时间表，那也很酷。 冲突完全支持这一点。
- 有趣的事实3： CouchDB的“冲突”不符合Git的冲突。 沙发冲突是一个不同的修订历史，Git称之为“分叉”。 出于这个原因，CouchDB社区用一个沉默的n表示 “冲突”：“co-flicked”。
-
-
当一个孩子有多个父母时，Git也会合并。 CouchDB也有这样的。
- 在数据模型中，没有合并。 客户只需将一个时间线标记为已删除，并继续使用唯一的现存时间表。
- 在应用程序中，感觉就像一个合并。 通常，客户端以特定于应用程序的方式合并来自每个时间线的数据 。 然后它将新的数据写入时间线。 在Git中，这就像复制和粘贴从分支A到分支B的变化，然后提交到分支B和删除分支A. 数据被合并，但没有
git merge。 - 这些行为是不同的，因为在Git中，时间表本身很重要。 但是在CouchDB中，数据是重要的，时间线是偶然的 – 它只是在那里支持复制。 这就是为什么CouchDB的内置版本不适合存储维基页面等版本数据的原因。
最后的笔记
在这篇文章中至less有一个句子（可能是这个）是完整的BS。
感谢杰森的优秀的概述！ 正在研究TouchDB及其Couchbase复制的Jens Alfke（非正式地）描述了CouchDB复制algorithm本身，如果您对“标准”CouchDB复制器协议如何工作的技术细节感兴趣的话。
总结他列出的步骤：
- 找出以前的复制有多远
-
_changes起，获取源数据库_changes - 对一批更改使用
revs_diff，以查看目标上需要哪些更改 - 将所有缺less的修订元数据和当前文档数据+附件从源文件复制到目标文件，发布到
bulk_docs以进行优化，从而以不同于通常的更高级MVCC处理在PUT上执行的方式存储文档。
我已经在这里掩盖了很多细节，并build议通读原始解释。
CouchDB v2.0.0的文档涵盖了更广泛的复制algorithm 。 他们有图表，示例中间响应和示例错误。 他们使用IETF RFC的“必须”，“应该”等语言。
2.0.0的细节（截至2016年1月还没有发布）和1.x有一点不同，但是基本的描述仍然是描述的 。
在Apache CouchDB Conf 2013上 ，Benjamin Young在复制中引入了replication.io ，FTW！ 说话 。 对于基于HTTP的主 – 主复制的规范进行定义并最终成为一个持续的努力。
它也logging在这里： http ： //www.dataprotocols.org/en/latest/couchdb_replication.html ，以及。
