分布式技术

分布式模式

• 单机模式:所有有用程序和数据均部署在一台电脑或服务器上，由一台计算机完成所有的处理
  • 缺点:单个计算机的处理能力取决于cpu和内存，而且存在性能首先，单点失效问题
  • 优点:功能，代码和数据集中，便于维护，管理和执行
• 数据分布式模式:利用多台计算机并行处理多个请求，在相同的时间内完成更多的请求，解决单机效率瓶颈问题。多集群出现的问题如下
  • 不同服务器，如何均匀的转发到不同的应用服务器上。
  • 请求量较大时，对数据库的频繁读写操作，数据库IO访问的瓶颈
  • 当有些数据成为热点数据时，导致数据库访问频繁，压力增大
  • 对提升单个任务的执行性能和降低时延无效
    -任务并行:将单个复杂的任务拆分为多个子任务，使得多个子任务可以在不同的计算机上并行执行

分布式系统指标

• 性能:衡量一个系统处理各种任务的能力
  • 吞吐量:一定时间内可以处理的任务数
    • tps：事务数每秒，用于衡量一个系统每秒处理的事务数
    • qps:查询数每秒，用于衡量一个系统每秒处理的查询数
    • bps:比特数每秒，用于衡量一个系统每秒处理的数据量
  • 响应时间:系统响应一个请求或输入需要花费的时间。
  • 完成时间:系统完成一个请求或处理需要花费的时间
• 资源:一个系统提供正常能力需要占用的硬件资源
  • 空载资源占用:一个系统没有任何负载时的资源占用
  • 满资源占用:一个系统满额负载时的资源占用
• 可用性和可扩展性
  • 可用性:系统在面对各种异常时，可以正确提供服务的能力，可以用系统停止服务的时间与总的时间之比衡量
  • 可靠性：表示一个系统不出故障的概率
  • 可扩展性:分布式系统通过扩展集群集群规模提高系统性
    • 加速比:用来衡量系统可扩展性的常用指标
• 不同分布式系统的指标
  • 电商系统:电商系统是吞吐量
  • IoT:IoT系统最重要的是资源占用指标
  • 电信业务:响应时间，完成时间，和可用性
  • HPC:HPC系统是任务执行时间长，可用性和可扩展性要求高
  • 大数据：可扩展性是大数据系统优先考虑的
  • 云计算:系统占用资源和响应时间
  • 区块链：吞吐量和完成时间是区块链系统的是要目标，可用性极高

分布式互斥

• 分布式互斥：在分布式系统中，排他性的资源访问方式称为分布式互斥，被互斥访问的恭喜资源叫临界资源
  • 集中式算法:引入一个协调者持续，得到一个分布式算法，每个程序需要访问临时资源，先给协调者发送请求。如果没有程序使用这个资源，则直接授权访问，否则等待。
  • 分布式算法:当一个程序要访问临界资源时，先向系统中的其他程序发送一条消息，在接收到所以程序返回的统一消息后，才可以访问临界资源，分布式算法适合节点数目少，且变动不频繁的系统
  • 令牌环算法:所有程序构成一个环结构，令牌按照顺时针方向在程序传递，收到令牌的程序有权访问临界资源，访问完成后送到下一个程序，若该程序不需要访问临界资源，直接把令牌传送给下一个程序，适用于系统规模较小，并且系统中每个使用临界资源的频率高，且使用时间比较短的场景
  • 两层结构的分布式令牌环算法:

分布式选举：

• 含义:选举出一个主节点，由他来协调和管理其他节点，保证集群有序运行和节点间数据的一致性
• 分布式选举算法:
  • Bully算法:选择所要活着的节点中，id最大的节点作为主节点
  • 选举消息:
    • 1.发送Election消息，用于发起选举。
    • 2.回复Alive消息，对Election消息的应答。
    • 3.Victory消息，竞选成功的主节点想其他节点发送宣誓主权的消息
  • 选举流程:
    • 1.集群中每个节点判断自己的ID是否为当前活着的节点中ID最大的，如果是，则直接想起他节点发送VIctory消息，宣誓自己的主权
    • 2.如果自己不是当前活着的节点中ID最大的，则向比自己ID大的所有节点发送Election消息，并等待其他节点的回复
    • 3.在给定的时间内，本节点没有收到其他节点回复的Alive消息，认为自己成为主节点，并发送Victory消息，宣誓自己为主节点，如果收到比自己ID大的Alive消息，等待其他节点发送Victory消息
    • 4.若本节点收到比自己ID小的节点发送的Election消息，则回复Alive消息，告知其他节点，重新选举
  • 优点:算法复杂度低，选举快，简单易实现
  • 缺点:每个节点需要存储全局节点消息。新增服务时，如果新增的节点id大于目前的id，则会引发重新选举
