分布式理论

1.特点

• 可扩展性
• 服务无状态：服务状态是服务请求所需的数据。无状态服务处理数据全部来自请求携带的信息，cookie通过客户端保存token来保持状态。
  有状态服务：服务存储请求上下文的数据信息，session维持用户信息

2.CAP理论

在一个分布式系统中只能具有以下其中两个特性:

• Consistency (一致性)：也叫做数据原子性，系统在执行某项操作后仍然处于一致的状态。
  在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。
  等同于所有节点访问同一份最新的数据副本。
• Availability (可用性)：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。
  一定时间内指的是，在可以容忍的范围内返回结果，结果可以是成功或者是失败。
• Partition tolerance (分区容错性)：在网络分区的情况下，被分隔的节点仍能正常对外提供服务
  (分布式集群，数据被分布存储在不同的服务器上，无论什么情况，服务器都能正常被访问)。

2.1 CP架构

放弃可用性，追求一致性和分区容错
Zookeeper采用CP一致性，分布式服务架构，解决分布式集群中应用系统的协调和一致性问题
如果不要求A (可用)，相当于每个请求都需要在服务器之间保持强一致，而P (分区)会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。
设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。 对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

2.2 AP架构

放弃强一致性，追求分区容错性，可用性
Eureka各个节点平等的，几个节点挂掉不影响正常节点工作
要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在A (可用
性)方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

3.BASE理论

• Basically Availavle 基本可用：
• Soft-state 软状态：对应原子性（强制一致性），允许系统数据存在中间状态，该状态不影响系统整体可用性，允许系统多个不同节点数据副本存在数据延时
• Eventually Consistent 最终一致性：数据不能一直是软状态
  Base理论是在CAP上发展的，CAP理论描述分布式系统中数据一致性，可用性，分区容错性之间的制约关系，Base理论则是对CAP理论的实际应用，在分区和副本存在的前提下，通过一定的系统设计方案，放弃强一致性，实现基本可用，比如NoSQL系统，微服务架构。
  ACID是一种强一致性模型，用于数据库中，BASE理论面向的是高可用，可拓展的分布式系统，ACID适合传统金融等业务，在实际场景中,ACID和Base理论往往会结合使用

4.全局时钟和逻辑时钟

分布式系统解决传统单体架构的单点问题和性能容量问题
带来的新问题

• 多节点时间同步问题：不同机器的物理时钟难以同步，导致无法区分在分布式系统中多个节点的事件时序。
  没有全局时钟，绝对的内部一致性是没有意义的，外部一致性注意是多并发访问时更新的数据如何获取。
• 逻辑时钟：描绘了分布式系统中事件发生的时序，是为了区分现实中物理时钟提出的概念
  实际应用时，只要所有机器时间相同就够了，这个时间不一定跟实际时间相同，如果俩个节点不进行交互，他们的时间甚至不需要同步，问题在于：节点的交互要在事件的发生顺序上达成一致，而不是时间达成一致

5.数据一致性模型

• 强一致性：当更新操作完成之后，任何多个后续进程的访问都会返回最新的更新过的值，根据CAP理论，这种实现需要牺牲可用性
• 弱一致性：系统在数据写入成功后，不承诺立即可以读到最新写入的值，也不会具体承诺多久之后可以读到。用户读到某一操作对系统操作的更新需要一段时间，这段时间为不一致性窗口。
• 最终一致性：是弱一致性特例，强调是所有的数据副本，在经过一段时间的同步后，最终都能到达一个一致的状态。最终一致性的本质需要系统保证最终数据能够到一致，到达最终一致性的时间，就是不一致窗口时间，在没有故障发生的前提下，不一致窗口时间主要受通信延迟，系统负载和复制副本的个数影响。包括因果一致性和会话一致性
• 会话一致性： 将对系统数据访问过程框定在一个会话当中，约定系统能保证同一个有效的会话中实现读己之所写的一致性，时间开发中有分布式Session一致性问题，可以认为是会话一致性的应用。

5.1 Quorum机制

