Kaka与Zookeeper的爱恨情仇（——zookeeper过半选举机制）

        关于我们在学习kafka中的一些问题及架构，我想在这里浅谈一下我个人的理解；

        之所以说这个kafka呢，主要还是最近做实时的项目中大量用到了kafka这个消息中间件，可以说kafka是我们大数据实时项目中一个代表性的一个主要起到缓存数据的一个消息中间件；说到消息，kafka里的消息队列就不得不提：

 一 、Kafka

        1.1消息队列（Message Queue）

        1.1.1 传统消息队列的应用场景

 

使用消息队列的好处

1）解耦：

　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2）冗余：

消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

3）扩展性：

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。

4）灵活性 & 峰值处理能力：

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

5）可恢复性：

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

6）顺序保证：

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka保证一个Partition内的消息的有序性）

7）缓冲：

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

8）异步通信：

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们

1.1.2  消息队列的两种模式

1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。

消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息）

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

两种模式的优势和劣势：

点对点模式：可以保证每条消息都是被消费的，按照顺序处理发布订阅模式：可以一次性将数据分发给多个消费者，有可能出现消息顺序不对 1.2 定义

Apache Kafka是一个开源消息系统，最初是由LinkedIn公司开发，并于2011年初开源。采用Scala语言开发的一个多分区、多副本并且基于Zookeeper协调的分布式消息系统，现在已经捐献给了Apache基金会。在流式计算中，Kafka一般用来缓存数据，Storm通过消费Kafka的数据进行计算。

Kafka是一个分布式的基于发布/订阅模式的消息队列(Message Queue),主要应用于大数据实时处理领域。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。无论是kafka集群，还是consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性。 1.3 Kafka基础架构

Cluster：集群  服务端

1）Zookeeper：Zookeeper负责保存broker集群元数据，并对控制器进行选举等 *** 作

2）Producer （生产者）：消息生产者，就是向kafka broker发消息的客户端。

3）Consumer（消费者）：消息消费者，向kafka broker取消息的客户端

4）Topic ：可以理解为一个队列。是一个逻辑的存在，生产者和消费者面向的都是一个topic；

10

9

8

7

6

5

4

3

2

1

5）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。同一个组的消费者消费同一个主题数据的时候，不能消费相同分区的数据    如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。

6）Broker（中间件）：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

 Replication:备份   message ：消息

7）Partition（分区）（物理存在）：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。

8）Offset（偏移量）：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

9）Replication：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。

10）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。

11）follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader。

12）Record：实际写入kafka中并可以被读取到的消息记录。每个record包含了key、value、和timestamp。

1.4使用场景 日志收集：一个公司可以用kafka收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如Hadhoop、Hbase、Sorl等消息系统：解耦和生产者和消费者、缓存消息等用户活动跟踪：kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘运营指标：kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种 *** 作的集中反馈，比如报警和报告流式处理：比如spark streaming和storm Zookeeper

       zookeeper是一个分布式协调服务。所谓分布式协调主要是来解决分布式系统中多个进程之间的同步限制，防止出险脏读，例如我们常说的分布式锁。

        zookeeper中的数据是存储在内存当中的，因此它的效率十分高效。它内部的存储方式十分类似于文件存储结构，采用了分层存储结构。但是它和文件存储结构的区别是，它的各个节点中是允许存储数据的，需要注意的是zk的每个节点存储数据不能超过1M。它的内存数据结果如下图：

 zookeeper中可以通过不同路径访问到不同节点，因为是分层结构，也可以通过父节点访问到该节点下的所有子节点信息。

        zk简单api：

        1）create：创建一个新节点，通过指定路径的方式创建节点，例如创建路径为/A/A1/demo，则会在A1节点下创建一个demo节点；

        2）delete：删除节点，通过路径的方式删除节点，如果删除路径为/A/A1/demo，则会删除A1节点下的demo节点；

        3）exists：判断指定路径下的节点是否存在，例如判断路径为/A/A1/demo，则会判断A1节点下的demo节点是否存在；

        4）get：获取指定路径下某个节点的值是什么，例如获取路径为/A/A1/demo，则会获取A1节点下的demo节点的值什么；

        5）set：为指定路径的节点进行赋值 *** 作，例如修改路径为/A/A1/demo，则会修改A1节点下的demo节点的值；

        6）get children：获取指定路径节点下的子节点信息，例如获取路径为/A，则会获取A节点下的A1和A2节点；

        7）sync：获取到同步数据，这个涉及到了zk的原理，zk集群属于最终一致性，调用该方法，可以获取到最终的结果值，如果不使用该方法，在查询的时候可能获取到的值是中间值；

        zk中创建的节点分为两种：永久性节点和临时性节点。永久性节点即创建以后，在不执行delete命令的前提下，该节点是永久存在的；而临时节点与session有关，每个客户端与zk建立链接的时候会生成一个session，这个session不会因为链接zk服务器节点的变化而变化，只有当客户端断开连接以后，该session才会消失，而临时节点会随着session的消失而消失。

        zk拥有watch机制，也就是监视机制，可以支持响应式编程模式，它可以对某个路径的终节点及其子节点的变更进行监视，当其发生变更以后，会调用注册的callback方法，然后进行具体的业务逻辑。例如监测路径为/A/A1，那么它会加测A1节点，以及附属于A1的所有子节点，这个子不单单只一层子节点，是指所有层的子节点。

        zk拥有以下几个重要特性：

        1）顺序一致性：来自客户端的相关指令会按照顺序执行，不会出现乱序的情况，客户端发送到服务的指令1->2->3->4，那个这些指令就会按照顺序执行；

        2）原子性：更新只有成功和失败，没有中间状态；

        3）可靠性：也可以称之为持久性，节点更新以后，在下次更新之前，它的数据不会发生变更；

        4）准实时性：也可以称之为最终一致性，在zk集群中，一个客户端修改了其中的一个节点，一定时间以后，所有可用的服务对应的节点都会变成更新以后的值。

zk的选举机制原理——过半选举

        三个核心选举原则：

                （1）Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作；

                （2）在集群正常工作之前，myid小的服务器给myid大的服务器投票，直到集群正常工作，选出Leader；

                （3）选出Leader之后，之前的服务器由Looking改变为Following，以后的服务器都是Follower；

过程：

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。

假设这些服务器从id1-5，依序启动：

因为一共5台服务器，只有超过半数以上，即最少启动3台服务器，集群才能正常工作。

（1）服务器1启动，发起一次选举。

         服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成；

         服务器1状态保持为LOOKING；

（2）服务器2启动，再发起一次选举。

         服务器1和2分别投自己一票，此时服务器1发现服务器2的id比自己大，更改选票投给服务器2；

         此时服务器1票数0票，服务器2票数2票，不够半数以上（3票），选举无法完成；

         服务器1，2状态保持LOOKING；

（3）服务器3启动，发起一次选举。

         与上面过程一样，服务器1和2先投自己一票，然后因为服务器3id最大，两者更改选票投给为服务器3；

         此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数（3票），服务器3当选Leader。

         服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。

         此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。

         此时服务器4服从多数，更改选票信息为服务器3；

        服务器4并更改状态为FOLLOWING；

（5）服务器5启动，同4一样投票给3，此时服务器3一共4票，服务器5为1票；

        服务器5并更改状态为FOLLOWING；

最终Leader是服务器3，状态为LEADING；

其余服务器是Follower，状态为FOLLOWING。

引用资料：

zookeeper详解_、风筝的博客-CSDN博客_zookeeper

zookeeper选举机制——过半选举 - black9 - 博客园