什么是集群？

集群主要分成三大类 （高可用集群， 负载均衡集群，科学计算集群）

高可用集群( High Availability Cluster)

负载均衡集群(Load Balance Cluster)

科学计算集群(High Performance Computing Cluster)

1、高可用集群(High Availability Cluster)

常见的就是2个节点做成的HA集群，有很多通俗的不科学的名称，比如”双机热备”, “双机互备”, “双机”。高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的，保护的是用户的业务程序对外不间断提供服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)。

2、负载均衡集群(Load Balance Cluster)

负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。

负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。

3、科学计算集群(High Performance Computing Cluster)

高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。

高性能计算分类：　

31、高吞吐计算(High-throughput Computing)

有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。象在家搜寻外星人（ SETI@HOME – Search for Extraterrestrial Intelligence at Home ）就是这一类型应用。

这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上参加SETI的计算节点，计算节点在给定的数据上用给定的模式进行搜索，然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的 数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。

所谓的Internet计算都属于这一类。按照 Flynn的分类，高吞吐计算属于SIMD（Single Instruction/Multiple Data）的范畴。

32、分布计算(Distributed Computing)

另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。按照Flynn的分类，分布式的高性能计算属于MIMD（Multiple Instruction/Multiple Data）的范畴。

下面说说这几种集群的应用场景：

高可用集群这里不多作说明。

想Dubbo是比较偏向于负载均衡集群，用过的猿友应该知道（不知道的可以自行了解一下），Dubbo同一个服务是可以有多个提供者的，当一个消费者过来，它要消费那个提供者，这里是有负载均衡机制在里面的。

搜索引擎Elasticsearch比较偏向于科学计算集群的分布计算。

而到这里，可能不少猿友都知道，集群的一些术语：集群容错、负载均衡。

我们以Dubbo为例：

集群容错（http://dubboio/User+Guide-zhhtm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99）

Dubbo提供了这些容错策略：

集群容错模式：

可以自行扩展集群容错策略，参见：集群扩展

Failover Cluster

失败自动切换，当出现失败，重试其它服务器。(缺省)

通常用于读操作，但重试会带来更长延迟。

可通过retries="2"来设置重试次数(不含第一次)。

Failfast Cluster

快速失败，只发起一次调用，失败立即报错。

通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。

通常用于写入审计日志等操作。

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。

通常用于消息通知操作。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。

通常用于实时性要求较高的读操作，但需要浪费更多服务资源。

可通过forks="2"来设置最大并行数。

Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(210开始支持)

通常用于通知所有提供者更新缓存或日志等本地资源信息。

负载均衡（http://dubboio/User+Guide-zhhtm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1）

Dubbo提供了这些负载均衡策略：

Random LoadBalance

随机，按权重设置随机概率。

在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

轮循，按公约后的权重设置轮循比率。

存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

一致性Hash，相同参数的请求总是发到同一提供者。

当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

算法参见：http://enwikipediaorg/wiki/Consistent_hashing。

缺省只对第一个参数Hash，如果要修改，请配置<dubbo:parameter key="hasharguments" value="0,1" />

缺省用160份虚拟节点，如果要修改，请配置<dubbo:parameter key="hashnodes" value="320" />

在“高并发，海量数据，分布式，NoSql，云计算”概念满天飞的年代，相信不少朋友都听说过甚至常与人提起“集群，负载均衡”等，但不是所有人都有机会真正接触到这些技术，也不是所有人都真正理解了这些“听起来很牛的”技术名词。下面简单解释一下吧。（从一个网站上面看到的，例子很有趣，分享给大家）

集群(Cluster)

所谓集群是指一组独立的计算机系统构成的一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送，实现分布式计算机。通俗一点来说，就是让若干台计算机联合起来工作(服务)，可以是并行的，也可以是做备份。

负载均衡(Load Balance)

网络的负载均衡是一种动态均衡技术，常见的实现方式是通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。日常生活中到处都能看到“负载均衡”，一个超市的收营员高峰期只能服务10位顾客，当做活动时有20位顾客需要服务的话可能就会排长队，这样购物体验将会很差(就像客户抱怨系统/网站访问太慢)。最简单的办法就是再招个营业员，重新开通一个出口。负载均衡的核心就是“分摊压力”。