Quorum选举算法：抽屉原理，在N个副本中，一次更新成功的如果有W个，那么在读取数据时是要从大于N-W个副本中读取，这样就能至少读到一个更新的数据。
设有N个副本，更新操作wi在W个副本更新成功之后，才认为此次更新操作wi成功，把这次成功提交的更新操作对应数据叫做成功提交的数据，对于读操作而言，至少需要读R个副本才能读到此次更新的数据，其中W+R>N,即W和R有重叠，一般W+R=N+1。
N为存储数据副本数量，W为更新成功所需副本，R一次数据对象读取要访问的副本的数量。
Quorum机制无法保证强一致性，无法实现任何时刻用户或节点都可以读到最近一次成功提交的副本数据，使用时需要配合获取成功提交的版本号的metadata服务。
与其对应WARO（Write All Read one） 是一种简单的副本控制协议，当Client请求向某副本写数据，只有所有副本都更新成功之后，这次写操作才算成功，否则失败。优先保证读服务，写服务可用性较低，牺牲更新服务的可用性，最大程度增强读服务的可用性。

5.2 一致性算法

5.2.1 Paxos

解决问题：一个分布式系统如何就某个值达成一致。
三种节点角色

• Proposer提案者：流程开始时，Proposer提出议案，就是value，在工程可以为任何操作，比如修改变量的值，Paxos协议中统一将这些操作抽象为value，不同Proposer可以提出不同的甚至矛盾的value
• Acceptor批准者：集群中，Acceptor有N个，Acceptor之间完全对等独立，Proposer提出的value，必须获得超过半数（N/2 +1）的Acceptor批准才能通过
• Learner学习者:不参与选举，而是学校被批准的value，Paxos，Learner注意参与相关的状态机同步流程。
• Client产生议题者:作为产生议题者，实际不参与选举，比如发起修改请求来源等。
  Proposer和Acceptor交互：Paxos描述就是一个由多个Proposer和Acceptor构成的系统中，如何让多个Acceptor针对Proposer提出的多个提案达成一致的过程
  
  Paxos选举过程：Proposer生产全局唯一且递增的ProposerID，向Paxos集群的所有机器发送Prepare请求这里不携带value，只携带N即ProposerID，Acceptor收到Prepare请求后，判断收到的ProposerID是否比之前已响应的所有提案的N大，如果是则在本地持久化N，即为MAX_N,回复请求并带上已经Accept提案中N最大的value，如果此时还没有已经Accept的提案，则返回value为空，做出承诺，不会Accept任何小于Max_N的提案。如果否，则不回复或者回复Error。
  Phase2选举阶段拆分为P2a，P2b,P2c
• P2a:Proposer发送Accept，经过一段时间后，Proposer收集到一些Prepare回复，有几种情况。1.回复数量 > 一半的Acceptor数量，且所有回复的value都为空时，则Proposer发出accept请求，并带上自己指定的value。2.若回复数量 > 一般的Acceptor数量，且有的回复value不为空时，则Porposer发出accept请求，并带上回复中ProposalID最大的value，作为自己的提案内容。3.回复数量<=一半的Acceptor数量时，则尝试更新生成更大的ProposalID，再转到准备阶段执行。
• P2b:Acceptor应答Accept，Acceptor收到Accept请求后，判断，若收到的N>=max_N,则回复提交，并持久化N和value。如N<Max_N,则不回复或回复提交失败
• P2c:Proposer统计投票，经过一段时间后，Proposer会收集到一些Accept回复提交成功的情况，比如，当回复数量>一半的Acceptor数量时，则表示提交value成功，此时可以发一个广播给所有的Proposer，Learner，通知他们已commit的value
  当回复数量<=一半的Acceptor数量时，尝试更新生成更大的ProposalID，转到准备阶段执行。当收到一条提交失败的回复时，则尝试生成更大的ProposalID，也会转到准备阶段执行。
  
• 如果半数以内Acceptor失效，如何正常运行：在Paxos流程中，如果出现半数以内的Acceptor失效，可以分为俩种情况：1.如果半数以内Acceptor失效时还没确定最终的value，此时所有的Proposer会重新竞争提案，最终有一个提案成功提交。
  2.如果半数以内Acceptor失效时已确定最终的value，此时所有Proposer提交前必须以最终的value提交，也就是value实际已经生效，此值可以被获取，并不再修改
