本文介绍关于分布式系统的一些理论，后续还会涉及到
CAP理论
- 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本
- 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
- 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在一定时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
- 三者很难同时满足，一般根据系统处理业务场景在某一点上进行折中
BASE理论
- Basically Available, Soft state, Eventually consistent（基本可用、软状态、最终一致性）
Paxos
- 是一个解决分布式系统中，多个节点之间就某个值（提案）达成一致（决议）的通信协议
- 两阶段协议，分为Prepare阶段和Accept阶段
- Prepare阶段
- Proposer生成全局唯一且递增的提案ID（生成方法很多，比如时间戳+IP+序列号等），向Paxos集群的所有机器发送请求，这里无须携带提案内容，只携带提案ID即可（且把提案id叫作Pn，也有一种说法ID其实代表版本version）
- Acceptor收到提案请求后，做出以下约定：1）不再应答<=Pn的Prepare请求 2）对于<Pn的Accept请求亦不处
- Accept阶段
- Proposer收集到多数派应答（这里的多数派，就是超过n/2+1, n是集群数）Prepare阶段的返回值后，从中选择proposalID最大的提案内容，作为要发起Accept的提案，如果这个提案为空值，则可以自己随意决定提案内容。然后携带上当前proposalID，向Paxos集群的所有机器发送Accpet请求
- Accpetor收到Accpet请求后，检查不违背自己之前做出约定的情况下，持久化当前Proposal ID和提案内容。最后Proposer收集到多数派应答的Accept回复后，形成决议
- Prepare阶段
2PC
- 在事务处理、关系型数据库及计算机网络中，2阶段提交协议（2PC）是一种典型的原子提交协议（atomic commitment protocol）。它是一种由协调器来处理分布式原子参与者是提交或者回滚事务的分布式算法
- 协议包括2个阶段
- 提交请求阶段或者叫投票阶段：该阶段的任务是确定相关参与者对于事务处理是否准备就绪，YES代表可以commit, NO则反之
- 提交阶段：基于投票结果，由协调器决定提交事务抑或是退出事务处理；各事务参与者遵循指示，对本地事务资源做需要的动作
- 最大的不足是提交协议是阻塞型协议，如果事务协调器宕机，某些参与者将无法解决他们的事务：一个参与者发送确认消息给协调器，因协调器无法工作而导致事务未处理完而处于悬挂状态
3PC
- 第一阶段，投票，事务协调器询问参与者是否能提交（canCommit），都得到肯定回答后，继续第二阶段。第二阶段是预提交，都确认预提交成功后，进行第三阶段。第三阶段就是真实的提交，成功则完成事务；失败则继续重试
- 3PC是在2PC的基础上增加了一次交互，也就是preCommit（又称预提交）。只要预提交都成功，则一定要保证doCommit提交成功，即使协调器在下一阶段不可用，或者调用超时
Raft
- Paxos和Raft都是为了实现一致性（Consensus）这个目标，这个过程如同选举一样，参选者需要说服大多数选民（服务器）投票给他，一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同
- 选举过程：
- 任何一个服务器都可以成为一个候选者，它向其他服务器（选民）发出要求选举自己的请求
- 其他服务器同意了，回复OK（同意）指令
- 这样，这个候选者就成为领导者，它可以向选民们发出要执行具体操作动作的指令，比如进行日志复制
- 如果一旦这个Leader宕机崩溃了，那么Follower中会有一个成为候选者，发出邀票选举，相当于再次执行1）～2）的步骤
解决脑裂问题
- 指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏
- 通过心跳检测做主备切换的时候，就存在不确定性。心跳检测的不确定性是发生脑裂问题的一个非常重要的原因。比如Slave提供服务了，但此前被判死的Master又“复活”了，还在继续工作，则对应用程序逻辑带来未知因素，其中就包括抢夺资源
- 有一种做法称为设置仲裁机制，例如设置第三方检测服务器（Monitor），当Slave确定准备接管Master时，让Monitor也ping一下Master，如果没有通讯，则判断其“死亡”；同时Master在对外提供服务时，每隔一段时间比如10s由Master服务器ping Slave服务器和Monitor，如果均出现异常，则暂定业务操作，重试。重试多次之后则退出程序执行或者执行服务器重启操作
- 通过Lease机制也可以进一步处理双主脑裂问题。我们假设Slave已经在提供服务了，对应的Server服务器则获得Slave颁发的Lease。假设老Master仍在提供服务，则Lease必然是过期的，因此请求失效，老Master请求频繁时效的情况下，可以通过配置监控点触发报警，以人工介入让老Master放弃身份，转换为Slave
MVCC
- 基于多版本并发控制，乐观机制
