数据库集群和分布式事务和JTA

主从集群

主从集群，效果是主库可以写，从库只能读。在主库宕机后，从库可以切换为主库。（主从集群不牵扯到分布式事务）

这种方案会导致主从之间的延迟问题。

MySQL Cluster集群方案

LVS+Keepalived+MySQL Cluster

• LVS（提供负载均衡）+Keepalived（提供心跳监测）+MySQL Cluster
  
  其中MySQL Cluster的原理如下
  
  Mysql集群比mysql单机效率肯定低。
  如果使用innodb作为引擎，则该集群支持XA（实际上只要引擎支持XA，跨MYSQl和Oracle也没问题）

Oracle DataGuard

Data Guard 是Oracle的远程复制技术，它有物理和逻辑之分，但是总的来说，它需要在异地有一套独立的系统，这是两套硬件配置可以不同的系统，但是这两套系统的软件结构保持一致，包括软件的版本，目录存储结构，以及数据的同步（其实也不是实时同步的），这两套系统之间只要网络是通的就可以了，是一种异地容灾的解决方案
https://blog.csdn.net/define_us/article/details/83826333

Oracle RAC

https://blog.csdn.net/define_us/article/details/83184753

脑裂问题

在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。

分布式事务

XA协议（本质上就是2PC）

是唯一一个两阶段提交不能解决的困境是：当协调者在发出commit T消息后宕机了，而唯一收到这条命令的一个参与者也宕机了，这个时候这个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他节点也最终也会收到commit T的信息。所以才有3PC。

XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器（资源）与事务管理器（可以时中心节点，也可以时请求事务的客户端）之间进行通信的标准接口。这两者分别承担事务参与者／事务协调者两种角色

在XA分布式事务的第一阶段，作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。
在接到Prepare请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。如果参与者执行成功，暂时不提交事务，而是向事务协调节点返回“完成”消息。
当事务协调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段。
在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。
接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。
当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

详情请参考
https://blog.csdn.net/bjweimengshu/article/details/79607522

XA的事务状态转移如下

MYSQL

MYSQL内部有两种XA

1. 内部XA
   在使用innodb作为存储引擎，并且开启binlog的情况下，MySQL同时维护了binlog日志与innodb的redo log为了保证这两个日志的一致性，MySQL使用了XA事务，由于只在单机上工作，所以被称为内部XA在使用innodb作为存储引擎，并且开启binlog的情况下，MySQL同时维护了binlog日志与innodb的redo log为了保证这两个日志的一致性，MySQL使用了XA事务，由于只在单机上工作，所以被称为内部XA

2. 外部XA
   就是一般谈论的分布式事务了MySQL支持XA START/END/PREPARE/COMMIT这些sql语句，通过使用这些命令，我们是可以完成分布式事务的

JTA

也就是Java Transaction API，是一套操作事务管理器的接口。当然springJTA是整合JTA。既然是API，实际上不包含具体实现

JTA最大的问题恐怕就是吞吐量了。