集群服务器

　　rabbitmq作为企业级的消息队列，功能很齐全，既可以作为单一的部署模式，又可以做集群的部署模式 　　单一部署就不说了，就是在一台服务器上部署rabbitmq消息队列，可以参考我的博客： Ubuntu16.04下，erlang安装和rabbitmq安装步骤 去安装部署 　　集群部署有好几种方式，具体使用哪一种，要根据自己的需求而定，这里主要介绍一下普通集群和镜像集群 　　普通模式 　　普通模式是集群的默认模式，集群中各个节点拥有相同的队列结构，但是队列的消息实体已保存在其中一个节点，当消费者consumer连接集群中的某个节点时，会通过集群内部通信，将消息传到当前节点，再防御给消费者consumer，举个例子： 　　假设集群中有两个节点（A和B），当生产者producer将消息发布在A上，且消息实体保存在A上 时 ，但是A和B有相同的队列结构，当消费者 consumer 连接到B时，B会临时的从A拉去消息，然后再返回给消费者。 　　普通集群模式的部署，我们准备了三台测试服务器，IP分别是192.168.209.133， 192.168.209.134， 192.168.209.135，它们的hostname分别是test1，test2，test3， 　　然后分别安装rabbitmq，可以参考我的博客： Ubuntu16.04下，erlang安装和rabbitmq安装步骤

1、Sentinel 哨兵 　　　　Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。 　　　　例如： 　　　　 　　　　在Server1 掉线后： 　　　　升级Server2 为新的主服务器： 　　 2、Redis 主从分离 　在讲解Sentinel 哨兵集群之前，我们先来搭建一个简单的主从分离（读写分离）。 首先，我们默认大家都已经安装了redis，然后我们将 redis.conf 拷贝多份，并且创建多个目录，用于区分多个redis 服务： 　　　 　这里面，每个目录中都有自己的redis.conf 配置文件，接下来，我们先设置主服务器的配置文件。 一、配置Master 1、修改端口 # Accept connections on the specified port, default is 6379 (IANA #815344). # If port 0 is specified Redis will not listen on a TCP socket. port 6380 　　redis 的默认端口是6379，这里我们把主服务器的端口设置为6380

之前我们在搭建hadoop分布式环境的时候用到过Zookeeper注册hadoop服务。那么到底Zookeeper在分布式环境中发挥了什么作用呢，这次我们就来讨论这个问题。 在分布式系统中通常都会有多台机器构成一个集群来对外提供服务，对外来说有几台机器在提供服务它并不关心，那么对内而言组成集群的机器如何互相协调保持一致这是个问题。Zookeeper将提供这样的一个功能–分布式协调技术。 1. Zookerrper概述 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。 ZooKeeper性能上的特点决定了它能够用在大型的、分布式的系统当中。从可靠性方面来说，它并不会因为一个节点的错误而崩溃。除此之外，它严格的序列访问控制意味着复杂的控制原语可以应用在客户端上。ZooKeeper在一致性、可用性、容错性的保证，也是ZooKeeper的成功之处，它获得的一切成功都与它采用的协议——Zab协议是密不可分的。 ZooKeeper在实现这些服务时，首先它设计一种新的数据结构——Znode，然后在该数据结构的基础上定义了一些原语，也就是一些关于该数据结构的一些操作

1：下载Nginx http://nginx.org/en/download.html 选中稳定版 2：解压，打开E:\nginx-1.14.0\conf中 nginx.conf文件 #user nobody; worker_processes 4; #工作进程的个数，一般与计算机的cpu核数一致 #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { #允许最大连接数;最大连接数 = 连接数 * 进程数 worker_connections 1024; } http { include mime.types; #文件扩展名与文件类型映射表 default_type application/octet-stream; #默认文件类型 #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs

准备工作 1、 四台已安装windows server 2008 r2 系统的虚拟机，配置如下： CPU : 1核 MEMORY : 2GB DISK : 40GB(未分区) NetAdapter : 2块 2、 网卡设置： 本地连接：外网IP（由于虚拟机本身处于内网网段，192.168.1.2-192.168.1.255，在此我们把当前内网视为外网公开的IP）。 PC01：192.168.1.241 (域主机) PC02：192.168.1.242 (集群主节点) PC03：192.168.1.243 (集群辅助节点) PC04：192.168.1.244 (集群辅助节点) 本地连接2：域内网IP。这里设置为192.168.10.1 PC01：192.168.10.1 (域主机) PC02：192.168.10.2 (集群主节点) PC03：192.168.10.3 (集群辅助节点) PC04：192.168.10.4 (集群辅助节点) 3、 虚拟机默认安装只有一块网卡，以下演示添加网卡： 注意：此时两块网卡都处于NAT模式，在此我将第一个网络适配器的网络连接模式改为桥连接，目的是为了与我物理机所处的内网电脑进行交互。 安装域控制器和配置域 安装域控制器 在IP：192.168.1.241这台虚拟机上建立域控制器 注意：在未配置固定IP时，无法安装有效的域控制器

