基础事物和分布式事物

  1. 基础事物

try {
START TRANSACTION;
INSERT INTO `order_main_0`.`order_0` (`id`)VALUES(1);INSERT INTO `order_main_0`.`order_0` (`id`)VALUES(2);
COMMIT;					
catch (Exception $e) {    
ROLLBACK;
						
}
这种事物只适用于同一个数据库服务器,同一服务器不同的数据库也是可以操作
如果做了数控的拆分,库A在服务器1上,库B在服务器2上,就不能使用普通事物

2.分布式事物的难点

ACID特性在分布式环境下变得困难:

  1. 因为网络通信的不可靠,事物的原子性需要用多次日志和网络通信来保证;

  2. 存储节点增大,放大了单个存储节点在事物过程中出现故障的风险;

  3. 用锁实现的事物隔离性,在故障或网络抖动时严重影响性能;

3.分布式事物行业主要解决的方案:

  1.我们主要采取MQ事物解决方案,

  2.还有2pc,3pc,Tcc等方案进行必要的介绍


3.1 两阶段提交(2pc)

两阶段提交又称2pc,2pc是一个非常经典的强一致性,中心化的原子提交协议;
第一阶段:请求/表决阶段
第二阶段:

以下几点是XA-两阶段提交协议中会遇到的一些问题:
1.性能问题: 从流程上我们可以看出,其最大缺点就在于它的执行过程中间,节点都处于阻塞状态,各个操作数据库的节点此时都占
用着数据库资源,只有当所有节点准备完毕,事物协调者才会通知进行全局提交,参与者进行本地事物提交后才会释放资源,这样的过程
会比较漫长,对性能影响比较大;
2.协调者单点故障问题: 事物协调这时整个XA模型的核心,一旦事物协调者节点挂掉,会导致参与者收不到提交或者回滚的通知,从而导致
参与者节点始终处于事物无法完成的中间状态;
3.丢失消息导致的数据不一致问题: 在第二个阶段,如果发生局部网络问题,一部分事物参与者收到了提交消息,另一部分事物参与者没有收到
提交消息,那么就会导致节点间数据的不一致问题;

3.2 三阶段提交(3pc)

三阶段提交又称3pc,其在两阶段提交的基础上增加了CanCommit阶段,并引入了超时机制,一旦事物参与者迟迟没有收到协调者的Commit请求
就会自动进行本地commmit,这样相对有效地解决了协调者单点故障的问题,但是性能和不一致问题任然没有根本解决;

3.2 补偿事物(Tcc)

说起分布式事物的概念,不少人会搞混淆,似乎好像分布式事物就是tcc,实际上TCC和2pc,3pc一样,只是分布式的一种实现方案而已;
TCC又称补偿事物,其核心思想是:针对每个操作都要注册一个与其对应的确认和补偿(撤销操作),它分成三个操作
1.Try阶段:主要是对业务系统做检测及资源预留
2.Confirm阶段:确认执行业务操作,通过调用确认接口
3.Cancel阶段:取消执行业务操作,通过调用取消接口
TCC事物的处理流程与2PC两阶段提交类似,不过2pc通常都是在垮库的DB层面,而TCC本质上就是一个应用层的2pc,需要通过业务逻辑来实现,这种分布式事物的
实现方式的优势在于,可以让应用自己定义数据库操作的颗粒,使得降低锁冲突,提高吞吐量成为可能性;
而不足之处则在于对应用的侵入性非常强,业务逻辑的每个分支都需要实现try,confirm,cancel三个操作,此外其实现的难度比较大,需要安装网络状态,系统
故障等不同的回滚策略,为了满足一致性要求,confirm和cancle接口还必须实现消息的幂等性,开发量很大

3.3 MQ最终一致性事物

最终一致性事物需要解决的主要难点
1.消息百分投递成功   
  结合comfrim机制
2.消息百分百消费成功   
  结合ack机制,并且要解决幂等性问题

3.3 MQ分布式事物基础

1.什么是confirm机制
概念:pro发送消息到Broker,Broker接收到消息后,产生回送响应Pro中有一个Confirm Listener异步监听响应应答
步骤:
消息的确认Rro投递后,如果Broker收到消息则会给Pro一个响应;
Pro接收应答用来确认这个条消息是否正常发送到Broker,该方法也是消息可靠性投递的核心保障;

MyAnswer博客


实现confirm机制

  1. 在channel上开启确认模式  $channel->confirm_select();

  2. 在channel上添加监听 $channel->wait_for_pending_acks(); 监听成功和失败的返回结果,根据具体的结果对信息进行重新发送,或记录日志等后续处理

MyAnswer博客
请先登录后发表评论
  • 最新评论
  • 总共0条评论