浅谈分布式事务控制在银行应用的实现.docxVIP

浅谈分布式事务把握在银行应用的实现 2021-07-29 现今互联网界，分布式系统和微服务架构盛行。一个简约操作，在服务端格外可能是由多个服务和数据库实例协同完成的。在全都性要求较高的场景下，多个独立操作之间的全都性问题显得格外麻烦。 基于水平扩容力量和成本考虑，传统的强全都的处理方案（e.g.单机事务）纷纷被抛弃。其理论依据就是响当当的CAP原理。往往为了可用性和分区容错性，忍痛放弃强全都支持，转而追求最终全都性。 分布式系统的特性 在分布式系统中，同时满足CAP定律中的全都性?Consistency、可用性 Availability和分区容错性 Partition Tolerance三者是不行能的。在绝大多数的场景，都需要牺牲强全都性来换取系统的高可用性，系统往往只需要保证最终全都性。 CAP理解： Consistency：强全都性就是在客户端任何时候看到各节点的数据都是全都的（All nodes see the same data at the same time）。 Availability：高可用性就是在任何时候都可以读写（Reads and writes always succeed）。 Partition Tolerance：分区容错性是在网络毛病、某些节点不能通信的时候系统仍能连续工作（The system continue to operate despite arbitrary message loss or failure of part of the the system）。以实际效果而言，分区相当于对通信的时限要求。系统假如不能在时限内达成数据全都性，就意味着发生了分区的情况，必需就当前操作在C和A之间做出选择。 ACID理解： Atomicity 原子性：一个事务中的全部操作，要么全部完成，要么全部不完成，不会结束在两头某个环节。事务在执行过程中发生错误，会被回滚到事务开头前的形态，就像这个事务从来没有执行过一样。 Consistency 全都性：在事务开头之前和事务结束以后，数据库的完整性没有被破坏。 Isolation 隔离性：数据库允很多个并发事务同时对其数据进行读写和修改的力量，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不全都。 Durability 长久性：事务处理结束后，对数据的修改就是永久的，即便系统毛病也不会丢失。 分布式事务的基本引见 分布式事务服务（Distributed Transaction Service，DTS）是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终全都性。 CAP理论告知我们在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件确定会消灭延迟丢包等问题，所以分区容忍性是我们必需需要实现的，所以我们只能在全都性和可用性之间进行权衡。 为了保障系统的可用性，互联网系统大多将强全都性需求转换成最终全都性的需求，并通过系统执行幂等性的保证，保证数据的最终全都性。 数据全都性理解： 强全都性：当更新操作完成之后，任何多个后续进程或者线程的访问都会前往最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。依据 CAP 理论，这种实现需要牺牲可用性。 弱全都性：系统并不保证后续进程或者线程的访问都会前往最新的更新过的值。系统在数据写入成功之后，不承诺马上可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终全都性：弱全都性的特定方式。系统保证在没有后续更新的前提下，系统最终前往上一次更新操作的值。在没有毛病发生的前提下，不全都窗口的时间次要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终全都性系统。 常用的分布式技术说明 1. 本地消息表 这种实现方式的思路是源于ebay，其基本的设计思想是将近程分布式事务拆分成一系列的本地事务。 举个经典的跨行转账的例子来描述。 第一步伪代码如下，扣款1W，通过本地事务保证了凭证消息插入到消息表中。 1 2 3 4 5 Begin?transaction ????update?A?set?amount?=?amount?-?10000?where?userId?=?1; ????insert?into?message(userId,?price,?status)?values(1,?10000,?1); End?transaction commit; 其次步，通知对方银行账户上加1W了，通常接受两种方式： 接受时效性高的MQ，由对方订阅消息并监听，有消息时自动触发大事。 接受定时轮询扫描的方式，去检查消息表的数据。 2. 消息两头件 非事务性的消息两头件 还是以上述提到的跨行转账为例，我们很难保证在扣款完成之后对MQ投递消息的操作就