分布式数据库架构下，到底要不要使用 2PC来实现分布式事务呢？

前面介绍了很多关于分布式数据库的一些知识点，但是，分布式数据库还有一个很令人头疼的问题，那就是分布式事务。本篇文章，我们就来看一下，如何在海量的互联网业务中实现分布式事务。

一、分布式事务是什么？

事务的概念相信大家已经非常熟悉了，事务就是要满足 ACID 的特性，总结来说。

• A（Atomicity） 原子性：事务内的操作，要么都做，要么都不做；

• C（Consistency） 一致性：事务开始之前和事务结束以后，数据的完整性没有被破坏；如唯一性约束，外键约束等；

• I（Isolation）隔离性：一个事务所做的操作对另一个事务不可见，好似是串行执行；

• D（Durability）持久性：事务提交后，数据的修改是永久的。即使发生宕机，数据也能修复；

需要注意的是：当前数据库的默认事务隔离级别都没有达到隔离性的要求，MySQL、Oracle、PostgreSQL等关系型数据库都是如此。大多数数据库事务隔离级别都默认设置为 READ-COMMITTED，这种事务隔离级别没有解决可重复度和幻读问题。

但由于在绝大部分业务中，都不会遇到这两种情况。若要达到完全隔离性的要求，性能往往又会比较低。因此在性能和绝对的隔离性前，大多数关系型数据库选择了一种折中。

那什么是分布式事务呢？简单来说，就是要在分布式数据库的架构下实现事务的ACID特性。前面我们了解了分布式数据库架构设计的一个原则，即大部分的操作要能单元化。即在一个分片中完成。如对用户订单明细的查询，由于分片键都是客户ID，因此可以在一个分片中完成。那么他能满足事务的ACID特性。

但有的电商平台的核心业务逻辑，是无法实现在一个分片中完成的，比如下单的逻辑，大致流程如下：

START TRANSATION;

INSERT INTO orders VALUES (......