Redis怎么做集群

为什么集群？

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

方案

1Redis官方集群方案 Redis Cluster

Redis Cluster是一种服务器Sharding技术，30版本开始正式提供。

Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。

Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

Redis Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。

对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

Redis Cluster是Redis 30以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

2Redis Sharding集群

Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

Redis Sharding可以说是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。

庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

Jedis的Redis Sharding实现具有如下特点：

1 采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

2为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

3ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

NLB群集可以支持WEB、FTP、***、ISA。那么我们今天就简单做一下基于WEB服务的NLB群集两个节点的实验。NLB群集可以保证web服务的高可用性，windows server 2008操作系统可以支持32个NLB节点。所有节点都在同时提供服务，所以，当其中一台服务器宕机的时候，其他节点服务器依然在提供服务，因此，NLB服务可以保证高可用性。

实验环境：

如上图所示：左边的服务器，我们更改计算机名为：NODE-1、右边服务器的计算机名为NODE-2，NODE-1的ip地址为：19216811，NODE-2的ip地址为：19216812。每台服务器都配置为一块网卡，一个群集ip：1921681254供外网用户访问

实验步骤：

首先，我们搭建NLB群集的环境，所以，我们应该先在两台服务器上安装NLB群集服务。在NODE-1上：

在NODE-2上重复上述步骤。

以上步骤，我们将两个节点的计算机群集环境都安装成功，下面，我们在群集上安装web服务，在node1上：

添加必需的功能

在node-2上，重复上述操作即可，web安装ok，为了验证群集实验是否是连续提供服务，我们还需要在node-1和node-2上创建不同的站点（为了验证实验结果）。此步骤略。。。

到这里，我们群集环境和安装的web服务都已经ok了，下面，就需要我们进行配置群集服务了，以保证群集的高可用性和可靠性。

在NODE-1上：创建新群集

下一步，设置优先级别

下一步，设置群集ip;1921681254

下一步，由于我们群集节点只添加了一块网卡，所以，我们选择“多播”。（原因，在博客里有相应的文章，请仔细阅读。）

删除“端口规则”

下一步，等待群集“已聚合”

Ok，我们已经完成了一个节点的配置，下面我们仍然在NODE-1上添加NODE-2群集

在NODE-1上：选择“添加主机到群集”

通过NODE-2的网卡ip地址连接到NODE-2上：

下一步，设置优先级别：

删除端口规则

两个节点主机全部聚合，此刻，NLB群集配置我们都已经完成了。下面我们进行测试，在client主机的IE输入群集ip进行访问，客户端client的ip地址是1921681100，首先在客户端client上ping群集的ip：1921681254

根据上图所示，客户机client和群集ip是通信的。然后我们再通过http://1921681254来访问web

默认情况下，node-1在提供服务，当我们将node-1模拟宕机后，我们再进行测试

Ok，测试已成功！！！

在实际应用中，如果网站的访问量很大，为了提高访问速度，可以与多个Tomcat服务器与Apache服务器集成，让他们共同运行servlet/jsp组件的任务，多个Tomcat服务器构成了一个集群（Cluster）系统，共同为客户提供服务。集群系统具有以下优点：

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

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

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

原理：JK插件的负载均衡器根据在workerproperties中配置的lbfactor（负载平衡因数），负责为集群系统中的Tomcat服务器分配工作负荷，以实现负载平衡。每个Tomcat服务器间用集群管理器（SimpleTcpCluster）进行通信，以实现HTTP回话的复制，比如Session。

下面我们在一台机器上配置一个Apache和两个Tomcat服务器集群：

2安装Apache，安装两个Tomcat，并把一个测试项目放到两个Tomcat的webapps目录下以便以后测试。

3把mod_jkso复制到<apache_home>/modules下。

4在<apache_home>/conf目录下创建：workersproperties文件：

"pln">worker "pun"> "pln">list "pun">= "pln"> worker1 "pun">, "pln">worker2 "pun">, "pln">loadbalancer         "com">#apache把Tomcat看成是工人，loadbalancer是负载均衡器

workerworker1host=localhost        #Tomcat worker1服务器

workerworker1port=8009            #Tomcat端口

workerworker1type=ajp13            #协议

