浅谈分布式组件-kafka、zookeeper

接触分布式相关概念差不多有两周时间了，以前觉得其很神秘，离自己也很遥远，进而对它充满向往。如今有机会参与相关的工作让我觉得既兴奋又倍感压力。好了，切入正题，今天主要就之前学习的一些知识点：kafka、zookeeper做一下总结。
一：消息队列MQ
说到消息队列MQ，目前业界常用的有RabbitMQ、ZeroMQ、ActiveMQ、Kafka、RocketMQ。下面主要就Kafka进行展开分析总结，RocketMQ将作为接下来研究内容。说到这里，还有一个概念需要提一下，那就是JMS：java消息服务应用程序接口，是java平台中关于面向消息中间件的技术规范（类似JDBC），提供了标准的产生、发送、接收消息的接口，支持两种消息模型：点对点和发布订阅模型。MQ与JMS之间是什么关系呢？MQ是消息队列服务，是面向消息中间件的最终实现，是真正的服务提供者；MQ的实现可以是基于JMS，也可以是基于其他协议规范。ActiveMQ遵循JMS规范，Kafka虽然提供了类型JMS的特性，但它并不是JMS规范的实现。
为什么要使用消息队列？
一：异步通信：消息发送到消息队列后可以立即返回，不用等待接收者的响应，消息保存在队列中，直到接收者成功消费后将其从队列中移除，保证了消息的传递。系统中对于那些操作处理时间长但实时性要求不高的请求，可以通过消息异步反馈。
二：解耦：远程过程调用或者服务器间通过socket建立连接的应用，如果由一方接口变了或者端口、ip变了，另一方需要更改代码或者配置。而使用MQ，只要消息的格式不变，即使接收者的接口或端口、ip发生了变化，消息的发送者也无需作任何调整，换言之，发送者无需知道接收者是谁，降低了两个进程间的耦合度。
三：提供路由：发送者与接收者之间无需建立连接，两者通过消息队列从发送者路由到接收者，对于网络不通的两个服务起到很好的中转作用。
好了，言归正传，下面我们来谈谈Kafka。
kafka-分布式消息中间件，主要用于日志系统。先理解一下它的几个重要概念：
Broker：一台kafka的服务器就是一个broker。
Producer：消息生产者，向broker发送消息的客户端。
Consumer：消息消费者，向broker取消息的客户端。自己保存消费状态。
Consumer Group(CG)：实现一个topic消息的广播和单播。一个topic可以有多个CG，topic消息会发送到所有的CG，但每个CG只会将消息发送给该CG中的一个consumer。单播只需要将所有的consumer放到同一个CG中，消息会在consumers间作负载均衡；广播则只需每个consumer独立拥有一个CG。
Topic：消息类别，也可以理解为queue，一个topic的消息存于一个或多个broker上。
Partition：基于topic拆分，每个topic包含一个或多个partition。每个partition都是一个有序队列，Kafka只保证每个partition是有序的，不保证一个topic的整体顺序。
当一个group中，有consumer加入或离开时，会触发partition均衡，以提升topic并发消费能力。
Producer端直接连接broker.list列表，从列表中返回TopicMetadataResponse.该Metadata包含了Topic下每个partition leader建立socket连接并发送消息。
Consumer端使用zookeeper来注册consumer信息，包括consumer消费的partition列表等，同时也用来发现broker列表，并和partition leader建立socket连接获取信息。
kafka是分布式消息系统。那么为什么要引入分布式消息队列？
一：可靠：消息分布式存储能避免单台机器发生故障造成数据丢失。
二：可扩展：体现在访问量和数据量两个方面。分布式消息队列服务会随着访问量的增减自动增减逻辑处理服务器；当数据量扩大时，后端分布式存储会自动扩容。
三：安全：单机情况下，如果有多个业务同时在使用消息队列，一个业务操作占用队列的时间过长，会导致其他业务无法正常的与消息队列通信，从而影响业务正常运行。使用分布式能保证同时使用消息队列的业务之间不会相互干扰；消息内容的安全性，业务需要通过密钥来访问消息队列，其他业务无法访问到非自身业务的数据。
Kafka的安装配置分为单机和集群两种模式，具体配置方法此处不展开，可参考网上教程。Kafka的正常运行，需要配置并先启动zookeeper（为分布式应用提供一致性服务的软件）。
Zookeeper为分布式系统提供了高效且易于使用的协同服务，它可提供诸多服务，如统一命名服务、配置管理、状态同步和组管理、Leader选举等。kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。
下面简单的描述一下kafka在zookeeper中的存储结构：
Broker注册信息存储节点位置是：/brokers/ids/[0…N] ，Topic注册信息存储了其下partitions所有分配信息，其节点位置是：/brokers/topics/[topic] ，其partition状态信息则位于/brokers/topics/[topic]/partitions/[partitionId]/state，consumer注册信息节点位置：/consumers/[groupId]/ids/[consumerIdString]