• Acceptor需要接受更大的N，也就是ProposalID有什么意义：防止其中一个Proposer崩溃产生阻塞问题，允许其他Proposer用更大ProposalID来抢占临时的访问权
• 如何产生唯一编号ProposalID：唯一编号是让所有Proposal都从不相交的数据集合中进行选择，需要保证不同Proposer之间不重复。5个proposer，则可为每一个proposer分配一个标识j，那么每一个Proposer提出的决议编号为5*i+j,i为议案次数

5.2.2 其他算法

• Zab
• Raft
• NWR
• Gossip
• 一致性Hash

6.Zookeeper保持数据一致性

Zookeeper提供类似于Linux文件文件系统的数据模型和基于watcher机制的分布式事件通知，特性依赖于Zookeeper高容错数据一致性协议

6.1 Zab一致性协议

Zookeeper通过Zab协议来保证分布式事务最终一致性，Zab（Zookeeper Atomic Broadcast 原子广播协议）支持崩溃恢复，Zookeeper实现一致主备模式的系统架构来保持集群中各个副本之间数据一致性
具体实现：

• 消息广播协议：Leader节点接受事务提交，并且将新的Proposal请求广播给Follower节点，收集各个节点反馈，决定是否进行Commit
• 崩溃恢复阶段：如果在同步过程中出现Leader节点宕机，进入崩溃恢复阶段，重新进行Leader选举，崩溃恢复阶段还包含数据同步操作，同步集群中最新的数据，保持集群数据一致性
  

6.2 Zxid

是Zab协议的事务编号，64位，低32位简单单调递增计数器，针对客户端每一个事务请求，计数器+1。高32位代表Leader周期年代编号，epoch表示当前集群所处年代或周期，Raft中，每一个任期的开始都是一次选举，Raft算法保证在给定的一个任期最多有一个领导人。每当一个新的Leader选举出现时，就会在这个Leader服务器上取出其本地日志中最大事务的Zxid，并从中读取epoch值然后+1，作为新的周期ID，高32位代表每代Leader唯一性

6.3 Zab流程

消息广播-> 崩溃恢复 -> 数据同步

• 消息广播：在Zookeeper中所有事务请求由Leader节点处理，其他服务器为Follower，Leader将客户端事务请求转化为事务Proposal，并且将Proposal分发给集群中其他所有Follower，完成广播之后，Leader等待Follower反馈，当有过半数Follower反馈消息后，Leader将再次向集群内Follower广播Commit信息，Commit信息就是确认将之前的Proposal提交。MySQL默认模式是autocommit自动提交模式，如果显式开始事务，在每次变更之后都要通过COMMIT语句确认，将更改提交到数据库。Leader节点写入操作：第一步是广播事务操作，第二部是广播提交操作。过半数是反馈的节点数 >= N/2 + 1，N是全部Follower节点数量。
  
• 崩溃恢复：保证Leader进程崩溃时候可以重新选出Leader并且保证数据完整性。进入崩溃恢复阶段：初始化集群，Leader崩溃，Leader失去半数机器支持，与集群中超过一半的节点断连。
  崩溃恢复模式将会开启新一轮选举，选举产生的Leader会与过半的Follower进行同步，使数据一致，当与过半机器同步完成后，退出恢复模式，然后进入消息广播模式。
  
  5个Follower服务器，Leader为2，挂掉之后，开始选举。1.各个节点变更状态为Looking，除了Leader，Follower还有Observer节点，不参与选举。2.各个节点发出投票进行选举，第一次投票，所有人投自己，然后将投票发给集群所有机器，运行期间，每个机器Zxid大概率不同。3.集群接受投票，开始处理。设3的Zxid最大，1认为3可以成为Leader，投票给他。首先选举epoch最大的，再选ZXID最大的，若都相等，则选择id最大的，zoo.cfg的myid.4.选举成功改变状态。
  
• 数据同步：选举过程中，通过投票确认Leader服务器最大Zxid节点，同步阶段利用Leader前一阶段获得最新Proposal历史，同步集群所有副本

6.4 Zab和Paxos算法

