这是我参与「第五届青训营」笔记创作活动的第12天。

学习内容

今天学习了分布式事务和相关内容并做了简单实践。

分布式事务

为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设：
- 引入协调者(Coordinator )和参与者( Participants )，互相进行网络通信
- 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
- 所有节点不会永久性损坏，即使损坏后仍然可以恢复
正常流程：两个阶段——Prepare阶段和Commit阶段
异常流程：
1. Prepare阶段失败 -> 回滚；
2. 协调者宕机 -> 重新启用新的协调者；
3. 双故障重启 -> 数据库管理员介入
两阶段提交需解决的问题：
- 性能问题：两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。
- 协调者单点故障问题：如果事务协调者节点宕机，需要另起新的协调者，否则参与者外干中间状态无法完成事务。
- 网络分区带来的数据不一致：一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致。

针对两阶段提交的补充，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制
流程：
1. CanCommit阶段：询问是否可以执行；
2. PreCommit阶段：重新确认是否可以执行；
3. DoCommit阶段：向所有人提交事务。
解决两个问题：单点故障问题和阻塞问题，另外引入了超时机制，在等待超时之后，会继续进行事务的提交。但仍没有解决两阶段面临的性能问题和网络分区场景带来的数据一致性问题。

多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。

悲观锁和乐观锁
- 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据
- 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作
物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常1ms<ϵ<7ms。
逻辑时钟：中心化授时的方式--时间戳预言机（TSO），好处是无需硬件的支持

三要素：
- N：在分布式存储系统中，有多少份备份数据
- W：代表一次成功的更新操作要求至少有w份数据写入成功
- R：代表一次成功的读数据操作要求至少有R份数据成功读取

为了保证强一致性，需要保证 W+R>N

一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。

三种角色：
- Leader——领导者：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
- Follower——跟随者：接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志
- Candidate——备选者：Leader选举过程中的临时角色。向其他节点发送请求投票信息
状态转移：
- Log（日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题；
- Term（任期号）：单调递增，每个Term内最多只有一个Leader；
- Committed：日志被复制到多数派节点，即可认为已经被提交；
- Applied：日志被应用到本地状态机：执行了log中命令，修改了内存状态。

37a962fd32c94ad68fe702d0097d95ef_tplv-k3u1fbpfcp-zoom-in-crop-mark_4536_0_0_0.png

Leader选举过程：
1. 初始全部为Follower
2. Current Term + 1
3. 选举自己
4. 向其它参与者发起RequestVote请求，retry直到：
  - 收到多数派请求，成为Leader，并发送心跳
  - 收到其它Leader的请求，转为Follower，更新自己的Term
  - 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮
两个规则：
- 在一个任期内每个参与者最多投一票（持久化）；
- 要成为Leader，必须拿到多数投票。
Log Replication过程：新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志
切主：当Leader出现问题时，就需要进行重新选举
1. Leader发现失去Follower的响应，失去Leader身份
2. 两个Follower之间一段时间未收到心跳，重新进行选举，选出新的Leader，此时发生了切主
3. Leader自杀重启，以Follower的身份加入进来
Stale读：发生Leader切换，old leader收到了读请求。如果直接响应，可能会有Stale Read

Paxos算法与RAFT算法区别：
- Multi-Paxos 可以并发修改日志，而Raft写日志操作必须是连续的
- Multi-Paxos 可以随机选主，不必最新最全的节点当选Leader
优势：写入并发性能高，所有节点都能写
劣势：没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录

捕获.PNG

捕获.PNG