MongoDB和Cassandra的分布式事务实现

MongoDB和Cassandra通过完全不同的机制保障分布式事务一致性，这源于它们迥异的设计哲学（MongoDB偏向CP，Cassandra偏向AP）。

简单来说：

• MongoDB（v4.0+）：提供真·多文档ACID事务，类似传统数据库，但使用分布式快照隔离。
• Cassandra：核心是最终一致性，通过轻量级事务（LWT）提供很有限的、类似“CAS”的原子性保证。

下面我将分别解析它们的具体实现，并通过一个表格进行直观对比。

🍃 MongoDB：基于多文档的分布式事务

从4.0版本开始，MongoDB在副本集上支持了多文档事务，并在4.2版本扩展到了分片集群，实现了真正的分布式ACID事务。其核心机制如下：

1. 分布式快照隔离：
   MongoDB事务的隔离级别默认是快照隔离（Snapshot Isolation）。事务启动时，会获取一个全局一致的快照点。在事务进行期间，所有的读操作都基于这个快照，从而确保可重复读，避免脏读、不可重复读和幻读。

2. 两阶段提交（2PC）与两阶段锁定（2PL）：

   • 两阶段锁定：MongoDB在分片集群级别使用一种优化的两阶段锁定来管理并发。事务在执行过程中会获取操作所需资源的锁（文档级或集合级），并在事务提交或回滚后释放。
   • 两阶段提交协调：在分片集群中，当一个事务涉及多个分片时，MongoDB会使用一个协调者（通常是与客户端连接交互的mongos实例） 来协调所有参与分片，共同完成事务的提交或回滚，确保所有分片上的操作要么全部成功，要么全部失败。

3. 混合逻辑时钟与事务时间戳：
   MongoDB内部使用混合逻辑时钟（HLC）或逻辑时钟来为每个操作分配全局唯一的、单调递增的时间戳。这个时间戳用于：

   • 确定事务快照的版本。
   • 在数据分片和副本集间对操作进行排序，解决冲突。

4. 写冲突检测与处理：
   如果两个事务尝试修改同一份文档，MongoDB会检测到写-写冲突。通常，后提交的事务会回滚（客户端可以重试），这是快照隔离下的典型行为。

⚡️ 重要限制：MongoDB事务有默认60秒的执行时间限制，并且事务中所有修改的文档总大小不能超过16MB。这是为了保证系统不会因长事务而长时间持有锁，影响性能。

📊 Cassandra：轻量级事务（LWT）

Cassandra作为一个为高可用性和分区容忍性设计的AP系统，其核心是最终一致性。它不提供通用的多行/多表事务，仅通过 “轻量级事务” 提供一种条件更新机制，其本质是基于Paxos协议的“比较并设置”（CAS）。

1. Paxos协议实现：
   Cassandra的LWT在集群中使用Paxos协议来就某个条件（如“某行的值是否为X”）达成共识。

   • 提议阶段：客户端向所有副本（至少需要满足法定数量）发起一个Paxos提议，包含一个** ballot（选票/时间戳）** 和要执行的更新操作。
   • 准备/承诺阶段：副本节点会承诺不接受比当前收到的ballot更早的提议。这确保了在并发LWT中，只有拥有最新ballot的提议能胜出。
   • 提交阶段：一旦提议获得多数派（法定人数）接受，协调者会发送提交请求，让所有副本执行更新。

2. 单行级别的线性化保证：
   LWT通常只作用于单行（分区键相同的一组列）。它可以保证对该行的条件更新是原子的、一致的，并且具有线性化语义（即在分布式环境中看起来像瞬间完成）。例如，“只有当库存大于0时，才将其减1”。

3. 性能代价：
   由于Paxos协议需要多轮网络通信（通常需要4次往返），LWT的延迟远高于普通写操作，吞吐量也会显著下降。因此，Cassandra官方强烈建议仅将其用于必须解决并发冲突的极少数场景。

📈 核心对比

特性维度	MongoDB 分布式事务	Cassandra 轻量级事务 (LWT)
设计哲学	CP优先，在分区容忍下优先保证一致性。	AP优先，优先保证可用性与分区容忍，一致性为次。
事务范围	通用多文档/多集合事务，可跨分片。	极有限的单行条件更新（类似CAS操作）。
一致性模型	强一致性（快照隔离），提供ACID保证。	最终一致性为默认，LWT提供线性化的单行原子性。
隔离级别	快照隔离（默认）。	线性化（仅限于LWT涉及的该行数据）。
底层机制	分布式快照 + 两阶段提交/锁定 + 混合逻辑时钟。	Paxos协议 实现的条件共识。
性能影响	有开销（锁、协调），但不至于数量级的差异。	开销巨大，延迟是普通写的数倍，不适用于高频操作。
主要用途	需要严格ACID保证的复杂业务逻辑（如银行转账、订单处理）。	解决特定并发冲突（如用户注册时防止用户名重复、库存安全扣减）。

