zookeeper集群

Kafka的集群配置 一般有 三种方法 ，即 （1）Single node – single broker集群； （2）Single node – multiple broker集群； （3）Multiple node – multiple broker集群。 前两种方法官网上有配置过程（ （1）（2）配置方法官网教程 ），下面会简单介绍前两种方法，主要介绍最后一种方法。 准备工作： 1.Kafka的压缩包，这里选用的是 kafka_2.10-0.8.2.2.tgz 。 2.三台CentOS 6.4 64位虚拟机。分别是192.168.121.34(主机名为master)、192.168.121.35(主机名为datanode1)、192.168.121.36(主 机名为datanode2)。 一、Single node – single broker集群配置（单节点单boker集群配置） 注：图片来源自网络 1.解压Kafka的压缩包 [root @master kafkainstall]# tar -xzf kafka_2.10-0.8.2.0.tgz [root @master kafkainstall]# cd kafka_2.10-0.8.2.2 这里我新建了一个kafkainstall文件夹来存放加压后的文件，然后进入解压后的kafka_2.10-0.8.2.2文件夹。

关于集群中的"脑裂"问题，之前已经 在这里 详细介绍过，下面重点说下Zookeeper脑裂问题的处理办法。脑裂通常会出现在集群环境中，比如ElasticSearch、Zookeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如ElasticSearch集群中有Master节点，Zookeeper集群中有Leader节点。 一、zookeeper 集群的节点为什么要部署成奇数 zookeeper容错指的是：当宕掉几个zookeeper节点服务器之后，剩下的个数必须大于宕掉的个数，也就是剩下的节点服务数必须大于n/2，这样zookeeper集群才可以继续使用，无论奇偶数都可以选举leader。例如5台zookeeper节点机器最多宕掉2台，还可以继续使用，因为剩下3台大于5/2。 那么为什么最好为奇数个节点呢？ 是在以最大容错服务器个数的条件下，会节省资源 。比如，最大容错为2的情况下，对应的zookeeper服务数，奇数为5，而偶数为6，也就是6个zookeeper服务的情况下最多能宕掉2个服务，所以从节约资源的角度看，没必要部署6（偶数）个zookeeper服务节点。 zookeeper集群有这样一个特性： 集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。 也就是说如果有2个zookeeper节点，那么只要有1个zookeeper节点死了

使用Docker快速搭建Zookeeper和kafka集群 镜像选择 Zookeeper和Kafka集群分别运行在不同的容器中 zookeeper官方镜像，版本3.4 kafka采用wurstmeister/kafka镜像 集群规划 hostname Ip addr port listener zoo1 172.19.0.11 2184:2181 zoo2 172.19.0.12 2185:2181 zoo3 172.19.0.13 2186:2181 kafka1 172.19.0.14 9092:9092 kafka1 kafka2 172.19.0.15 9093:9093 kafka2 Kafka3 172.19.0.16 9094:9094 Kafka3 宿主机root OSX 192.168.21.139【DHCP获取，会变动】 实现目标 kafka集群在docker网络中可用，和zookeeper处于同一网络 宿主机可以访问zookeeper集群和kafka的broker list docker重启时集群自动重启 集群的数据文件映射到宿主机器目录中 使用yml文件和$ docker-compose up -d命令创建或重建集群 1 $ docker-compose up -d zk集群的docker-compose.yml version: '3.4'

Docker 一步搞定 ZooKeeper 集群的搭建 背景 原来学习 ZK 时, 我是在本地搭建的伪集群, 虽然说使用起来没有什么问题, 但是总感觉部署起来有点麻烦. 刚好我发现了 ZK 已经有了 Docker 的镜像了, 于是就尝试了一下, 发现真是爽爆了, 几个命令就可以搭建一个完整的 ZK 集群. 下面我简单记录一下使用 Docker 搭建 ZK 集群的一些步骤. 镜像下载 hub.docker.com 上有不少 ZK 镜像, 不过为了稳定起见, 我们就使用官方的 ZK 镜像吧. 首先执行如下命令: 1 docker pull zookeeper 　　 当出现如下结果时, 表示镜像已经下载完成了: 1 2 3 4 5 6 7 8 9 10 11 12 13 >>> docker pull zookeeper Using default tag: latest latest: Pulling from library /zookeeper e110a4a17941: Pull complete a696cba1f6e8: Pull complete bc427bd93e95: Pull complete c72391ae24f6: Pull complete 40ab409b6b34: Pull complete d4bb8183b85d: Pull complete

Kafka支持单集群20万分区 之前网上关于确定Kafka分区数的博客多多少少都源自于饶军大神的文章，如今他带来了这方面的第二篇文章，特此翻译一下，记录一下其中的要点。 　　原贴地址： https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster 　　Kafka中topic可以设置多个分区，而分区是最小的并行度单位。通常而言，分区数越多吞吐量也越高。但是依然有很多因素制约了一个Kafka集群所能支持的最大分区数。我现在高兴地宣布Kafka 1.1.0版本在这方面取得了重大的改进。目前生产环境中单Kafka集群支持的分区上限得到了极大的提升。 　　为了便于理解这个改进是如何实现的，我们重温一下分区leader和controller的基本概念。首先，每个分区都可以配置多个副本用于实现高可用性以及持久性。其中的一个副本被指定为leader而所有client只与leader进行交互；其次，cluster中的某个broker被指定为controller来管理整个集群。若broker挂掉，controller负责为该broker上所有分区选举leader。 　　默认情况下关闭Kafka broker执行的是一个受控关闭操作（下称controlled shutdown）。Controlled

Hadoop 2x 一.Hadoop1.x的弊端 1.namenode只有一个-->容易发生单点故障:当前直接出现问题，整个集群没办法工作 2.namenode没办法扩充 NameNode会随着业务量的增大，内存中的数据会越来越大 会导致一直要增加内存来满足集群的需要 一旦业务量大大的超过内存那么业务就无法被处理 3.NameNode内存太大 如果内存大小达到上百G，开机时间过长 4.不能实现业务隔离 二.Hadoop2.x的解决方案 1.集群高可用 添加主备namenode节点 当主节点发生故障时,直接切换成备用namenode节点 2.集群可扩展性 联邦机制(hdfs federation) 进行分而治之 2.x的变化对用户来讲都是透明的，对用的操作影响很小 三.Hadoop2.x之HA 1.HA的节点 ActiveNameNode(ANN) 活跃的节点 作用:管理元数据信息(路径 文件 权限 等...);启动时接受DN汇报的BLK信息;维护文件与块的映射,维护块与DN的映射;与DN保持心跳,监控DN的存活(3秒, 10 分钟);当客户端写入读取文件的时候都与ANN通信. 主活动节点类似于以前的皇帝 StandbyNameNode(SNN) 备用的NamdeNode 删除了SecondaryNameNode,其功能完全有StandbyNameNode代替

转自： https://www.cnblogs.com/ysw-go/p/11396343.html 第一部分：单机模式 1)下载地址：http://www.pirbot.com/mirrors/apache/zookeeper/，建议下载stable版本 2）解压缩 将下载好的压缩包解压到指定目录，比如：D:\software\apache-zookeeper-3.5.5-bin 3）环境变量配置 新增：ZOOKEEPER_HOME，变量值为zookeeper的安装目录，按照上图解压的话就是：D:\software\apache-zookeeper-3.5.5-bin path新增路径：$ZOOKEEPER_HOME\bin（启动脚本都在这个目录下） 4）修改配置文件 在conf目录下有一个名为zoo_sample.cfg的文件，改文件是启动zookeeper服务需要的配置，将改文件复制一份，新建一个命名为zoo.cfg的文件，里面涉及几个主要的配置。 #这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳 tickTime=2000 initLimit=10 syncLimit=5 #顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper

一、 Dubbo 介绍 1.1 dubbo 出现的背景 大规模服务化之前，应用可能只是通过 RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。 (1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。 并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。 (2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。 (3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。 其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。 1.2 dubbo 的详细介绍 1. Dubbo 是什么？ Dubbo(注：HSF提供的是分布式服务开发框架

1.ZooKeeper 是什么？ ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。 2. 应用场景 · 命名服务 · 配置管理 · 集群管理 · 分布式锁 · 队列管理 3. 架构 4. 设计目的 Zookeeper 是一个高效的、可扩展的服务， read 和 write 操作都被设计为快速的， read 比 write 操作更快。 · 顺序一致性（ Sequential Consistency ）：从一个客户端来的更新请求会被顺序执行。 · 原子性（ Atomicity ）：更新要么成功要么失败，没有部分成功的情况。 · 唯一的系统镜像（ Single System Image ）：无论客户端连接到哪个 Server ，看到系统镜像是一致的。 · 可靠性（ Reliability ）：更新一旦有效，持续有效，直到被覆盖。 · 时间线（ Timeliness ）：保证在一定的时间内各个客户端看到的系统信息是一致的。 5. 数据模型 Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图所示： 树节点被称为znode。可以存储数据,有一个与之关联的ACL（AccessControlLists）

1、 KDC 创建 principal 1.1 、创建认证用户 登陆到 kdc 服务器，使用 root 或者可以使用 root 权限的普通用户操作： # kadmin.local -q “addprinc -randkey hbase/yjt” # kadmin.local -q “addprinc -randkey zookeeper/yjt” # kadmin.local -q “addprinc -randkey zkcli/yjt” 其中 hbase 集群有几台，上面的第一台命令就需要执行几次，每次执行的时候请把 yjt 修改成你机器对应的主机名 同理， zookeeper 也是一样 1.2 、生成密钥文件 生成 hbase 密钥文件 # kadmin.local -q “xst -norankey -k /etc/hbase.keytab hbase/yjt” 生成 zookeeper 密钥文件 # kadmin.local -q “xst -norankey -k /etc/zk.keytab zookeeper/yjt zkcli/yjt” 拷贝 hbase.keytab 到所有的 hbase 集群节点的 conf 目录下 拷贝 zk.keytab 到所有 zookeeper 集群节点的 conf 目录下 2 、 zookeeper 操作 2.1 、创建 jaas