workerworker1lbfactor=100            #负载平衡因数

workerworker2host=localhost        #Tomcat worker2服务器

workerworker2port=8009            #因为在一台机器上所以端口不能一样

workerworker2type=ajp13            #协议

workerworker2lbfactor=100            #设为一样代表两台机器的负载相同

workerloadbalancertype=1b

workerloadbalancerbalanced_workers=worker1,worker2

workerloadbalancersticky_seesion=false

workerloadbalancersticky_session_force=false

说明：1workerloadbalancersticky_seesion如果设为true则说明会话具有“粘性”，也就是如果一个用户在一个Tomcat中建立了会话后则此后这个用户的所有操做都由这个Tomcat服务器承担。集群系统不会进行会话复制。如果设为false则下面的 sticky_session_force无意义。

2sticky_session_force：假设sticky_session设为true，用户会话具有了粘性，当当前Tomcat服务器停止服务后，如果sticky_session_force为true也就是强制会话与当前Tomcat关联，那么会报500错误，如果设为false则会转到另外的Tomcat服务器。

5修改<apache_home>/conf/httpdconf文件，在文件后面加上：

"com">#Tomcat集群配置

"com">LoadModule jk_module modules/mod_jkso

JkWorkersFile conf/workersproperties

#我的工人们

JkLogFile logs/mod_jklog            

#日志文件

JkLogLevel debug                     

#tomcat运行模式

JkMount /jsp loadbalancer          

#收到jsp结尾的文件交给负载均衡器处理

JkMount /helloapp/ loadbalancer     

#收到helloapp/路径交给负载均衡器处理

6修改两个Tomcat的conf/servicexml文件。

61首先要修改AJP端口，确保他们与workersproperties中配置的一样

例如按我们上面的配置，只需要把Tomcat2中的AJP端口该为8109即可。

62此外在使用了loadbalancer后，要求worker的名字与Tomcat的servicexml中的Engine元素的jvmRoute属性一致，

例如worker1修改为： <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker1">

63另外，如果两台Tomcat服务器装在一台机器上，必须确保他们的端口没有冲突，Tomcat中一共配置了三个端口：

<Server port="8005" shutdown="SHUTDOWN">

<Connector port="8080" />

<Connector port="8109" protocol="AJP/13" redirectPort="8443" />

把其中一个该了让它们不一样就行了。

完成了以上步骤我们的集群算是基本完成了，打开Apache和两个Tomcat 浏览器进入：localhost/demo/ 能够正确访问。

为了测试，我们写一个jsp文件：testjsp

"tag"><html>

<head>

<title>test</title>

</head>

<body>

    <%

        Systemoutprintfln("call testjsp");

    %>

    session:<%=sessiongetId() %>

</body></html>

把它放到两个Tomcat中的demo项目中，浏览器访问这个页面，每次访问只在一个Tomcat控制台打印语句。

然而页面中的Session Id是会变的。这种情况下如果一个用户正在访问时，如果跳到另一个Tomcat服务器，那么他的session就没有了，可能导致错误。

7配置集群管理器

如果读者对HttpSession有了解应该知道，用户的会话状态保存在session中，一个浏览器访问多个网页它们的请求始终处于一个会话范围中，因此SessionID应该是不变的。

以上我们看到的浏览器中的SessionID不同，因为转到另一个Tomcat后当前会话就结束了，又在另一个服务器上开启了一个新的会话。那么怎么让多个Tomcat服务器共享一个会话呢

为了解决上述问题，我们启用Tomcat的集群管理器（SimpleTcpCluster）：

71修改Tomcat1和Tomcat2的servletxml文件，在Engine元素中加入以下Cluster元素