💎 总结与选择建议

• 如果你需要的是：跨多个文档、集合或分片的强一致性ACID事务，以支持复杂的业务逻辑（如金融交易），那么MongoDB是更合适的选择。
• 如果你需要的是：极高的写入可用性、可扩展性和最终一致性，仅在极少数的关键冲突点（如唯一性约束）需要线性化保证，那么可以接受Cassandra的LWT作为补偿机制。

总而言之，MongoDB试图将传统数据库的事务能力引入分布式文档数据库，而Cassandra则坚守其AP阵营，仅提供最必要的、代价高昂的原子性工具作为补充。

---

在高并发场景下，MongoDB和Cassandra保障性能与一致性的策略截然不同：MongoDB通过一套相对完整的ACID事务机制，以牺牲部分性能为代价换取强一致性；而Cassandra则通过其高度可调的最终一致性模型，以最大化性能和可用性为首要目标。

📊 深入对比：核心策略与应对机制

策略维度	MongoDB	Cassandra
核心策略	一致性优先：提供跨文档的ACID事务。	性能与可用性优先：最终一致性为默认，提供可调的一致性级别。
事务模型	真·分布式事务：多文档ACID，默认快照隔离。	无通用事务：仅提供基于Paxos的轻量级事务用于CAS操作。
性能保障	1. 事务时间与大小限制 2. 读写在多数节点完成 3. 锁机制	1. 极致扩展与无中心 2. 可调的一致性级别 3. 高性能写入路径
高并发优化	1. 将大事务拆为小事务 2. 使用可重试写入 3. 合理设计分片键	1. 避免使用LWT 2. 利用异步写入与批量 3. 精心设计数据模型
典型适用场景	需要严格ACID的复杂操作，如金融交易、订单处理。	需要极高吞吐和可用性的场景，如用户会话、物联网日志、实时推荐。

🍃 MongoDB：强一致性的性能权衡

MongoDB通过其分布式事务提供强一致性，其性能保障和限制如下：

• 性能保障机制：
  1. 硬性限制：默认60秒执行超时和16MB的文档修改总量限制，防止长事务耗尽资源。
  2. 读写在多数节点完成：确保数据的持久性和一致性视图，但会增加延迟。
  3. 锁机制：使用优化的两阶段锁，但锁冲突仍是高并发下的主要瓶颈。
• 高并发下的优化实践：
  1. 拆解事务：将大事务拆分为多个小事务，减少锁持有时间。
  2. 启用重试：使用可重试写入，自动处理瞬时网络问题。
  3. 设计分片键：让事务操作尽量集中在单个分片，避免昂贵的跨分片协调。

📈 Cassandra：可调一致性的性能至上

Cassandra通过放弃通用事务来换取极致的性能与扩展性：

• 性能保障机制：
  1. 无中心扩展：真正的去中心化架构，线性扩展能力强。
  2. 可调一致性：允许为每次读写设置一致性级别（如ONE， QUORUM， ALL），在延迟和一致性间灵活权衡。
  3. 高性能写入：先写内存和提交日志，写入速度极快。
• 高并发下的优化实践：
  1. 规避LWT：严禁将轻量级事务用于高频操作。仅将其用于极低频的冲突解决（如用户名唯一性检查）。
  2. 采用异步与批量：使用异步驱动和批量写入来提升吞吐。
  3. 优化数据模型：围绕查询设计表，避免读时连接，这是Cassandra性能的基石。

💎 决策指南：如何选择？

选择的关键在于明确业务对一致性的真实需求。

应选择MongoDB，如果您的业务是：

• 交易型系统：如电商的订单-库存-支付链路，需要严格的ACID保证。
• 复杂状态迁移：如工作流审批，状态变更需原子性跨越多个文档。
• 可以接受：为了强一致性，承受相对更高的写入延迟和更复杂的分片架构。

应选择Cassandra，如果您的业务是：

• 海量数据写入：如物联网传感器数据、应用日志、实时点击流。
• 高可用性优先：如全球化的用户会话存储，要求低延迟且永远可写。
• 可以接受：默认最终一致性，通过精心设计的数据模型和查询来避免对事务的需求。

🔮 总结与建议

从根本上说，MongoDB和Cassandra代表了分布式系统CAP定理下的两种经典取舍。不存在同时具备两者最优解的方案。

在实际选型时，建议你问自己两个问题：

1. 核心业务操作是否必须作为一个不可分割的整体成功或失败？ 如果是，MongoDB的路径更可行。
2. 系统是否要求极高的写入吞吐和可用性，并能容忍短暂的数据不一致？ 如果是，Cassandra是更优选择。

如果你的场景介于两者之间（例如，大部分操作可最终一致，但小部分需要事务），现代实践中也常采用“混合持久化”策略：用Cassandra处理海量主体数据流，同时用一个支持ACID的关系型数据库或MongoDB来处理核心的强一致性业务。