go语言后端9| 青训营笔记这是我参与「第五届青训营」笔记创作活动的第9天一、本堂课重点内容：本堂课的知识要点有哪

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

一、本堂课重点内容：

本堂课介绍了哪些知识点？
什么是分布式？
- 分布式系统定义：跨多个节点的计算机程序的集合
- 使用分布式系统的五大优势：去中心化、低成本、弹性、资源共享、可靠性高
- 分布式系统的挑战：故障、网络、环境、安全
Why-How-What
- 使用者视角：大规模计算存储的述求
- 学习者视角：后端开发必备技能
常见的分布式系统
- 分布式存储：GFS、Ceph、HDFS、Zookeeper
- 分布式数据库：Spanner、TiDB、HBase、MangoDB
- 分布式计算：Hadoop、YARN、Spark

定义：
- 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
三个假设：
- 协调者和参与者进行通信
- 预写式日志被保持在可靠的存储设备上
- 所有节点不会永久性损坏，即使损坏后仍然可以恢复
正常流程：Prepare阶段和Commit阶段
异常流程：Prepare阶段失败 -> 回滚；协调者宕机 -> 重新启用新的协调者；双故障重启 -> 数据库管理员介入
两阶段提交需解决的问题：
- 性能问题：需要多次网络通信，资源需要等待并锁定
- 新协调者：如何确定状态选出新协调者
- Commit阶段网络分区带来的数据不一致：非所有节点都收到Commit请求
两个思考：
- 日志被保存在「可靠」的存储设备上。如何保证这一点？
- 参与者Commit了，但Ack信息协调者没收到。怎么办？

MVCC：多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。
悲观锁和乐观锁
- 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据
- 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作
版本的选取：使用物理时钟或逻辑时钟
- 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms。
- 逻辑时钟：中心化授时的方式--时间戳预言机（TSO），好处是无需硬件的支持

有什么实践举例帮助理解知识点？
拜占庭将军问题
两将军问题
- 定义：
  - 两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识
- 结论：
  - 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识
- TCP是两将军问题的一个工程解
三将军问题：
- 两个“忠将”A和B，一个“叛徒”C，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。
- 由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致
四将军问题：
- 将军D作为消息分发中枢，约定如果没收到消息则执行撤退
- 步骤：
  - 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
  - D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。
- 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致

今天学了分布式理论，没学完。笔记略显粗糙，先这样吧。