分布式事务架构设计（ word 可编辑版）.docxVIP

PAGE PAGE 10 分布式事务架构设计 分布式事务架构设计 现今互联网界，分布式系统和微服务架构盛行。一个简单操作，在服务端非常可能是由多个服务和数 现今互联网界，分布式系统和微服务架构盛行。一个简单操作，在服务端非常可能是由多个服务和数 据库实例协同完成的。在一致性要求较高的场景下，多个独立操作之间的一致性问题显得格外棘手。 基于水平扩容能力和成本考虑，传统的强一致的解决方案（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 理解：? ACID 理解： ? Atomicity 原子性：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间 某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有 执行过一样。 ? Consistency 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。 ? Isolation 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防 止多个事务并发执行时由于交叉执行而导致数据的不一致。 ? Durability 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 分布式事务的基本介绍 分布式事务服务（Distributed Transaction Service，DTS）是一个分布式事务框架，用来保障在大规模 分布式事务服务（Distributed Transaction Service，DTS）是一个分布式事务框架，用来保障在大规模 分布式环境下事务的最终一致性。 CAP 理论告诉我们在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延 迟丢包等问题，所以分区容忍性是我们必须需要实现的，所以我们只能在一致性和可用性之间进行权衡。 为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等 性的保证，保证数据的最终一致性。 数据一致性理解： ? ? 强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。 这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论， 这种实现需要牺牲可用性。 ? 弱一致性：系统并不保证后续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入 成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更 最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更 新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副 本的个数影响。DNS 是一个典型的最终一致性系统。 常用的分布式技术说明 本地消息表 这种实现方式的思路是源于 ebay，其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。 举个经典的跨行转账的例子来描述。 第一步伪代码如下，扣款 1W，通过本地事务保证了凭证消息插入到消息表中。 第二步，通知对方银行账户上加 1W 了，通常采用两种方式： 第二步，通知对方银行账户上加 1W 了，通常采用两种方式： ? ? 采用时效性高的 MQ，由对方订阅消息并监听，有消息时自动触发事件。 ? 采用定时轮询扫描的