分布式应用现在已经越来越广泛,Spring Could也是一个不错的一站式解决方案,不过据我了解国内目前貌似使用阿里Dubbo的公司比较多,一方面这个框架也确实很OK,另一方面可能也是因为Dubbo的中文文档比较全的缘故,据Dubbo官网上的消息,阿里已经重新开始了对Dubbo的维护,这也算是使用Dubbo的互联网公司的福音了吧。OK,废话不多说,今天我们就先来看看如何在Linux上安装zookeeper。
了解过Dubbo的小伙伴都知道,Dubbo官方建议我们使用的注册中心就是zookeeper,zookeeper本来是Hadoop的一个子项目,现在发展成了Apache的顶级项目,看名字就知道Zookeeper就是动物园管理员,管理Hadoop(大象)、Hive(蜂房/蜜蜂)等动物。Apache上的Zookeeper分Linux版和Windows版,但是考虑到实际生产环境都是Linux,所以我们这里主要介绍Linux上Zookeeper的安装,Windows上Zookeeper的安装则比较简单,下载解压即可,和Tomcat差不多。
OK,废话不多说,接下来我们就来看看zookeeper的安装步骤。
环境:
1.VMware® Workstation 12 Pro
2.CentOS7
3.zookeeper-3.4.10(本文写作时的最新稳定版)
安装步骤
1.下载zookeeper
zookeeper下载地址如下,小伙伴们可以在第一个地址中选择适合自己的zookeeper版本,也可以直接点击第二个地址下载我们本文使用的zookeeper。
1.http://mirrors.hust.edu.cn/apache/zookeeper/
2.http://mirrors.hust.edu.cn/apache/zookeeper/zookeeper-3.4.10/zookeeper-3.4.10.tar.gz
2.将下载好的zookeeper上传到Linux服务器上
上传方式多种多样,我这里采用了xftp,小伙伴们也可以直接使用putty上传,上传结果如下:
3.将文件解压到/opt目录下
4.进入到刚刚解压好的目录中,创建两个文件夹,分别是data和logs,如下:
5.将解压后zookeeper-3.4.10文件夹下的zoo_sample.cfg文件拷贝一份命名为zoo.cfg,如下:
6.修改zoo.cfg文件,添加data和log目录,如下:
1.2888 端口号是zookeeper服务之间通信的端口
2.3888 是zookeeper 与其他应用程序通信的端口
3.initLimit:这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连接 Zookeeper服务器的客户端,而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10 个心跳的时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息,那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒。
4.syncLimit:这个配置项标识 Leader 与 Follower 之间发送消息,请求和应答时间长度,最长不能超过多少个 tickTime 的时间长度,总的时间长度就是 2*2000=4 秒
5.server.A=B:C:D:其中 A 是一个数字,表示这个是第几号服务器;B 是这个服务器的IP地址或/etc/hosts文件中映射了IP的主机名;C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口;D 表示的是万一集群中的 Leader 服务器挂了,需要一个端口来重新进行选举,选出一个新的 Leader,而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式,由于 B 都是一样,所以不同的 Zookeeper 实例通信端口号不能一样,所以要给它们分配不同的端口号。
7.在 dataDir=/opt/zookeeper-3.4.10/data下创建 myid文件 编辑myid文件,并在对应的IP的机器上输入对应的编号。如在zookeeper上,myid文件内容就是1。如果只在单点上进行安装配置,那么只有一个server.1。如下:
8.在.bash_profile文件中增加zookeeper配置:
9.使配置生效
10.关闭防火墙
11.启动并测试
启动之后如果能看到Mode:standalone就表示启动成功了。
12.关闭zookeeper
13.配置开机启动zookeeper
注意注意 在centos7中,/etc/rc.local的权限被降低了,所以需要执行如下命令赋予其可执行权限
chmod +x /etc/rc.d/rc.local
相关知识:
选举
Leader选举
选举原则就是比计较MYID、ZXID,这里我们以3台为例,其实2台也可以完成选举,但是通常集群规模最小是3台
服务器启动期间的选举
Server1 myid:1 zxid:0
Server2 myid:2 zxid:0
Server3 myid:3 zxid:0
每个服务器都会发出一条投票且都是投给自己,以Server1为例(1,0),把这个信息发送到集群中其他服务器上。当然它自己也会收到别人的投票信息
每个服务器收到其他服务器的投票,先会检查有效性包括检查是否是本轮投票以及是否来自LOOKING状态的服务器发出的
处理投票,首先比较ZXID,值最大的为Leader,如果值一样那么就比较myid,myid最大的为Leader,Server1会收到(1,0)(2,0)(3,0)经过比较自己的myid不是最大的,它会重新投票新的投票(3,0)并从新发到集群中去,对于Server2也一样,对于Server3来说它不用更新投票信息它比较后自己就是最大的所有再次发出投自己的票就可以。这样每个机器又会收到2个投票信息,Server1会收到Server2、3发来的(3,0)。
每次投票服务器都会进行投票统计,判断是否有超过半数机器相同的投票信息,对于这三台服务器来说最终投票结果是(3,0),那么除了Server3之外其他都会收到2张(3,0)的投票,这样在一个3台集群中超过半数投票是投给一个机器的,那么这个机器就是集群的Leader。
一旦确定了Leader那么就需要设置自己的角色以及改变自己的状态Leader变成LEADING,而Follower就变成FOLLOWING。
服务器运行期间的选举
当集群中的服务器数量发生变化时才会进行重新选举,比如之前的Leader故障或者新加入一台Zookeeper服务器。
我们假设上面的Leader Server3挂了,然后重新选举
Server1 myid:1 zxid:123
Server2 myid:2 zxid:122
Server3 myid:3 zxid: (宕机)
当集群感知到Leader挂了,那么所有Follower角色的服务器就转变状态从FOLLOWING变成LOOKING
每个服务器发出投票Server1会发出(1,123)到集群中,Server2会发出(2,122)到集群中,因为第一轮都是投自己。
集群中可用服务器收到投票
投票处理,这里和启动时候使用相同的原则,Server1投票不变因为它的ZXID比Server2的大,所以它再次发一个投自己的票,Server2发现自己的ZXID小所以更新投票信息(1,123)再次发出去
统计投票信息,最终Server1胜出成为Leader
改变服务器状态
负载均衡:
主要是三点:负载均衡算法,健康检查和会话保持
一般来说负载均衡设备都会默认支持多种负载均衡分发策略,例如:
Ø 轮询(RoundRobin)将请求顺序循环地发到每个服务器。当其中某个服务器发生故障,AX就把其从顺序循环队列中拿出,不参加下一次的轮询,直到其恢复正常。
Ø 比率(Ratio):给每个服务器分配一个加权值为比例,根椐这个比例,把用户的请求分配到每个服务器。当其中某个服务器发生故障,AX就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
Ø 优先权(Priority):给所有服务器分组,给每个组定义优先权,将用户的请求分配给优先级最高的服务器组(在同一组内,采用预先设定的轮询或比率算法,分配用户的请求);当最高优先级中所有服务器或者指定数量的服务器出现故障,AX将把请求送给次优先级的服务器组。这种方式,实际为用户提供一种热备份的方式。
Ø 最少连接数(LeastConnection):AX会记录当前每台服务器或者服务端口上的连接数,新的连接将传递给连接数最少的服务器。当其中某个服务器发生故障,AX就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
Ø 最快响应时间(Fast Reponse time):新的连接传递给那些响应最快的服务器。当其中某个服务器发生故障,AX就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
以上为通用的负载均衡算法,还有一些算法根据不同的需求也可能会用到,例如:
Ø 哈希算法( hash): 将客户端的源地址,端口进行哈希运算,根据运算的结果转发给一台服务器进行处理,当其中某个服务器发生故障,就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
Ø 基于策略的负载均衡:针对不同的数据流设置导向规则,用户可自行编辑流量分配策略,利用这些策略对通过的数据流实施导向控制。
Ø 基于数据包的内容分发:例如判断HTTP的URL,如果URL中带有.jpg的扩展名,就把数据包转发到指定的服务器。