zookeeper集群

监控zookeeper来自网上，大家一搜就可搜到了，只是zabbix版本和zookeeper有点出入，自行修改一下就可以了。 zookeeper监控要点 系统监控 这个监控linux系统以及修改linux服务器参数即可 内存使用量 ZooKeeper应当完全运行在内存中，不能使用到SWAP。Java Heap大小不能超过可用内存。 Swap使用量 使用Swap会降低ZooKeeper的性能，设置vm.swappiness = 0 网络带宽占用 如果发现ZooKeeper性能降低关注下网络带宽占用情况和丢包情况，通常情况下ZooKeeper是20%写入80%读入 磁盘使用量 ZooKeeper数据目录使用情况需要注意 磁盘I/O ZooKeeper的磁盘写入是异步的，所以不会存在很大的I/O请求，如果ZooKeeper和其他I/O密集型服务公用应该关注下磁盘I/O情况 ZooKeeper监控 zk_avg/min/max_latency 响应一个客户端请求的时间，建议这个时间大于10个Tick就报警 平均延迟/最小延迟/最大延迟 zk_outstanding_requests 排队请求的数量，当ZooKeeper超过了它的处理能力时，这个值会增大，建议设置报警阀值为10 堆积请求数 zk_packets_received 接收到客户端请求的包数量 收包数 zk_packets

Zookeeper 由 Apache Hadoop 的 Zookeeper 子项目发展而来，Google Chubby的一个开源实现。它是一个分布式应用程序协调服务，提供的功能包括：配置管理，名字服务，提供分布式同步、队列管理、集群管理等。 从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式。 Zookeeper有两种运行模式： 独立模式（standalone mode)：只运行在一台服务器上，适合测试环境。 复制模式（replicated mode)：运行于一个集群上，适合生产环境，这个计算机集群被称为一个“集合体”（ensemble） 复制模式的Zookeeper通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够保证服务继续。这跟Zookeeper的复制策略有关：Zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。 Zookeeper服务有两个角色，一个是leader，负责写服务和数据同步，剩下的是follower，提供读服务