• Raft算法
  • raft算法角色:
    • leader 主节点，同一时刻只有leader
    • Candidate 候选者，每个节点都可以成为Candidate，具有改角色的候选者，曹辉被选为leader
    • Follower:Leader的跟随者，不可以发起选举
  • 选举流程
    • 1.初始状态,所有节点为Follower角色
    • 2.开始选举时，Follower -> Candidate 角色，然后向其他节点发送选举请求
    • 3.其他节点根据接收到的选举请求，先后顺序是否同意成为主，在每轮选举中，一个节点只能投出一张票
    • 如果发起选举请求的节点获得超过一半的投票，则成为主节点，成为leader，其他节点的状态有Candidate->Follower
    • 5.当leader节点失活，或任期到了，将会进入新的一轮选举
• ZAB算法(Zookeeper实现分布式协调功能算法)

  • ZAB算法角色:

    • Leader 主节点
    • Follower:leader 跟随者
    • Observer 观察者，无投票权

  • zap 算法:每个节点有一个唯一的三元组(server_id,server_zxID,epoch)。server_id表示本节点唯一的Id，server_zxId表示本节点存放数据的ID，数据ID越大，表示数据越新，权重越大，epoch表示当前选取轮数。ZAB选举算法的核心“少数服从多数，ID大的节点优先成为主”

  • 选举流程:

    • 服务器:

      server1	server2	server3
      server_id：1	server_id：2	server_id：3
      vote_id:1	vote_id:2	vote_id:3

    • 1.系统启动，3台服务器当前投票都是第一轮，所以epoch=1，server_zxId为0,第一轮，由于不知道选举谁，所以每台服务器都投自己一票，并广播给其他服务器

    • 根据判断规则，因为epoch和zxID相同，比较server_id,取最大者为leader，所以server1和server2更新vote_id ,变重新投票

    • 系统内所有服务器都推选了Server3,所以server3当选leader

  • 优点:稳定性比较好

  • 缺点:每个节点会广播消息，集群中的消息量为n*(n-1)条消息，容易出现广播风暴

• 性能:Bully

分布式共识

• 含义:分布式共识是多个节点均可独自操作或记录的情况下，是的所以节点针对某个状态达成一致的过程，分布式共识技术，就是区块链技术共识机制的核心
• 分布式在线记账一致性问题的共识技术
  • poW算法(工作量证明)：
    • 含义:通过一份证明，用来确认你做过一定量的工作
    • 原理:利用区块index，前一个区块的哈希值，交易的时间戳，区块数据和nonce值，用sha256哈希算法计算，获取哈希值，例如判断获取的hash值前4个是否为0，如果都不是，递增nonce值，重新计算，如果是，则本次计算结束，谁先计算完成，谁就有这个区块的记账权
    • 流程:
      • 客户端A产生交易，想全网广播，要求记账
      • 其他节点接收到请求后，将交易信息放入区块中
      • 每个节点通过PoW算法，计算本节点的区块哈希值，去找工作量证明
      • 比如节点B优先找到工作量证明，就向全网广播
      • 其他节点接受到广播，过改区块有效，接受该区块，并跟随在该区块的末尾，制造新区块，延长该链条
    • 缺点:共识达成的周期长，效率低，资源消耗大
  • PoS算法:
    • 原理:不同于Pow算法，PoS算法用系统权益代理算力，来决定区块记账权，拥有的权益越大，获得记账权的概率就越大 ，而且pos节点计算获取记账权的方法不一样，pow是利用区块的index，前一个区块的哈希值，交易的时间戳，区块数据和onoce值，通过sha256哈希计算出哈希值，并判断hash值的前几个值是否都为0。pos是根据节点拥有的股权或权益进行计算
    • 缺点:pos算法中持有的币越多或越久就越容易挖到区块，容易被持币数量大的一部分人掌握，出现垄断现象
  • DPoS算法:
    • 原理：为了解决Pos算法的垄断问题，推出了DPos算法，相对于Pos算法，Dpos引入了受托人，主要为:1.投票选举出若干信誉度更高的受托人记账，解决所有节点参与竞争，到时消息量大，2.每隔一定周期，会调整受托人，避免受托人造假和独权
