分布式事务架构设计.pdfVIP

分布式事务架构设计 1 现今互联网界， 分布式系统和微服务架构盛行。 一个简单操作， 在服务端非常可能是由多个服务和数 据库实例协同完成的。在一致性要求较高的场景下，多个独立操作之间的一致性问题显得格外棘手。 基于水平扩容能力和成本考虑，传统的强一致的解决方案（ e.g. 单机事务）纷纷被抛弃。其理论依据就是 响当当的 CAP 原理。往往为了可用性和分区容错性，忍痛放弃强一致支持，转而追求最终一致性。 分布式系统的特性 在分布式系统中，同时满足 CAP 定律中的一致性 Consistency 、可用性 Availability 和分区容错性 Partition Tolerance 三者是不可能的。在绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性， 系统往往只需要保证最终一致性。 2 CAP 理解： Consistency ：强一致性就是在客户端任何时候看到各节点的数据都是一致的 （All nodes see the same data at the same time ）。 Availability ：高可用性就是在任何时候都可以读写（ Reads and writes always succeed ）。 3 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 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 分布式事务的基本介绍 4 分布式事务服务（ Distributed Transaction Service ，DTS ）是一个分布式事务框架，用来保障在大规模 分布式环境下事务的最终一致性。 CAP 理论告诉我们在分布式存储系统中， 最多只能实现上面的两点。 而由于当前的网络硬件肯定会出现延 迟丢包等问题，所以分区容忍性是我们必须需要实现的，所以我们只能在一致性和可用性之间进行权衡。 为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等 性的保证，保证数据的最终一致性。 数据一致性理解： 强一致性： 当更新操作完成之后， 任何多个后续进程或者线程的访问都会返回最新的更新过的值。 这种是对用户最友好的，就是