zookeeper集群

二、环境搭建 参考：http://kafka.apache.org/documentation.html#quickstart Step 1: 下载Kafka wget http://mirrors.noc.im/apache/kafka/0.9.0.0/kafka_2.11-0.9.0.0.tgz 解压: > tar -xzf kafka_2.9.2-0.8.1.1.tgz > cd kafka_2.9.2-0.8.1.1 复制代码 Step 2: 启动服务 Kafka用到了Zookeeper，所有首先启动Zookper，下面简单的启用一个单实例的Zookkeeper服务。可以在命令的结尾加个&符号，这样就可以启动后离开控制台。 > bin/zookeeper-server-start.sh config/zookeeper.properties & [2013-04-22 15:01:37,495] INFO Reading configuration from: config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig) ... 复制代码 现在启动Kafka: > bin/kafka-server-start.sh config/server.properties

ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。 ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。 例如，Apache HBase使用ZooKeeper跟踪分布式数据的状态。 先来介绍一下分布式： 分布式应用 分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。通常来说，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）需要几个小时才能完成，而分布式应用通过使用所有系统涉及的计算能力可以在几分钟内完成。 通过将分布式应用配置为在更多系统上运行，可以进一步减少完成任务的时间。分布式应用正在运行的一组系统称为 集群 ，而在集群中运行的每台机器被称为 节点 。 分布式应用有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序实际上是分布式的，并具有通用接口，以便客户端可以连接到集群中的任何服务器并获得相同的结果。

1.zap协议 ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。 来源： CSDN 作者： qq_25705173 链接： https://blog.csdn.net/qq_25705173/article/details/103654765

Kafka Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 1.前言 消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 1.1 Kafka的特性: - 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 - 可扩展性：kafka集群支持热扩展 - 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 - 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） - 高并发：支持数千个客户端同时读写 1.2 Kafka的使用场景： - 日志收集

zookeeper简介 1、什么是zookeeper ZooKeeper 是一个分布式的，开放源码的分布式应用程序协同服务。 ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服 务封装起来，构成一个高效可靠的原语集，并以一系列简单易用 的接口提供给用户使用。 2、zookeeper的使用场景 2.1、数据发布/订阅，配置中心 1、发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅。 2、Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。 2.2、分布式锁 1、排它锁也叫独占锁 ① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成功的客户端需要注册/exclusive_lock节点监听。 ② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。 2、读写锁 ① 获取锁，在需要获取共享锁时，所有客户端都会到

