kafka

kafka概述

(1).概述

Kafka是由LinkedIn开发的一个分布式的消息系统，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础

Kafka使用Scala编写，它以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark都支持与Kafka集成

特性：

1).以时间复杂度为O(1)的方式（顺序读写）提供消息持久化能力，对TB级以上数据也能保证正常时间复杂度的访问性能

2).高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100000条以上消息的传输

3).支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输

4).同时支持离线数据处理（因为消息可以保存默认是168小时）和实时数据处理

支持在线水平扩展

(2).为什么使用消息队列

• 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。

• 可扩展性：kafka集群支持热扩展

• 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

• 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）

• 高并发：支持数千个客户端同时读写

(3).基本的kafka系统术语

1、消费者(Consumer)：从消息队列中取消息的客户端应用程序

2、生产者(Producer)：向broker发布消息的应用程序

3、broker：Kafka以集群方式运行，集群中每个服务器称为broker

4、主题(Topic)：一组消息的归纳

5、分区(Partition)：一个Topic中的消息数据按照多个分区组织，分区是Kafka消息队列组织的最小单位，一个分区可以看作是一个队列

6、队列中消费的位置(offset)：Consumer消息Partition中的数据的位置

Kafka的使用场景：

• 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

• 消息系统：解耦和生产者和消费者、缓存消息等。

• 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

• 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

• 流式处理：比如spark streaming和storm

Kakfa的设计思想

Kakfa Broker Leader的选举：Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。例如：一旦有一个broker宕机了，这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态，并选取ISR列表中的一个replica作为partition leader（如果ISR列表中的replica全挂，选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了，则将新的leader设置为-1，等待恢复，等待ISR中的任一个Replica“活”过来，并且选它作为Leader；或选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader），这个broker宕机的事情，kafka controller也会通知zookeeper，zookeeper就会通知其他的kafka broker。

体系结构

 KafKa利用ZooKeeper保存相应元素据信息，KafKa元素据包括如broker节点信息、KafKa集群信息、旧版消费者信息以及消费偏移量信息offset、topic信息、分区状态信息、分区副本分配方案信息、动态配置信息等。KafKa在启动或者运行过程中会在ZooKeeper上创建相关的节点来保存元数据信息，KafKa通过监听机制在这些节点注册相应监听器来监听节点元素据的变化，从而由ZooKeeper负责管理维护KafKa集群，同时通过ZooKeeper我们能够很方便的对KafKa集群进行水平扩展以及数据迁移；

基本原理

  每个topic 有一个或多个分区，每个分区在物理上对应一个文件夹，分区命令规则：主题名称—分区编号，（分区编号从0开始）

任何发布到分区的消息会直接追加到日志文件（分区目录下以.log为文件名后缀的数据文件）的尾部，而每条消息在日志中的位置都会对应一个按顺序递增的偏移量。偏移量是一个分区下严格有序的逻辑值，它并不表示消息在磁盘上的物理位置。

        为了能快速查找到对应offset的数据，需要两个索引文件：

                .index 结尾：根据有序的offset进行查找

                .timeindex 结尾： 根据有序的时间戳进行查找

                              

 

每个分区又一到多个副本。其中有一个是leader角色，其他是Follower角色。

        leader处理所有的针对这个partition的读写请求，而followers被动复制leader的结果。如果这个leader失效了，其中的一个follower将会自动的变成新的leader。每个broker自己所管理的partition的可以是leader，同时又是其他broker所管理partitions的followers，kafka通过这种方式来达到负载均衡。

        一般情况下partition的数量大于等于broker的数量，并且所有partition的leader均匀分布在broker上

分区能增，不能减；

副本能增，也能减；

 

消息生产

 Producer将消息发布到它指定的topic中,并负责决定发布到哪个分区

        主要两种方式：

                1）round-robin做简单的负载均；

                2）根据消息中的某一个关键字来进行区分；

        Producer根据指定的partition方法（round-robin、hash等），将消息发布到指定topic的partition里面。

消费与消费者组

Kafka提供了一种consumer的抽象概念：Consumer Group。

一个消费组可以有多个消费实例，这个实例可以是进程，也可以是线程。

同一Topic 的一条消息，只能被同一个 Consumer Group 的一个 Consumer 消费；

但 多个Consumer Group可同时消费这一消息。

 

在一个Consumer Group内

1）如果consumer比partition多，是浪费，因为kafka的设计是在一个partition上是不允许并发的，所以consumer数不要大于partition数；

2）如果consumer比partition少，一个consumer会对应于多个partitions，这里主要合理分配consumer数和partition数，否则会导致partition里面的数据被取的不均匀，最好partiton数目是consumer数目的整数倍；

3）如果consumer从多个partition读到数据，不保证数据间的顺序性，kafka只保证在一个partition上数据是有序的，但多个partition，根据你读的顺序会有所不同；

消费顺序

Kafka通过Topic中partition概念实现并行消费；

Kafka可以同时提供顺序性保证和多个consumer同时消费时的负载均衡；（同一个主题的消息 只能被同一个consumer组 一个consumer 实例消费）

实现的原理是通过将一个topic中的每个partition分配给一个consumer group中的不同consumer实例；

通过这种方式：

        Kafka只在partition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费顺序性；

kafka优化

kafka同hdfs一样实现了软件raid，支持多磁盘并且不做raid，就是为了充分利用多磁盘并发读写，又保证每个磁盘连续读写的特性。

合理设置topic的partition数量，保证并发度。

Jvm内存不宜过大4G左右即可。

如何为Kafka集群选择合适的Topic/Partitions数量

1）越多的分区可以提供更高的吞吐量，因为一个Partitions可以对应一个Consumer，Partitions越多吞吐量越高，也就是Consumer会并行读取Partitions

2）分区多了会消耗更多的系统资源比如文件的句柄，broker会为每个Partitions分配一个文件目录，目录中分索引文件和数据文件。所以分区多了需要打开的文件自然就多了。

3）更多分区会导致更高的不可用性，在有副本的情况下更多的分区会导致更多的复制操作，在brokers宕机时也需要恢复更多的Partition。

4）越多的分区可能增加端对端的延时，因为producer发布消息后consumer需要等待所有partition完成复本复制之后才能得到该消息，分区越多说明复制所花费的时间越长，因为从一个broker到别一个broker复制数据是由一个线程来完成的。

5）越多的Partition意味着需要客户端分配更多的内存，比如一个topic有2000个分区，当只有一个consumer时，则这个consumer需要在内存中记住这2000个分区信息。