单库单表事物到分布式事物一键解读

目录

一:数据库事物的实现与缺陷

1.mysql事物解决的问题

2.事物回滚的理论机制

3.事物特性的协作性。

二:分库,分表的事物的实现

1.实现的场景

2.解决方案   

3.2p式提交的理论

4.2p式提交的缺点

三:分布式事物

1.分布式理论的提出

2.CAP理论的选择

3.如何实现高可用的A理论

4.分布式事物的实现


一:数据库事物的实现与缺陷

1.mysql事物解决的问题

  官方定义中:事物是用来解决mysql中的幻读,脏读,不可重复读。简而言之,当有多个客户端对数据库进行查询或者修改新

增修改操作时,会产生不同步信息,导致查询结果不一致。其实我认为吧还有一种比较重要的方式事物回滚,就是当你直接

进行增删改时,允许结果错误时进行回滚。

 

2.事物回滚的理论机制

   事物回滚的外在表现:  在开启事务的时候,多个操作中有一个执行失败,就会导致整个执行失败。这其实就是基于数据库事物的

ACID特性。

   原子性:原子性是事物外观表现的最直接的解释,即要么都执行,要么都不执行。那么是如何实现都不执行或者都执行的?哈

哈这是就是基于mysql的回滚日志(undo log)实现,所有进行修改的操作都会先被记录在这个日志中,当某一个修改操作失败,

就开始读取回滚日志并回复数据。我们这里就简要讨论一下什么是回滚日志。

                  (1)管理者事物的状态:Active,事物的初始状态,表示事物正在执行。Partially Commited,最后一条语句执行之后

                                                                 failed,事物无法正常执行。aborted,事物回滚且数据库恢复到事物进行之前的状态

                                                                  commited:成功执行整个事物。了解事物的运行状态可以理解其中的过程。

                    (2)并行下事物切割:其实当前多个客户端同时进行才是事物的正正状态。比如A用户正在执行update操作

                                                                       B用户在A执行之前实现了查询操作,B以为这是查询结果,但在随后的一秒A就行了

                                                                       修改。B又没有重新查询,这样B之前查询结果就错了。回滚日志可以实现并行状态下

                                                                       将并行操作切割成多段执行。

 

   持久性:将操作结果保持到数据库中。持久性操作也是基于mysql的重做日志(redo log)重做日志分为内存中日志,一个是磁

                   盘中的日志。前者易失去,后者具有永久性。

                      (1)缓存日志的新增:在开启事务的过程中,对数据库中的修改会被记录在缓存日志中。

                      (2)磁盘日志的新增:在事物提交后,缓存日志修改会被读取到磁盘日志中,并进行数据库修改。

  隔离性:数据库中每一个客户端操作都是一个独立操作。一个操作未实现,就不会被另一个操作读取和修改。但是这样就会导

                   事物的并行的问题。这里就要我们自己去处理事物的隔离级别。

                        (1)未提交读:A用户在事物提交之前修改了某一个属性值,B用户读取到的就是修改后的值。但是如果A的事物

                                                      回滚,B这里显示还是修改的值,这就是脏读。举个例子:A操作这样一个属性:set  name="AN" 

                                                       where id =‘1’  ,此时B执行了 select name  where id ='1' 结果就是AN,但是A回滚了name=‘BN’,

                                                        B的结果还是AN。

                         (2)已提交读:只有事物提交后,另一个客户端才能读取到。

                         (3)可重复读:其他事物读取的数据只能是已提交的事物,但是,如果有其他事物修改该结果,读取的还是该结

                                                        果。

                         (4)串行化:只要有一个事物在执行这个操作,其他都得等着直到该事物执行结束。

                            上述4中隔离性,性能依次降低,安全性依次升高。那么如何实现高级别的隔离?

                            方法一:.比较常见的方法就是加锁,my sql和常见数据的锁都分为2中,共享锁(读锁)和互斥锁(写锁),前

                                             者实现了   读操作可以并发执行,后者控制数据库更新不会被其他事物肝脑。

                           方法二:时间戳,时间戳实现事物的隔离级别时,一般会使用乐观锁。先对数据进行修改,在写回时再去判断当

                                           前值,也就是时间戳是否改变过,如果没有改变过,就写入,否则,生成一个新的时间戳并再次更新数

                                           据,乐观锁其实并不是真正的锁机制,它只是一种思想。

                             方法三:多版本和快照隔离,也就是mvcc,修改时先执行查询。

  一致性:数据库中数据的一致性。

 

3.事物特性的协作性。

  上面谈了事物的4种特性,那么4中特性并不是单独执行的。那么我们来看看这4种特性的协作性。

      原子性和持久性的协作:从上面可知,这2中特性依赖于回滚日志和重做日志,统称为事物日志。前者保证对事物的影响操作

                                                   可以撤销。后者允许提交的事物可以重做,他俩保证了异常回滚和宕机恢复数据。               

      隔离性和原子性的协作:mvcc特性。正常读取为了保证性能是不会获取互斥锁的,除非在查询后添加for update获取事务所。       

   4.普通事物的不足。

