php企业网站开发源码/网络广告投放公司

1. 分布式基础理论

1.1 CAP理论

CAP 理论可以表述为，一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三项中的两项。

一致性是指“所有节点同时看到相同的数据”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，等同于所有节点拥有数据的最新版本。

可用性是指“任何时候，读写都是成功的”，即服务一直可用，而且是正常响应时间。我们平时会看到一些 IT 公司的对外宣传，比如系统稳定性已经做到 3 个 9、4 个 9，即 99.9%、99.99%，这里的 N 个 9 就是对可用性的一个描述，叫做 SLA，即服务水平协议。比如我们说月度 99.95% 的 SLA，则意味着每个月服务出现故障的时间只能占总时间的 0.05%，如果这个月是 30 天，那么就是 21.6 分钟。

分区容错性具体是指“当部分节点出现消息丢失或者分区故障的时候，分布式系统仍然能够继续运行”，即系统容忍网络出现分区，并且在遇到某节点或网络分区之间网络不可达的情况下，仍然能够对外提供满足一致性和可用性的服务。

分布式系统所关注的，就是在 Partition Tolerance 的前提下，如何实现更好的 A 和更稳定的 C。业务上对一致性的要求会直接反映在系统设计中，典型的就是 CP 和 AP架构。

CP 架构：对于 CP 来说，放弃可用性，追求一致性和分区容错性。
AP 架构：对于 AP 来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的 Base 也是根据 AP 来扩展的。

对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。

1.2 BASE理论

Base 是三个短语的简写，即基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。

Base 理论的核心思想是最终一致性，即使无法做到强一致性（Strong Consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual Consistency）。

基本可用

基本可用比较好理解，就是不追求 CAP 中的「任何时候，读写都是成功的」，而是系统能够基本运行，一直提供服务。基本可用强调了分布式系统在出现不可预知故障的时候，允许损失部分可用性，相比正常的系统，可能是响应时间延长，或者是服务被降级。

举个例子，在双十一秒杀活动中，如果抢购人数太多超过了系统的 QPS 峰值，可能会排队或者提示限流，这就是通过合理的手段保护系统的稳定性，保证主要的服务正常，保证基本可用。

软状态

软状态可以对应 ACID 事务中的原子性，在 ACID 的事务中，实现的是强一致性，要么全做要么不做，所有用户看到的数据一致。其中的原子性（Atomicity）要求多个节点的数据副本都是一致的，强调数据的一致性。

原子性可以理解为一种“硬状态”，软状态则是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

最终一致性

数据不可能一直是软状态，必须在一个时间期限之后达到各个节点的一致性，在期限过后，应当保证所有副本保持数据一致性，也就是达到数据的最终一致性。

在系统设计中，最终一致性实现的时间取决于网络延时、系统负载、不同的存储选型、不同数据复制方案设计等因素。

CAP 及 Base 的关系

Base 理论是在 CAP 上发展的，CAP 理论描述了分布式系统中数据一致性、可用性、分区容错性之间的制约关系，当你选择了其中的两个时，就不得不对剩下的一个做一定程度的牺牲。

Base 理论则是对 CAP 理论的实际应用，也就是在分区和副本存在的前提下，通过一定的系统设计方案，放弃强一致性，实现基本可用，这是大部分分布式系统的选择，比如 NoSQL 系统、微服务架构。

2. 分布式事务模型

2.1 强一致性模型

强一致性事务主要用于对数据一致性要求比较高，在任意时

刻都能查询出最新写入的数据的场景，比如跨行转账。

DTP模型

DTP模型是X/Open组织定义的一套分布式事务标准。这套标准主要定义了实现分布式事务的规范和API接口，具体的实现则交给相应的厂商来实现。

在DTP模型中定义了3个核心组件:

AP(Application Program)
应用程序，AP组件定义了分布式事务（也即全局事务）的边界（即事务的开始和结束）以及组成事务的具体操作（Actions）；
RM(Resource Managers)
资源管理器，RM指的是诸如MySQL、Oracle这样的数据库或者相应的数据库驱动或可访问的文件系统或者打印机服务器，用以提供访问数据库资源的接口；
TM(Transaction Manager)
事务管理器，TM是分布式事务的协调者，其负责为分布式事务分配事务ID，监控事务的执行过程，负责事务的完成和容错工作。TM管理的分布式事务可以跨多个RM，TM还管理2PC协议，协调分布式事务的提交/回滚决策。

在DTP模型中使用了2种通信规范：

TX规范，其定义了用于在AP组件和TM组件之间的通讯API规范，如tx_begin( )、tx_end()、tx_info()等接口用以开启、结束和查询分布式事务；
XA(eXtended Architecture)规范，其定义了TM和RM之间通信的API规范。XA协议中规定了DTP模型中RM需要提供prepare、commit、rollback接口给TM调用，以实现两阶段提交。

XA规范

XA规范是X/Open 组织针对二阶段提交协议的实现做的规范。目前几乎所有的主流数据库都对XA规范提供了支持。XA规范的最主要的作用是，就是定义了RM-TM的交互接口。

两阶段提交协议（Two Phase Commit）不是在XA规范中提出，但是XA规范对其进行了优化。XA规范对两阶段提交协议有2点优化：

