分布式事务,解决方案

解决pyinstaller在单一文件时无法正确添加权限清单问题,(UAC,uac_admin,manifest,asInvoker,python,requireAdministrator)

聊聊分布式事务,再说说解决方案
分布式事务CAP理解论证-解决方案
分布式系统的2PC、3PC详细分析
github tcc示例
分布式事务、重复消费、顺序消费

一、理论

CAP相关:

CAP与BASE相关:我的博客

而对于分布式中的问题的解决方案,CAP原则出现,描述如下:

一致性(Consistency):

像A节点写入一条信息之后,同一时刻,在其他节点都可以读到这条信息

可用性(Availability):

多布一些节点A,B,C…,任何时刻,用户访问,都应该以可预期的结果返回,而不是浏览器报错,404,500,页面丢失…等用户体验不好的情况发生

分区容忍性(PartitionTolerance):

当各系统模块间通信出现问题时,设计一个策略,使系统仍可对外提供满足一致性或可用性

刚接触cap时,有些不理解分区容忍性,我们自己倒推一下:

  1. 为了保证一致性,我们需要各个节点同步消息
  2. 为了保证可用性我们可以多部署节点,部分节点挂了仍可对外提供服务
  3. 为了保证分区容忍性:此刻卡壳了,怎么做?没了一种具体的方式,然而他还是客观存在的。后来发现:进入了思维盲点:只要在分布式场景中,分区必然存在,那么如果不处理分区发生时的情况,节点无法通讯时会发生什么?–此刻如果仍对外提供服务,那么导致无法同步消息,即保证不了强一致性;如果要保证强一致性,那么就需要节点阻塞,一直等待通讯恢复,即保证不了可用性.

所以分区容忍性就是:当发生分区问题时,我们使用策略,在一致性和可用性二者间选择
注意: 无法通信包括网络问题,或者节点机器宕机

误区: CAP理论中说三者不可兼得,但实际情况是,在分布式场景中分区一定存在,即必须有分区容忍性对应的策略,之后才能在一致性和可用性间二者之间选择.所以对主流架构来说不是三选二,而是二选一。

对P的理解

很多人可能对分区容忍性不太理解,知乎有一个回答对这个解释的比较清楚CAP理论中的P到底是个什么意思?,这里引用一下:

  • 一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
  • 当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
  • 提高分区容忍性的办法就是一个数据项复制到多个节点上,那么出现分区之后,这一数据项就可能分布到各个区里,容忍性就提高了。
  • 然而,要把数据复制到多个节点,就会带来一致性的问题,就是多个节点上面的数据可能是不一致的。
  • 要保证一致,每次写操作就都要等待全部节点写成功,而这等待又会带来可用性的问题。
  • 总的来说就是,数据存在的节点越多,分区容忍性越高,但要复制更新的数据就越多,一致性就越难保证。为了保证一致性,更新所有节点数据所需要的时间就越长,可用性就会降低。

XA规范:

http://www.jasongj.com/big_data/two_phase_commit/
https://www.cnblogs.com/zhoujinyi/p/5257558.html

XA规范中,事务管理器主要通过以下的接口对资源管理器进行管理

  • xa_open,xa_close:建立和关闭与资源管理器的连接。
  • xa_start,xa_end:开始和结束一个本地事务。
  • xa_prepare,xa_commit,xa_rollback:预提交、提交和回滚一个本地事务。
  • xa_recover:回滚一个已进行预提交的事务。

XA规范:https://www.cnblogs.com/wt645631686/p/10882998.html

解决方案

一些具体实现

使用限制:

a. XA事务和本地事务以及锁表操作是互斥的

开启了xa事务就无法使用本地事务和锁表操作:

mysql> xa start 't1xa';
Query OK, 0 rows affected (0.04 sec)
mysql> begin;
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state
mysql> lock table t1 read;
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state

开启了本地事务就无法使用xa事务:

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> xa start 'rrrr';
ERROR 1400 (XAE09): XAER_OUTSIDE: Some work is done outside global transaction

b. xa start 之后必须xa end, 否则不能执行xa commit 和xa rollback

自然语言处理(NLP) - 数学基础(1) - 排列组合

所以如果在执行xa事务过程中有语句出错了,你也需要先xa end一下,然后才能xarollback。

注意事项:

a. mysql只是提供了xa事务的接口,分布式事务中的mysql实例之间是互相独立的不感知的。 所以用户必须
自己实现分布式事务的调度器

