比较全的常见的架构设计思想整理

一、MPP 架构

1、MPP架构的基础概念

MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。

简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

MPP 属于Shared Nothing，根据Shared 的不同，可以分为如下几种：

Shared Everthting:一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer

Shared Disk：各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac，它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能。

Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和hadoop ，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。

我们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的schema，比如MySQL Proxy和Google的各种架构，只需增加服务器数就可以增加处理能力和容量。

很多 Nosql数据库都是基于 MPP Shared Nothing架构的，比如

Greenplum是一种基于PostgreSQL的分布式数据库。其采用shared nothing架构（MPP），主机，操作系统，内存，存储都是自我控制的，不存在共享。也就是每个节点都是一个单独的数据库。节点之间的信息交互是通过节点互联网络实现。通过将数据分布到多个节点上来实现规模数据的存储，通过并行查询处理来提高查询性能。
这个就像是把小数据库组织起来，联合成一个大型数据库。将数据分片，存储在每个节点上。每个节点仅查询自己的数据。所得到的结果再经过主节点处理得到最终结果。通过增加节点数目达到系统线性扩展。

elasticsearch也是一种MPP架构的数据库，Presto、Impala等都是MPP engine，各节点不共享资源，每个executor可以独自完成数据的读取和计算，缺点在于怕stragglers，遇到后整个engine的性能下降到该straggler的能力，所谓木桶的短板，这也是为什么MPP架构不适合异构的机器，要求各节点配置一样。

Spark SQL应该还是算做Batching Processing, 中间计算结果需要落地到磁盘，所以查询效率没有MPP架构的引擎（如Impala）高。

2、MPP架构特征

● 任务并行执行;

● 数据分布式存储(本地化);

● 分布式计算;

● 私有资源;

● 横向扩展;

● Shared Nothing架构。

3、基于MPP架构的数据库架构

这种架构中的每一个节点（node）都是独立的、自给的、节点之间对等，而且整个系统中不存在单点瓶颈，具有非常强的扩展性。

二、SMP(Symmetric Multi-Processor)架构

SMP又称对称多处理器结构，SMP系统内有许多紧耦合多处理器，在这样的系统中，所有的CPU共享全部资源，如总线，内存和I/O系统等;

所谓对称多处理器结构，是指服务器中多个 CPU 对称工作，无主次或从属关系。各 CPU 共享相同的物理内存，每个 CPU 访问内存中的任何地址所需时间是相同的，因此 SMP 也被称为一致存储器访问结构 (UMA ： Uniform Memory Access) 。对 SMP 服务器进行扩展的方式包括增加内存、使用更快的 CPU 、增加 CPU 、扩充 I/O( 槽口数与总线数 ) 以及添加更多的外部设备 ( 通常是磁盘存储 ) 。

主要特征是共享，系统中所有资源 (CPU 、内存、 I/O 等 ) 都是共享的。也正是由于这种特征，导致了SMP 服务器的主要问题，那就是它的扩展能力非常有限。对于 SMP 服务器而言，每一个共享的环节都可能造成 SMP 服务器扩展时的瓶颈，而最受限制的则是内存。由于每个 CPU 必须通过相同的内存总线访问相同的内存资源，因此随着 CPU 数量的增加，内存访问冲突将迅速增加，最终会造成 CPU 资源的浪费，使 CPU 性能的有效性大大降低。实验证明， SMP 服务器 CPU 利用率最好的情况是 2 至 4 个 CPU 。

三、SOA 架构

SOA 即面向服务的架构，将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来，接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性，SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

松耦合系统脚骨的好处有两点：

1、它的灵活性，它非常的灵活。

2、当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。与之相反，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用跟SOA 相提并论的还有一个ESB（企业服务总线），单来说ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

SOA 所解决的核心问题：

1. 系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如ESB、以及技术规范、服务管理规范；
这一步解决的核心问题是【有序】

2. 系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】

3. 业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。

本文作者：张永清来源出处：https://www.cnblogs.com/laoqing/p/13042432.html