"tag"><Cluster "pln">  "atn">className "pun">= "atv">"orgapachecatalinahatcpSimpleTcpCluster"

            channelSendOptions="8">

        <Manager className="orgapachecatalinahasessionDeltaManager"

        expireSessionsOnShutdown="false"

        notifyListenersOnReplication="true"/>

        <Channel className="orgapachecatalinatribesgroupGroupChannel">

            <Membership className="orgapachecatalinatribesmembershipMcastService"

                        bind="127001"

                        address="228004"

                        port="45564"

                        frequency="500"

                        dropTime="3000"/>    

            <Receiver className="orgapachecatalinatribestransportnioNioReceiver"

                      address="auto"

                      port="4000"

                      autoBind="100"

                      selectorTimeout="5000"

                      maxThreads="6"/>

            <Sender className="orgapachecatalinatribestransportReplicationTransmitter">

                <Transport className="orgapachecatalinatribestransportnioPooledParallelSender"/>

            </Sender>

            <Interceptor className="orgapachecatalinatribesgroupinterceptorsTcpFailureDetector"/>

            <Interceptor className="orgapachecatalinatribesgroupinterceptorsMessageDispatch15Interceptor"/>

        </Channel>

        <Valve className="orgapachecatalinahatcpReplicationValve" filter=""/>

        <Valve className="orgapachecatalinahasessionJvmRouteBinderValve"/>

        <Deployer className="orgapachecatalinahadeployFarmWarDeployer"

                    tempDir="/tmp/war-temp/"

                    deployDir="/tmp/war-deploy/"

                    watchDir="/tmp/war-listen/"

                    watchEnabled="false"/>

        <ClusterListener className="orgapachecatalinahasessionJvmRouteSessionIDBinderListener"/>

        <ClusterListener className="orgapachecatalinahasessionClusterSessionListener"/>

        </Cluster> 

关于Cluster的相关介绍参照：<tomcat-home>\webapps\docs\cluster-howtohtml  <tomcat-home>\webapps\docs\config\clusterhtml

72分别修改Tomcat1和Tomcat2 demo项目的webxml文件，在后面加入<distributable>元素

"tag"><web-app>

"pln">

"tag"><distributable/>

</web-app>

如果一个web项目的webxml文件中指定了<distributable/>元素那么Tomcat服务器启动这个Web应用时，会为它创建由<Cluster>元素指定的会话管理器，这里我们用的是DeltaManager,他们把会话从一个Tomcat服务器复制到集群中另一个Tomcat服务器。

73重新启动两个Tomcat，发现Tomcat控制台还是依次打印出Call testjsp 页面中的SessionID却不变了。测试完成。

重要说明：(1)如果项目要发布到集群上，那么与会话有关的类需要实现javaioSerializable序列化接口。

(2)集群中Tomcat间用组播方式进行通信，如果机器上有多个网卡则可能导致组播失败，解决的办法是<Cluster>元素的<Membership>元素配置bind属性，它用于明确知道组播地址：

<Membership className="orgapachecatalinatribesmembershipMcastService" bind="127001"/>

(3)如果集群较小，可以采用DeltaManager会话管理器，如果多的话建议使用BackupManager

(4)<Membership>的address设为"228004"，运行时须确保机器联网能访问到该地址，否则可能运行失败。

Docker最核心的特性之一，就是能够将任何应用包括Hadoop打包到Docker镜像中。这篇教程介绍了利用Docker在单机上快速搭建多

节点 Hadoop集群的详细步骤。作者在发现目前的Hadoop on 

Docker项目所存在的问题之后，开发了接近最小化的Hadoop镜像，并且支持快速搭建任意节点数的Hadoop集群。

一 项目简介

GitHub: kiwanlau/hadoop-cluster-docker

直接用机器搭建Hadoop集群是一个相当痛苦的过程，尤其对初学者来说。他们还没开始跑wordcount，可能就被这个问题折腾的体无完肤了。而且也不是每个人都有好几台机器对吧。你可以尝试用多个虚拟机搭建，前提是你有个性能杠杠的机器。

我的目标是将Hadoop集群运行在Docker容器中，使Hadoop开发者能够快速便捷地在本机搭建多节点的Hadoop集群。其实这个想法已

经有了不少实现，但是都不是很理想，他们或者镜像太大，或者使用太慢，或者使用了第三方工具使得使用起来过于复杂。下表为一些已知的Hadoop on 

Docker项目以及其存在的问题。

我的项目参考了alvinhenrick/hadoop-mutinode项目，不过我做了大量的优化和重构。alvinhenrick/hadoop-mutinode项目的GitHub主页以及作者所写的博客地址如下：

GitHub：Hadoop (YARN) Multinode Cluster with Docker

