分布式理论 | 青训营笔记

29 阅读4分钟

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

一、本堂课重点内容:

  • 分布式概述
  • 分布式事务

二、详细知识点介绍:

分布式概述

分布式系统是计算机程序的集合,这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。

大概可以分为分布式计算、分布式存储、分布式数据库等。

其优势:

  • 去中心化
  • 低成本
  • 弹性
  • 资源共享
  • 可靠性高

同时也会面临的挑战有:

  • 普遍的节点故障
  • 不可靠的网络
  • 异构的机器与硬件环境
  • 安全

常见的分布式系统

分布式存储:

  • Google File System(GFS):谷歌的分布式文件系统
  • Ceph:统一的分布式存储系统
  • HadoopHDFS:基于GFS架构的开源分布式文件系统
  • Zookeeper:高可用的分布式数据管理与系统协调框架

分布式数据库:

  • Google Spanner:谷歌可扩展的、全球分布式的数据库
  • TiDB:开源分布式关系型数据库
  • HBase:开源Nosql数据库
  • MongoDB:文档数据库

分布式计算:

  • Hadoop:基于MapReduce分布式计算框架
  • Spark:在Hadoop基础上,使用内存来存储数据
  • YARN:分布式资源调度

分布式事务

二阶段提交

二阶段提交(Two-phase Commit):为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的—种演算法。

三个假设:

  • 引入协调者(Coordinator)和参与者(Participants),互相进行网络通信
  • 所有节点都采用预写式日志,且日志被写入后即被保持在可靠的存储设备上
  • 所有节点不会永久性损坏,即使损坏后仍然可以恢复 image.png 可能出现的情况:
  • 情况1 Coordinator不宕机,Participant宕机。需要进行回滚操作
  • 情况2 Coordinator宕机,Participant不宕机。可以起新的协调者,待查询状态后,重复二阶段提交情况3)Coordinator宕机,Participant宕机。
  • 情况3︰无法确认状态,需要数据库管理员的介入,防止数据库进入一个不一致的状态。
  • 回滚:在Prepare阶段,如果某个事务参与者反馈失败消息,说明该节点的本地事务执行不成功,必须回滚。

两阶段提交需注意的问题:

1.性能问题: 两阶段提交需要多次节点间的网络通信,耗时过大,资源需要进行锁定,徒增资源等待时间。

2.协调者单点故障问题: 如果事务协调者节点宕机,需要另起新的协调者,否则参与者处于中间状态无法完成事务。

3.网络分区带来的数据不一致: 一部分参与者收到了Commit消息,另一部分参与者没收到Commit消息,会导致了节点之间数据不一致。

三阶段提交

三阶段提交解决了二阶段提交的两个问题: 1.单点故障问题 2.阻塞问题

另外引入超时机制,在等待超时之后,会继续进行事务的提交。 image.png

MVCC

MVCC是一种并发控制的方法,维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写,也不阻塞读。MVCC为每个修改保存一个版本,和事务的时间戳相关联。可以提高并发性能,解决脏读的问题。

Spanner论文里通过TrueTime API提供一个物理时钟的方式。服务器时钟偏差在1到7ms之间。

另外一种时间戳的实现:时间戳预言机(TSO),采用中心化的授时方式,所有协调者向中心化节点获取时钟。优点是算法简单,实现方便,但需要每个节点都与他进行交互,会产生一些网络通信的成本。TSO的授时中就需要考虑低延迟,高性能以及更好的容错性。

三、课后个人总结:

这次学习让我学到了很多关于分布式的相关知识,但是对于小白的我来说,听的一脸懵,还是要反复琢磨呀!