SpringCloud/分布式入门

1.集群/分布式/微服务/SOA是什么？

1.1什么是集群

源于维基百科
计算机集群简称集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多

集群的技术特点

• 通过多台计算机完成同样的任务，达到更高的效率——就比如我一台Redis最多允许同时处理100个请求，要同时处理200个请求，加多一台Redis实例即可
• 两台或多台机器的内容和工作过程完全一样，如果有一台死机，那么另一台可以接替它的工作

集群：同一个业务，部署在多个服务器上(不同的服务器运行同样的代码，干同一件事)

2.什么是分布式

源于维基百科
分布式系统是一组计算机，通过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。

Example：

小明在公司身兼数职，行政和财务都是他来负责（模块耦合性很高），压力实在太大，后面公司找了一个新的财务经理，小明可以专心负责行政了（模块抽离）

在项目种，其实主要访问的都是那几个热点模块，其他访问量很低的模块（比如后台管理）其实是很少访问的，所以我们可以将每个模块单独抽取出来，访问量大的模块用好的服务器部署，而访问量低的就用差一点的

这样做有两个好处：

• 资源利用率更合理
• 代码耦合度降低，模块之间独立，便于扩展和复用
• 高吞吐量，某个任务在一台机器上可能要10小时，用10台机器分布式运行可能只需要2小时

分布式：一个业务分拆多个子业务，部署在不同的服务器上(不同的服务器，运行不同的代码，为了同一个目的)，集群是不同服务器运行相同的代码

注意，集群和分布式并不冲突，我们可以有分布式集群，就相当于用多个集群做不同的小任务，

2.CAP理论

• C(Consistency)数据一致性：服务A、B、C三个节点都存储了用户数据，三个节点的数据都需在同一时刻保证数据的一致性。（A中的数据发生改变，那么B、C也要获取这个改变，并同步修改）
• A(Availability)可用性：服务a,b,c三个节点，其中一个节点死机了，那么另外两台结点分担它的任务，不能影响整个集群的工作
• P(Partiton Tolerance)分区容错性：允许系统通过网络协调工作，分区容错性要解决由于网络分区导致数据的不完整以及无法访问的问题
  （以下三个结点就是一个集群，他们之间可以相互通信）
  

由于我们的系统是分布式的，节点之间的通信是通过网络来进行的。只要是分布式系统，那很有可能会出现一种情况：因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。
数据散落在这些不连通的区域中，就叫做分区

现在出现了网络分区后，此时有一个请求过来了，想要注册一个账户。

此时**节点3和节点1是不可相互通信的，**这就需要进行抉择

• 如果此时允许用户成功注册，那么用户注册成功的记录只会在节点1和节点2或者节点2和节点3之间同步，这其实就是我们说的保证了可用性
  （为了可用性放弃了数据一致性）
• 如果此时不允许用户成功注册，而是必须等到节点1和节点3恢复通信才行，这就保证了数据一致性而放弃了可用性

CAP细分化

1.一般我们所说的分布式系统，P（分区容错性）是必需的，但是CAP是没有办法同时保证三个特性的，所以我们可以选择AP或者CP，但这不意味着我们完全放弃了A或者C
2.在CAP理论中的C其实代表的是强一致性，要求每个节点上的数据都必须是最新的，其实一致性还有其他级别
1）弱一致性：弱一致性是相对于强一致性而言，它不保证总能得到最新的值；可以理解为数据更新后，能容忍后续的部分访问无法完成或者全部访问都无法完成，这就是弱一致性（就好比双十一抢货的时候，明明还显示有货，但是点击就提示已经卖光了）
2）最终一致性(eventual consistency)：放宽对时间的要求，在完成操作响应后的某个时间点，被调多个节点的数据最终达成一致，最终一致性其实就是一种特殊的弱一致性

弱一致性和最终一致性的区别

弱一致性即使过了不一致时间窗口，后续的读取也不一定能保证一致，而最终一致过了不一致窗口后，后续的读取一定一致。

可用性的值域可以定义成0%到100%的连续区间

所以，CAP理论定义的其实是在容忍网络分区的条件下，“强一致性”和“极致可用性”无法同时达到。

于是在CAP理论的基础上再次延展出了一个分布式理论——BASE理论

什么是BASE理论

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

BA(Basically Available)——基本可用

系统在某些不可抗力的影响下，仍然能够保证“可用性”，即在一定时间内仍能返回一个确定的结果，这就是基本可用

BA和C的区别

• 可以适当的延长响应时间，例如双十一秒杀活动，响应的时间比平时慢很多
• 给部分用户直接返回一个降级页面，但是这个降级页面也必须是一个明确的结果

S(Soft State)——软状态

软状态就是允许系统中的数据存在一个中间状态，并且认为这个中间状态不会影响系统的整体可用性。即是可以对系统不同节点之间的数据同步进行一个延迟过程。

E(Eventually)——最终一致性

同一个共享数据的多个副本可以暂时不一致，但经过一定时间后一定是全部一致的（最终还是会转换成强一致性）

分布式事务解决方案

在分布式架构下，每个节点只知晓自己操作的失败或者成功，无法得知其他节点的状态。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚（rollback）。

