day17 分布式 |青训营笔记

zhouxing9454
108 阅读6分钟

题记

这是我参与「第五届青训营 」伴学笔记创作活动的第 17天，本文用于记录在青训营的学习笔记和一些心得。

day17 2月14日

分布式概述

分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。

优势:

  • 去中心化
  • 低成本
  • 弹性：根据波峰波谷，自动扩缩容
  • 资源共享：服务器之间共享资源
  • 可靠性高：一台服务器的系统崩溃不会影响到其他的服务器

挑战：

  • 普遍的节点故障:基本每天都会出现节点问题
  • 不可靠的网络:网络基础设置问题，包括传输、高负载、信息丢失问题。
  • 异构的机器与硬件环境:不同机器下性能不同
  • 安全:开放式系统的特性让分布式计算机系统存在着数据的安全性和共享的风险问题

image-20230206150213212

image-20230206150954478

image-20230206153718664

系统模型

根据故障处理的难易程度来划分的(从难到易)

Byzantine failure：节点可以任意篡改发送给其他节点的数据，是最难处理的故障

Authentication detectable byzantine failure (ADB)：节点可以篡改数据，但不能伪造其他节点的数据

Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚

Omission failure：节点收到数据的时间无限晚，即收不到数据

Crash failure：节点停止响应，持续性的故障

Fail-stop failure：错误可检测，是最容易处理的故障

image-20230206155535041

拜占庭将军问题

两将军问题

  • 定义：

    • 两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识

  • 结论：

    • 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识

方案一:同时发送N个信使，任何一个达到对方军队，都算成功。

方案二:设置超时时间，发送后未在一定时间返回，则加派信使。

共识与消息传递的不同:即使保证了消息传递成功，也不能保证达成共识。

TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。

思考: 1.为何三次握手?而不是两次和四次?

为了实现可靠数据传输，TCP 协议的通信双方，都必须维护一个序列号， 以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认。

2.挥手过程中，如果FIN报文丢失，发生什么?

如果FIN 报文丢了，那么客户端迟迟收不到被动方的 ACK 的话，也就会触发超时重传机制，重传 FIN 报文，重发次数由 tcp_orphan_retries 参数控制。当客户端重传 FIN 报文的次数超过 tcp_orphan_retries 后，就不再发送 FIN 报文，则会在等待一段时间（时间为上一次超时时间的 2 倍），如果还是没能收到第二次挥手，那么直接进入到 close 状态。

三将军问题：

  • 两个“忠将”A和B，一个“叛徒”C，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。
  • 由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致

四将军问题：

  • 将军D作为消息分发中枢，约定如果没收到消息则执行撤退

  • 步骤：

    • 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
    • D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。

  • 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致

image-20230206164601858

image-20230206165405141

image-20230206165047526

理论基础

C(Consistence)：一致性，指数据在多个副本之间能够保持一致的特性（严格的一致性)。

A (Availability)：可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。

P(Network partitioning)：分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

image-20230206165934258

image-20230206171052845

ACID解释

image-20230206182543774

image-20230206205200796

分布式事务

image-20230206185146977

image-20230206185226098

image-20230206185302158

网络分区带来的数据不一致：解决方法就是rollback

image-20230206185915490

image-20230206192045027

MVCC

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

  • 版本的选取：使用物理时钟或逻辑时钟

    • 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms。
    • 逻辑时钟：中心化授时的方式--时间戳预言机（TSO），好处是无需硬件的支持

共识协议

image-20230206193243579

image-20230206194820372

image-20230206195125590

image-20230206195942280

image-20230206200730618

image-20230206201157347

分布式实践

image-20230206201957482

image-20230206202441553

课后问题

  • 分布式系统有哪些优势和挑战？
  • 两将军问题为什么理论上永远达不成共识？
  • 为什么TCP采用三次握手？而不是两次和四次？
  • 为什么在4将军问题中，增加1轮协商就可以对抗拜占庭故障？
  • 什么是最终一致性？什么是线性一致性？
  • CAP理论中，请举例说明可用性和一致性的矛盾？
  • 数据库里的一致性和分布式系统中的一致性有什么区别？
  • 两阶段提交中，什么场景需要数据库管理员介入？
  • 三阶段提交缓和两阶段提交的哪两个问题？
  • 什么场景适合乐观锁？什么场景适合悲观锁？
  • 在共识协议中，为什么说允许数据被覆盖会带来数据一致性问题？
  • RAFT协议中，Leader写成功日志Log20但未同步给Followers后宕机，Follower重新选举后产生一条新日志Log20，这时Leader重启，整个系统发现两种不一样的Log20的记录，请问如何区分并拒掉前面的Log20？
  • RAFT协议中，Stale读是如何产生的？该如何解决Stale读的问题？
avatar
文章
阅读
粉丝