分布式原理概括

分布式原理

知识点1

• 分布式与集群的区别:

  集群:多个人在一起作同样的事 。

  分布式 :多个人在一起作不同的事 。

• CAP理论和base理论

  CAP 理论含义是，一个分布式系统不可能同时满足一致性(C:Consistency)，可用性(A: Availability)和分区容错 性(P:Partition tolerance)这三个基本需求，最多只能同时满足其中的2个。

  选项	描述
  C 一致性	分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致
  A 可用性	Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常
  P 分区容错性	系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务

• BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是:即使无法做到强一致性，但每个应用都可 以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

• 3PC协议（CanCommit、PreCommit和doCommit三个阶段 ）

  注意:一旦进入阶段三，可能会出现 2 种故障:

  1. 协调者出现问题
  2. 协调者和参与者之间的网络故障

  如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交，如果本来是要发送中断的，此时提交的话，会造成数据不一致问题；

Paxos算法

• Paxos算法
  • 解决了分布式系统一致性问题。
  • Client:客户端—>Proposer:提案发起者(重点理解)—>Acceptor:决策者，可以批准提案—>Learners:最终决策的学习者

• 阶段一:

  (a) Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。

  (b) 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求 的编号，那么它就会将它已经接受过的编号最大的提案(如果有的话)作为响应反馈给Proposer，同时该 Acceptor承诺不再接受任何编号小于N的提案。

• 阶段二:

  (a) 如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意:V就是收到的响应中编号最大的提案的value，如果 响应中不包含任何提案，那么V就由Proposer自己决定。

  (b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare 请求做出过响应，它就接受该提案。

• 阶段三：

  假设存在这样一种极端情况，有两个Proposer依次提出了一系列编号递增的提案，导致最终陷入死循环，没有 value被选定,具体流程如下:

  

  解决:通过选取主Proposer，并规定只有主Proposer才能提出议案。这样一来只要主Proposer和过半的Acceptor 能够正常进行网络通信，那么但凡主Proposer提出一个编号更高的提案，该提案终将会被批准，这样通过选择一个 主Proposer，整套Paxos算法就能够保持活性;

一致性算法-Raft

• 分布式理论:一致性算法 Raft

  三个身份：

  • 领导者(leader):处理客户端交互，日志复制等动作，一般一次只有一个领导者
  • 候选者(candidate):候选者就是在选举过程中提名自己的实体，一旦选举成功，则成为领导者
  • 跟随者(follower):类似选民，完全被动的角色，这样的服务器等待被通知投票

  而影响他们身份变化的则是**选举，Raft使用心跳机制来触发选举**。当server启动时，初始状态都是follower。每一个server都有一个定时器，超时时 间为election timeout(一般为150-300ms)，如果某server没有超时的情况下收到来自领导者或者候选者的任何 消息，定时器重启，如果超时，它就开始一次选举。

  日志复制(保证数据一致性) :

  

  4 个步骤:

  • 客户端的每一个请求都包含被复制状态机执行的指令。

  • leader把这个指令作为一条新的日志条目添加到日志中，然后并行发起 RPC 给其他的服务器，让他们复制这 条信息。

  • 跟随者响应ACK,如果 follower 宕机或者运行缓慢或者丢包，leader会不断的重试，直到所有的 follower 最终 都复制了所有的日志条目。

  • 通知所有的Follower提交日志，同时领导人提交这条日志到自己的状态机中，并返回给客户端。

    可以看到，直到第四步骤，整个事务才会达成。中间任何一个步骤发生故障，都不会影响日志一致性。

    注意：只有正在运行的节点数量大于一半的情况下，事务才会真正的提交，不然只是记录在本地数据，不会进行提交；

rpc

• 基本原理

  • 在底层层面去看，网络通信需要做的就 是将流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现，其中传输协议比较出名的有tcp、 udp等等，tcp、udp都是在基于Socket概念上为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、 aio三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些 更为贴近应用易用的应用层协议。

• 例子

  • 老张煮开水。 老张，水壶两把(普通水壶，简称水壶;会响的水壶，简称响水壶)。
    1 老张把水壶放到火上，站立着等水开。(同步阻塞-BIO)
    2 老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。(同步非阻塞)
    3 老张把响水壶放到火上，立等水开。(异步阻塞)
    4 老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。(异步非阻塞)

• RPC架构

  一个完整的RPC架构里面包含了四个核心的组件，分别是Client，Client Stub，Server以及Server Stub，这个Stub 可以理解为存根

  
  

Netty 模型

• Netty 抽象出两组线程池， BossGroup 专门负责接收客 户端连接， WorkerGroup 专门负责网络读写操作。 NioEventLoop 表示一个不断循环执行处理 任务的线程， 每个 NioEventLoop 都有一个 selector， 用于监听绑定 在其上的 socket 网络通道。 NioEventLoop 内部采用串行化设计， 从消息的读取->解码->处理->编码->发送， 始 终由 IO 线 程 NioEventLoop 负责