博客：Hadoop (YARN) Multinode Cluster with Docker

下面两个表是alvinhenrick/hadoop-mutinode项目与我的kiwenlau/hadoop-cluster-docker项目的参数对比：

可知，我主要优化了这样几点：

更小的镜像大小

更快的构造时间

更少的镜像层数

更快更方便地改变Hadoop集群节点数目

另外，alvinhenrick/hadoop-mutinode项目增加节点时需要手动修改Hadoop配置文件然后重新构建hadoop-

nn-dn 

镜像,然后修改容器启动脚本，才能实现增加节点的功能。而我通过shell脚本实现自动话，不到1分钟可以重新构建hadoop-master镜像，然后

立即运行!本项目默认启动3个节点的Hadoop集群，支持任意节点数的Hadoop集群。

另外，启动Hadoop，运行wordcount以及重新构建镜像都采用了shell脚本实现自动化。这样使得整个项目的使用以及开发都变得非常方便快捷。

开发测试环境

操作系统：ubuntu 1404 和 ubuntu 1204

内核版本: 3130-32-generic

Docker版本：150 和162

小伙伴们，硬盘不够，内存不够，尤其是内核版本过低会导致运行失败。

二 镜像简介

本项目一共开发了4个镜像：

serf-dnsmasq

hadoop-base

hadoop-master

hadoop-slave

serf-dnsmasq镜像

基于ubuntu:1504 (选它是因为它最小，不是因为它最新)

安装serf: serf是一个分布式的机器节点管理工具。它可以动态地发现所有Hadoop集群节点。

安装dnsmasq: dnsmasq作为轻量级的DNS服务器。它可以为Hadoop集群提供域名解析服务。

容器启动时，master节点的IP会传给所有slave节点。serf会在container启动后立即启动。slave节点上的serf 

agent会马上发现master节点(master 

IP它们都知道嘛)，master节点就马上发现了所有slave节点。然后它们之间通过互相交换信息，所有节点就能知道其他所有节点的存在了。

(Everyone will know 

Everyone)。serf发现新的节点时，就会重新配置dnsmasq，然后重启dnsmasq。所以dnsmasq就能够解析集群的所有节点的域名

啦。这个过程随着节点的增加会耗时更久，因此，若配置的Hadoop节点比较多，则在启动容器后需要测试serf是否发现了所有节点，DNS是否能够解析

所有节点域名。稍等片刻才能启动Hadoop。这个解决方案是由SequenceIQ公司提出的，该公司专注于将Hadoop运行在Docker中。参考

这个演讲稿。

hadoop-base镜像

基于serf-dnsmasq镜像

安装JDK(OpenJDK)

安装openssh-server，配置无密码SSH

安装vim：介样就可以愉快地在容器中敲代码了

安装Hadoop 230: 安装编译过的Hadoop(252， 260， 270 都比230大，所以我懒得升级了)

另外，编译Hadoop的步骤请参考我的博客。

如果需要重新开发我的hadoop-base, 需要下载编译过的hadoop-230安装包，放到hadoop-cluster-docker/hadoop-base/files目录内。我编译的64位hadoop-230下载地址：

另外，我还编译了64位的Hadoop 252、260,、270, 其下载地址如下：

hadoop-230: 

hadoop-252: 

hadoop-260:

hadoop-270: 

hadoop-master镜像

基于hadoop-base镜像

配置hadoop的master节点

格式化namenode

这一步需要配置slaves文件，而slaves文件需要列出所有节点的域名或者IP。因此，Hadoop节点数目不同时，slaves文件自然也

不一样。因此，更改Hadoop集群节点数目时，需要修改slaves文件然后重新构建hadoop-master镜像。我编写了一个resize- 

clustersh脚本自动化这一过程。仅需给定节点数目作为脚本参数就可以轻松实现Hadoop集群节点数目的更改。由于hadoop-master

 镜像仅仅做一些配置工作，也无需下载任何文件，整个过程非常快，1分钟就足够了。

hadoop-slave镜像

基于hadoop-base镜像

配置hadoop的slave节点

镜像大小分析

下表为sudo docker images的运行结果：

易知以下几个结论：

serf-dnsmasq镜像在ubuntu:1504镜像的基础上增加了754MB

