集群与分布式

Cluster(集群)概述

当单独一台主机无法承载现有的用户请求量；或者一台主机因为单一故障导致业务中断的时候，就可以增加服务主机数，这些主机在一起提供服务，就叫集群，而用户所看到的依然是单个的主机，用户并不用知道具体是集群内哪台设备为我提供服务，只需要知道访问集群的入口即可。

集群类型包括：

1. LB # Load Balancing负载均衡
2. HA # High Availability 高可用，双机主备
3. HP # High Performancing 高性能

构建高可扩展性系统的重要原则：在系统内部尽量避免串行化和交互

Load Balancing(负载均衡) 集群

根据请求报文的目标IP:PORT将其转发至后端主机集群中的某一台主机

LB的作用：将业务请求分摊到多个后端设备进行执行，例如Web服务器、FTP服务器等，当一台web服务器为1W人提供服务的时候，为了减少单台服务器的压力，可以把1W人分成4份，增加三台服务器，四台服务器每台2500人，共同完成工作任务，就算一台坏掉了，其余三台还能正常提供服务。也是变相实现了高可用，可以解决单点故障

类似于交换机的转发以及路由器的转发，都是把收到的请求转发到另一个地方，LB可以称为4层交换或4层路由，工作在4网络7层模型中4层及以上，主要是对协议请求报文进行广播，转发，广播是对于同一个区域来进行的（LB整个架构中的每一台设备都相当于交换机一个端口，其中一个端口(调度器)收到请求报文，广播给其余的RS或选择一个RS进行接收该请求）

负载均衡实现方式从软硬件来区分，分两种：

1. 硬件负载均衡：通过硬件设备来实现负载均衡功能，国内常用前三家的设备
   1. F5厂家的BIG-IP，最好的，并发承载能力最高，价格也是最好的
   2. Citrix(思捷)厂家的NetScaleer
   3. A10厂家的A10
   4. Array厂家
   5. Redware
   6. 等等等
2. 软件负载均衡：通过软件技术来实现负载均衡功能
   1. LVS(Linux virtual server)，Linux自带的功能2.LB之LVS概念、类型、调度方法、命令操作与实际配置.note
   2. haProxy
   3. Nginx
   4. ATS(apache traffic service)
   5. 等等。软件负载均衡基于工作的协议层次划分：
      1. 传输层：lvs，haproxy
      2. 应用层：haproxy，nginx，ats

LB的实现方式

在很久很久以前，只有一台服务器来为用户提供服务，用户直接访问这台服务器的IP即可，如上文描述，当一台服务器不够用的时候，想让多台服务器同时为用户提供服务，这就是负载均衡的技术，那么这么多台服务器，每个服务器都有自己的IP，用户如何知道自己访问哪个呢？

这时候在这些服务器前面就需要有一个调度人员，来处理用户的请求，用户具体访问哪台服务器，由这个调度人员来决定，这个调度人员的工作，也可以同通过一台服务器来实现，这台调度服务器，就是实现LB技术的设备。而调度器(Director)的叫法，也是由此而来

High Availability(高可用) 集群

为提升系统可用性，组合多台主机构建的集群称为 **High Availability(高可用，简称 HA)** 集群

HA的作用：为避免单一资源损坏导致业务终端，那么就需要增加备用资源，当主资源坏了之后，备用资源可以立刻接替已坏资源的工作继续提供服务。两个资源中间需要交换数据以确认对方是否是正常运行，是否需要把备用资源启动成主资源提供服务，这种检测机制就是heartbeat心跳检测。（注意：资源包括但不限于真实物理机，虚拟机，操作系统，系统中的一个应用程序，系统中的一个进程等等。比如，当一台主机宕机了，可以由另一台主机接管；当系统中的web进程终止了，由另一台设备的web进程提供服务）

HA 的实现方式

+ keepalived

Distributed(分布式)系统概述