• 一致性和共识的区别:
  • 一致性:分布式系统中，多个节点之间，给定一系列操作，在约定协议的保障下，对外界呈现的数据或状态是一致的
  • 共识:分布式系统中，多个节点之间，彼此对某个状态达成一致结果的过程

分布式事务

• 事务:表示包含一系列操作的，一个有边界的工作序列，有明确的开始和结束标志，要么完全执行，要么完全失败。分布式事务就是在分布式系统中运行的事务，由多个本地事务组合而成
• 事务ACID基本特性
  • 原子性:表示事务最终的状态只有两种，成功和不执行，如果事务中任何一步不成功，整个事务就失败，所有操作会被取消
  • 一致性：表示事务操作前和操作后，数据的完整性保持一致或满足完整性约束
  • 隔离性：表示当系统内有多个事务并发执行时，多个事务不会相互干扰，一个事务内部的操作及使用的数据，对其他并发事务是隔离的
  • 持久性：表示当一个事务完成后，它对数据库所做的更新就被永久保存下来。
• 分布式事务实现:

  • 基于XA协议的两段式提交协议方法:

    • XA:XA是一个分布式事务协议，规定了事务管理器和资源管理器接口
    • 事务管理器:负责各个本地资源的提交和回滚
    • 资源管理器:分布式事务的参与者，通常为数据库存储服务
    • 两段提交过程:
      1. 事务管理器会向资源管理器发起执行操作的CanCommit请求，并等待参与者的响应。
      2. 参与者接收到请求后，开始执行请求中的事务操作，记录但是不提交，成功后返回yes，否则no 终止操作。
      3. 当所有的参与者都返回yes后，系统就进入了提交阶段，在提交阶段，协调者会根据所有参与者的消息想参与者发送DoCommit或DoAbort指令
      4. 若协调者收到都是yes消息，则向参与者发送DoCommit消息，参与者会完成剩余的操作并释放资源，返回协调者HaveCommitted消息
      5. 如果协调者收到no消息，则会想所有参与者发送DoAbort消息，那么发送yes消息的参与者会执行回滚操作，然后返回协调者HaveCommited消息
      6. 协调者接收到HaveCommitted消息，事务就结束了
    • 基于XA的两阶段提交缺点:
      • 同步阻塞:本地资源管理器占用临界资源时，其他资源管理器如果访问同一临界资源，处于阻塞状态
      • 单点故障:如果事务管理器发送故障，整个系统处于停滞状态
      • 数据不一致:当协调者向参与者发送DoCommit后，如果发生网络波动，会造成一些参与者收不到消息，只有一部分参与者接收到请求，并执行提交操作，造成数据不一致问题

  • 三阶段提交协议方法:三阶段提交是对二阶段提交阻塞和数据不一致的改进，三阶段提交引入超时机制和准备阶段，三阶段分表为 CanCommit，PreCommit，DoCommit三个阶段

    • 超时机制:协调者和参与者加入超时机制，如果协调者或参与者发生超时，那边就会根据当前的状态选择提交或者终止事务
    • 准备阶段：在提交阶段之前，引入预提交，排除一些不一致的情况，保证在最后提交之前各参与节点的状态是一致的
    • 过程
      1. CanCommit阶段，协调者发送CanCommit请求给参与者，等待参与者响应，如果yes表示可以执行，否则失败
      2. PreCommit阶段，协调者根据参与者的回复情况，决定是否PreCommit操作，如果参与者都回复yes，协调者将会发送PreCommit请求，参与者接收到PreCommit请求后，执行后事务操作，操作完成后，返回ACK响应，等待最终指令
      3. 如果参与者发送No指令，或者协调者超时，未收到消息，则像参与者主动发送Abort消息，中断事务。
      4. 参与者收到Abort消息后，或者超时未收到协调者消息，则自己发起终断操作
      5. 若PreCommit阶段，参与者都执行成功，则加入DoCommit阶段。协调者接收到所有ACK消息后，向所有参与者发送DoCommit消息
      6. 参与者接收到DoCommit消息，开始提交事务，并发送ACK响应，协调者接收到参与者的ACK响应后完成事务。
      7. 在DoCommit阶段参与者向协调者发送ACK消息后，如果长时间没有得到协调者的响应，默认情况下，参与者会自动将事务提交

  • 基于消息的最终一致性方法:基于分布式消息的一致性方案得事务处理，引入一个消息中间件，用于多个引用质检消息传递。

