主从集群
主从集群,效果是主库可以写,从库只能读。在主库宕机后,从库可以切换为主库。(主从集群不牵扯到分布式事务)
这种方案会导致主从之间的延迟问题。
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
-
内部XA
在使用innodb作为存储引擎,并且开启binlog的情况下,MySQL同时维护了binlog日志与innodb的redo log为了保证这两个日志的一致性,MySQL使用了XA事务,由于只在单机上工作,所以被称为内部XA在使用innodb作为存储引擎,并且开启binlog的情况下,MySQL同时维护了binlog日志与innodb的redo log为了保证这两个日志的一致性,MySQL使用了XA事务,由于只在单机上工作,所以被称为内部XA -
外部XA
就是一般谈论的分布式事务了MySQL支持XA START/END/PREPARE/COMMIT这些sql语句,通过使用这些命令,我们是可以完成分布式事务的
JTA
也就是Java Transaction API,是一套操作事务管理器的接口。当然springJTA是整合JTA。既然是API,实际上不包含具体实现
JTA最大的问题恐怕就是吞吐量了。