分布式理论

分布式系统的定义

硬件或软件分布在不同的网路计算机上，彼此间透过消息进行通信或协调的系统。

解决的问题（单体架构缺点）

• 对海量用户处理能力有限。
• 程序复杂性越高，开发效率越低。
• 生产环境发生重大BUG，将导致整个服务瘫痪。
• 代码量增加，编译效率下降。
• 只能关注一套技术栈。

名词释义（分布式/集群/网络分区）

分布式：多个人在一起做不同的事。

集群：多个人在一起做相同的事。

网络分区（脑裂）：网络之间不连通，导致分布式系统出现局部小集群，小集群间网络异常，小集群内部网路正常。

架构演进

单体应用架构->应用服务器和数据库服务器分离->应用服务器集群->数据库服务器主从复制，读写分离->增添搜索引擎缓解数据库压力->增加缓存缓解读库压力->数据库拆分（水平/垂直拆分）->应用服务器垂直拆分->应用服务器水平拆分。

一致性分类

1、强一致性：要求系统写入什么，读出来也是什么。性能影响大。

2、弱一致性：不承诺多久后数据能达到一致，尽可能在某个级别（秒/分/小时）达到一致状态。

3、读写一致性：第一时间看到自己更新的内容，其他人不保证。

• 特定内容从主库读取，主库压力大。
• 刚更新的内容从主库读取，过段时间后，从从库读取。

4、最终一致性：仅保证最终系统内所有副本的数据是正确的。

CAP定理

1、Consistency（一致性）：所有副本数据一致，从任意节点读取到的数据都是最新的。

2、Availablity（可用性）：对外提供的服务保持正常，不会出现响应超时或响应错误。

3、Partition torerance（分区容忍性）：当出现网络分区时，仍可对外提供服务。

任何分布式系统指哪个同时满足三个要求中的其中两个。例如：用户向N1发出请求，将值从vo改成v1，此时网络N1和N2之间发生中断，然后又有一个用户向N2发出请求获取该字段的值。此时有三种做法：

• 将vo返回（牺牲一致性，AP模式）
• 等待网络恢复，再返回v1（牺牲可用性，CP模式）
• 将N1，N2合并（舍弃分布式技术，CA模式）

BASE理论

对CAP定理的权衡结果，如果无法做到强一致性，则根据业务特点，以适当方式实现最终一致性。

1、Basically Available（基本可用）：当分布式系统出现故障时，允许损失部分可用性。（时间：正常是0.5秒响应结果，故障时可增加到1-2秒）。流量激增时，将部分用户引导到降级页面）

2、Soft State(软状态)：允许数据存在中间状态（有部分数据尚未完成同步），但不影响系统整体可用性。

3、Eventuallly consistent（最终一致性）：经过一段时间的同步后，数据最终能达到一致。

一致性协议（处理分布式事务）

2PC（两阶段提交）

流程

1、准备阶段：协调者给每个参与者发送prepare消息，运行本地事务但不提交。

2、提交阶段：协调者发现参与者运行失败或超时，则向参与者发送RollBack消息，否则发送Commit消息。

缺点

1、同步阻塞：在一阶段未到二阶段时，参与者事务都处于阻塞状态。

2、单点问题：如果协调者在运行二阶段时崩溃，参与者事务都处于锁定状态。

3、数据不一致：协调者在尚未发送完Commit消息就崩溃，将导致数据不一致。

4、过于保守：任意节点失败，将导致整个事务失败。

3PC（三阶段提交）

流程

1、CanCommit：协调者给每个参与者发送包含事务的请求，询问是否可以运行。

2、PreCommit：协调者要求参与者运行事务。

3、DoCommit：协调者要求参与者提交事务：此阶段参与者若无法收到协调者消息，超时默认提交事务。

降低了2PC的事务阻塞范围，但并未完全解决数据不一致的问题。

一致性算法（选出最终结果或Leader）

Paxos算法

角色

1、Client客户端：向分布式系统发出请求。

2、Proposer提案发起者：说服Acceptor达成一致。

3、Acceptor决策者：批准提案。

4、Leaner学习者：学习最终决策。

规范

1、一个Acceptor必须接受它收到的第一个提案。

2、每次收到的提案值，都必须跟第一次一样。

3、一个提案被选定，需要被半数以上的Acceptor接受。

流程1

1、Proposer向半数以上的Acceptor发起编号为N但没有Value的prepare请求。

2、如果Acceptor未接受过该提案，则返回null。

3、此时Proposer可以自行决定value值，向Accptor发起编号为N，值为value的accept请求。

4、Accpetor接受编号为N，值为Value的提案。

流程2

1、Proposer向半数以上的Acceptor发起编号为N+1但没有Value的prepare请求。

2、如果Acceptor已经接受过编号为N的提案，则返回提案N的Value值。

3、此时Proposer向Acceptor发起编号为N+1，值为Value的accept请求。

4、Acceptor接受编号为N+1，值为Value的提案。

极端情况：两个Proposer依次提交编号递增的提案，导致死循环。

解决：规定只有一个Proposer能提交提案。

Raft算法

角色

1、Leader领导者：与客户端交互，只有一个。

2、Candidate候选者：负责在选举过程中提名自己，当选举成功，成为领导者。

3、Follower跟随者：选民，等待投票通知。

流程

1、选举开始，所有节点都是Follower。

2、如果收到RequestVote（投票给我）、AppendEntries（已选出Leader）的请求，则保持Follower状态。

3、一段时间（随机150~300ms）内没收到请求，则将身份转换为Candidate开始竞选Leader，如果获得半数票数则成为Leader。

4、如果最后没选出Leader，则开启下一轮选举。

分布式系统设计策略

心跳检测

通常携带状态、元数据信息，方便管理。

• 周期心跳检测：响应超时，判定死亡。
• 累积失效检测：对濒临死亡的节点，发起有限次数重试。

高可用

• 主备模式（常用）：主机宕机，备机接管主机的一切工作。主机恢复后，通过自动热备或手动冷备的方式将服务切换回主机。
• 互备模式（多主）：两台主机同时运行，并且相互监测。
• 集群模式：多个节点同时运行，透过主节点分担请求，需解决主节点高可用问题。

负载均衡

解决方案

• 硬件：F5
• 软件：LVS、HAProxy、Ngnix。

策略：随机、轮询、权重、最少连接、哈希。

网路通信

RPC

Remote Procedure Cal