浅谈分布式事务
现今互联网界，分布式系统和微服务架构盛行。一个简单操作，在服务端非常可能是由多个服务和数据库实例协同完成的。在一致性要求较高的场景下，多个独立操作之间的一致性问题显得格外棘手。
基于水平扩容能力和成本考虑，传统的强一致的解决方案（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，通过本地事务保证了凭证消息插入到消息表中。
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投递消息的操作就一定能成功。这样一致性似乎很难保证。
try {
bool result = dao.update(model); // 操作数据库失败，会抛出异常
if (result) {
mq.send(model); // 如果mq方式执行失败，会抛出异常
}
} catch(Exception e) {
rollback(); // 如果发生异常，则回滚
}
我们来分析下可能的情况：
- 操作数据库成功，向MQ中投递消息也成功，皆大欢喜。
- 操作数据库失败，不会向MQ中投递消息了。
- 操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚。
从上面分析的几种情况来看，基本上能保证发送者发送消息的可靠性。我们再来分析下消费者端面临的问题：
- 消息出列后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致。
- 尽量避免消息重复消费。如果重复消费，也不能因此影响业务结果。
This chapter requires login to view full content. You are viewing a preview.
Login to View Full ContentCourse Curriculum
编程根基：数据结构、算法与系统基础
Java 内核：JVM 与并发编程
框架与 I/O：Spring、Netty 与 Web 容器
高性能中间件：消息、缓存与存储
架构能力：高可用、DDD 与系统设计
云原生：容器化、可观测性与工程效能
Speaker
