分布式事务解决方案

事务

事务由单独单元的一个或者多个sq!语句组成，在这个单元中，每个mysql语句时
相互依赖的。而整个单独单元作为一个不可分割的整体，如果单元中某条sq!语句
一旦执行失败或者产生错误，整个单元将会回滚,所有受到影响的数据将会返回到
事务开始以前的状态;如果单元中的所有sq!语句均执行成功，则事务被顺利执行。

• 原子性:一个事务不可在分割，要么都执行要么都不执行。
• 一致性:一个事务的执行会使数据从一个一 致状态切换到另一个一致的状态。
• 隔离性: 一个事务的执行不受其他事物的干扰
• 持久性:一个事务一旦提交，则会永久的改变数据库的数据

分布式事务

分布式事务就是为了保证不同数据库的数据一致性

CAP定理

CAP定理，又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)的架
构师来说，CAP就是你的入门理论。

• C(一致性):对某个指定的客户端来说，读操作能返回最新的写操作。
  对于数据分布在不同节点上的数据来说，如果在某个节点更新了数据,那么在其他节点如
  果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是
  分布式不一致。
• A (可用性):非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响
  应)。可用性的两个关键一个是合理的时间， 一个是合理的响应。
  合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是
  系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是
  返回40。
• P (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里集群有
  多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

BASE

• BASE是Basically Available(基本可用)、 Soft state(软状态)和Eventually
  consistent (最终一致性)三个短语的缩写， 是对CAP中AP的一个扩展。
• 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
• 软状态:允许系统中存在中间状态，这个状态不影响系统可用性,这里指的是
  CAP中的不一致。
• 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。
  • BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一 致，保证了延迟
    后的一致性。
  • BASE和ACID是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性
    来获得可用性，并允许数据在一段时间内是不一 致的，但最终达到一致状态。

2PC/XA

• XA是由X/Open组织提出的分布式事务的规范。 XA规范主要定义了(全局)事务管
  理器™和(局部)资源管理器(RM)之间的接口。主流的关系型数据库产品都实现
  了XA接口的。
• 资源管理器(resource manager) :
  • 用来管理系统资源，是通向事务资源的途径。数据库就是一种资源管理器。资源管理还应
    该具有管理事务提交或回滚的能力。
• 事务管理器(transaction manager) :
  • 事务管理器是分布式事务的核心管理者。事务管理器与每个资源管理器(resource
    manager)进行通信，协调并完成事务的处理。
  • 事务的各个分支由唯一命名进行标识Xid

eg:atomikos分布式事务框架

可靠消息最终一致性

基于两阶段提交的XA分布式事务，但是这类方案因为需要资源的全局锁定，导致性
能极差;因此后面就逐渐衍生出了消息最终一致性、 TCC等、 柔性事务、的分布式事
务方案,下面主要来分析基于消息的最终一致性方案。

基于MQ的事务消息

基于本地消息得到最终一致性

第二步的消息数据就是保证消息已经发送到MQ里面

独立消息服务的最终一致性

TCC方案

• TCC方案分为3个阶段,分别是try、confirm、 cancel
• Try阶段
  • 这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留
• Confirm阶段
  • 这个阶段说的是在各个服务中执行实际的操作
• Cancel|阶段
  • 如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成
    功的业务逻辑的回滚操作

LCN方案

• TX-LCN由两大模块组成, TxClient、 TxManager,
• TxClient作为模块的依赖框架，提供TX-LCN的标准支持,
• TxManager作为分布式事务的控制放。事务发起方或者参与方都由TxClient端来控
  制。