四、微服务架构

微服务架构其实和SOA 架构类似,微服务是在SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

组件表示一个可以独立更换和升级的单元，就像PC 中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。如果我们把PC 作为组件以服务的方式构建，那么这台PC 只需要维护主板和一些必要的外部设备。CPU、内存、硬盘都是以组件方式提供服务，PC 需要调用CPU 做计算处理，只需要知道CPU 这个组件的地址即可。

SOA与微服务区别：

1、SOA注重重用，微服务注重重写

SOA 的主要目的是为了企业各个系统更加容易地融合在一起。
微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始。

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的 API Gateway 的模式主要目的也不是重用代码。

而是减少客户端和服务间的往来。API gateway 模式不等同与 Facade 模式，我们可以使用如 Future 之类的调用，甚至返回不完整数据。

2、SOA注重水平服务，微服务注重垂直服务

本文作者：张永清来源出处：https://www.cnblogs.com/laoqing/p/13042432.html

SOA 设计喜欢给服务分层(如 Service Layers 模式)。我们常常见到一个 Entity 服务层的设计，美其名曰 Data Access Layer。这种设计要求所有的服务都通过这个 Entity 服务层。来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的 Data Store。我们在拆分数据库时可以适当的做些去范式化，让它不需要依赖其他服务的数据。

微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。在 SOA 设计模式中这种情况通常会用到 Multi-ChannelEndpoint 的模式返回一个大而全的结果兼顾到所有的客户端的需求。

3、SOA注重自上而下，微服务注重自下而上

SOA 架构在设计开始时会先定义好服务合同。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法来集中管理服务。SOA 架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。

SOA 架构适用于 TO GAF 之类的架构方法论。

微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。

微服务与 SOA 有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与 SOA 原则的演化的目标也是相同的，则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于，微服务专注于以自治的方式产生价值。但是两种架构背后的意图是不同的：SOA 尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

五、架构设计图

1、技术架构

从技术层面描述，主要是分层模型，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的主要实现概括

2、系统架构

指的完整系统的组成架构，例如系统分成几个部分？服务平台、管理门户、终端门户、ATM门户、外部系统以及接口、支撑系统等，将这些系统进行合理的划分。然后再进行功能分类细分，总之，将整个系统业务分解为逻辑功能模块，并且科学合理，就是系统架构

3、部署架构

指的是系统如何部署，包括应用的节点机器，网络、交换机，防火墙等。比如采用什么网络，nginx 部署几台，vip如何转发、APP应用部署多少个节点等。

4、数据架构

数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

5、代码架构

子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

代码架构主要定义：

①. 代码单元:

配置设计框架、类库。

②. 代码单元组织：

编码规范，编码的惯例。项目模块划分顶层文件结构设计，比如mvc设计。依赖关系

六、分布式架构中分布式事务的解决方案

1、分布式架构中分布式事务问题以及2PC/3PC协议

1）、单机ACID事务：

ACID原则是数据库事务正常执行的四个，分别指原子性、一致性、独立性及持久性。但是随着项目越来越大，数据量越来越多，单台数据库的磁盘系统被占满了或是单张表数据量太大，导致客户端请求数据库时存在阻塞问题或者是效率问题，此时的做法是将数据库进行分库分表，将数据按一定的规则（比如按照不同的业务）分配到不同的机器上，此时数据会在多个分布于不同服务器中的数据库，所以产生了分布式事务的问题。

2）、分布式事务：

分布式事务指的是跨系统、跨机器之间的事务，由于其不满足单机的ACID特性，所以分布式事务往往很复杂。分布式数据库的一般划分方式如下：

垂直切分：将单个表按业务细化出多张表，每张表存放着不同的字段，当需要使用到多张表时将其连接在一起（join）即可获取到所需的数据。

