分布式数据库集群

① 分布式数据库 与 集群数据库 之间的关系

分布式, 往往指数据被割裂, 分置不同地方
集群指, 在任何实例上, 看到的数据都是一致的.
两者有非常大的不同.
mysql 做不了集群, 只能做分布. 可以认为你必须先知道数据在哪个mysql实例上.

② oracle数据库的分布式和tomcat的集群式有什么区别

分布式是架构部署模式的一种。分布式多用于描述架构设计上，当然现在有各种新用法。
集群是硬件部署模式的一种，是集中部署在一个机房里的计算机群体的集中称谓。
分布式网站集群系统是一种多网站架构模式，支持生成独立网站、多个网站,完成各个网站横向一体化和纵向一体化网站群的构建，主站、子站、网站间的信息可共享和信息互联。
简单的说：就是一个企业/个人可以像申请博客那样自助建站，维护，更新，而分布式，就是把问题分开解决的意思，即系统分布在几个不同服务器上。

③ 分布式数据库与数据库集群的区别到底是什么哪位高手帮忙解惑下~~~~~~~~~~跪求

来具体说说数据库集群吧
集群主要分成三大类 （高可用集群， 负载均衡集群，科学计算集群）
高可用集群( 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://bbo.io/User+Guide-zh.htm#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

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

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

负载均衡（http://bbo.io/User+Guide-zh.htm#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://en.wikipedia.org/wiki/Consistent_hashing。

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

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

④ 数据库中的集群和F5

分布式数据库系统分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。
----- ----
分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。在分布式数据库系统中，一个应用程序可以对数据库进行透明操作，数据库中的数据分别在不同的局部数据库中存储、由不同的 DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。
一个分布式数据库在逻辑上是一个统一的整体，在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。 更确切地讲，不存储在同一计算机的存储设备上。 这就是与集中式数据库的区别。从用户的角度看，一个分布式数据库系统在逻辑上和集中式数据库系统一样，用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上，有单个数据库管理系统(DBMS)管理一样，用户并没有什么感觉不一样。
分布式数据库系统是在集中式数据库系统的基础上发展起来的，是计算机技术和网络技术结合的产物。分布式数据库系统适合于单位分散的部门，允许各个部门将其常用的数据存储在本地，实施就地存放本地使用，从而提高响应速度，降低通信费用。分布式数据库系统与集中式数据库系统相比具有可扩展性，通过增加适当的数据冗余，提高系统的可靠性。在集中式数据库中，尽量减少冗余度是系统目标之一．其原因是，冗余数据浪费存储空间，而且容易造成各副本之间的不一致性．而为了保证数据的一致性，系统要付出一定的维护代价．减少冗余度的目标是用数据共享来达到的。而在分布式数据库中却希望增加冗余数据，在不同的场地存储同一数据的多个副本,其原因是：①．提高系统的可靠性、可用性当某一场地出现故障时，系统可以对另一场地上的相同副本进行操作，不会因一处故障而造成整个系统的瘫痪。②．提高系统性能系统可以根据距离选择离用户最近的数据副本进行操作，减少通信代价，改善整个系统的性能。
分布式数据库具有以下几个特点：
(1)、数据独立性与位置透明性。数据独立性是数据库方法追求的主要目标之一，分布透明性指用户不必关心数据的逻辑分区，不必关心数据物理位置分布的细节，也不必关心重复副本（冗余数据）的一致性问题，同时也不必关心局部场地上数据库支持哪种数据模型．分布透明性的优点是很明显的．有了分布透明性，用户的应用程序书写起来就如同数据没有分布一样．当数据从一个场地移到另一个场地时不必改写应用程序．当增加某些数据的重复副本时也不必改写应用程序．数据分布的信息由系统存储在数据字典中．用户对非本地数据的访问请求由系统根据数据字典予以解释、转换、传送．
(2)、集中和节点自治相结合。数据库是用户共享的资源．在集中式数据库中，为了保证数据库的安全性和完整性，对共享数据库的控制是集中的，并设有DBA负责监督和维护系统的正常运行．在分布式数据库中，数据的共享有两个层次：一是局部共享，即在局部数据库中存储局部场地上各用户的共享数据．这些数据是本场地用户常用的．二是全局共享，即在分布式数据库的各个场地也存储可供网中其它场地的用户共享的数据，支持系统中的全局应用．因此，相应的控制结构也具有两个层次：集中和自治．分布式数据库系统常常采用集中和自治相结合的控制结构,各局部的DBMS可以独立地管理局部数据库，具有自治的功能．同时，系统又设有集中控制机制，协调各局部DBMS的工作，执行全局应用。当然,不同的系统集中和自治的程度不尽相同．有些系统高度自治，连全局应用事务的协调也由局部DBMS、局部DBA共同承担而不要集中控制，不设全局DBA,有些系统则集中控制程度较高，场地自治功能较弱。
(3)、支持全局数据库的一致性和和可恢复性。分布式数据库中各局部数据库应满足集中式数据库的一致性、可串行性和可恢复性。除此以外还应保证数据库的全局一致性、并行操作的可串行性和系统的全局可恢复性。这是因为全局应用要涉及两个以上结点的数据．因此在分布式数据库系统中一个业务可能由不同场地上的 多个操作组成．例如, 银行转帐业务包括两个结点上的更新操作。这样，当其中某一个结点出现故障操作失败后如何使全局业务滚回呢？如何使另一个结点撤销已执行的操作(若操作已完成或完成一部分）或者不必再执行业务的其它操作(若操作尚没执行)？这些技术要比集中式数据库复杂和困难得多，分布式数据库系统必须解决这些问题．
(4)、复制透明性。用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。在分布式数据库系统中，可以把一个场地的数据复制到其他场地存放，应用程序可以使用复制到本地的数据在本地完成分布式操作，避免通过网络传输数据，提高了系统的运行和查询效率。但是对于复制数据的更新操作，就要涉及到对所有复制数据的更新。
(5)、易于扩展性。在大多数网络环境中，单个数据库服务器最终会不满足使用。如果服务器软件支持透明的水平扩展，那么就可以增加多个服务器来进一步分布数据和分担处理任务。
分布式数据库的优点：
(1)具有灵活的体系结构 。
(2)适应分布式的管理和控制机构。
(3)经济性能优越 。
(4)系统的可靠性高、可用性好 。
(5)局部应用的响应速度快。
(6)可扩展性好，易于集成现有系统。
分布式数据库的缺点：
(1)系统开销大，主要花在通信部分。
(2)复杂的存取结构，原来在集中式系统中有效存取数据的技术，在分成式系统中都不再适用。
(3)数据的安全生和保密性较难处理。
分布式数据库系统的目标
分布式数据库系统的目标，也就是研制分布式数据库系统的目的、动机，主要包括技术和组织两方面的目标．
1．适应部门分布的组织结构，降低费用。
使用数据库的单位在组织上常常是分布的（如分为部门、科室、车间等等），在地理上也是分布的．分布式数据库系统的结构符合部门分布的组织结构，允许各个部门对自己常用的数据存储在本地，在本地录入、查询、维护，实行局部控制．由于计算机资源靠近用户，因而可以降低通信代价，提高响应速度，使这些部门使用数据库更方便更经济。
2．提高系统的可靠性和可用性。
改善系统的可靠性和可用性是分布式数据库的主要目标．将数据分布于多个场地，并增加适当的冗余度可以提供更好的可靠性．一些可靠性要求较高的系统，这一点尤其重要．因为一个地出了故障不会引起整个系统崩溃．因为故障场地的用户可以通过其它场地进入系统．而其它场地的用户可以由系统自动选择存取路径，避开故障场地，利用其它数据副本执行操作，不影响业务的正常运行．
3．充分利用数据库资源，提高现有集中式数据库的利用率
当在一个大企业或大部门中已建成了若干个数据库之后，为了利用相互的资源，为了开发全局应用，就要研制分布式数据库系统．这种情况可称为自底向上的建立分布式系统．这种方法虽然也要对各现存的局部数据库系统做某些改动、重构，但比起把这些数据库集中起来重建一个集中式数据库，则无论从经济上还是从组织上考虑，分布式数据库均是较好的选择．
4．逐步扩展处理能力和系统规模
当一个单位规模扩大要增加新的部门(如银行系统增加新的分行，工厂增加新的科室、车间)时，分布式数据库系统的结构为扩展系统的处理能力提供了较好的途径：在分布式数据库系统中增加一个新的结点．这样做比在集中式系统中扩大系统规模要方便、灵活、经济得多。
在集中式系统中为了扩大规模常用的方法有两种：一种是在开始设计时留有较大的余地．这容易造成浪费，而且由于预测困难，设计结果仍可能不适应情况的变化．另一种方法是系统升级，这会影响现有应用的正常运行．并且当升级涉及不兼容的硬件或系统软件有了重大修改而要相应地修改已开发的应用软件时，升级的代价就十分昂贵而常常使得升级的方法不可行．分布式数据库系统能方便地把一个新的结点纳入系统，不影响现有系统的结构和系统的正常运行，提供了逐渐扩展系统能力的较好途径，有时甚至是唯一的途径。
①数据库系统与应用 赵致格编着 清华大学出版社p. 260
②数据库原理及应用 张晋连 编着 电子工业出版社P.13

⑤ 分布式数据库的分布式数据库相对传统集中式数据库的优点

大数据时代，面对日益增长的海量数据，传统的集中式数据库的弊端日益显现，分布式数据库相对传统的集中式数据库有如下优点。
● 更高的数据访问速度：分布式数据库为了保证数据的高可靠性，往往采用备份的策略实现容错，所以，在读取数据的时候，客户端可以并发地从多个
备份服务器同时读取，从而提高了数据访问速度。
● 更强的可扩展性：分布式数据库可以通过增添存储节点来实现存储容量的线性扩展，而集中式数据库的可扩展性十分有限。
● 更高的并发访问量：分布式数据库由于采用多台主机组成存储集群，所以相对集中式数据库，它可以提供更高的用户并发访问量。

⑥ 什么是分布式数据库

精确的分布式数据库定义：分布式数据库是由一组数据组成的，这组数据分布在计算机网络中的不同的计算机上，网络中的每个节点具有独立处理的能力(称为场地自治)，可以执行局部应用。同时，每个节点也能通过网络通信子系统执行全局应用。与之前的定义相比，更注重场地自治性以及自治场地之间的协作性。

分布式数据库系统：一个粗略的定义是“分布式数据库由一组数据组成，这些数据物理上分布在计算机网络的不同节点上(亦称场地)上，逻辑上是属于同一个系统。” 这里强调两点：

(1)分布性：数据库中的数据不是存储在同一场地，更确切的说，不存储在同一计算机的存储设备上，这就可以和集中式数据库相互区别。

(2)逻辑整体性：这些数据逻辑上是互相联系的，是一个整体(逻辑上如同集中数据库)。

⑦ 国产分布式数据库到底怎么样

分布式是趋势。
推荐一款有幸用过，使用效果很好的国产分布式数据库——思极有容数据库。
趋势价值分析
1）分布式是趋势，但是技术门槛高，对研发，运维的水平要求高。；
2）思极有容数据库作为分布式解决方案对应用透明，研发人员精力集中在业务实现，而不是被分库分表耗费过多精力，从而提高效率，这是一个很有价值和意义的事情。
如果和传统国产数据库厂家，例如达梦、人大、神通等相比，思极有容数据库采用原生分布式架构，在集群扩展性和大规模部署后集群性能方面有较大优势；同时思极有容数据库 完全兼容和继承MySQL生态，非常的易用易适配，可以无缝衔接大量第三方数据处理组件，有巨大的生态优势。
和开源数据库MySQL/PostgreSQL相比，思极有容数据库 具备强大的扩展能力和准线性的性能提升优势，在数据存储容量、事务吞吐性能、数据库原生高可用方面具备碾压优势。
和新兴分布式数据库厂家，例如阿里DRDS、腾讯TDSQL等相比，思极有容数据库具备更加完备的SQL语法支持，具备更加强大的事务吞吐性能，对应用适配更加友好。

⑧ 什么叫分布式数据库，有什么优点和缺点

1.分布式数据库是数据库的一种，是数据库技术和网络技术的结合产物。

2.各有优点和缺点.分布式数据库分为逻辑上分部物理上分布及逻辑上分布物理上集中两种。

是的,分布式数据文件便于数据库的管理维护。

⑨ 分布式数据库与数据库集群的区别到底是什么哪位高手帮忙解惑下~~~~~~~~~~跪求

（1）另外一位博主的观点（http://blog.csdn.net/bluishglc/article/details/5483162）

博主有对他的表述有作一点修改补充，方便各位猿友明了他的意思。

简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

例如：

如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行改任务需10小时。

采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是Hadoop的Map/Rece分布式计算模型）

而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，10小后，10个任务同时完成，这样，整身来看，还是平均1小时完成一个任务！（注意这里的任务和子任务的区别）

（2）知乎（https://www.hu.com/question/20004877）

这个猿友描述得很简单明了：

分布式：一个业务分拆多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上

另外一位猿友从另外一个角度去表述：

集群是个物理形态，分布式是个工作方式。

这位猿友的描述也很简洁，但是比较抽象：

按照我的理解，集群是解决高可用的，而分布式是解决高性能、高并发的

（3）网络（http://ke..com/view/4804677.htm、http://ke..com/view/3022776.htm）

集群：

集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。

分布式：

一种基于网络的计算机处理技术，与集中式相对应。由于个人计算机的性能得到极大的提高及其使用的普及，使处理能力分布到网络上的所有计算机成为可能。分布式计算是和集中式计算相对立的概念，分布式计算的数据可以分布在很大区域。

看完这些是不是有种似懂非懂的感觉？博主也是一样！所以我们接下来继续了解。

上面博主有说过自己有接触过分布式服务框架Dubbo，那么我们看看它为什么说自己是分布式服务架构？（http://bbo.io/User+Guide-zh.htm#UserGuide-zh-%E8%83%8C%E6%99%AF）

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

偶然之间，有发现据说“Git就是分布式版本控制系统”，为什么它是分布式的呢？

Git就是分布式版本控制系统，对应的是集中式的版本控制如SVN。简单的说，分布式的版本控制就是每个人都可以创建一个独立的代码仓库用于管理，各种版本控制的操作都可以在本地完成。每个人修改的代码都可以推送合并到另外一个代码仓库中。而像SVN这样，只有一个中央控制，所有的开发人员都必须依赖于这个代码仓库。每次版本控制的操作也必须链接到服务器才能完成。很多公司喜欢用集中式的版本控制是为了更好的控制代码。如果个人开发，就可以选择Git这种分布式的。

从一般开发者的角度来看，git有以下功能：

1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。
2、在自己的机器上根据不同的开发目的，创建分支，修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6、生成补丁（patch），把补丁发送给主开发者。
7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

看了分布式服务框架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://bbo.io/User+Guide-zh.htm#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
广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
通常用于通知所有提供者更新缓存或日志等本地资源信息。

负载均衡（http://bbo.io/User+Guide-zh.htm#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://en.wikipedia.org/wiki/Consistent_hashing。
缺省只对第一个参数Hash，如果要修改，请配置<bbo:parameter key="hash.arguments" value="0,1" />
缺省用160份虚拟节点，如果要修改，请配置<bbo:parameter key="hash.nodes" value="320" />

还有比较好奇它们是怎么通信的？

像早期版本的Elasticsearch的话，自动发现节点机制，ES是一个基于p2p的系统，它先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互。

而Dubbo是有个注册中心，它支持多个注册中心，但是推荐使用ZooKeeper。关于ZooKeeper可以自行了解，很多集群相关的框架都有使用到它。当然像Elasticsearch是自己有相应的机制实现的。