b. xa事务有一些使用上的bug, 参考http://www.mysqlops.com/2012/02/24/mysql-xa-optimize.html

主要是:
“MySQL数据库的主备数据库的同步,通过Binlog的复制完成。而Binlog是MySQL数据库内部XA事务的协调者,并且MySQL数据库为binlog做了优化——binlog不写prepare日志,只写commit日志。
所有的参与节点prepare完成,在进行xa commit前crash。crash recover如果选择commit此事务。由于binlog在prepare阶段未写,因此主库中看来,此分布式事务最终提交了,但是此事务的操作并未 写到binlog中,因此也就未能成功复制到备库,从而导致主备库数据不一致的情况出现。
而crash recover如果选rollback, 那么就会出现全局不一致(该分布式事务对应的节点,部分已经提交,无法回滚,而部分节点回滚。最终导致同一分布式事务,在各参与节点,最终状态不一致)”

参考的那篇blog中给出的办法是修改mysql代码,这个无法在DBScale中使用。 所以可选的替代方案是不使用
主从复制进行备份,而是直接使用xa事务实现同步写来作为备份。

二、两阶段提交2PC

1. 介绍

分布式事务,解决方案

两个角色:

  1. 协调者
  2. 参与者

两个阶段:

  1. 阶段一:提交事务请求
  2. 阶段二:执行事务提交

牺牲了一部分可用性来换取的一致性。解决方案有:springboot+Atomikos or Bitronix

优点: 原理简单,实现方便

缺点:

  1. 同步阻塞:在提交的过程中,所有参与者都处于阻塞状态,大大降低并发度
  2. 单点问题:一旦协调者出现问题,则所有参与者处于锁定状态,无法对外服务
  3. 数据不一致:在阶段二,协调者发送了commit之后,发生了局部网络异常或者协调者尚未发送完commit请求就宕机了,导致部分参与者收到commit,导致系统出现不一致
  4. 太过保守:协调者在阶段一中,参与者出现故障而导致协调者无法获取到所有参与者的响应,协调者只能依靠超时时间来判断是否中断事务。换句话说,没有完善的容错机制。

2. 实现

JTA(Java Transaction API)定义了对XA事务的支持。像很多其他的Java规范一样,JTA仅仅定义了接口,具体的实现则是由供应商(如J2EE厂商)负责提供,目前JTA的实现主要有以下几种:

  • J2EE容器所提供的JTA实现(如JBoss)。
  • 独立的JTA实现:如JOTM(Java Open Transaction Manager),Atomikos。这些实现可以应用在那些不使用J2EE应用服务器的环境里用以提供分布事事务保证。

MySQL中的XA实现分为:外部XA和内部XA。前者是指我们通常意义上的分布式事务实现;后者是指单台MySQL服务器中,Server层作为TM(事务协调者),而服务器中的多个数据库实例作为RM,而进行的一种分布式事务,也就是MySQL跨库事务;也就是一个事务涉及到同一条MySQL服务器中的两个innodb数据库(因为其它引擎不支持XA)。

三、三阶段提交3PC

是二阶段的改进版,将二阶段的提交事务请求过程一分为二,形成了:

  1. CanCommit:协调者发送事务询问、参与者反馈
  2. PreCommit:协调者发送预提交请求、参与者事务预提交(执行事务操作,写undo、redo日志)、参与者响应
  3. doCommit:协调者发送提交请求、参与者事务提交(事务提交,释放资源)、参与者响应

在阶段二中,参与者可能会响应no,或者协调者等待超时时间后还无法收到所有参与者的反馈,则中断事务:协调者向所有参与者发送abort请求。参与者无论是收到协调者的abort请求,或者等待协调者请求过程中超时,都会中断事务。

在阶段三中,如果有任一参与者发送了no,或者等待超时后协调者还没收到所有参与者的反馈,则中断事务。需要注意的事,进入阶段三,可能会有下面两种故障:

  • 协调者出现问题
  • 协调者、参与者之间的网络出现问题

无论哪种情况,都会导致参与者无法及时收到来自协调者的doCommit或者abort请求,这种情况,参与者在等待超时后继续进行事务提交。

优点:

  1. 降低了参与者的阻塞范围(二阶段中如果参与者与协调者断开,参与者abort;三阶段,提交),并且能够在单点故障后继续达成一致。

缺点:

  1. 参与者在收到preCommit后出现网络分区,参与者依然会提交事务,会造成不一致。

四、实现

todo

故事2:本人经历

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享