大规模集群，通常具备以下一些特点：

(1)高可靠性(HA)

利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。

(2)高性能计算(HP)

即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析、化学分析等。

(3)负载平衡(LB)

即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。

当然，以上的这些特点，在某些适应场合下是需要同时具备的。常用的集群又分以下几种：

load balance cluster(负载均衡集群)

一共有四兄弟开裁缝铺，生意特别多，一个人做不下来，老是延误工期，于是四个兄弟商量：老大接订单, 三个兄弟来干活。 客户多起来之后，老大根据一定的原则(policy) 根据三兄弟手上的工作量来分派新任务。

High availability cluster(高可用集群)

两兄弟开早餐铺，生意不大，但是每天早上7点到9点之间客户很多并且不能中断。为了保证2个小时内这个早餐铺能够保证持续提供服务，两兄弟商量几个方法:

方法一：平时老大做生意，老二这个时间段在家等候，一旦老大无法做生意了，老二就出来顶上，这个叫做 Active/Standby(双机热备)

方法二：平时老大做生意，老二这个时候就在旁边帮工，一旦老大无法做生意，老二就马上顶上，这个叫做Active/Passive(双机双工)

方法三：平时老大卖包子，老二也在旁边卖豆浆，老大有问题，老二就又卖包子，又卖豆浆，老二不行了，老大就又卖包子，又卖豆浆这个叫做Active/Active (dual Active)(双机互备)

(包子= application package, 互相照应叫做heartbeat, 顶替对方工作叫做 failover/takeover 如果两个兄弟突然都瞎了聋了，不知道现在对方到底是否正在干活，都认为自己要顶对方的工作，这个叫做brain-split, 然后需要第三者，比如他们的老爹来解决问题，这个叫做tier-breaker, 或者让他们两个的媳妇过来拉走其中一个，这个叫做fency。)

high computing clustering(高性能计算集群)

10个兄弟一起做手工家具生意，一个客户来找他们的老爹要求做一套非常复杂的仿古家具，一个人做也可以做，不过要做很久很久，为了1个星期就交出这一套家具，10个兄弟决定一起做。

老爹把这套家具的不同部分分开交给儿子们作，然后每个儿子都在做木制家具的加工，最后拼在一起叫货。

老爹是scheduler任务调度器，儿子们是compute node 他们做的工作叫做作业。

(其实，还有一种，分布式存储相关的集群，应用于超大规模网站，云计算平台等等。涉及点存储方面的，这里就不介绍了)

严格来讲，这些已经超过了一般开发人员的知识范畴了，想真正理解和掌握这些并不太容易，有时候需要真正的实践而不是闭门造车。从运维人员和系统架构师的角度来看，不仅需要具备丰富的操作系统配置和管理的经验，更要具备网络协议、存储等相关的知识(懂算法和底层的就更完美了)。从开发人员和软件架构师的角度来看，需要考虑的重点又不同了。当然，远远不止我所提到的这些。现在的Web应用一般都比较依赖于基础架构，而越来越脱离了”纯软件架构“的本质。集群不是万能的，但有时候确实相当有用。由于项目和工作关系，我本人目前主要使用的是微软的技术体系(当然，目前大都是基于windows平台的)。有机会的话，我可以将自己在这方面的研究和实践分享出来，更希望有兴趣的朋友在一块分享和交流。

总结：

分布式是指将不同的业务分布在不同的地方，集群指的是将几台服务器集中在一起，实现同一业务。在现有网络结构之上，负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。你对三者了解了么？

云服务器是基于规模化的物理服务器集群，每个集群节点被部署在骨干数据中心，可独立提供计算、存储、带宽等互联网基础设施服务。

小鸟云服务器配备纯SSD架构打造的高性能存储，提供优质、高效、弹性伸缩的云计算服务。同时可弹性扩展的资源用量，最大程度的节省IT运营成本，提高资源的有效利用率。