只读断言

在Phase 1中，RM可以断言“我这边不涉及数据增删改”来答复TM的prepare请求，从而让这个RM脱离当前的全局事务，从而免去了Phase 2。

一阶段提交

如果需要增删改的数据都在同一个RM上，TM可以使用一阶段提交——跳过两阶段提交中的Phase 1，直接执行Phase 2。

执行流程

DTP中的分布式事务（即全局事务）的执行流程如下：

（1）首先，在系统中的所有RM通过XA规范提供的API向TM注册，即RM涉及的分支事务处理将纳入到TM统一管理；

（2）然后，AP开启全局事务，AP通过TX规范提供的API向TM申请全局事务的开启，此时，全局事务正式开启。TM会返回其为本次全局事务分配的全局事务ID，即XID，给提出全局事务的AP；

（3）接着，AP根据获取到的XID开始其操作序列，具体的操作就是向不同的RM发送SQL操作请求；

（4）然后，RM根据接受的来自AP的SQL操作请求进行本地数据库操作（即执行本地事务）。RM在执行本地事务时会通过TM提供的XA规范API提交分支事务请求（请求中携带XID）。TM在接收到RM的分支事务请求后，分配分支事务ID并将其反馈给相应的RM；

（5）TM与RM进行基于2PC协议的事务预提交，及进行Prepare操作；

（6）当TM根据RM Prepare操作的执行情况决策出现有分支事务已经全部完成Prepare操作，如果是，那么TM向AP发送Commit决策结果；否则，那么TM向AP发送Rollback决策结果。当进行2PC协议时，如果RM出现故障，TM负责协调故障处理，保证其决策可进行；

（7）当AP接收到TM的决策时，如果后续还有分支事务需要执行，那么AP继续步骤③；否则，AP决策分布式事务的结果是Commit还是Rollback。

（8）如果AP决定Commit/Rollback分布式事务，那么它将通过TX规范API通知TM，最终的执行决定由TM通过2PC协议通知RM完成；

（9）最后，RM向TM提出注销申请，TM注销已注册的RM；AP向TM提交分布式事务结束请求，TM结束分布式事务。

2PC

两阶段提交（Two Phase Commit），就是将提交(commit)过程划分为2个阶段(Phase)：

阶段1：

TM（事务管理器）通知各个RM（资源管理器）准备提交它们的事务分支。如果RM判断自己进行的工作可以被提交，那就对工作内容进行持久化，再给TM肯定答复；要是发生了其他情况，那给TM的都是否定答复。

以mysql数据库为例，在第一阶段，事务管理器向所有涉及到的数据库服务器发出prepare"准备提交"请求，数据库收到请求后执行数据修改和日志记录等处理，处理完成后只是把事务的状态改成"可以提交",然后把结果返回给事务管理器。

阶段2

TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare失败的话，则TM通知所有RM回滚自己的事务分支。

以mysql数据库为例，如果第一阶段中所有数据库都prepare成功，那么事务管理器向数据库服务器发出"确认提交"请求，数据库服务器把事务的"可以提交"状态改为"提交完成"状态，然后返回应答。如果在第一阶段内有任何一个数据库的操作发生了错误，或者事务管理器收不到某个数据库的回应，则认为事务失败，回撤所有数据库的事务。数据库服务器收不到第二阶段的确认提交请求，也会把"可以提交"的事务回撤。

两阶段提交方案下全局事务的ACID特性，是依赖于RM的。一个全局事务内部包含了多个独立的事务分支，这一组事务分支要么都成功，要么都失败。各个事务分支的ACID特性共同构成了全局事务的ACID特性。也就是将单个事务分支支持的ACID特性提升一个层次到分布式事务的范畴。

2PC存在的问题

二阶段提交看起来确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的：

同步阻塞问题

2PC 中的参与者是阻塞的。在第一阶段收到请求后就会预先锁定资源，一直到 commit 后才会释放。

单点故障

由于协调者的重要性，一旦协调者TM发生故障，参与者RM会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。

数据不一致

若协调者第二阶段发送提交请求时崩溃，可能部分参与者收到commit请求提交了事务，而另一部分参与者未收到commit请求而放弃事务，从而造成数据不一致的问题。

3PC

三阶段提交（3PC)，是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点：

引入超时机制。同时在协调者和参与者中都引入超时机制。
在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1.事务询问协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。

2.响应反馈参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段

协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

1.发送预提交请求协调者向参与者发送PreCommit请求，并进入Prepared阶段。

2.事务预提交参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

3.响应反馈如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

1.发送中断请求协调者向所有参与者发送abort请求。

2.中断事务参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

- Case 1：执行提交

1.发送提交请求协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。

2.事务提交参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

3.响应反馈事务提交完之后，向协调者发送Ack响应。

4.完成事务协调者接收到所有参与者的ack响应之后，完成事务。

- Case 2：中断事务协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

1.发送中断请求协调者向所有参与者发送abort请求

2.事务回滚参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3.反馈结果参与者完成事务回滚之后，向协调者发送ACK消息

4.中断事务协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。

2.2 最终一致性模型

TCC

TCC是Try-Confirm-Cancel的简称: