Search for a command to run...
自圆其说是本 blog 的宗旨，有的时候理论真实可能会更加复杂，但是我愿意使用自己能理解的方式去理解的，并且达到自圆其说的地步；目前处于分布书存储领域，这个领域大神 太多但我不是那种很牛逼的大神。来这个领域只是为了追求自己喜欢做的事情,所以会持续几年吧。
个人喜欢非常 cool 的工具和膜拜各类大神，前提是你真的比我厉害，不喜欢吹嘘的人。算不上很喜欢写程序，但是挺喜欢现在的状态，最好 35 岁别把我裁了就更加好了。梦想着 自己能实现收支平衡，做一个开心的废物；最近一段时间正在学习 Rust，这个语言我超级喜欢，因为我非常喜欢 C++，但是不得不说 C++ 的包袱太重了；下一份工作可能会尝试 remote work，不知道这是不是我喜欢的生活； 家中有一个小宝贝，有点任性，不知道我能不能教育好她，希望她能健健康康的成长，我努力让自己不焦虑去鸡娃；我努力让你成为富 二代吧。
No comments yet. Be the first to comment.
本周是black Friday,我订阅了几个AI服务，还是蛮贵的...不过这样基本上构成我目前整体的知识阅读的过程，随着Ai的不断发展，工具链的替换可能是很重要的一个过程的。我主要订购了以下几个工具： Memo: 这个工具的主要作用是将视频/audio转srt，并且带有ai翻译的工具；当然我觉得它做的非常好的是，它把整个链路做的非常好的，并且可以用本地的资源做audio->text；而且它自带了很多的ai功能，比如对字幕进行进一步的AI的处理，提问，summarize和思维导图等等；目前我主要...
今天凌晨4点多起来看了一眼丈母娘的发烧是否ok...就导致我有点睡不着的，刷了一会推特之后又开始睡觉了，于是就开始做了一个很可怕的梦。 噩梦 那天，我不知道是在哪里..我带着女儿和我弟出去玩的，貌似是一个风景山区。于是我就带着女儿和弟弟出去玩的；我们走啊走, 沿着一条路一直走..突然看到一个小道有一家饭店的，这个饭店是比较特殊，有很多海鲜的；我看上了一只大龙虾，我问多少钱的，他说大概就70rmb就可以的。。。我觉得很划算的，我心想：我买下来，到时候把老婆叫过来一起吃的，并且告诉她这个才70rmb...
下面我分享一个推特上的一个关于子女教育的推 哈哈哈哈，李诞这个视频我看过 我给你分享几个我和我女儿之间的小故事 第一个故事 我经常给小朋友说：你们现在上学的成绩不重要，你们现在数学考试都是语文脑筋急转弯，语文考试都是历史背诵，一点用都没有，你出了社会就知道，社会根本没有选择题，社会要有选择题就好了，最难的是你遇到困难，你连门都找不到。我第一次这样讲的时候是女儿小学4年级，那时候我女儿听的一愣一愣的，她不明白，但是觉得我的理论和学校的不一样，很狂妄，但是她很喜欢，哈哈哈哈。 她什么时候真正明...
最近我在国内，我老婆在马来；最近在计划搬家的，找的那个房子不包含一些必要的家具，于是我老婆就必须要买点家具的，主要是沙发和餐桌..我们本来计划是说去ikea去买，但是我老婆觉得ikea的家具不便宜，并且款式一般的，最终问了中介找了一个二手平台找找看不错的家具。 我老婆挑了两个家具的，我看了一下价格也不算便宜的，但是我老婆喜欢的，于是我就说你觉得ok那就购买吧。我还顺便问了一下，这个家具能不能线下看一下货的，但是我老婆说这货在很远的地方的，大概是300公里的一个城市的。那我就说这个包邮吗，我老婆说...
1. Current 当下 最近依然还在中国，已经回来快一个月了. 最近一直在忙着带丈母娘看病和住院的。索性一切都还在可控范围内的，丈母娘由于糖尿病控制的很差导致本身的冠心病也复发. 这次去浙江省人民医院去做了造影检查和支架植入的手术的，不过这一切都比我预估的要顺利，我就怕她由于长时间没吃药和高血糖的持续的时间太长了，会带来严重的问题，不过好在没有发生最坏的事情的。 因为做了手术，所以这段时间我和我老婆的姐姐每人轮换的陪床，不过陪床真的好累的，因为睡得很不好的，特别的累。不过好在都结束了，而且丈...
这篇文章主要介绍了 mongo 在副本集中的实现的共识算法，与大部分的 raft 不一样，它是基于 pull-base 的模式的；我在第一次解决 mongo 的副本集问题的时候一开始就进入了 push-base 的 raft 的分析，后来发现整个代码逻辑有点奇怪；mongo 对 raft 类似的实现还是进行了很多不一样的修改，从而达到它想要的目的；这文章可能很好的理解到很多 mongo 的知识，所以我决定来翻译这个文章；大家别对我的英文水平抱有任何幻想，我只是想让自己能更加明白一点，而且也不会全文一字一句的翻译，有的大概的意思就差不多，英语好的小伙伴直接原文吧，其实并不难读, Fault-Tolerant Replication with Pull-Based Consensus in MongoDB.
在本论文中，我们将展示在 mongo 中，副本集中的强一致性是如何设计和实现的；mongo 的共识算法继承与 raft，通过这个算法可能保证 mongo 能提供线性化和容忍小于半数以上节点挂掉的能力；但是 mongo 的共识算法和主流的 raft 算法主要的区别点：mongo 实现了一套独特的 pull-base 的数据同步模型，一个副本通过拉取另外一个副本来获得新的能力. 这种 pull-base 的数据模型被初始化在任何一个副本中，而这种拉取的过程可能会发生在任何两个副本之间，这个是与主流的 raft 算法是很不一样的。基于 pull-base 模型提供了更加灵活可变的数据传输拓扑结构，而这些的变化能让 mongo 在性能和财务的损耗有这一定的优势，这是我们用户强烈希望的；这篇论文会描述几个方面的内容：
mongodb 是基于文档管理的分布式数据库；在这些年我们一直致力于改进副本集的功能，让它能支持更加强的一致性语意；在前几个 paper 中，分别描述了mongodb 是如何支持 tunable consistency和mongodb 是如何支持 causal consistency，而今天这篇论文主要准备详细介绍关于 mongo 是如何实现线性化的副本一致性。
对于实现副本集之间的数据的线性一致性的主流方式就是基于共识算法；而目前共识算法主要是 raft 和 paxos；在我们研究之下，目前不存在一个算法能直接 (不需要进行大量修改) 适配我们的场景。这个关键原因在于这些主流的算法都是基于 push-base 模型，在一个副本集中会存在一个 primary，数据是通过 primary 推向各个副本；而 mongo 想要的是基于 pull-base 模型，一个副本会主动拉去另外一个副本并且不一定是 primary 的副本;
有一些原因促使我们构建一套以拉为主的同步模型；
因为没有太合适的，所以我们基于 raft 开发了我们自己的副本同步模型；之所有选择 raft，主要原因是更加被工业界接受，比较简单易懂和更加类似于我们之前的版本的副本同步模型，当然我们也相信给予其他的，比如 Paxos，也是能正常工作的；我们的方法的原则是解耦 raft 中的数据同步的过程 (大部分就是AppendEntriesRPC):一个副本通过 pull 模型从另外一个副本拉去新的数据和副本之间相关报告它们自己最新的同步状态，从而能知道某一个请求是否满足了大多数的要求;
开发一个新的副本同步模型通常说的要比做的简单；我们在开发过程中遇到的最大的挑战在于对 raft 协议的细微的改动；raft 协议本身是被证明是 ok 的，但是我们每次微笑的改动都会遇到一些非预期的边缘测试通不过，从而影响了整个服务的正确性。为了验证我们设计和实现是正确的，我们花了巨大的工作量在于验证和测试这个协议本身，有model checking by TLA+，单元测试，集成测试，混沌测试和故障注入测试。
最终我们开发出来的协议成功的完成了可以在任意两个副本之间进行数据拉取的主要目标；和 raft 的以推模型不一样的，我们的系统支持任意的数据同步路径：从链式推送到广播; 基于我们开发的同步模型为 mongo 提供了许多优点，包含了性能上的 (比如可以减轻 primary 压力充分利用其他节点的能力等) 和管理维度上的 (比如可以管理数据传播路径等); 这篇论文主要会包含以下内容：
我们将根据如下组织本论文。
Mongodb 接口和架构. mongodb 是一个存储文档性数据，支持对单文档或者多文档的 crud，并且支持一种rich query language的数据库; 每一个文档是一个二进制的一段数据，这个数据结构类似于 json; 文档通过唯一 id 来进行标识，并且被组织在集合 (Collection) 中，这个集合类似于 Sql 中的 table;
为了提供高可用，mongodb 提供了以一组副本集的模式来运行一个数据库，这组副本集通过公式算法来进行数据同步和备份. mongo 也支持按照水平维度进行扩展，将在相同的集合中的数据分布在不同的 shard 上，整个模型是 share-nothing; 每一个 shard 是按照副本集进行部署。在这篇论文中我们将聚焦于单个副本集。
一致性和容错性. 在之前的论文中，我们介绍了 mongodb 是如何去支持弱一致性，包括因果一致性的。在这片论文中，我们将聚焦于一种强一致性的 - 线性一致性。我们假设在一个部分的异步环境中，所谓异步环境是消息的达到时间完全没上限和没有一个靠谱或者完美的错误检测方法；对于副本集中的每一个 node，在少于半数节点都出现故障的情况下依然都能保证系统可用。而对于这种在容错系统中保证线性一致性的解决方式通常就是共识算法。共识算法有：
我们的解决方法采用了近几年比较流行的 Raft，但是最终发明了一个被大量修改之后的新的协议。
基于 pull-base 的 mongodb 进化. 在 10 年前的 mongo 1.0 版本，那个时候 mongo 支持 master-slave 这种模型的副本同步的方式，但是与其他的 master-slave 不一样的是，mongo 在那个时候就会选择了 pull-base 的模型的，而且 pull 的目标不一定是 primary.
对于基于 pull-base 模式的同步数据最最大的优势在于针对网络可以有能力去做更加灵活的网络传输的方案; 依赖于用户需要，数据的传输能工作在星形拓扑结构，链式结构，或者混合结构。这种对数据链路的控制是很多用户需要的，大部分原因在于性能和钱财上的消耗。举个例子：当我们被部署在 AWS 的 EC2 上，数据传输在内网是又快又便宜，但是跨机房的传输就变得又贵又慢。
基于拉模型的数据同步方式在最近几年不断的不迭代和进化中；在几年前我们推出发布版本中，我们假设是一个半同步网络，在这种网络中：要不通过手动的方式进行错误管理 (用户需要在切换 leader 的时候去提前指定 new 的 primary 在哪里) 要不就是错误检测工具会要求消息必须在 30s 之内达到；从 2015 年开始，我们基于 Raft 重新建模了同步模型;新的歇息保证了在异步环境下面的安全性和支持全自动的错误恢复的功能。和之前一样，这个模型依然是基于 pull-base 的，在下一个段落我们将开始描述这是如何实现的。
本段落将描述 mongo 的副本是如何工作的；包括整体的架构和数据结构 ($3.1)、整个副本协议的主题 ($3.2)、关于正确性的讨论 ($3.3) 和系统是如何选择数据传输路径的 ($3.4);最后会有一个附录，总结了 mongo 的共识算法与 raft 之间的区别。
在 mongo 中，副本之间复制的基本单元是 oplog,oplog 是一个有序的日志项；每一个日志项表示对数据库的一次操作; 下面展示了一些 oplog 的一些例子; 这种日志项会被存储在一个叫做 oplog 的表中，oplog 的表的行为和一张普通的用户表几乎是一致的；但是当一些数据不需要的的时候，oplog 会自动删除最老的数据，并且新的数据添加到 oplog 中;
{ // The oplog entry timestamp
"ts": Timestamp(1597904287, 12),
// The term of this entry
"t": NumberLong(40),
// The operation type, "i" for insert
"op": "i",
// The collection name
"ns": "test.collection",
// A unique collection identifier
"ui": UUID("947b54f...852f62")),
// The document to insert
"o":{ "_id": ObjectId("5f3e...b950"), "x": 1 }
}
一个 oplog 的日志项需要被同步到半数以上的服务器上才能被认为是 commit; 被 commit 的日志项即使出现了少于半数节点故障也能保证持久化下来; mongo 系统会等待请求被 commit 之后才会返回给 client. mongo 也支持弱一致性的写入操作，在一个请求还没有真正被 commit 之后就回复 client(29,34); 在副本同步之后，理论上所有的服务器都应该有相同的 oplog，而 oplog 将按照相同的顺序被应用在所有的服务器上。
一个服务节点能扮演的 primary 或者 secondary 两种角色，只有 primary 才能承担写请求。当一个 secondary 转变成 primary 的过程中会出现第三种角色: candidate(候选者),mongo 的竞选规则和 raft 是类似的; 比如当一个节点在选举超时的时间内没有发现 primary，这个时候当前节点就
其他的节点 (voter，选民) 有两个保证：
如果这个候选者能获得半数以上的投票 (包含自己的一票) 的话，就可以从候选者变成 primary;
在选举成功之后，一个新的 primary 将有一个独一无二的任期号 (单调递增)；当新 primary 产生新的 oplog 会写入到自己的 oplog 表中，其他的副本将通过数据同步协议 ($3.2) 进行同步；可能会出现超过一个以上的 primary 出现在集群中，但是数据同步和共识算法协议保证最多只有一个 primary 能成功的 commit 一个特定位置的日志项。
在 mongo 中，每一个 oplog 都会有 timestamp 和 primary 的任期号；timestamp 是一个单调的逻辑时钟；这两个数据索引 oplog 的位置的，这两个数据组成的数据对被叫做OpTime, Optime 能用来标识 oplog 的在副本集中的唯一性，提供了 oplog 的全局有序性; OpTimes 按字典顺序进行比较，比如一个 Optime 如果 term 比别的 opTime 更加大的话，那这个 Optime 就比较大；如果 term 一样的话，那么就比较 timestamp 的大小。
如前面提到的，mongo 是按照拉模式进行副本之间的数据同步。不像 raft 或者其他的共识算法协议一样，当 primary 需要将新的日志项同步给副本的时候需要从 primary 主动推送给 secondary(比如 raft 中的AppendEntries这个 RPC 接口)；在 mongo 中，primary 是等待其他的副本拉取最新的 oplog 的日志项来保证数据同步。
primary 在将一个日志项添加到自己的 oplog 中，会处理从 secondary 的两种类型的 RPC 请求，分别为：
PullEntriesUpdatePositionsecondary 通过PullEntries来拉取最新的日志，而使用UpdatePosition来报告 secondary 本身的一些状态，primary 通过这些信息来判断 oplog 是否已经被同步到半数以上的节点，并且可以安全的 commit 这个数据；和 Raft 一样，一旦当前位置的日志项被 commit 了，那么间接的就表示之前的所有的日志项都被 commit 了;
PullEntries这里面有一个关键的设计抉择是 secondary 的PullEntries请求并不一定只能发送给 primary.代替的是 secondary 可以按照就近原则从周边的 server 中拉取 oplog 的数据。而这个正在拉取的 secondary 被叫做syncing server，它的上游即被拉取的 server 被叫做同步源 sync-source.
secondary 会持续不断的发送PullEntries请求给选择出来的同步源 ($3.4 段会对同步源有更加详细的描述)，并接受最新的日志项。这个PullEntries包含了当前 server 最新的 oplog 的 timestamp(prevLogTimestamp) 作为参数。当同步源接受到一个PullEntries请求之后会回复比这个 timestamp 相同或者大于的 oplog 的日志项数组，如果当同步源比当前节点的 oplog 要老的时候，会返回一个空的数组；如果PullEntries的请求参数和同步源的日志项是相同的时候，这个时候不会马上返回而是会等待一段时间 (默认是 5s)，主要是为了防止PullEntries的频繁请求。
当 secondary 收到了同步源的回复之后，它会尝试将收到的 oplog 日志与自己的 oplog 日志进行合并。在合并之前，secondary 对检查当前收到的 oplog 是否能和本地的 oplog 进行合并，特别是它会检查接受到的 oplog 的第一个日志项是否和自己的 oplog 最后一个日志项是一样的；因为只有是一样的，才能让 secondary 持续合并后期的 oplog. 假如接受到的回复的日志项不能与本地的 oplog 有交集并且接受到的 oplog 通过比较OpTime发现比本地更加新，这个时候 secondary 会按照自己的 oplog 的顺序往前匹配，直到找到与同步源最近的一个有交集的日志项，这个时候会清除这个日志项之后的所有 oplog 日志然后再将同步源的 oplog 日志进行同步，这样之后 secondary 的 oplog 的日志就和同步源的是一致的。而被舍弃的这些日志相较于 Raft 来说，会有更加多的工作要做；原因在于 mongo 在这边投机 (预测) 的优化。
正常 Raft 的协议是需要等待 secondary 都接受了当前日志项之后才会被 commit 的，而 mongo 通过 primary 往周边节点发送信息的结果来获得是否可以被 commit. 而且同步源本身可以是非 primary，是否存在可能同步错误的 oplog 呢，又或者本身已经被 commit 的日志也会被清理掉呢？
UpdatePosition当接受了PullEntries的回复，并将对应的 oplog 日志项合并到本地的 oplog 之后，secondary 会通过UpdatePosition这个接口将自己最新的 Oplog 发送给自己的同步源，而同步源在接受到这个消息之后会转发给自己的同步源，就通过这样一层一层的发送最后就到达了 primary 节点. primary 会在内存 (非持久化) 中保存着每一个副本的最新 oplog 的位置，当接受到一个UpdataPosition的请求之后，primary 会将于本地的数据进行比较，如果比它新就会更新内存中对应的数据。然后 primary 会对这些内存中的统计数据进行计算，如果发现有一个 OpTime 超过半数的有相同任期和相同或者更大的时间戳的话，primary 就会更新lastCommitted为上面的那个 OpTime，并且将这个信息同步给其他的副本，通过的方式是在其他的消息中夹带着同步过去，比如心跳消息或者PullEntries的回复中，而lastCommitted被认为是已经被提交的位置。
在 mongo 中，PullEntries这个 rpc 请求是通过查询大于等于时间戳的 oplog 表来实现的；因为 oplog 这个表是按照 timestamp 进行排序的，所以这个查询本身非常容易被优化；使用 mongo 的游标可以让同步节点能批量的工作和支持类似于流式的方式进行工作，以便同步源在不等待新的请求的情况下将数据发送出去，从而减少本身同步带来的耗时;
这边的细节估计需要考究一下，如果在不等待新的请求的情况下将新的数据发送出去，接受方应该是等待或者？
为了避免过多的UpdatePosition消息转发，每一个服务器在两次转发的过程中，被动的批量接受UpdatePosition的包然后进行合并，仅仅保持每一个服务器上的最新的 oplog 位置。在整个流程中，每一个服务器最多只会存在一个UpdatePosition的消息给同步源，这个UpdatePosition消息只会在等待上一个消息发送完之后才会发送下一个。
在 mongo 的心跳请求和 raft 不一样，它的职责更加明确，从传统 Raft 的AppendEntries中解耦出来。心跳请求会发送给所有的副本，主要的作用是监控存活简单、将当前可以被 commit 的位置同步和选择合适的同步源。
细心的读者肯定会发现，我们的数据同步协议中仅仅只是检查日志项的OpTimes，但是不会检查或者比较当前的同步源的任期是否高于或者相同自己的任期；这个与 Raft 数据同步的协议是有区别的。在 raft 中的数据同步过程中，这个检查是会在AppendEntries的 rpc 中执行的，只有当AppendEntries中包含的 primary 的任期号大于或者等于本身接受节点的任期号的时候才会让这个 rpc 返回成功。
这个关键性的协议改变意味着在 mongo 中基于日志数据同步的行为会和 Raft 有着不同；在 Raft 中，假如一个节点已经投票给更高任期的节点之后，当前这个节点是不会再接受老的 primary 的AppendEntries的请求。但是在 Mongo 中，因为PullEntries请求是不会检查同步源的任期的，所以即使当前节点已经投票给任期更加大的节点，同步源是过期的 primary，它依然能从过期的 primary 中同步到比它新的日志项。
关于上图的一些描述:
- 每一个框表示oplog的日志项,里面的数字为当前term
- (a): server A 和Server E两个都是primary;
- (b): raft仅仅只会允许A到B的数据复制(红色箭头)
- (c): mongo能支持A到B,C,D的数据复制(红色箭头)
- (d):C/D会通过
UpdatePosition的请求来报告自己的位置，这个请求包含了自己的任期（橘色的箭头），A收到这个信息之后就强制让出primary- (e): 最后数据都会是serverE，那么之前(c)过程中的数据复制将被回滚掉;
上图展示了raft在secondary的行为上的区别;
在mongo中，B/C/D都能从A上面同步到新的日志项，即使C/D在这个时间已经投票给了任期为3的E, 也不会干扰到这个同步过程；假如A是B/C/D的同步源，那么这个三个节点将因为A中的日志项比它们三个节点的本地oplog日志项新，所以也会同步过来；现在A中的这条任期为2的日志项已经被同步到集群的大多数节点，那么这条日志项就被认为是committed，如果我们没有进一步修改Raft的规则: 一条leader committed的日志项在将来是不能进行修改,那么最后服务器E的任期为3的日志项会重新覆盖被committed日志，这明显是违反了Raft的安全性;
为了阻止上面的情况发生，我们增加了为UpdataPosition rpc添加了新的参数: 为正在同步的server的任期号; 这个rpc的接收方如果发现接收到的任期号比本地任期高的话，就会更新本地的任期号；假如这个接收者是老的primary的话，那么当前节点在发现有更高任期的出现之后，在触发committed之前就会主动step down自己的primary，这样就避免了任何不安全的提交。在上面的例子中，A接收到了UpdatePosition时候，发现了任期号3之后立马就进行step down操作，不会更新lastCommitted; 所以即使日志已经被同步到了大多数节点，日志也不会被认为是committed.
到目前为止，我们假设一个secondary可以在投票给更加新的节点之后依然可以从旧的primary同步日志项. 事实上，这个时候同步方的节点可能已经被选举为新primary. 即使一个primary(或者候选者)已经在更加高的任期号投票给它自己，它依然可以从其他更加低任期号的节点中同步数据，只要没有用新的任期号构建新的日志项写入到自己本地的oplog即可(因为写入了节点的oplog就比其他的要新). mongo会尽可能的保留未提交的日志用于failover使用，这是与Raft的最大的区别
更正式，我们对UpdatePosition的修改是为了保证Raft的一个关键的特性-leader的完整性. 这个特性主要指:当一个任期的日志项被committed了之后，那么这个日志项将会一直存在于后期所有leader的日志中. 在mongo中，只有primary收到了超过半数的UpdatePosition的任期号为T的同步信息之后，才会认为任期为T的一个日志项被committed了.后期其他的leader(U > T)必须从半数以上节点中获得投票信息，那么必然有两个半数以上的集合会存在交集，而存在的这个交集是保证安全性的关键点. 要不投票节点在投票之前发送了UpdatePosition的请求，那么隐含了新的primary节点有了这条被committed的日志，要不就是在UpdatePosition之前发送了投票请求，那么这个时候老primary收到请求之后会立马进行退位操作，也保证了没有任何日志被提交；无论哪种情况，都能保证leader的完整性.
除了这个特性，其他的Raft特性我们都仍然保持，所以可以Raft的证明过程也证明我们的协议的正确性。此外，为了公式地验证我们的系统的正确性，我们已经用TLA+写了关于我们协议的正式的规范，并且应用于模型检查;
通过Heartbeat rpc可以知道其他的服务器的状态，包含有oplog的位置等；而选择一个同步源的标准就是选择的节点存在有比自己更新的oplog即可. 当同步源发生回滚(日志被清理和重新覆盖) 的场景下，这个条件也会在接收到PullEntries的回复之后进行再次check. 当然mongo用一套机制保证了不会让这个同步过程形成一个环. 一个server从一个同步源同步数据之后，它会持续从这个节点拉取数据，除非同步源出现了不可用或者更加好的同步源产生了，所以在一个稳定的环境下，一个server不大会频繁的改变自己的同步源.
在这个段落，我们将介绍mongo的几个关键特征。
在基于Raft的系统中，副本能应用一条日志的条件必须是等到收到committed的消息才可以. mongo中有一种优化，叫做
当一条日志项被add到oplog，就投机化的apply一条oplog中的日志项 [译者: 不再等待commit，oplog有什么我就直接apply]. 假如发生了failover操作的话，那么之前被投机apply的日志项就可能需要被删除(类似于3.2.1的例子). 在那个例子中，系统就需要回滚那些item =2 在A/B/C/D中的日志项. 在数据库领域通用的回滚策略是通过undo or redo log来实现的. mongo为了实现这个目标的方式是通过将存储引擎(WiredTiger)和本身的复制协议进行统一设计.
WT是一个支持多版本事务的存储引擎，它能使用oplog timestamp来定位到对应的版本和数据更新. 关于WT有三个关键的功能支持了之前说的那些事情;
<=这个时间戳的更新的数据合并到底层磁盘上的checkpoint和垃圾回收掉这些不再需要被存储的version当一个节点需要被回滚的时候，整个决策的过程是通过与它的同步源进行交互之后，获得与同步源的公共的oplog位置，比如Tcommon,这个节点需要截断所有在Tcommon的oplog日志项；而且这种操作，一定需要回滚到这些被清理掉的日志相关的投机写操作.
从mongo 4.0版本开始，WT引擎已经支持了将数据回滚到某一个指定时间的相关版本的功能. mongo会周期性的通知存储引擎目前的稳定时间戳Tstable, 这个时间戳来源于当前节点收到的committed信息.
为了能回滚被删除的日志项的对应的更新数据，这个正在做回滚操作的节点会将自己的版本回滚到最新的稳定时间戳的版本，然后再从同步源节点同步[Tstable, Tcommon]之间的oplog;
当oplog的磁盘空间达到预设的阈值之后，mongo会清理老久的oplog日志，通常默认是5%的磁盘空余就会开始. 在大多数的共识系统中，比如Chubby或者Raft，通常会在清理过期oplog之前都会去做一次对db的快照,这些快照被用于到新的节点加入的时候进行追赶使用. 而且mongo并不是依赖这种快照策略，而这个过程被叫做initial sync(初始同步).
mongo不使用快照策略在初始同步的主要原因是mongo有一个可插拔的存储api，它不需要存储引擎支持快照的功能. 比如在WT之前的存储引擎是mmap，这个mmap是不支持快照的；所以mongo的决策的最大原因是在于向后兼容没有快照功能的存储引擎.
在mongo的初始同步流程如下：
[译者:不出意外是不会换的，如果同步源不可用是另外的情况了]; 一旦这个流程开始，这个新的节点会继续记录当前同步源已经被committed的oplog的位置，以这个位置作为自己同步oplog的开始Tstartcursor将每一个表进行遍历过来.当然在遍历的过程中，同步源不会停止写，所以会将一些更新结果也一并同步到新的节点上来,比如有一些数据已经被更新、有一些数据已经过时了，一些数据已经被删除了等. 在最后一步会对这个数据进行修复的.[译者]: [Tstart, Tend]之间的oplog是会影响clone过程中的数据的一致性的;在clone完之后在回放这段时间的oplog就能保证整个数据库状态在Tend节点的一致性，后面的数据变化只需要同步oplog即可，而这个时间点之后的数据库处于不一致的，存在oplog可能生效也可能不生效的过程； 而clone和回放oplog是有先后顺序的;可以看这个文档:https://zhuanlan.zhihu.com/p/79786663
假如遇到了同步源不可用的时候，那么新节点会重新选择一个同步源，重新上面的这个过程.
从上面的流程中我们注意到了有的时候一些oplog在新节点上会被重放两次. 这个一个操作被应用在初始同步之后的话，那么本身copy的数据库就包含了这次操作，所以就会造成新的节点重复回放两次oplog. mongo为了避免这种情况造成的数据库不一致，通过的方式将oplog的重放便成幂等：也就是说同一条oplog被应用多次的结果是一模一样的.
对于一些改变数据库状态的操作(插入、更新、删除等)，我们在初始同步节点将这些操作的语意进行修改来保证它们的幂等. 在mongo中，insert的操作如果遇到已经存在见直接忽略；update和delete操作如果被操作的对象不存在也会被忽略。mongo支持很多丰富的操作，比如递增文档中某一个字段的value等. 这些操作都将被primary转化为unconditional field assignments. 比如一个递增的操作，primary会将这个字段的value取出来然后进行+1，最后在oplog中的是计算完之后的数据；从结果上来说，数据库的一致性需要同步源和新节点一起来保证.
在故障恢复之后，在primary上面的没有被提交的日志会因为故障的原因而失去. 这对于其他的系统可能是一件好事情，因为这个时候客户端将会尝试这些没有返回committd回复的请求，但是对于mongo来说却是有问题的，因为mongo支持弱一致的功能，主要是写入primary成功和少于majority节点数据同步成功之后就会返回客户端已经成功. 因为这个，当故障发生之后，就会触发一大批没有被提交的日志丢失。虽然理论上来说，客户端在选择用这种方式进行写入的时候就没有保证一定是不丢失的，但是mongo依然会尽可能的将这些未提交的日志保留下来。
出于这个目的，我们将介绍在选举primary过程中的额外的步骤-primary catchup阶段. 新的primary在转化为primary之后并不会马上的开始承担写任务，代替的是， 它将持续从它之前的同步源中同步比它新的oplog到本地，直到没有更新的或者超时；这个超时是可以配置的，默认是1分钟。我们牺牲了快速恢复的时间来获得保存更加多的未提交的日志。
在3.3的介绍，这个设计是可能的. 当新的primary在没有写入任何的oplog到本地之前的，从老的primary上同步数据是可以的.
mongo支持一个特殊的角色叫做仲裁节点；仲裁节点是一种类似于secondary可以用来进行投票的，但是本身因为不会存储数据而不会消耗任何的存储成本和复制成本，它的作用仅仅只是用于投票.比如, 在Primary-Secondary-Arbiter这样的部署结构中，当primary因为故障而挂了之后，secondary能从自己和仲裁节点那边得到选票，最后变成primary来提供服务；但是这些写都只能是未提交模式，因为没有办法达到majority个数的写. 假如这个时候一个新的节点加入用于替换之前crash掉的primary的话，这个arbiter的存在可以安全的进行集群成员的变更
[译者]： 仲裁节点使用的最多的应该是集群夸机房部署的情况，为了防止单机房挂了之后导致的整个集群不可能，所以就必须多机房部署；但是只是两个机房部署的话，不管怎么样当主机房挂了之后，另外机房的集群肯定是不可用的，因为选择不出来primary; 三机房部署并不是每一个公司都能承担的了的，多机房的数据同步也会消耗不少的时间；而仲裁节点就是破局的点，本身仲裁节点对资源的消耗有限，所以将它部署到公有云的虚拟node上作为第三个机房，当主机房挂掉之后，依然能保证多数选票，那就能达到高可用性.
为了容错的需求，用户常常会部署一些副本用于分担primary的读流量或者通过访问本地的数据来降低延迟。比如，用户可能需要在一些副本上通过mongo的聚合语句来跑比较重负担的分析任务. 这些副本是不能用于容错使用的而且在比较重负债的情况下会影响本身的写入延迟. 另外一个比较明显的例子就是: 为了能让全球部署的应用能达到能访问就近的数据中心来获得低延迟，这就需要在全球部署十几个副本. 假如发生了比较罕见的同时几个服务器出现故障，不应该通过所有的副本的个数来计算majority的个数来满足容错，也不希望用这个数来确定是否commit写.
mongo的无投票角色就是用于这个目的. 无投票角色本身和正常的secondary节点是一样的，但是他们没有参与投票的权限，也不会计算在majority的个数中，与之对应的应该就是投票成员. mongo目前支持50个副本，但是最多指支持7个投票成员. 因为这样能保证即使是majority写也能尽可能快的返回.
无投票成员在推模式下面工作的非常的好，尽可能的最小化对primary的影响，也可能将一些特殊的读服务的场景迁移到这些无投票成员节点上.
在出现故障的场景中，secondary会等待一个选举超时时间之后才会进行选举，这个时间是用来确定primary不可用；而且当故障是可以被预期的 ，这个老的primary将在某一个时候进行下线之类的。这个时候mongo提供了主动切换primary的功能，这个会缩短切换的整体过程，减少不可用的时间，并且减少候选者的等待时间.
当一个primary通过admin的命令操作触发主动退让primary的命令之后，它将停止写操作和等待用户指定的时间让有资格的secondary来追oplog; 然后primary会从中选择出最好的secondary来运行选举的过程. 在大部分场景下，这个被选择出来的secondary会赢的选票变成新的primary. 这种主动退让的策略相较于等待选举超时而言缩短了failover的不可用时间；这个有点类似于在Raft中的leader转让.
这个功能已经被用在MongoDB Atlas上，这是mongo维护的云服务的数据库. Atlas 的用户可以使用滚动升级的方式来执行一些操作，比如应用一些安全补丁、扩展集群和升级最新的稳定版本的mongo.而滚动升级就会使用到primary的主动切换的功能；通过这个方式可以最小化可预期的故障恢复的不可用时间. 事实上，在Atlas的故障大部分都是可被预期的操作.
在大部分情况下，用户对哪些服务器能作为primary是有偏好的，特别在多数据中心的场景下，用户需要primary部署在离用户比较近的数据中心从而获得低延迟. mongo支持通过配置的方式来指定选举之间的优先级. 当一个secondary发现自己的优先级比当前的primary的优先级要高了之后，它将在基于优先级的情况下的超时时间之后进行一轮选举.这个超时时间是会因为优先级的高低有不同，更加高的优先级会有更加小超时时间. 用这种方式，优先级最新的node的将最新被选举成功，并成为新的leader. 假如因为oplog的原因没有选举成，但是它在后期依然会因为优先级的原因不断的进行选举，知道变成primary. 当优先级被设定为0的时候，当前节点就失去了选举的权利.
当一个高优先级的server出现故障的时候，选举会存在一个潜在的问题，当这台服务器起来之后会生成更加高的任期让当前的primary退让下来. 当因为高优先级的服务器重启带来的同步日志滞后，并且在重启之后加入到集群中的时候，这个问题会产生尤其大的破坏性. 直到这个高优先级的服务器能追上最新的oplog之前，它都会进行不断的选举，每次选举的会造成集群一种抖动. 虽然集群都能在最后选择出一个新的primary，但是整个集群会每隔一个选举超时就触发集群不可用；为了解决当一个节点被重新加入到集群的时候,在raft论文的$9.6章节有描述预选举,主要是说候选节点只有知道它能获得半数以上的选票的时候它的任期才能被增加(任期号也不是你想自我增加就能增加的，需要别人认可). mongo通过用dry-run的方式来实现预选举. 当一个具有高优先级但是过时的候选节点即使它不会赢得primary，但是它依然会进行选举. 但是这个候选人会在预选举的时候就失败，通过这个机制保护了现存的primary被这种更高任期号的干扰[译者]按照raft中的描述，任期号递增是有限制的，也是通过限制任期号递增来限制对集群的干扰，所以理论上集群中不会存在无效的高任期号，我觉得mongo这边因为是通过这种方式限制更加高的优先级.
值得注意的类似于网络分区等罕见的场景下，可能会发生两个节点一直不断的进行选举任务从而引起活性问题. 这个和优先级设计的问题不一样的，并且优先级的设计也不会使得更加糟糕. 在这些场景中，预选举并不能完全解决这些问题. 在异步网络中活性是不可能被保证的. 当然在真实世界中，这通常不是个问题.
strawman solution通过使用将读请求当作写请求的方式来实现线性读; mongo优化了这种方式，它是通过看primary中的日志项是否已经被复制到其他的节点，如果已经复制到大多数的话，那么读这些操作就可以达到线性读. 值得注意的是这个优化与弱一致性的读是不一样的，虽然它们两个都将读操作转移到了oplog上面. 即使弱一致性读在primary和secondary节点上都能支持，但是它是不需要等待节点之间的数据同步的，但是线性读的话就只能在primary上读并且必须等到一次同步过程.
[译者]这部分内容是基本的评测，可以自行看论文
[译者]这部分内容可以自行看论文
[译者]这部分内容可以自行看论文
由于我本身对mongo的了解还在不断摸索中，文中有一些地方可能翻译不那么到位，而且没有很详细的看过mongo这块源码，可能在思考中有一部分只能靠自己的经验和之前看raft的相关资料来思考，如果有什么不对的，各位可以通过一下方式来找我或者自行看英文论文:
本篇文章以 MIT 协议开源，欢迎任何人转载、引用