文章目录 一、软件版本与系统环境 二、zookeeper 安装 1、xftp上传zookeeper压缩包并解压 2、进入解压好的安装包 在conf文件夹下配置环境 3、配置环境变量 4、启动zookeeper 三、Hbase集群搭建 1、xftp上传Hbase压缩包并解压 2、环境变量配置 3、启动Hbase 一、软件版本与系统环境 ①HBase，1.2.0， 下载链接 ②ZooKeeper，3.4.5， 下载链接 二、zookeeper 安装 1、xftp上传zookeeper压缩包并解压 cd / opt / soft ls tar - zxvf zookeeper - 3.4 .5 - cdh5 . 14.2 . tar . gz mv zookeeper - 3.4 .5 - cdh5 . 14.2 zooker345 2、进入解压好的安装包 在conf文件夹下配置环境 cd zookeeper345 / cd conf ls cp zoo_sample . cfg zoo . cfg vi zoo . cfg 修改存储数据路径、添加zookeeper交换数据端口已经选举端口 dataDir = / opt / soft / zookeeper345 / data server . 1 = 192.168 .56 .122 : 2287 : 3387 添加存储文件夹 [

前言 早先过了一遍Kafka，摄取了不少知识细节，未免遗忘梳理记录下，推荐书本 《Kafka 权威指南》。 Quick Start 基础概念 关于Kafka是什么，可以参考 官网介绍 ，一个分布式流处理平台，通俗点理解就是一款基于发布和订阅的消息系统。Kafka设计实现的目标在于： 使用推送和拉取模式解藕生产者和消费者 为消息系统中传递的消息提供数据持久化 通过优化系统实现高吞吐量 系统可以随着数据流的增长进行横向拓展 既然kafka的实质是一个消息系统，类似其他MQ他也有 生产者：消息产生这，向kafka推送消息 消费者：消息的实际使用者，从kafka拉取生产者推送至kafka的消息 Topic：消息主题，亦可理解为消息类型，生产者发送了什么主题的消息，对应订阅了该主题的消费者方可拉取到该消息 Kakfa系统中一些概念 broker：一个独立的kafka服务被称为一个broker 集群：kafka是集群式的提供服务，broker是集群的一个组成部分 分区：一个topic下的至少要包含一个分区，亦可包含多个分区，topic下的消息是存储于分区中的，如图下示。对于给定分区中，消息是按照进入分区的顺序，先到者先被消费。 偏移量：消费者根据偏移量来区分哪些消息已经别消费过。 如果觉得概念枯燥繁多可先忽略。 Kafka部署 先快速将kafka搭建起来，对于kafka系统

1、选举相关概念： 选票：（myid，zxid，当前节点选取轮次，被推举服务器选举轮次，状态（looking））。 选举发生情况：启动时选举，运行时选举。 外部投票：其他服务器发送来的投票。 内部投票：服务器自身当前的投票。 选举轮次：epoch--leader选举周期。 pk：比较内部选票和外部选票，确定是否变更内部选票，主要是比较zxid和myid。 2、选举过程： （1）每个服务器节点先初始化自己的选票，即（myid，zxid，当前节点选取轮次，被推举服务器选举轮次，状态（looking））。 （2）发送初始化选票到所有集群中的节点。 （3）接收外部选票 （4）判断选举轮次，内部选票选举轮次要是大于外部选票，就继续接收外部选票，如果小于等于外部的选举轮次，就进行选票pk，即判断自己是否要变更内部选票。 （5）变更内部选票，将选票发送至集群中。 （6）归档。每个节点将收到的所有外部选票进行归档。 （7）统计。判断是否有过半的服务器认可当前内部选票，如果是，那就选举结束，即超过一半选票同意新leader，那就成功。 来源： https://www.cnblogs.com/guoyu1/p/11992233.html

欢迎和大家交流技术相关问题： 邮箱: jiangxinnju@163.com 博客园地址: http://www.cnblogs.com/jiangxinnju GitHub地址: https://github.com/jiangxincode 知乎地址: https://www.zhihu.com/people/jiangxinnju 转自： http://jiajun.iteye.com/blog/899632 原文图片丢失，本文补充图片，优化排版，修正部分错误。 一、简介 History l started by chad walters and jim l 2006.11 G release paper on BigTable l 2007.2 inital HBase prototype created as Hadoop contrib l 2007.10 First useable Hbase l 2008.1 Hadoop become Apache top-level project and Hbase becomes subproject l 2008.10 Hbase 0.18,0.19 released Hbase是bigtable的开源山寨版本。是建立的HDFS之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。

问题导读： 1.master挂机，传统做法备份必然是以前数据，该如何保证挂机数据与备份数据一致？ 2.分布式系统如何实现对同一资源的访问，保证数据的强一致性？ 3.集群中的worker挂了，传统做法是什么？zookeeper又是如何做的？ 分布式系统的运行是很复杂的，因为涉及到了网络通信还有节点失效等不可控的情况。下面介绍在最传统的 master -workers 模型 ，主要可以会遇到什么问题，传统方法是怎么解决以及怎么用zookeeper解决。 Master节点管理 集群当中最重要的是Master，所以一般都会设置一台Master的Backup。 Backup会定期向Master获取Meta信息并且检测Master的存活性，一旦Master挂了，Backup立马启动，接替Master的工作自己成为Master，分布式的情况多种多样，因为涉及到了网络 通信 的抖动，针对下面的情况: Backup检测Master存活性传统的就是定期发包，一旦一定时间段内没有收到响应就判定Master Down了，于是Backup就启动，如果Master其实是没有down，Backup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢？Backup也启动了，这时候集群里就有了两个Master，很有可能部分workers汇报给Master，另一部分workers汇报给后来启动的Backup