1. Nginx负载均衡高可用 　　首先介绍一下Keepalived，它是一个高性能的服务器高可用或热备解决方案，Keepalived主要来防止服务器单点故障的发生问题，可以通过其与Nginx的配合实现web服务端的高可用。 Keepalived以VRRP协议为实现基础，用VRRP协议来实现高可用性（HA）.VRRP (Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP（一个或多个），如下图所示： 这张图的意思是，我们使用keepalived来管理两台设备的Nginx，并虚拟出一个IP，我们现在两台装有Nginx的设备分别是192.168.101.3和192.168.101.4，那么我们可以虚拟出一个192.168.156.xx的IP，外界请求直接访问虚拟IP而不是真正的Nginx，让虚拟IP去访问提供服务的Nginx（注意：高可用是指同一时间提供服务的只有一台设备，提供服务的设备挂掉之后，备份服务器便开始提供服务），然后再由Nginx去访问tomcat。 要实现nginx的高可用，需要实现 备份机 。 我们拿两台虚拟机来搭建nginx高可用环境，这两台设备分别是192.168.101.3（主机名是nginx1）和192.168.101.4

1. Nginx负载均衡高可用 首先介绍一下Keepalived，它是一个高性能的服务器高可用或热备解决方案，Keepalived主要来防止服务器单点故障的发生问题，可以通过其与Nginx的配合实现web服务端的高可用。 Keepalived以VRRP协议为实现基础，用VRRP协议来实现高可用性（HA）.VRRP (Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP（一个或多个），如下图所示： 这张图的意思是，我们使用keepalived来管理两台设备的Nginx，并虚拟出一个IP，我们现在两台装有Nginx的设备分别是192.168.101.3和192.168.101.4，那么我们可以虚拟出一个192.168.156.xx的IP，外界请求直接访问虚拟IP而不是真正的Nginx，让虚拟IP去访问提供服务的Nginx（注意：高可用是指同一时间提供服务的只有一台设备，提供服务的设备挂掉之后，备份服务器便开始提供服务），然后再由Nginx去访问tomcat。 要实现nginx的高可用，需要实现备份机。 我们拿两台虚拟机来搭建nginx高可用环境，这两台设备分别是192.168.101.3（主机名是nginx1）和192.168.101.4（主机名是nginx2）。

由于公司缓存方案改进，准备采用codis集群作为主要的缓存解决方案（codis：国内豌豆荚开发的redis集群解决方案，已开源，github地址：https://github.com/CodisLabs/codis），codis集群依赖于zookeeper集群，本文介绍zookeeper集群的实现。 一、Zookeeper原理简介 ZooKeeper是一个开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 Zookeeper设计目的 最终一致性：client不论连接到那个Server，展示给它的都是同一个视图。 可靠性：具有简单、健壮、良好的性能、如果消息m被到一台服务器接收，那么消息m将被所有服务器接收。 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。 原子性：更新只能成功或者失败，没有中间状态。 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布

一、Zookeeper原理简介 ZooKeeper是一个开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 Zookeeper设计目的 最终一致性：client不论连接到那个Server，展示给它的都是同一个视图。 可靠性：具有简单、健壮、良好的性能、如果消息m被到一台服务器接收，那么消息m将被所有服务器接收。 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。 原子性：更新只能成功或者失败，没有中间状态。 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。 Zookeeper工作原理 1、在zookeeper的集群中，各个节点共有下面3种角色和4种状态： 角色：leader,follower,observer 状态：leading

Apache Kafka是一个分布式消息发布订阅系统，而Kafka环境往往是在集群中配置的。本篇就对配置3个broker的Kafka集群进行介绍。 Zookeeper集群 Kafka本身提供了启动了zookeeper的脚本和配置文件。 1. 修改配置文件 进入kafka主目录，编辑文件config/zookeeper.properties，配置如下： tickTime=2000 #心跳时间，毫秒 initLimit=5 #Follower在启动是需要在5个心跳时间内从Leader同步数据 syncLimit=2 #超过两个心跳时间收不到Follower的效应，就认为此Follower已经下线 #zookeeper集群的三个服务器 server.1=192.168.10.152:2888:3888 server.2=192.168.10.153:2888:3888 server.3=192.168.10.170:2888:3888 在三个机器进行同样得配置，或者将配置文件传到集群中其他机器上。 2. 配置主机标识 在三台机器dataDir目录(zookeeper.properties配置)下，新建文件myid，写入相应标识 echo 1 > /tmp/zookeeper/myid #1为标识，在其他机器上改为2或3 3. 启动Zookeeper集群