• 联系：都有Leader进程角色，负责协调多个Follower进程运行。都应用Quroum机制，Leader机制会等待超过半数的Follower做出正确反馈后才提交提案。Zab中，Zxid通过epoch来代表当前Leader周期，Paxos中，同样存在一个标识叫做Ballot Number
• 区别：Paxos是理论，Zab是实践，Paxos是论文性质来设计一种通用分布式一致性算法，Zab是一个特别设计的崩溃可恢复原子消息广播算法

7.区块链

起源于中本聪的比特币，本质是去中心化的数据库，公开透明，作为分布式账本技术，每个节点都可以参与数据库记录，注重安全和可信度胜过效率的技术。

7.1 共识

每个参与者都维护数据，最终以谁的为准。
来源于分布式系统的一致性问题，常见共识机制有POW,POS,DPOS
系统需要一个主进程来协调，系统的所有觉得都由主进程来达成一致性，区块链没有类似master角色，需要某种共识机制达成一致性

7.2 拜占庭将军

网络通信中，节点故障，信道不可靠的情况为非拜占庭错误。恶意响应，系统被攻击，传递错误消息称为拜占庭错误。
所有将军如何达成共识去攻打拜占庭帝国，核心描述是，军中可能有叛徒却要保持进攻一致。在区块链中，关键是如何避免恶意共识即错误记账

7.3 比特币的POW机制

• POW：工作量证明，最早用来防垃圾邮件，谷歌邮件强制每个给谷歌服务器发送邮件的发送者必须先完成一定量的计算工作，造成一小段时间延迟。
• 挖矿是将一段时间内的比特币系统发生的交易进行确认，并记录在区块链上形成新的区块的过程，由于需要竞争记账权，利用计算机算Hash值，随机碰撞解题。
• 中本聪在比特币系统设置一道题目，通过不断调节Nonce值，来对区块头算Hash，要求找到一个Nonce值，使得算出来Hash值满足某个固定值，一般使用SHA256算法
  
• 比特币系统自身会调节难度，控制解题时间，一般10分钟挖出一块区域，算出Nonce值，接下来吧这个放入结构体里，通过P2P网络广播出去，其他系统节点收到后，发现这个Nonce值合法，会认为挖矿成功，会得到比特币奖励和本区块内交易的手续费
• POW优点：POW是第一个完全去中心化共识算法的，并且节点自由进出，容易实现，由于对算力高要求，破坏系统花费巨大。
• POW缺点：能源浪费，巨大算法浪费在挖矿中，而且不产生任何机制

7.4 区块链分叉和51%攻击

• 51%攻击：Hash不可逆，依靠暴力计算，当掌握超过全网一般算力时，就能控制网络链的走向。系统出现链的分叉，最终会有一条链成为最长的链，现实生活中，分裂出BCH,GTG等分叉币。

7.5 POS权益证明

类似股东大会机制，拥有股份越多的人拥有越多投票权，越容易获取记账权。POS通过保证金对赌一个合法的块成为新的区块，收益为抵押资本的利息和交易服务费，提供保证的保证金越多，则获得记账权的概率就越大，合法记账者可以获得收益，ETH以太坊使用

7.6 DPOS委托权益证明

采用DPOS机制的典型代表是EOS，类似董事会制度，在DPOS下，选出一定数量代表，负责生产区块

8.系统拆分

分布式业务系统，就是把原来用 Java 开发的一个大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。

如果是那种代码量多达几十万行的中大型项目，团队里有几十个人，那么如果不拆分系统，开发效率极其低下，问题很多。但是拆分系统之后，每个人就负责自己的一小部分就好了，可以随便玩儿随便弄。分布式系统拆分之后，可以大幅度提升复杂系统大型团队的开发效率。

8.1 如何拆分

大部分的系统，是要进行多轮拆分的
分布式服务框架
说一下的 Dubbo 的工作原理？注册中心挂了可以继续通信吗？
Dubbo 支持哪些序列化协议？说一下 Hessian 的数据结构？PB 知道吗？为什么 PB 的效率是
最高的？
Dubbo 负载均衡策略和高可用策略都有哪些？动态代理策略呢？
Dubbo 的 SPI 思想是什么？
如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试？
分布式服务接口的幂等性如何设计（比如不能重复扣款）？
分布式服务接口请求的顺序性如何保证？
如何自己设计一个类似 Dubbo 的 RPC 框架？