CAP 理论

  1. 一致性(Consistency)、可用性(Availability)、分区容忍性(Partition Tolerance)
    • 一致性：分布式系统中的所有数据是否一直满足系统的限制约束。
    • 可用性：快速响应用户请求的能力
    • 分区容错性：
  2. 以上三个特性只能同时满足两个，其中分区容忍性又是不可或缺的！
  3. 分区是分布式系统不可避免地问题，分区一旦发生就意味着要在一致性和可用性之间作出选择。

BASE 理论

  1. BASE理论是对CAP中地一致性和可用性进行一个权衡的结果
  2. 核心思想就是用最终一致性来代替强一致性。
  3. 基本可用(Basically Available)、软状态(Soft state)、最终一致性(Eventually consistent)

分布式事务的解决方案

两阶段提交(2PC)

  1. 为了满足事务的 ACID，需要引入一个协调者，其他节点被称为参与者。
  2. 阶段一：准备阶段
    • 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复
    • 各个参与者执行事务操作，并将 undo 和 redo 写入事务日志中
    • 如果参与者执行成功，给协调者返回yes，否则返回 no
  3. 阶段二：提交阶段
    • 如果所有参与者都回复了 yes 则协调者向所有参与者发送commit指令
    • 如果有一个参与者回复了 no，或者触发了协调者的超时机制，则向所有参与者发送rollback指令。
  4. 一致性：
    • 强一致性
  5. 缺点
    • 同步阻塞问题：所有参与者在事务提交阶段都处于同步阻塞状态，占用系统资源，容易造成性能瓶颈
    • 单点故障问题：如果协调者存在单点故障，参与者将一直处于锁定状态！
    • 数据一致性：在阶段2中，如果参与者与协调者都挂了，可能会导致数据不一致。

三阶段提交

  1. 主要由两个改动点
    • 将准备阶段一分为二，解决了同步阻塞问题
    • 在参与者也引入了超时机制，解决了单点故障问题。
  2. 阶段一：决定阶段（我感觉第一阶段的意义就是打声招呼，确定一下参与者的状态，如果参与者状态都很好再执行具体的事务操作，从而避免了同步阻塞问题）
    • 协调者向所有参与者发出准备消息（同2PC）
    • 参与者收到消息并执行事务之后，返回是否yes or no
  3. 阶段二：准备提交
    • 协调者准备提交消息，向所有参与者发送准备提交消息（若有一个no或者`超时，则进入第三阶段回滚阶段，若全为yes，则进入第二阶段））
    • 参与者收到该消息之后写入log record中，并回答确认消息 ack。如果参与者一直接收不到预提交命令超时，则会进行回滚操作。
  4. 阶段三：执行段
    • 协调者感觉参与者回答的ack/abort消息（如果有一个no或超时，则进行rollback操作），向参与者发送commit/rollback命令
    • 参与者根据协调者的命令决定执行提交或者回滚，完成事务的处理。
    • 如果参与者一直没有收到协调者的命令超时，会继续执行commit操作（因为在第一阶段已经确定过参与者的状态都是ok的，所以在这一阶段虽然没有收到协调者的消息，但是成功提交的概率很大）。
  5. 一致性
    • 强一致性
  6. 缺点
    • 通信次数更多
    • 无论是2PC还是3PC都无法彻底解决数据一致性问题，想要解决数据一致性问题，还是要依赖于 paxo

补偿事务（TCC Try Confirm Cancel）

  1. 服务化的二阶段编程模型，采用的补偿机制
  2. 条件
    • 需要实现确认和补偿逻辑
    • 需要支持幂等（一次执行和多次执行效果相同）
  3. 流程
    • Try:对业务系统做检测及资源预留（第一阶段)
    • Confirm：对业务系统做确认提交(第二阶段）
    • Cancel：在业务执行错误，需要回滚的状态下执行业务的取消，预留资源释放。（第二阶段）