在上述的讨论中我们均讨论的是单库,单表的事物。明显在分库甚至分布式的事物就需要另外讨论了。

 

二:分库,分表的事物的实现

1.实现的场景

    当我们的业务过大,进行横向扩展和纵向扩展时,需要进行分库和分表的时候,我们就需要保证了分库分表和主库主表的事物

 一致。实现理论,就是每一次操作都会记录成一条消息,然后发布给其他表库。              

2.解决方案   

   分库的情况下实现的是事物的一致性的方法常用的就是2p式提交。

   (1)当一个数据库提交成功在执行第二个数据库的修改。

(2)用一个中间表来记录某一个表的修改情况,如果成功就修改第二个,这时候有人就会问第二个表如果执行失败呢?这个就留给大家自己去想了。

单库单表事物到分布式事物一键解读_第1张图片

(3)这样可以用中间表去管理多个库表的执行了。

 

3.2pc式提交的理论

  其实看到这里我们就能很明显的看出,实则多段式的提交就是类似于消息通知,一个执行了去通知其他的多个的执行。有兴趣

的可以用mq等中间件实现。mq等中间件的消息通知式的提交也是分布式解决事物的一个方案。

4.2pc式提交的缺点

(1)单点故障:比如图中的其他三个库挂掉一个怎么办?

 (2)数据延时或者不一致:中间表的实现是被动式的

 

三:分布式事物

1.分布式理论的提出

   在上述的的2p式提交中,我们曾说过mq事物声明通知可以作为分布式解决事物的一种方案,但是其还是具有2p是提交的缺点,

并且在分布式的情况下这种缺点被放大。因此,基于此有人提出了分布式事物的事物方案---CAP定理

    (1)C一致性:客户端知道一系类操作一定会生效

    (2)A可用性:每一个操作都必须可预期的响应结束

    (3)P分区容错性:单点故障,认可恢复

在实际应用中,P分区一定是要实现的。因此只能根据业务在A,C中选择一个。

2.CAP理论的选择

   cap理论进过证明适用于分布式系统的,但是他只能在cp和ap中选择一个。在实际身产中A理论一定比C理论要实用。就以上述

的2pc的提交为例我们假设两阶段提交的过程中每一个数据库都具有99.9%的可用性,那么如果两阶段提交涉及到两个数据库,这

个结果就是99.8%。根据系统可用性计算公式,假设每个月43200分钟,99.9%的可用性就是43157分钟, 99.8%的可用性就是

 43114分钟,相当于每个月的宕机时间增加了43分钟。明显ap理论的实用性大于cp。

3.如何实现高可用的A理论

    在上面我们描述了ap理论实用性大于cp理论。那么如何实现高可用的a理论?这里产生了一个新的定理:BASE理论,实则是

CAP理论的扩展。其内容为:(1)基本可用(2)软状态(3)最终一致性。期核心就是对CAP中的A,C理论的权衡取舍,最终

实现:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。

4.分布式事物的实现

(1)2段式提交(2pc)

          2pc提交基于xa协议的原理,下图就是实现的方式,他将事物分成2各部分,从而牺牲了部分可用性来换取一致性

                              单库单表事物到分布式事物一键解读_第2张图片

 其优点:在最大方面保持了事物的强一直,适用于数据强一致性的关键领域

 其缺点:过于复杂,不舍用于高并发场景

 

(2)补尝事物(TCC)

  其本质就是补尝机制,即每一个操作都有一个与之对应的确定和撤销操作

单库单表事物到分布式事物一键解读_第3张图片

  其优点:实现起来流程相较于2pc比较简单一些

  缺点:数据一致性差一些

 

  (3)本地消息表(异步确保)

       这种用该是业界内使用最多的方法了,其核心思想是将分布式事物拆分成本地事物。

                       单库单表事物到分布式事物一键解读_第4张图片

           具体实现的过程如下:并且消息中间件会定时烧苗消息表,然后处理多个消息表中的不一致的数据

         单库单表事物到分布式事物一键解读_第5张图片

          优点:这种方案遵循base理论,即便调用链很长也不会出现性能过低的情况

          缺点:表侵入

 

(4)MQ事物消息

           基于某一些第三方的mq是支持事物消息的,比如RocketMQ,支持2pc提交,但是rabbotmaq等不支持

           a.第一阶段Prepared消息,会拿到消息的地址。

           b.第二阶段执行本地事务,第三阶段通过第一阶段拿到的地址去访问消息,并修改状态。

                               单库单表事物到分布式事物一键解读_第6张图片

       优点:实现最终一致性

       缺点:主流mq不支持,实现难度大。

 

  (5)Sagas事物模型

  该事物模型是将一个很长的事物拆分成多个多个短事物,然后将多个短事物统一基于一个事物引擎来实现。当一个短事物

执行失败,前面的已经执行成功的都将执行补偿执行。

单库单表事物到分布式事物一键解读_第7张图片

   如图,当短事物02执行失败,其他全部执行补尝回滚

 

你可能感兴趣的:(数据库事物)