水平切分：使用多台数据库或表，将原先位于一个库或表的数据按某种规则映射到不同的机器上，以此来减少原先单库或单表中所含的数据大小。
按业务流程拆分：
- 通常，出现分库分表的场景还和业务拆分相关，一个很大的系统往往会拆分为多个小系统，每个小系统之间通过RPC来进行调用，相互协调完成业务，这也会出现分布式事务的问题：

3）、两阶段提交协议（2PC）：

两阶段提交协议(2PC)是处理分布式事务的一种基本协议，两阶段指的是prepare和commit/rollback阶段，并且划分出了事务管理器与资源管理器角色：

在两阶段提交协议中，有一个事务管理器和多个资源管理器，事务管理器分两阶段协调资源管理器。

在第一阶段，事务管理器询问所有资源管理器准备是否成功（prepare）。

如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作（commit）。

如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作（rollback）。

通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。
　　

该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
所有节点不会永久性损坏，即使损坏后仍然可以恢复。

优缺点：

优点：原理简单，实现方便。

缺点：
同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

4）、三阶段提交协议（3PC）

3PC，Three-Phase Commit，三阶段提交协议，由CanCommit、PreCommit、Do Commit三阶段组成。三阶段提交协议（3PC）相较于2PC来说，新增了一个预提交阶段（preCommit）与超时机制来再次校验当前是否全部资源管理器（参与者）都能够提交成功（或超时），若成功则进行真正的提交阶段，若不成功则回滚。

阶段一：Can Commit

事务询问。协调者向参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待参与者相应。
参与者向协调者反馈事务询问的相应。

Can Commit阶段和2PC的提交请求阶段一样。

阶段二：PreCommit

执行事务PreCommit

假如协调者获取的所有相应都是YES则执行事务预提交。

发送预提交请求。
事务预提交，执行事务操作，并将Undo和Redo信息记录到事务日志中
各参与中向协调者反馈事务执行结果的相应。

阶段三：doCommit
真正的事务提交，存在两种结果：

执行提交

发送提交请求协调者由预提交转换到提交状态，向所有参与者发送doCommit请求
事务提交参与者收到doCommit请求后，执行事务提交
反馈事务提交结果参与者完成事务提交后，向协调者发送ACK消息
完成事务协调者接收到所有参与者反馈的ACK消息后，完成事务

中断事务

发送中断请求
事务回滚
反馈事务回滚结果
中断事务

进入阶段三也存在两种故障：

协调者出现问题

协调者和参与者网络出现问题。

无论出现那种情况，最终都会导参与者无法及时接收到来自接收到协调者的doCommit请求或者是abort请求，针对这样的异常，参与者都会在等待超时之后，继续进行事务提交。

优点：降低参与者阻塞范围，并能够在出现单点故障后继续达成一致

缺点：引入preCommit阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者依然会进行事务提交，造成数据不一致。

3PC解决了参与者的阻塞范围，并且解决了协调者单点故障的问题。但是3PC还是存在问题：3PC无法解决当存在网络分区的时候，参与者无法通信的问题，在这种情况下，参与者只有一部分参与者能够执行提交请求，造成参与者数据不一致。

2、带有业务侵入的分布式事务解决方案：

1）、消息队列：

对于分布式事务问题，最简单的一种方式是使用消息队列来作为消息表，在业务的调用流程中通过消息队列来传达事务的执行结果，然后下一个流程作为消费者消费这个执行结果即可。由于要借助消息队列来完成这个过程，所以这种做法是有业务侵入的。

优缺点：

使用MQ解决分布式事务问题有如下的优点和缺点：

优点：简单易实现，并且随着MQ集群的出现和RocketMQ的prepare机制，使得这种方案具备高可用性和高性能，能达到最终一致性。是最常见的解决方案。

缺点：消费者只能成功，不能失败，若消费者失败也不能回滚前者的事务；具有一定的业务侵入性。

重点推荐：RocketMQ，因为其支持事务消息，RocketMQ的事务消息是基于2PC的提交协议。