> 参考文章： > > + [https://www.cnblogs.com/xybaby/p/7787034.html](https://www.cnblogs.com/xybaby/p/7787034.html) >

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。

1. 系统的各个组件分布于网络上的多个NODE上
2. 各组件之间仅仅通过消息传递来通信并协调行动

分布式系统存在的意义

1. 向上扩展的性价比越来越低
2. 单机扩展存在性能上升临界点
3. 处于稳定性以及可用性考虑，单机会存在多方面的问题

分布式计算：YARN

batch：MapReduce

in-memory:spark

stream：storm

分布式系统的实现

+ 负载均衡： - Nginx：高性能、高并发的web服务器；功能包括负载均衡、反向代理、静态内容缓存、访问控制；工作在应用层 - LVS： Linux virtual server，基于集群技术和Linux操作系统实现一个高性能、高可用的服务器；工作在网络层 + webserver： - Java：Tomcat，Apache，Jboss - Python：gunicorn、uwsgi、twisted、webpy、tornado + service： - SOA、微服务、spring boot，django + 容器： - docker，kubernetes

• cache：
  • memcache、redis等
• 协调中心、仲裁系统：分布式协作协议，分布式系统中只要存在主备节点这种角色，则必须要有一套系统来选举出来哪个是主的，这就是仲裁系统的由来
  • zookeeper、etcd、VRRP、corosync等
  • zookeeper使用了Paxos协议Paxos是强一致性，高可用的去中心化分布式。zookeeper的使用场景非常广泛，之后细讲。
• rpc框架：
  • grpc、dubbo、brpc
  • dubbo是阿里开源的Java语言开发的高性能RPC框架，在阿里系的诸多架构中，都使用了dubbo + spring boot
• 消息队列：
  • kafka、rabbitMQ、rocketMQ、QSP
  • 消息队列的应用场景：异步处理、应用解耦、流量削锋和消息通讯
• 实时数据平台：
  • storm、akka
• 离线数据平台：(分布式存储)
  • hadoop(HDFS)、spark
  • PS: apark、akka、kafka都是scala语言写的，看到这个语言还是很牛逼的• dbproxy：
  • cobar也是阿里开源的，在阿里系中使用也非常广泛，是关系型数据库的sharding + replica 代理
• db：
  • mysql、oracle、MongoDB、HBase
• 搜索：
  • elasticsearch、solr
• 日志：
  • rsyslog、elk、flume

分布式系统的基本问题：可用性与一致性

分布式系统的挑战

一致性可理解为所有节点都能访问到最新版本的数据，这在单机场景下非常容易实现，使用共享内存和锁即可解决，但数据存储在单机会有两个限制：

1）单机不可用系统整体将不可用；

2）系统吞吐量受限于单机的计算能力。

消除这两个限制的方法是用多机来存储数据的多个副本，负责更新的客户端会同时更新数据的多个副本，于是问题就来了，多机之间的网络可能无法连接，当负责更新的客户端无法同时到连接多个机器时，如何能保证所有客户端都能读到最新版本的数据？

如下图1中所示，Client A负责更新数据，为了保证Server 1和Server 2上的数据是一致的，Client A会将X=1的写操作同时发给Server 1和Server 2，但是当Client A和Server 2之间发生网络分区（网络无法连接）时，此时如果让write X=1的写操作在Server 1上成功，那Client B和Client C将从Server 1和Server 2上读取到不一致的X值；此时如果要保持X值的一致性，那么write X=1的写操作在Server 1和Server 2上都必须失败，这就是著名的CAP理论：在容忍网络分区的前提下，要么牺牲数据的一致性，要么牺牲写操作的可用性。

图1：CAP理论示意图

解决这个问题你可能会想到让Client C同时读取Server 1和Server 2上的X值和版本信息，然后取Server 1和Server 2最新版本的X值，如下图2所示。但Client C和Server 1之间也可能发生网络分区，这本质上是牺牲读可用性换取写可用性，并没有突破CAP理论。

图2：对图1中可用性的优化

CAP理论

CAP理论由加州大学伯克利分校的计算机教授Eric Brewer在2000年提出，其核心思想是任何基于网络的数据共享系统最多只能满足数据一致性(Consistency)、可用性(Availability)和网络分区容忍(Partition Tolerance)三个特性中的两个，三个特性的定义如下：

• Consistency(数据一致性)：等同于所有节点拥有数据的最新版本
• Availability(可用性)：数据具备高可用性
• Partition Tolerance(分区容忍)：容忍网络出现分区，分区之间网络不可达

在大规模的分布式环境下，网络分区是必须容忍的现实，于是只能在可用性和一致性两者间做出选择，CAP理论似乎给分布式系统定义了一个悲观的结局，一时间大家都按照CAP理论在对热门的分布式系统进行判定，譬如认为HBase是一个CP系统、Cassandra是AP系统。

我个人认为这是不严谨的，理由是CAP理论是对分布式系统中一个数据无法同时达到可用性和一致性的断言，而一个系统中往往存在很多类型的数据，部分数据（譬如银行账户中的余额）是需要强一致性的，而另外一部分数据（譬如银行的总客户数）并不要求强一致性，所以拿CAP理论来划分整个系统是不严谨的， CAP理论带来的价值是指引我们在设计分布式系统时需要区分各种数据的特点，并仔细考虑在小概率的网络分区发生时究竟为该数据选择可用性还是一致性。

对CAP理论的另外一种误读是系统设计时选择其一而完全不去优化另外一项，可用性和一致性的取值范围并不是只有0和1，可用性的值域可以定义成0到100%的连续区间，而一致性也可分为强一致性、弱一致性、读写一致性、最终一致性等多个不同的强弱等级，细想下去CAP理论定义的其实是在容忍网络分区的条件下，“强一致性”和“极致可用性”无法同时达到。

（注：这里用“极致可用性”而不用“100%可用性”是因为即使不考虑一致性，多台server组成的分布式系统也达不到100%的可用性，如果单个server的可用性是P，那n台server的极致可用性是

，公式的意思是只要任何一台或多台server可用就认为系统都是可用的）

虽然无法达到同时达到强一致性和极致可用性，但我们可以根据数据类型在二者中选择其一后去优化另外一个，Paxos协议就是一种在保证强一致性前提下把可用性优化到极限的算法。

Paxos协议

Paxos协议由Leslie Lamport最早在1990年提出，由于Paxos在云计算领域的广泛应用Leslie Lamport因此获得了2013年度图灵奖。

Paxos协议提出只要系统中2f+1个节点中的f+1个节点可用，那么系统整体就可用并且能保证数据的强一致性，它对于可用性的提升是极大的，仍然假设单节点的可用性是P，那么2f+1个节点中任意组合的f+1以上个节点正常的可用性P(total)=

，又假设P=0.99，f=2，P(total)=0.9999901494，可用性将从单节点的2个9提升到了5个9，这意味着系统每年的宕机时间从87.6小时降到0.086小时，这已经可以满足地球上99.99999999%的应用需求。

Leslie写的两篇论文：《The Part-Time Parliament》和《Paxos Made Simple》比较完整的阐述了Paxos的工作流程和证明过程，Paxos协议把每个数据写请求比喻成一次提案（proposal），每个提案都有一个独立的编号，提案会转发到提交者（Proposer）来提交，提案必须经过2f+1个节点中的f+1个节点接受才会生效，2f+1个节点叫做这次提案的投票委员会(Quorum)，投票委员会中的节点叫做Acceptor，Paxos协议流程还需要满足两个约束条件：

a）Acceptor必须接受它收到的第一个提案；

b）如果一个提案的v值被大多数Acceptor接受过，那后续的所有被接受的提案中也必须包含v值（v值可以理解为提案的内容，提案由一个或多个v和提案编号组成）。

Paxos协议流程划分为两个阶段，第一阶段是Proposer学习提案最新状态的准备阶段；第二阶段是根据学习到的状态组成正确提案提交的阶段，完整的协议过程如下：

阶段 1

1. Proposer选择一个提案编号n ，然后向半数以上的Acceptors发送编号为 n 的prepare请求。
2. 如果一个Acceptor收到一个编号为n 的prepare请求，且 n 大于它已经响应的所有prepare请求的编号，那么它就会保证不会再通过(accept)任何编号小于 n 的提案，同时将它已经通过的最大编号的提案(如果存在的话)作为响应。

阶段 2

1. 如果Proposer收到来自半数以上的Acceptor对于它的prepare请求(编号为n )的响应，那么它就会发送一个针对编号为 n ，value值为 v 的提案的accept请求给Acceptors，在这里 v 是收到的响应中编号最大的提案的值，如果响应中不包含提案，那么它就是任意值。
2. 如果Acceptor收到一个针对编号n 的提案的accept请求，只要它还未对编号大于 n 的prepare请求作出响应，它就可以通过这个提案。

用时序图来描述Paxos协议如图3所示：

图3：Paxos协议流程的时序图

上述Paxos协议流程看起来比较复杂，是因为要保证很多边界条件下的协议完备性，譬如初试值为空、两个Proposer同时提交提案等情况，但Paxos协议的核心可以简单描述为：Proposer先从大多数Acceptor那里学习提案的最新内容，然后根据学习到的编号最大的提案内容组成新的提案提交，如果提案获得大多数Acceptor的投票通过就意味着提案被通过。由于学习提案和通过提案的Acceptor集合都超过了半数，所以一定能学到最新通过的提案值，两次提案通过的Acceptor集合中也一定存在一个公共的Acceptor，在满足约束条件b时这个公共的Acceptor时保证了数据的一致性，于是Paxos协议又被称为多数派协议。

Paxos协议的真正伟大之处在于它的简洁性，Paxos协议流程中任何消息都是可以丢失的，一致性保证并不依赖某个特殊消息传递的成功，这极大的简化了分布式系统的设计，极其匹配分布式环境下网络可能分区的特点，相比较在Paxos协议之前的“两阶段提交（2PC）”也能保证数据强一致性，但复杂度相当高且依赖单个协调者的可用性。

那既然Paxos如此强大，那为什么还会出现ZAB协议？

ZAB协议

Paxos协议虽然是完备的，但要把它应用到实际的分布式系统中还有些问题要解决：

• 在多个Proposer的场景下，Paxos不保证先提交的提案先被接受，实际应用中要保证多提案被接受的先后顺序怎么办？
• Paxos允许多个Proposer提交提案，那有可能出现活锁问题，出现场景是这样的：提案n在第二阶段还没有完成时，新的提案n+1的第一阶段prepare请求到达Acceptor，按协议规定Acceptor将响应新提案的prepare请求并保证不会接受小于n+1的任何请求，这可能导致提案n将不会被通过，同样在n+1提案未完成第二阶段时，假如提案n的提交者又提交了n+2提案，这可能导致n+1提案也无法通过。
• Paxos协议规定提案的值v只要被大多数Acceptor接受过，后续的所有提案不能修改值v，那现实情况下我还要修改v值怎么办？

ZooKeeper的核心算法ZAB通过一个简单的约束解决了前2个问题：所有提案都转发到唯一的Leader（通过Leader选举算法从Acceptor中选出来的）来提交，由Leader来保证多个提案之间的先后顺序，同时也避免了多Proposer引发的活锁问题。

ZAB协议的过程用时序图描述如图4所示，相比Paxos协议省略了Prepare阶段，因为Leader本身就有提案的最新状态，不需要有提案内容学习的过程,图中的Follower对应Paxos协议中的Acceptor，Observer对应Paxos中的Learner。

图4：ZAB协议的工作过程

ZAB引入Leader后也会带来一个新问题： Leader宕机了怎么办？其解决方案是选举出一个新的Leader，选举Leader的过程也是一个Paxos提案决议过程，这里不展开讨论。

那如何做到提案的值v可以修改呢？这不是ZAB协议的范畴，研究ZooKeeper源码后发现它是这么做的：ZooKeeper提供了一个znode的概念，znode可以被修改，ZooKeeper对每个znode都记录了一个自增且连续的版本号，对znode的任何修改操作（create/set/setAcl）都会促发一次Paxos多数派投票过程，投票通过后znode版本号加1，这相当于用znode不同版本的多次Paxos协议来破除单次Paxos协议无法修改提案值的限制。

从保证一致性的算法核心角度看ZAB确实是借鉴了Paxos的多数派思想，但它提供的全局时序保证以及ZooKeeper提供给用户可修改的znode才让Paxos在开源界大放异彩，所以ZAB的价值不仅仅是提供了Paxos算法的优化实现，也难怪ZAB的作者一直强调ZAB和Paxos是不一样的算法。

总结

CAP理论告诉我们在分布式环境下网络分区无法避免，需要去权衡选择数据的一致性和可用性，Paxos协议提出了一种极其简单的算法在保障数据一致性时最大限度的优化了可用性，ZooKeeper的ZAB协议把Paxos更加简化，并提供全局时序保证，使得Paxos能够广泛应用到工业场景。