一、Election接口 选举的父接口为Election，其定义了lookForLeader和shutdown两个方法，lookForLeader表示寻找Leader，shutdown则表示关闭，如关闭服务端之间的连接。 Election接口的实现类 1、AuthFastLeaderElection，同FastLeaderElection算法基本一致，只是在消息中加入了认证信息，在3.4.0版本后已经被弃用。 2、FastLeaderElection，是标准的fast paxos算法的实现，基于TCP协议进行选举。 3、LeaderElection，在3.4.0版本后已经被弃用。 FastLeaderElection分析 1、重要内部类 1、Notification类 Notification表示收到的选举投票信息（其他服务器发来的选举投票信息），其包含了投票中被选举者的服务器sid、zxid、选举周期epoch，选举者的服务器sid,状态，选周期epoch static public class Notification { /* * Format version, introduced in 3.4.6 */ public final static int CURRENTVERSION = 0x2; int version; /* * Proposed leader

环境：centos7 、JDK8 一、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 状态

1、 集群 win7 虚拟机网络配置为桥接模式 集群机器保持同个网段，能互通 2、 修改 ip 和主机名（虚拟机桌面版） : vi /etc/hosts 添加 ip 主机名： 192.168.10.190 master 192.168.10.191 slave1 192.168.10.192 slave2 vi /etc/hostname 修改为主机名 ，如 master 然后使配置文件生效 source /etc/sysconfig/network 重启机器 reboot 3 、新增用户及密码 useradd -p 密码 用户名 将用户添加到 root用户组下 usermod -g root hadoop01 4 、配置 ssh 下载： yum install openssh-server 开启 ssh服务 systemctl start sshd / service sshd start 查询状态 systemctl status sshd / service sshd status 配置开机启动： configure --level 2345 sshd on 测试下能否 ssh连接 5 、免密码登录 在 hadoop01用户下， cd /home/hadoop01 生成秘钥 ssh-keygen -t rsa 生成之后会在用户的根目录生成一个 “.ssh”的文件夹 ls

微服务的一般架构图： 架构图 使用dubbo+zookeeper实现简化的微服务架构 dubbo是一个分布式服务框架，是阿里巴巴SOA服务化治理方案的核心框架。zookeeper是一个开源的分布式协调服务，是由雅虎创建的，基于google chubby。 zookeeper能做什么 1.数据的发布/订阅（配置中心:disconf） 2.命名服务 3.master选举(kafka、hadoop、hbase) 4.分布式队列 5.分布式锁 zookeeper特性 1.顺序一致性 从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中 2.原子性 所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、 要么全都不应用 3.可靠性 一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的 4.实时性 一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时） zookeeper可以作为dubbo服务的注册中心，两者结合起来可以实现微服务中的 服务注册、发现、负载均衡和健康检查，容错，动态配置管理的功能。 zk配置说明 zoo.cfg配置文件分析 tickTime=2000

无论是公司的生产环境，还是自己搭建的测试环境，Zookeeper集群的节点个数都是奇数个。至于为什么要是奇数个，以前只是模糊的知道是为了满足选举需要，并不知道详细的原因。最近重点学习zookeeper，了解到其中的原理，现将其整理记录下来。 首先需要明确zookeeper选举的规则：leader选举，要求 可用节点数量 > 总节点数量/2 。注意 是 > , 不是 ≥。 注：为什么规则要求 可用节点数量 > 集群总结点数量/2 ？ 如果不这样限制，在集群出现脑裂的时候，可能会出现多个子集群同时服务的情况（即子集群各组选举出自己的leader）， 这样对整个zookeeper集群来说是紊乱的。 换句话说，如果遵守上述规则进行选举，即使出现脑裂，集群最多也只能回出现一个子集群可以提供服务的情况（能满足节点数量> 总结点数量/2 的子集群最多只会有一个）。所以要限制 可用节点数量 > 集群总结点数量/2 。 采用奇数个的节点主要是出于两方面的考虑： 1、防止由脑裂造成的集群不可用。 首先，什么是脑裂？集群的脑裂通常是发生在节点之间通信不可达的情况下，集群会分裂成不同的小集群，小集群各自选出自己的master节点，导致原有的集群出现多个master节点的情况，这就是脑裂。 下面举例说一下为什么采用奇数台节点，就可以防止由于脑裂造成的服务不可用： (1) 假如zookeeper集群有 5

本文借鉴http://www.cnblogs.com/guozhen/p/5984915.html，在此基础上进行了完善，使之成为一个完整版的伪分布式部署说明，在此记录一下！ 一、本文目的 介绍如何在同一台虚拟机上搭建高可用的Activemq服务，集群数量包含3个Activemq，当Activemq可用数>=2时，整个集群可用。 本文Activemq的集群数量为3个，分别命名为mq1，mq2，mq3 二、概念介绍 1、伪集群 集群搭建在同一台虚拟机上，3个Activemq分别使用不同的端口提供服务，启用1个为Master，其它2个为Slaver，同一时间仅Master队列提供服务 2、高可用 3个Activemq服务,同一时间仅Master队列提供服务，当Master队列挂掉后，其它2个Slaver自动选举出1个成为Master，整个队列服务依然可用。当挂掉的队列重新恢复后，自动加入集群。当集群仅剩下1个队列时，整个队列不可用。 3、Activemq集群数据存储方式 a) kahaDB：文件共享，默认方式 b) JDBC：数据库共享 c) LevelDB：数据共享， 本文使用方式 三、Activemq伪集群的搭建 下载地址： http://download.csdn.net/detail/u010821757/9771407 （ zookeeper-3.4.9 ） 　　　　

ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。 ZooKeeper基本原理 1. 数据模型 如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类似，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的， 工控机 子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章《说说Zookeeper中的ACL》。 2.重要概念 2.1 ZNode

kafka自带sh脚本使用示例： （1）启动/关闭kafka服务： ```shell nohup env JMX_PORT=9999 /path/to/kafka_2.10-0.8.2.2/bin/kafka-server-start.sh config/server.properties >/dev/null 2>&1 & /path/to/kafka_2.10-0.8.2.2/bin/zookeeper-server-stop.sh config/zookeeper.properties >/dev/null 2>&1 & ``` （2）创建topic /path/to/kafka_2.10-0.8.2.2/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test 查看topic列表 /path/to/kafka_2.10-0.8.2.2/bin/kafka-topics.sh --list --zookeeper localhost:2181 （3）发送msg /path/to/kafka_2.10-0.8.2.2/bin/kafka-console-producer.sh --broker-list localhost