面试题：MongoDB复制集特定场景下的一致性挑战与解决

Question

假设在MongoDB复制集中，网络出现短暂分区，部分节点与主节点失联一段时间后又恢复连接，这种情况下增删改查操作的一致性如何保证？有哪些潜在问题以及应对策略？

Answer 1

一致性保证

1. 选举机制：当网络分区发生，主节点与部分节点失联，若失联时间较长，剩余能互相通信的节点（多数派）可能会进行新的主节点选举。新主节点选举产生后，在原主节点恢复连接前，新主节点可正常处理增删改查操作，保证这期间数据操作的一致性。
2. 同步机制：原主节点恢复连接后，它会检测到自己不再是主节点，然后从当前主节点同步数据，以保证数据最终一致性。它会接收并应用在其失联期间主节点上发生的所有数据更改操作。

潜在问题

1. 脑裂问题：若网络分区导致出现两个“主节点”（在分区两端都认为自己是主节点，虽然正常情况下多数派选举可避免，但极端网络问题可能引发），两边同时进行数据操作，会导致数据不一致。
2. 数据丢失风险：在网络分区期间，原主节点可能继续处理写操作（若未检测到自己已与多数派失联），但当它重新连接发现自己不再是主节点时，这些写操作可能需要回滚，导致数据丢失。
3. 读操作一致性问题：在网络分区及恢复过程中，读操作可能读到不一致的数据，比如从原主节点（恢复连接后变为从节点）读取到旧数据，而不是当前最新数据。

应对策略

1. 设置合适的心跳和选举超时时间：合理设置心跳检测时间和选举超时时间，减少脑裂发生的概率。若心跳检测频繁且选举超时时间合适，节点能更快感知网络问题并正确选举新主节点。
2. 写关注（Write Concern）设置：在进行写操作时，使用合适的写关注级别，如设置为“majority”，确保写操作在多数节点确认后才返回成功，降低数据丢失风险。
3. 读偏好设置：对于读操作，可设置读偏好为“primaryPreferred”或“primary”，优先从主节点读取数据，保证读取到最新数据，减少不一致问题。若应用场景允许，也可使用“secondaryPreferred”，但需要对可能读到旧数据的情况做好处理。