zookeeper集群

尚硅谷大数据技术之Kafka (作者：尚硅谷大数据研发部) 版本：V2.0 第1章 Kafka概述 1.1 消息队列 （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。 （2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。 1.2 为什么需要消息队列 1）解耦： 　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）冗余： 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 3）扩展性： 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。 4）灵活性 & 峰值处理能力： 在访问量剧增的情况下

版本：V2.0 第1章 HBase简介 1.1 什么是HBase HBase的原型是Google的BigTable论文，受到了该论文思想的启发，目前作为Hadoop的子项目来开发维护，用于支持结构化的数据存储。 官方网站：http://hbase.apache.org -- 2006年Google发表BigTable白皮书 -- 2006年开始开发HBase -- 2008年北京成功开奥运会，程序员默默地将HBase弄成了Hadoop的子项目 -- 2010年HBase成为Apache顶级项目 -- 现在很多公司二次开发出了很多发行版本，你也开始使用了。 HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群。 HBase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。 HBase是Google Bigtable的开源实现，但是也有很多不同之处。比如：Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google

Leader选举 Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。 (1) 服务器初始化启动。（集群的每个节点都没有数据 → 以SID的大小为准） (2) 服务器运行期间无法和Leader保持连接。（集群的每个节点都有数据 ,或者Leader 宕机→ 以ZXID 和 SID 的最大值为准） 1. 服务器启动时期的Leader选举 若进行Leader选举，则至少需要2台机器，两台的高可用性会差一些，如果Leader 宕机，就剩下一台，自己没办法选举。这里选取3台机器组成的服务器集群为例。 在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下 (1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。 (2) 接受来自各个服务器的投票

基本概念 1.Producer：消息生产者，就是向 kafka broker 发消息的客户端 2.Consumer：消息消费者，向 kafka broker 取消息的客户端 3.Consumer Group（CG ）：消费者组，由多个 consumer 组成。 消费者组内每个消费者负责消费不同分区的数据， 一个分区只能由一个 组内 消费者消费； 消费者组之间互不影响。 所有的消费者都属于某个消费者组，即 消费者组是逻辑上的一个订阅者。 4.Broker：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。 5.Topic：可以理解为一个队列， 生产者和消费者面向的都是一个 topic 6.Partition：为了实现扩展性， 一个非常大的 topic 可以分布到多个 broker （即服务器） 上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列； 7.Replica： 副本， 为保证集群中的某个节点发生故障时， 该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作， kafka 提供了副本机制， 一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。 8.leader：每个分区多个副本的“主”

1. kafka介绍 1.1. 主要功能 根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能： 　　1：It lets you publish and subscribe to streams of records.发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因 　　2：It lets you store streams of records in a fault-tolerant way.以容错的方式记录消息流，kafka以文件的方式来存储消息流 　　3：It lets you process streams of records as they occur.可以再消息发布的时候进行处理 1.2. 使用场景 1：Building real-time streaming data pipelines that reliably get data between systems or applications.在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能 2：Building real-time streaming applications that transform or react to the streams of data。构建实时的流数据处理程序来变换或处理数据流，数据处理功能 1.3

CAP 理论 什么叫 CAP 理论呢？CAP 理论是由 Eric Brewer 教授提出，是分布式系统中的一个重要的概念。具体如下： C（Consistency）：数据一致性。大家都知道，分布式系统中，数据会有副本。由于网络或者机器故障等因素，可能有些副本数据写入正确，有些却写入错误或者失败，这样就导致了数据的不一致了。而满足数据一致性规则，就是保证所有数据都要同步。 A（Availability）：可用性。我们需要获取什么数据时，都能够正常的获取到想要的数据（当然，允许可接受范围内的网络延迟），也就是说，要保证任何时候请求数据都能够正常响应。 P（Partition Tolerance）：分区容错性。当网络通信发生故障时，集群仍然可用，不会因为某个节点挂了或者存在问题，而影响整个系统的正常运作。 对于分布式系统来说，出现网络分区是不可避免的，因此分区容错性是必须要具备的，也就是说，CAP三者，P是必须的，是个客观存在的事实，不可避免，也无法绕过。 1. Zookeeper 的 CP 原则 对于 zookeeper 来说，它是 CP 的。也就是说，zookeeper 是保证数据的一致性的，但是这里还需要注意一点是，zookeeper 它不是强一致的，什么意思呢？ 打个比方，现在客户端 A 提交一个写操作，zookeeper 在过半数节点操作成功之后就可以返回，但此时，客户端 B

　　ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。（百度百科）。ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，其中分布锁和队列有Java和C两个版本，选举只有Java版本。一般用于分布式的消息监听（主要）和分布式锁的用途（次要）。 　　我们这次先来简单安装一个zookeeper和zookeeper的一些简单命令的使用。 一、安装 1，下载 　　输入，即可下载。我们最新版3.5.5为例来说。 /*--> */ /*--> */ wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/current/apache-zookeeper-3.5.5-bin.tar.gz 我们也可以直接去官网下载压缩包，然后自己上传到服务器上，下载地址： https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/ 2，解压 /*--> */ /*--> */ tar -zxvf apache-zookeeper-3.5.5-bin.tar.gz

1、ZooKeeper介绍与核心概念 1.1 简介 ZooKeeper最为主要的使用场景，是作为分布式系统的分布式协同服务。在学习zookeeper之前，先要对分布式系统的概念有所了解，否则你将完全不知道zookeeper在分布式系统中起到了什么作用，解决了什么问题。 1.2分布式系统面临的问题 我们将分布式系统定义为：分布式系统指的是同时跨越多个物理主机，将一个完整的系统划分为多个独立运行的子系统，这些子系统之间互相协作构成一个完整的系统功能。类比一下，分布式系统就是将一个完整的任务细分为多个子任务，一群人分别完成一个子任务，最终完成整个任务。人多力量大，每个服务器的算力是有限的，但是通过分布式系统，由n个服务器组成起来的集群，算力是可以无限扩张的。 说起分布式就要谈谈集群，两者很相似，都是通过网络协同多台主机服务器节点完成整体的功能。 但不同点在于： 集群中的每个服务器节点都完成的是同一个功能，比如mysql数据库集群、redis集群； 而分布式系统则是各个服务器节点所负责的是不同的子系统（任务或者说功能），比如电商系统的分布式系统会分为订单系统、支付系统、数据库系统、缓存系统等等。 所谓分布式集群系统，就是将一个完整的系统进行拆分多个子系统，每个子系统都进行集群部署，各系统集群之间互相协作，就能构成一个分布式集群系统。 优点显而易见，人多干活快，并且互为备份。但是缺点也很明显

 介绍常见的分布式一致性协议 一．CAP/BASE 1. CAP理论  CAP理论又称之为布鲁尔定理（Brewer’S theorem），认为在设计一个大规模可扩放的网络服务时候不能同时兼容：一致性（consistency）、可用性（Availability）、分区容错（Partition-tolerance）。  一致性：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本）  可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。  分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择  CAP理论容易理解，网上也有关于该理论的说明，包括模型的简易证明；弱条件下模型的成立等。  参考资料： http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 2. BASE理论  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写

1 SolrCloud简介 1.1什么是SolrCloud 　　SolrCloud(solr 云)是 Solr 提供的分布式搜索方案，当你需要大规模，容错，分布式索引和检索能力时使用 SolrCloud。当一个系统的索引数据量少的时候是不需要使用 SolrCloud的，当索引量很大，搜索请求并发很高，这时需要使用 SolrCloud 来满足这些需求。 　　SolrCloud 是基于 Solr 和Zookeeper的分布式搜索方案，它的主要思想是使用 Zookeeper作为集群的配置信息中心。 　　它有几个特色功能： 　　　　1）集中式的配置信息 　　　　2）自动容错 　　　　3）近实时搜索 　　　　4）查询时自动负载均衡 1.2 SolrCloud系统架构　　 　　　　 　　【1】物理结构 　　　　三个 Solr 实例（ 每个实例包括两个 Core），组成一个 SolrCloud。 　　【2】逻辑结构 　　　　索引集合包括两个 Shard（shard1 和 shard2），shard1 和 shard2 分别由三个 Core 组成，其中一个 Leader 两个 Replication，Leader 是由 zookeeper 选举产生，zookeeper 控制每个shard上三个 Core 的索引数据一致，解决高可用问题。 　　　　用户发起索引请求分别从 shard1 和