TM-Transaction Manager：事务协调者/管理者
AP-事务参与者:对应分布式系统中的节点，也是真正执行事务的角色

1.两阶段提交——2PC

二阶段提交协议（Two-phase Commit，即 2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理。

准备阶段

这是2PC中的第一阶段，由TM向系统的各个节点（AP）询问是否可以提交事务，但是并不是真正提交了事务

准备阶段又可以细分为3步操作
1）管理者TM向所以AP发送事务内容，询问是否可以提交事务，并等待响应
2）各个参与者执行事务，并将执行的操作记录在redo和undo日志中（这些信息保存在数据库MySQL中）
3）如参与者成功执行，反馈同意，否则返回中断事务信息

提交阶段

这一段阶段属于2PC的第二阶段（提交-执行阶段），协调者发起正式提交事务的请求，当所有参与者都回复同意时，则意味着完成事务，流程图如下：

可以细分为4个步骤
1）TM向各个参与者发送正式提交事务的commit指令，并等待反馈
2）参与者提交事务，并释放在整个事务期间占用的所有资源
3）所有参与者向TM返回一个ACK完成信息
4）TM收到所有参与者的ACK响应后，完成事务

但是在准备阶段如果有任一节点没有返回ack响应或者返回超时，都会中断事务，然后进行回滚，回滚事务依靠的就是MySQL中记录的undo和redo事务日志

回滚事务的步骤如下
1）TM向所以参与者发送一个回滚指令
2）各个参与者根据数据库中的事务日志（undo log）进行回滚操作，并释放在事务期间占用的所有资源
3）向TM返回回滚完成的ack响应
4）TM收到所有参与者的回滚ack后，取消事务

但是如果是在提交阶段返回ack响应信息超时是不会回滚事务的

2PC的缺点

• **性能问题：**延迟了事务的提交过程，并且在事务期间如果占用了一些系统公共资源，会阻塞第三方节点访问
• **单点故障问题：**如果TM发生了故障，那么所有参与者会因得不到指令而一直阻塞，需要人工进行干预
• 数据一致性问题：如果TM在发送commit指令之后宕机了，然后唯一收到这条commit指令的参与者也宕机了，那么即时后面恢复了TM，也无法得知这个事务的具体情况了，这是2PC无法解决的问题

2PC的优点

可以保证强一致性，对于一些对数据一致性要求高的系统可以使用（但也无法100%保证）

3阶段提交（3PC）

三阶段提交协议，是二阶段提交协议的改进版本，三阶段提交有两个改动点。

• 在TM和AP中都引入了超时重试机制
• 将2PC的准备阶段分成了两部分——Cancommit和Precommit，保证在最后的提交阶段各个AP的状态一致

阶段一：CanCommit阶段

其实和2PC的准备阶段很像，TM向所有参与者发起请求，询问是否可以执行事务。AP返回yes或者no

• 事务询问：协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
• 响应反馈：参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段二：PreCommit阶段

根据Cancommit阶段的响应信息，Precommit阶段有两种不同的操作

假如所有参与者均反馈 yes，TM预执行事务。
1）TM向所以AP发送Precommit指令
2）AP收到Precommit指令后，执行事务，并记录事务日志（不提交事务）
3）AP向TM返回ack响应

假如有一个或多个AP返回无法执行事务的响应，TM中断事务
1）TM向所有AP发送abort指令，中断执行事务
2）参与者收到abort指令，执行事务中断

阶段三：doCommit阶段

这个阶段会真正的提交事务，但是也会分两种情况

进入阶段 3 后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的 do Commit 请求或 abort 请求。3PC引入的超时机制就在这里起作用，超时后AP会自动提交事务。

1.TM发送doCommit指令
2.AP收到指令后，进行事务提交，提交完成后释放资源，返回ack
3.TM收到所有参与者的ack后，完成事务

• 中断事务：任何一个参与者返回no或者等待超时重试一定次数后仍没有收到ack响应，则执行事务中断
• 发送中断请求 如果协调者处于工作状态，向所有参与者发出 abort 请求
• 事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
• 反馈结果 参与者完成事务回滚之后，向协调者反馈ACK消息
• TM收到ack后，进行事务中断

3PC的优点

引入了超时重试机制，避免了2PC里出现的单点故障导致事务阻塞的问题

缺点

仍然没有解决数据一致性问题，假设一个AP（设置为x）在收到preCommit指令后与TM无法通信，而此时TM此时因为没有收到所有AP的ack，决定中断事务，但是这个指令无法发给x，x在等待超时后会自行提交事务。

TCC(事务补偿)——try-confirm和try-cancel

TCC（Try Confirm Cancel）方案是一种应用层面侵入业务的两阶段提交。是目前最火的一种柔性事务方案，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。

TCC分为两个阶段
1）第一阶段——try，对业务代码进行检测并保留执行事务所需的所有资源（加锁，锁住资源）
2）第二阶段：本阶段根据try阶段的结果决定confirm还是cancel

• Confirm（确认）：执行真正的业务（执行业务，释放锁）
• Cancel（取消）：取消try阶段保留的所有资源（释放锁）