在这一年的工作中,对一些分布式和集群技术也有一些接触,只是研究得并不深入。比如分布式服务框架Dubbo、搜索引擎Elasticsearch。
概念总是抽象的,配合实例会让你对概念的理解更加清晰。因此,如果刚好有使用到分布式和集群技术的猿友,可以边看本文的一些概念边回想你使用过的分布式和集群技术。如果你没有使用过相关技术,那其实也是可以以了解的心态将本文看完,后面接触到了,起码会有个大概的印象。
下面我们先看看其他猿友对“分布式”和“集群”的看法:
(1)另外一位博主的观点(http://blog.csdn.net/bluishglc/article/details/5483162)
博主有对他的表述有作一点修改补充,方便各位猿友明天他的意思。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
(2)知乎(https://www.zhihu.com/question/20004877)
这个猿友描述得很简单明了:
- 1
- 2
- 1
- 2
另外一位猿友从另外一个角度去表述:
- 1
- 1
这位猿友的描述也很简洁,但是比较抽象:
- 1
- 1
(3)百度百科(http://baike.baidu.com/view/4804677.htm、http://baike.baidu.com/view/3022776.htm)
集群:
- 1
- 1
分布式:
- 1
- 1
看完这些是不是有种似懂非懂的感觉?博主也是一样!所以我们接下来继续了解。
上面博主有说过自己有接触过分布式服务框架Dubbo,那么我们看看它为什么说自己是分布式服务架构?(http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF)
- 1
- 2
- 3
- 1
- 2
- 3
偶然之间,有发现据说“Git就是分布式版本控制系统”,为什么它是分布式的呢?(http://zhidao.baidu.com/link?url=WYNUjpVK8c-G5lq9EP6CMWAAwexIKduWUYlSC09iC5NRPYJI4L7HxoxgTRIiGxKoNQpBy4XCC_j_6toJOSbQzY8O6-NIXCBvUZ2–zcJwtK)
- 1
- 1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
看了分布式服务框架Dubbo和分布式版本控制系统Git的这些描述后,细想一下,似乎和上面的“分布式:一个业务分拆多个子业务,部署在不同的服务器上,集群:同一个业务,部署在多个服务器上”的观点些相似。
Dubbo将核心业务抽取出来,作为独立的服务模块,各个模块之间只需要依赖接口,接口实现分离,那么开发人员可以各自完成自己负责的服务模块,最后完成一个完整的系统。他们的目标是完成一个系统,而各个子服务模块相当于子业务。Git也类似。
事实上,分布式很多时候都开不了集群的,在Dubbo、Hadoop、Elasticsearch都有体现。
现在分布式概念可能我们相对比较清晰了,集群概念可能还比较模糊。另外,集群是如何跟分布式配合的呢,接下来我们继续了解集群。
集群主要分成三大类( 高可用集群, 负载均衡集群,科学计算集群)
高可用集群( 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集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。
高性能计算分类:
3.1、高吞吐计算(High-throughput Computing)
有一类高性能计算,可以把它分成若干可以并行的子任务,而且各个子任务彼此间没有什么关联。象在家搜寻外星人( SETI@HOME – Search for Extraterrestrial Intelligence at Home )就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上 参加SETI的计算节点,计算节点在给定的数据上用给定的模式进行搜索,然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的 数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式,所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照 Flynn的分类,高吞吐计算属于SIMD(Single Instruction/Multiple Data)的范畴。
3.2、分布计算(Distributed Computing)
另一类计算刚好和高吞吐计算相反,它们虽然可以给分成若干并行的子任务,但是子任务间联系很紧密,需要大量的数据交换。按照Flynn的分类,分布式的高性能计算属于MIMD(Multiple Instruction/Multiple Data)的范畴。
下面说说这几种集群的应用场景:
高可用集群这里不多作说明。
想Dubbo是比较偏向于负载均衡集群,用过的猿友应该知道(不知道的可以自行了解一下),Dubbo同一个服务是可以有多个提供者的,当一个消费者过来,它要消费那个提供者,这里是有负载均衡机制在里面的。
搜索引擎Elasticsearch比较偏向于科学计算集群的分布计算。
而到这里,可能不少猿友都知道,集群的一些术语:集群容错、负载均衡。
我们以Dubbo为例:
集群容错(http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E9%9B%86%E7%BE%A4%E5%AE%B9%E9%94%99)
Dubbo提供了这些容错策略:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
负载均衡(http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1)
Dubbo提供了这些负载均衡策略:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
还有比较好奇它们是怎么通信的?
像早期版本的Elasticsearch的话,自动发现节点机制,ES是一个基于p2p的系统,它先通过广播寻找存在的节点,再通过多播协议来进行节点之间的通信,同时也支持点对点的交互。
而Dubbo是有个注册中心,它支持多个注册中心,但是推荐使用ZooKeeper。关于ZooKeeper可以自行了解,很多集群相关的框架都有使用到它。当然像Elasticsearch是自己有相应的机制实现的。