面试题：MongoDB复制集中增删改查一致性保证的原理

Question

请阐述在MongoDB复制集中，增删改查操作是如何保证一致性的？主要涉及哪些机制和组件？

Answer 1

增删改操作保证一致性机制

1. 多数写确认（Majority Write Concern）
   • 在MongoDB复制集中，默认的写操作是在primary节点执行，当写入完成后，primary会等待多数（majority）的副本节点确认接收到写入操作，才会向客户端返回成功。例如，在一个包含3个节点的复制集中，需要2个节点（即多数节点）确认写入，写入操作才被认为成功。这确保了写入操作在大多数节点上持久化，从而保证了数据的一致性。如果在等待多数节点确认过程中，有节点故障导致无法达到多数，写操作会失败，客户端会收到相应的错误提示。
2. 操作日志（oplog）
   • primary节点上的所有写操作都会记录到操作日志（oplog）中。oplog是一个特殊的固定集合（capped collection），它以时间顺序记录了所有数据库的更改操作。secondary节点会定期从primary节点拉取oplog，并在本地重放这些操作，以保持与primary节点的数据同步。这种基于oplog的复制机制确保了secondary节点的数据与primary节点最终一致。
3. 心跳机制（Heartbeat）
   • 节点之间通过心跳机制来保持通信，复制集中的每个节点都会定期向其他节点发送心跳消息，以确认彼此的状态。如果primary节点在一定时间内没有收到某个secondary节点的心跳，就会认为该secondary节点出现故障，并将其从复制集成员列表中移除。这有助于保证复制集中的节点状态准确，避免不一致情况，例如防止故障节点继续接收写入操作而导致数据不一致。
4. 选举机制（Election）
   • 当primary节点发生故障时，复制集会触发选举机制，从secondary节点中选举出一个新的primary节点。选举过程基于多数投票原则，只有获得多数节点投票的secondary节点才能成为新的primary。新的primary节点会继续处理写操作，由于oplog的存在，新primary节点的数据状态与原primary节点故障前是一致的，从而保证了数据一致性的延续。

读取操作保证一致性机制

1. 读取偏好（Read Preference）
   • MongoDB提供了多种读取偏好设置，客户端可以根据需求选择从哪个节点读取数据。例如，primary读取偏好只从primary节点读取数据，这样能保证读取到最新的数据，因为所有写操作都先在primary节点执行。而secondaryPreferred或secondary读取偏好允许从secondary节点读取数据，虽然可能会读到稍微滞后的数据，但能分担primary节点的负载。通过合理选择读取偏好，在满足一致性需求的同时，兼顾系统性能。
2. 线性化读（Linearizable Reads）
   • 从MongoDB 3.6版本开始支持线性化读。线性化读通过使用readConcern: "linearizable"选项，保证客户端读取到的数据反映了所有之前成功提交的写操作的结果。在执行线性化读时，MongoDB会确保读取操作等待所有未决的写操作在多数节点上完成，从而提供与写入顺序一致的读取结果，保证了强一致性。

涉及的组件

1. primary节点
   • 是处理写操作的主要节点，接收客户端的增删改请求，将写操作记录到oplog，并负责向多数节点同步写操作以确认写入成功。
2. secondary节点
   • 从primary节点拉取oplog，并在本地重放oplog中的操作以保持数据同步。在primary节点故障时，参与选举成为新的primary节点。
3. 仲裁节点（Arbiter）
   • 仲裁节点不存储数据，只参与选举投票。它的作用是在复制集中决定多数节点时提供额外的投票权，帮助快速选举出新的primary节点，维持复制集的高可用性和一致性。例如，在一个2个数据节点（1个primary和1个secondary）的复制集中加入一个仲裁节点，就构成了3个节点的复制集，能更好地进行选举和保证多数写确认。