我在这里的文档中读到：
http://orientdb.com/docs/last/Distributed-Architecture.html
OrientDB具有无主体系结构，副本可以处理读写操作。在两个客户端同时写入两个副本的情况下，数据库如何处理两个版本之间的冲突解决方案？
例如在Riak KV中，他们使用矢量时钟（或现在的虚线版本向量）来检测冲突，这些冲突要么被用户处理以进行合并，要么可以设置默认策略来选择像last-write这样的东西-wins。
我想知道OrientDB如何处理这个问题。
答案 0 :(得分：1)
Here是orientdb使用的冲突解决策略。
如果服务器数量偶数或数据库未对齐，则OrientDB使用冲突解决策略链。
此默认链定义为全局设置（distributed.conflictResolverRepairerChain）： -Ddistributed.conflictResolverRepairerChain =多数，内容，版本
按照声明顺序，依次调用“冲突解决策略”实施，直到选择获胜者为止。在默认配置中（上述）：
首先根据记录版本检查记录是否存在严格多数。如果存在多数，则选择获胜者
如果未找到严格的多数，将分析记录内容。如果通过创建具有不同版本但内容相同的记录达到多数，则该记录将通过使用两者之间的较高版本而成为赢家
如果在内容中找不到多数，则以较高版本为准（假设较高版本表示更新记录最多） OrientDB Enterprise Edition支持其他数据中心冲突解决方案（dc）。
在链的最后，如果未找到任何获胜者，则记录将保持不变，只有手动干预才能确定谁是获胜者。在这种情况下，控制台中会显示警告消息，并显示文本“自动修复找不到记录”和以下几组内容的获奖者：[记录]。
答案 1 :(得分：-1)
与旧式发电机非常相似，只是他们对此非常懒惰，基本上他们只是使用hazlecast来获得低跳数的dht，并保持事件的部分排序，（hazlecast有类似于每个版本矢量的东西）他们的集合的输入，但我认为他们出于某种原因使用时间戳而不是逻辑时钟），然后他们在一个草率的仲裁中进行读取修复，在查询中，后继/协调器获取最高时钟，从中获取值对等并将其应用于自身和其他所有人，并且对于写入，他们通常只需要n-1（n是复制因子），再次进行写入，它与逻辑时钟有关。
现在作为一个真正的数据库，除了完全没有复制的努力之外，它非常优秀，而且我必须交给他们他们做出合理的技术决策。
在你说哦之前你无法做到，我已经做到了，我已经实现了发电机的和弦变体，riaks梅树八卦协议，DVV以及CRDTS的大量负载，请注意我在C时只使用RPC框架，消息传递或事件循环从头开始。
因为我20岁，不要叫我一个老人。