hadoop-base镜像在serf-dnsmasq镜像的基础上增加了5707MB

hadoop-master和hadoop-slave镜像在hadoop-base镜像的基础上大小几乎没有增加

下表为sudo docker history indexalaudacn/kiwenlau/hadoop-base:010的部分运行结果

可知：

基础镜像ubuntu:1504为1313MB

安装OpenJDK需要3246MB

安装Hadoop需要1585MB

Ubuntu、OpenJDK与Hadoop均为镜像所必须，三者一共占了6144MB

因此，我所开发的hadoop镜像以及接近最小，优化空间已经很小了。

三 3节点Hadoop集群搭建步骤

1 拉取镜像

sudo docker pull indexalaudacn/kiwenlau/hadoop-master:010  sudo docker pull indexalaudacn/kiwenlau/hadoop-slave:010  sudo docker pull indexalaudacn/kiwenlau/hadoop-base:010  sudo docker pull indexalaudacn/kiwenlau/serf-dnsmasq:010 

3~5分钟OK~也可以直接从我的DokcerHub仓库中拉取镜像，这样就可以跳过第2步：

sudo docker pull kiwenlau/hadoop-master:010  sudo docker pull kiwenlau/hadoop-slave:010  sudo docker pull kiwenlau/hadoop-base:010  sudo docker pull kiwenlau/serf-dnsmasq:010 

查看下载的镜像：

sudo docker images 

运行结果：

其中hadoop-base镜像是基于serf-dnsmasq镜像的，hadoop-slave镜像和hadoop-master镜像都是基于hadoop-base镜像。所以其实4个镜像一共也就7774MB。

2 修改镜像tag

sudo docker tag d63869855c03 kiwenlau/hadoop-slave:010  sudo docker tag 7c9d32ede450 kiwenlau/hadoop-master:010  sudo docker tag 5571bd5de58e kiwenlau/hadoop-base:010  sudo docker tag 09ed89c24ee8 kiwenlau/serf-dnsmasq:010 

查看修改tag后镜像：

sudo docker images 

运行结果：

之所以要修改镜像，是因为我默认是将镜像上传到Dockerhub, 

因此Dokerfile以及shell脚本中得镜像名称都是没有alauada前缀的，sorry for 

this不过改tag还是很快滴。若直接下载我在DockerHub中的镜像，自然就不需要修改tag不过Alauda镜像下载速度很快的

哈~

3下载源代码

git clone https://githubcom/kiwenlau/hadoop-cluster-docker

为了防止GitHub被XX，我把代码导入到了开源中国的Git仓库：

git clone http://gitoschinanet/kiwenlau/hadoop-cluster-docker

4 运行容器

cd hadoop-cluster-docker  /start-containersh 

运行结果：

start master container  start slave1 container  start slave2 container  root@master:~# 

一共开启了3个容器，1个master, 2个slave。开启容器后就进入了master容器root用户的根目录(/root)。

查看master的root用户家目录的文件：

ls

运行结果：

hdfs run-wordcountsh serf_log start-hadoopsh start-ssh-serfsh 

start-hadoopsh是开启hadoop的shell脚本，run-wordcountsh是运行wordcount的shell脚本，可以测试镜像是否正常工作。

5测试容器是否正常启动(此时已进入master容器)

查看hadoop集群成员：

serf members 

运行结果：

masterkiwenlaucom 17217065:7946 alive  slave1kiwenlaucom 17217066:7946 alive  slave2kiwenlaucom 17217067:7946 alive 

若结果缺少节点，可以稍等片刻，再执行“serf members”命令。因为serf agent需要时间发现所有节点。

测试ssh：

ssh slave2kiwenlaucom 

运行结果：

Warning: Permanently added 'slave2kiwenlaucom,17217067' (ECDSA) to the list of known hosts  Welcome to Ubuntu 1504 (GNU/Linux 3130-53-generic x86_64)   Documentation: https://helpubuntucom/  The programs included with the Ubuntu system are free software;  the exact distribution terms for each program are described in the  individual files in /usr/share/doc//copyright  Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by  applicable law  root@slave2:~# 

退出slave2：

exit 

运行结果：

logout  Connection to slave2kiwenlaucom closed 