云服务器的物理架构，由存储服务器集群、计算服务器集群、基础架构管理服务器和网络交换机组成。其中，存储服务器集群构建虚拟资源池，具备超大容量，为节点内的云虚拟机提供逻辑磁盘存储、非结构数据存储以及整合备份服务;计算服务器集群，通过虚拟化技术整合，由控制平台按需生成、调配计算资源;管理服务器，采取双机热备的方式，对整个节点的所有计算服务器、共享存储、网络进行管理，同时对外提供管理整个节点的API;网络交换机，负责管理网段、公网交换网段、内部交换网段、存储网段等。

1)强扩展能力

其他扩展技术，通常仅能支持儿十个CPU 的扩展，扩展能力有限。而采用集群技术的集群系统则可以扩展到包括成百上千个CPU的多台服务穗，扩展能力具有明显优势。集群服务还可不断进行调整，以满足不断增长的应用需求。当集群的整体负荷超过集群的实际能力时，还可以添加额外的节点。

2)实现方式容易

服务器集群技术相对其他扩展技术来说更加容易实现，主要是通过软件进行的。在硬件上可以把多台性能较低、价格便宜的服务器，通过集群服务集中连接在一起即可实现整个服务器系统成倍，甚至几十、几百倍地增长。无论是从软硬件构成成本上来看，还是从技术实现成本上来看都较其他扩展方式低。

3)高可用性

使用集群服务拥有整个集群系统资源的所有权。如磁盘驱动器和IP地址将自动地从有故障的服务器上转移到可用的服务器上。当集群中的系统或应用程序出现故障时，集群软件将在可用的服务器上，重启失效的应用程序，或将失效节点上的工作分配到剩余的节点上。在切换过程中，用户只是觉得服务暂时停顿了一下。

4)易管理性

可以使用集群管理器来管理集群系统的所有服务器资源和应用程序，就像它们都运行在同一个服务器上一样。可以通过拖放集群对象，在集群里的不同服务器间移动应用程序，也可以通过同样的方式移动数据，还可以通过这种方式来手工地平衡服务器负荷、卸载服务器，从而方便地进行维护。同时，还可以从网络的任意地方的节点和资源处，监视集群的状态。当失效的服务器连回来时，将自动返回工作状态，集群技术将自动在集群中平衡负荷，而不需要入工干预。

初始阶段的网站架构

大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来，小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，这时的网站架构如图。

应用程序，数据库，文件等所有的资源都在一台服务器上。通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySql，汇集各种开源软件及一台廉价服务器就可以开始网站的发展之路了。

应用服务和数据服务分离

随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，这时就需要将应用和数据分离，应用和数据分离后整个网站使用三台服务器：应用服务器，文件服务器和数据库服务器，如下图所示，这三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU,数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存，文件服务器需要储存大量用户上传的文件，因此需要更大的硬盘。

应用和数据分离后，不同特性的服务器承担不同的服务角色，网站的并发处理能力和数据存储空间得到了很大改善，支持网站业务进一步发展，但是随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响，这时需要对网站架构进一步优化。

使用缓存改善网站性能

网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。淘宝买家浏览的商品集中在少部分成交数多、评价良好的商品上；百度搜索关键词集中在少部分热门词汇上；经常登录的用户才会发微博、看微博，而这部分用户也只占总用户数目的一小部分。

既然大部分的业务访问集中在，那么如果把这一小部分数据缓存在内存中，就可以减少数据库的访问压力。网站使用的缓存分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数量有限，而且会出现和应用程序争用内存的情况。远程分布式可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。

使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站的访问高峰期，应用服务器会成为整个网站的瓶颈。

使用应用服务器集群改善网站的并发处理能力

使用集群是网站解决高并发，海量问题的常用手段，当一台服务器的处理能力、储存空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求，这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。

对网站而言，只要能通过一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。如下图所示。

通过负载均衡调度服务器，可将来自用户浏览器的请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不在成为网站的瓶颈。

数据库读写分离

网站使用缓存后，大部分数据操作访问都可以不通过数据库就能完成，但是仍有一部分读操作，(缓存访问不命中、缓存过期)和全部的写操作，需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。

应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库或得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离时对应用透明。

使用反向代理和CDN加速网站响应

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，是用户在请求网站服务时，可以从距离自己最近的网路提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接给用户。

使用分布式文件系统和分布式数据库系统

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用，不到万不得以时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。

使用NOSQL和搜索引擎

对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。

业务拆分

随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现

分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择