分布式锁

• 分布式锁:分布式锁是指在分布式环境下，系统部署在多个机器中，实现多进程分布式互斥的一种锁。
• 分布式锁实现方法和对比:

  • 基于数据库实现分布式锁:

    • 实现:创建一张锁表，通过操作改表中的数据来实现 。当需要访问某个资源时，就在改表中增加一条记录，释放时，删除这条记录。但是频繁的读取数据会导致IO开销大，这种方式适用于并发量低，对性能要求低的场景
    • 缺点:1.单点故障，数据库崩溃，会导致系统无法使用，2.死锁:数据库锁没有失效时间，当获取锁的进程死掉，会发生死锁

  • 基于缓存实现分布式锁

    • 使用redis setnx(key,value)函数来实现分布式锁，key表示锁id，value=currentTime+timeOut,表示当前时间+超时时间。如果在value的时间内未释放锁，系统会自动释放锁
    • 优势:1.性能更好，数据存放与内存，避免频繁的IO操作。2.缓存可以集群部署，避免单点故障 3.提供了可以实现分布式锁的方法，使用简单 4.可以设置超时控制锁的释放
    • 缺点:可能会通过超时时间触发释放锁机制，从而误释放锁

  • 基于ZooKeeper实现分布式锁:

    • 原理:zk基于树形数据存储结构实现分布式锁，zk的树形数据存储结构主要有4中节点构成
      • 持久节点：默认的节点类型
      • 持久顺序节点：在创建节点时，zk根据节点创建的时间顺序对节点进行编号
      • 临时节点：当客户端与zk断连后，临时节点会被删除
      • 临时顺序节点:跟顺序节点一样，按时间顺序编号的临时节点
    • 实现:基于zk临时顺序节点实现分布锁 。每个客户端对某个资源加锁时，在改资源对应的指定节点目录下，生产一个唯一的临时有序节点，判断是否获取锁的方式，只需要判断有序节点序号是否是最小的一个，当释放锁的时候，将这个临时节点删除
    • 羊群效应:使用zk，当创建临时节点断开时。如果注册了Watcher通知事件，同一时间多个节点对应的客户端完成事务或事务终端，那么zk服务器短时间内向其他客户端发送大量的时间通知。将会对zk造成巨大的性能影响和网络冲击
    • 解决方法为:
      • 客户端调用 create 方法创建一个类似于 /lockpath/[hostname]-请求类型-序号 的临时顺序节点。
      • 客户端调用 getChildren 方法获取所有已经创建的子节点列表(这里不注册任何Watcher)。
      • 如果无法获取任何共享锁，那么调用exist来对比自己小的那个节点注册Watcher.读请求：向比自己序号小的最后一个写请求节点注册Watcher监听。写请求：向比自己序号小的最后一个节点注册Watcher监听
      • 等待Watcher监听，继续进入2步骤

  • 分布式锁注意事项:

    • 互斥性:分布式系统环境下，分布式锁应该能保证一个资源或一个方法在同一时间只能被一个机器的一个县城或进程操作
    • 具备锁失效机制:防止发生死锁
    • 可重入性:获取锁的进程可多次访问临界资源
    • 高可用性:防止出现单点故障