RocketMQ通过两个内部的topic来实现对消息的两阶段支持，RocketMQ在实现事务消息时，实际上是通过将生产投递过来的消息（消息上带有事务标识）投递到一个名为RMS_SYS_TRANS_HALF_TOPIC的topic中，而不是投递到真正的topic中，这个过程是第一阶段(prepare)，然后producer再通过TransactionListener的executeLocalTransaction方法执行本地事务，当producer的localTransaction处理成功或者失败后，producer会向broker发送commit或rollback命令，如果是commit，则broker会将投递到RMQ_SYS_TRANS_HALF_TOPIC中的消息投递到真实的topic中，然后再投递一个表示删除的消息到RMQ_SYS_TRANS_OP_HALF_TOPIC中，表示当前事务已完成；如果是rollback，则没有投递到真实topic的过程，只需要投递表示删除的消息到RMQ_SYS_TRANS_OP_HALF_TOPIC。最后，消费者和消费普通的消息一样消费事务消息。

整个过程如果没有遇到问题，则一切OK，但整个过程中可能会遇到以下错误：

第一阶段（prepare）失败：给应用返回发送消息失败
事务失败：发送回滚命令给broker，由broker执行消息的回滚
Commit或rollback失败：由broker定时向producer发起事务检查，如果本地事务成功，则提交消息事务，否则回滚消息事务

事务状态的检查有两种情况：

commit/rollback：broker会执行相应的commit/rollback操作
如果是TRANSACTION_NOT_TYPE，则一段时间后会再次检查，当检查的次数超过上限（默认15次）则丢弃消息

异常情况示意图如下：

2）、TCC：

TCC是一种经典的2PC解决方案，也就是将整个事务控制过程分为Try、Confirm和Cancel阶段，通过Try阶段来对所有的参与者进行资源的检查与预留，如果Try阶段全部成功，那么就对所有参与者进行Confirm；如果Try阶段出现一者失败，那么就对所有参与者进行Cancel。

由于Try、Confirm、Cancel 3个方法均由业务编码实现，所以TCC是具备强业务侵入性的。

并发控制：在实现TCC时，应当考虑并发性问题，将锁的粒度降到最低，以最大限度提高分布式事务的并发性。
幂等性：由于网络可能出现数据包重传的情况，所以需要考虑Try、Confirm和Cancel这三个阶段的幂等性，也就是Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。

3）、Saga：

Saga事务核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

Saga事务基本协议如下：

每个Saga事务由一系列幂等的有序子事务Ti组成。
每个Ti都有对应的幂等补偿动作Ci，补偿动作用于撤销Ti造成的结果，补偿过程也被称为冲正过程。

例如现在T1、T2、T3为扣减库存、创建订单、支付订单，如果在支付订单时失败了，那么就对原先的操作做回退，也就是补偿冲正：C3支付回滚、C2订单回滚、C1库存回滚，使得数据回到最开始的状态。

可以将Saga的各事务做成服务编排，制订好每个事务之间的调用顺序和回退顺序，这样可以将整个Saga事务的流程清晰化和规范化：

优缺点：

优点：实现简单，并且整个Saga事务的流程都十分地清晰，基于消息队列构建的Saga事务还可以避免单点问题。

缺点：具有业务侵入性，需要制订好每个子事务失败后对应的回滚（冲正）操作。

可以看到，和TCC相比，Saga没有“预留”动作，它的Ti就是直接提交到库。

3、业务非侵入的解决方案：

1）、FMT：

FMT（Framework-managed transaction）即框架管理事务，是一种无侵入的事务解决方案。该模式下，分布式事务框架会托管所有的事务操作，事务的一阶段和二阶段操作均由框架自动生成。

FMT一阶段：拦截业务SQL语句，保存SQL执行前的快照，执行SQL，并且添加相应的行锁，避免出现并发冲突。

FMT二阶段：执行其他业务SQL，若都成功，那么删除一阶段中产生的锁和快照；若其一失败，则重做快照，回滚数据，删除行锁。

优缺点

优点：整个事务处理过程由框架自动化完成，无需人工参与，无业务侵入性。