若ssh失败，请稍等片刻再测试，因为dnsmasq的dns服务器启动需要时间。测试成功后，就可以开启Hadoop集群了!其实你也可以不进行测试，开启容器后耐心等待一分钟即可!

6 开启Hadoop

/start-hadoopsh 

上一步ssh到slave2之后，请记得回到master啊!运行结果太多，忽略，Hadoop的启动速度取决于机器性能

7 运行wordcount

/run-wordcountsh 

运行结果：

input file1txt:  Hello Hadoop  input file2txt:  Hello Docker  wordcount output:  Docker 1  Hadoop 1  Hello 2 

wordcount的执行速度取决于机器性能

四 N节点Hadoop集群搭建步骤

1 准备工作

参考第二部分1~3：下载镜像，修改tag，下载源代码

注意，你可以不下载serf-dnsmasq，但是请最好下载hadoop-base，因为hadoop-master是基于hadoop-base构建的。

2 重新构建hadoop-master镜像

/resize-clustersh 5 

不要担心，1分钟就能搞定

你可以为resize-clustersh脚本设不同的正整数作为参数数1, 2, 3, 4, 5, 6

3 启动容器

/start-containersh 5 

你可以为resize-clustersh脚本设不同的正整数作为参数数1, 2, 3, 4, 5, 6

这个参数呢，最好还是得和上一步的参数一致:)

这个参数如果比上一步的参数大，你多启动的节点，Hadoop不认识它们

这个参数如果比上一步的参数小，Hadoop觉得少启动的节点挂掉了

4 测试工作

参考第三部分5~7：测试容器，开启Hadoop，运行wordcount

请注意，若节点增加，请务必先测试容器，然后再开启Hadoop, 因为serf可能还没有发现所有节点，而dnsmasq的DNS服务器表示还没有配置好服务

市面上存在两种数据库负载均衡的思路：1

基于数据库连接的负载均衡：例如总共有100个数据库连接，50个连接登录到数据库机器A，另外50个连接登录到数据库机器B，这样每个连接中接下来的所有请求全都是发往同一台数据库机器的

这种数据库负载均衡的思路模拟了WEB上的负载均衡方法，但是由于WEB连接是短时间连接(连接建立后，获取需要的HTML等资源后，连接马上被关闭)，而数据库连接是长时间连接(连接建立后，可长时间保持，客户可不停向数据库发送SQL请求，数据库做出回答，如此不断循环直到连接被人为或因错而断开为止)，因此这种数据库负载均衡思路存在着明显的缺点：有可能会发生绝大部分的请求压力都集中到某台数据库机器上去，从而使得负载均衡效果失效

2

基于批处理请求的负载均衡：在建立数据库连接的时候，会同时与每台数据库服务器建立连接，之后针对客户端的每次请求，都会根据负载均衡算法，独立地选出某个数据库节点来执行这个请求

此种思路符合数据库长时间连接的特征，不存在上面所述的基于连接的负载均衡方法的缺点

市面上的负载均衡厂商，既有基于连接的，也有基于批处理请求的，用户需仔细辨别才能找到自己想要的合适产品

linux服务器集群平台的搭建比较简单，有专门的均衡软件，比如lvs，lvs是一个集群系统，由很多服务器组成，可以根据需要，把它门分为三层，一层是前端机，用于均衡，相当于公平为系统分配工作，二层是服务器群，比如web服务器群，DNS，mail群等，这些就是接待员，把均衡器分配的工作进行处理，第三层是存储设备，用于存储数据，相当于档案库。

知道这些后，要搭建就非常容易，有现成的软件，比如我有四台web服务器，2台数据库，1台前置机 ，安装linux系统，安装lvs软件，比如

heartbeat-214-9el5i386rpm

heartbeat-ldirectord-214-9el5i386rpm

libnet-114-3el5i386rpm

heartbeat-devel-214-9el5i386rpm

heartbeat-pils-214-10el5i386rpm

perl-MailTools-177-1el5noarchrpm

heartbeat-gui-214-9el5i386rpm

heartbeat-stonith-214-10el5i386rpm

当然还需要配置，你可以自己百度有关lvs集群的详细安装说明。希望能帮助你。

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。