wordpress媒体库整理,网站优化 西安,网站迁移,做58同城这样的网站Cluster(集群)概述 当单独一台主机无法承载现有的用户请求量#xff1b;或者一台主机因为单一故障导致业务中断的时候#xff0c;就可以增加服务主机数#xff0c;这些主机在一起提供服务#xff0c;就叫集群#xff0c;而用户所看到的依然是单个的主机#xff0c;用户并…Cluster(集群)概述 当单独一台主机无法承载现有的用户请求量或者一台主机因为单一故障导致业务中断的时候就可以增加服务主机数这些主机在一起提供服务就叫集群而用户所看到的依然是单个的主机用户并不用知道具体是集群内哪台设备为我提供服务只需要知道访问集群的入口即可。
集群类型包括
LB # Load Balancing负载均衡HA # High Availability 高可用双机主备HP # High Performancing 高性能
构建高可扩展性系统的重要原则在系统内部尽量避免串行化和交互
Load Balancing(负载均衡) 集群
根据请求报文的目标IP:PORT将其转发至后端主机集群中的某一台主机
LB的作用将业务请求分摊到多个后端设备进行执行例如Web服务器、FTP服务器等当一台web服务器为1W人提供服务的时候为了减少单台服务器的压力可以把1W人分成4份增加三台服务器四台服务器每台2500人共同完成工作任务就算一台坏掉了其余三台还能正常提供服务。也是变相实现了高可用可以解决单点故障
类似于交换机的转发以及路由器的转发都是把收到的请求转发到另一个地方LB可以称为4层交换或4层路由工作在4网络7层模型中4层及以上主要是对协议请求报文进行广播转发广播是对于同一个区域来进行的LB整个架构中的每一台设备都相当于交换机一个端口其中一个端口(调度器)收到请求报文广播给其余的RS或选择一个RS进行接收该请求
负载均衡实现方式从软硬件来区分分两种
硬件负载均衡通过硬件设备来实现负载均衡功能国内常用前三家的设备 F5厂家的BIG-IP最好的并发承载能力最高价格也是最好的Citrix(思捷)厂家的NetScaleerA10厂家的A10Array厂家Redware等等等 软件负载均衡通过软件技术来实现负载均衡功能 LVS(Linux virtual server)Linux自带的功能2.LB之LVS概念、类型、调度方法、命令操作与实际配置.notehaProxyNginxATS(apache traffic service)等等。软件负载均衡基于工作的协议层次划分 传输层lvshaproxy应用层haproxynginxats
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)
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器处理更多的数据。
系统的各个组件分布于网络上的多个NODE上各组件之间仅仅通过消息传递来通信并协调行动
分布式系统存在的意义
向上扩展的性价比越来越低单机扩展存在性能上升临界点处于稳定性以及可用性考虑单机会存在多方面的问题
分布式计算YARN
batchMapReduce
in-memory:spark
streamstorm
分布式系统的实现 负载均衡 - Nginx高性能、高并发的web服务器功能包括负载均衡、反向代理、静态内容缓存、访问控制工作在应用层 - LVS Linux virtual server基于集群技术和Linux操作系统实现一个高性能、高可用的服务器工作在网络层 webserver - JavaTomcatApacheJboss - Pythongunicorn、uwsgi、twisted、webpy、tornado service - SOA、微服务、spring bootdjango 容器 - dockerkubernetes
cache memcache、redis等 协调中心、仲裁系统分布式协作协议分布式系统中只要存在主备节点这种角色则必须要有一套系统来选举出来哪个是主的这就是仲裁系统的由来 zookeeper、etcd、VRRP、corosync等zookeeper使用了Paxos协议Paxos是强一致性高可用的去中心化分布式。zookeeper的使用场景非常广泛之后细讲。 rpc框架 grpc、dubbo、brpcdubbo是阿里开源的Java语言开发的高性能RPC框架在阿里系的诸多架构中都使用了dubbo spring boot 消息队列 kafka、rabbitMQ、rocketMQ、QSP消息队列的应用场景异步处理、应用解耦、流量削锋和消息通讯 实时数据平台 storm、akka 离线数据平台(分布式存储) hadoop(HDFS)、sparkPS: apark、akka、kafka都是scala语言写的看到这个语言还是很牛逼的• dbproxycobar也是阿里开源的在阿里系中使用也非常广泛是关系型数据库的sharding replica 代理 db mysql、oracle、MongoDB、HBase 搜索 elasticsearch、solr 日志 rsyslog、elk、flume
分布式系统的基本问题可用性与一致性
分布式系统的挑战
一致性可理解为所有节点都能访问到最新版本的数据这在单机场景下非常容易实现使用共享内存和锁即可解决但数据存储在单机会有两个限制
1单机不可用系统整体将不可用
2系统吞吐量受限于单机的计算能力。
消除这两个限制的方法是用多机来存储数据的多个副本负责更新的客户端会同时更新数据的多个副本于是问题就来了多机之间的网络可能无法连接当负责更新的客户端无法同时到连接多个机器时如何能保证所有客户端都能读到最新版本的数据
如下图1中所示Client A负责更新数据为了保证Server 1和Server 2上的数据是一致的Client A会将X1的写操作同时发给Server 1和Server 2但是当Client A和Server 2之间发生网络分区网络无法连接时此时如果让write X1的写操作在Server 1上成功那Client B和Client C将从Server 1和Server 2上读取到不一致的X值此时如果要保持X值的一致性那么write X1的写操作在Server 1和Server 2上都必须失败这就是著名的CAP理论在容忍网络分区的前提下要么牺牲数据的一致性要么牺牲写操作的可用性。 图1CAP理论示意图 解决这个问题你可能会想到让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协议提出只要系统中2f1个节点中的f1个节点可用那么系统整体就可用并且能保证数据的强一致性它对于可用性的提升是极大的仍然假设单节点的可用性是P那么2f1个节点中任意组合的f1以上个节点正常的可用性P(total) 又假设P0.99f2P(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来提交提案必须经过2f1个节点中的f1个节点接受才会生效2f1个节点叫做这次提案的投票委员会(Quorum)投票委员会中的节点叫做AcceptorPaxos协议流程还需要满足两个约束条件
aAcceptor必须接受它收到的第一个提案
b如果一个提案的v值被大多数Acceptor接受过那后续的所有被接受的提案中也必须包含v值v值可以理解为提案的内容提案由一个或多个v和提案编号组成。
Paxos协议流程划分为两个阶段第一阶段是Proposer学习提案最新状态的准备阶段第二阶段是根据学习到的状态组成正确提案提交的阶段完整的协议过程如下
阶段 1
Proposer选择一个提案编号n 然后向半数以上的Acceptors发送编号为 n 的prepare请求。如果一个Acceptor收到一个编号为n 的prepare请求且 n 大于它已经响应的所有prepare请求的编号那么它就会保证不会再通过(accept)任何编号小于 n 的提案同时将它已经通过的最大编号的提案(如果存在的话)作为响应。
阶段 2
如果Proposer收到来自半数以上的Acceptor对于它的prepare请求(编号为n )的响应那么它就会发送一个针对编号为 n value值为 v 的提案的accept请求给Acceptors在这里 v 是收到的响应中编号最大的提案的值如果响应中不包含提案那么它就是任意值。如果Acceptor收到一个针对编号n 的提案的accept请求只要它还未对编号大于 n 的prepare请求作出响应它就可以通过这个提案。 用时序图来描述Paxos协议如图3所示 图3Paxos协议流程的时序图
上述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在第二阶段还没有完成时新的提案n1的第一阶段prepare请求到达Acceptor按协议规定Acceptor将响应新提案的prepare请求并保证不会接受小于n1的任何请求这可能导致提案n将不会被通过同样在n1提案未完成第二阶段时假如提案n的提交者又提交了n2提案这可能导致n1提案也无法通过。Paxos协议规定提案的值v只要被大多数Acceptor接受过后续的所有提案不能修改值v那现实情况下我还要修改v值怎么办 ZooKeeper的核心算法ZAB通过一个简单的约束解决了前2个问题所有提案都转发到唯一的Leader通过Leader选举算法从Acceptor中选出来的来提交由Leader来保证多个提案之间的先后顺序同时也避免了多Proposer引发的活锁问题。
ZAB协议的过程用时序图描述如图4所示相比Paxos协议省略了Prepare阶段因为Leader本身就有提案的最新状态不需要有提案内容学习的过程,图中的Follower对应Paxos协议中的AcceptorObserver对应Paxos中的Learner。 图4ZAB协议的工作过程 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能够广泛应用到工业场景。