缺点：由于基于框架来对SQL、事务等进行拦截，所以会有性能损耗（譬如需要使用注解、反射、动态代理等机制）。

2）、XA：

XA模式是另外一种无侵入的分布式事务解决方案，不同于FMT的是，XA模式下，所有一阶段和二阶段都由数据库来完成，而不是由框架来完成。其原理与FMT相似，都是借助了快照来完成回退操作。

优缺点

优点：主流的数据库都实现了XA分布式事务方案，所以可以方便地实现。

缺点：严重依赖于数据库自身的规范和接口，不能高效拓展。

3）、Atomikos

对于数据库层面的分布式事务而言，JTA（Java Transaction API，XA的JAVA实现方案）是一个不错的解决方案，通常JTA需要应用服务器的支持，但在查阅SpringBoot的文档时发现，它推荐了Atomikos和 Bitronix两种无需服务器支持的分布式事务组件，在这两个组件中，Atomikos更受大家的好评，所以建议选择使用Atomikos。Atomikos是一个公司的名字，AtomikosTransactionsEssentials是其开源的分布式事务软件包，而ExtremeTransactions是商业的分布式事务软件包。TransactionsEssentials是基于apache-license的，是JTA/XA的开源实现，支持Java Application和J2EE应用。需要的jar包：jta.jar、transactions-essentials-all.jar。（可以在http://www.atomikos.com下载）。

github地址：https://github.com/atomikos/transactions-essentials

4）、Seata

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务，由阿里巴巴一起参与开源的。目前还处于成长期，很多功能还有待实现和完善。

官方主页：http://seata.io/zh-cn/index.html

github地址：https://github.com/seata/seata

4、总结

分布式事务的解决基础是2PC和3PC协议。

2PC和3PC协议都划分出两个角色：事务发起者（事务管理器）和跟随者（资源管理器）。

2PC在第一阶段，事务管理器询问所有资源管理器准备是否成功（prepare）。如果所有资源均准备成功，那么在第二阶段事务管理器会要求所有资源管理器执行提交操作（commit）。如果任一资源管理器在第一阶段返回准备失败，那么事务管理器会要求所有资源管理器在第二阶段执行回滚操作（rollback）。通过事务管理器的两阶段协调，最终所有资源管理器要么全部提交，要么全部回滚，最终状态都是一致的。

3PC相对于2PC来说，增加了超时ACK判断以及在真正提交之前增加了预提交阶段（pre commit）来保证事务能够全部提交成功。

分布式事务的常见解决方案分为两大类，一类是业务侵入点、另一类是业务非侵入的。

业务侵入的有MQ、TCC、Saga这三种解决方案。MQ的优点是实现简单并且不会存在单点问题，但是需要使用特定的MQ譬如RocketMQ中的Half Message才能够满足需求，并且消费者对于消息的消费是一定需要成功的；TCC是一种经常使用的方案，它的做法是将整个分布式事务拆分为三个部分：Try、Confirm和Cancel，在Try阶段进行资源的检查与预留，在第二阶段进行事务的统一Confirm和Cancel；Saga的做法是将长事务拆分成顺序执行的子事务，如果其中一个子事务执行失败，则需要继续相应的事务补偿、回滚和数据冲正。

非业务侵入的解决方案有FMT和XA两种选择，FMT的思路是由框架来对SQL进行拦截，并且保存之前的快照，在第二个阶段中如果全部事务都执行成功那么就删除之前的快照并且释放掉行锁，如果执行失败，那么会执行之前的快照。XA和FMT的做法是类似的，不过XA的两个阶段都由数据库自身来保证。

最后，其实每一种方案都有各自的优点与缺点，要结合自身业务的情况和系统的特性来选择具体的方案，选择性地牺牲某些方面以保证某些方面。

七、大数据平台架构

1、Lambda架构

1）、Lambda架构的主要思想是将大数据系统架构为多个层次，分别为批处理层（batchlayer）、实时处理层（speedlayer）、服务层（servinglayer），如下图所示