kafka背景介绍

1.简介

　　kafka是一个高吞吐、分布式的发布-订阅消息系统，据官方介绍，kafka已经定位是一个分布式流式处理平台，支持的语言：java，python，C，C++，Go等客户端

1.1.背景

　　kafka是一款开源的，轻量级的，分布式，可分区和具有复制备份，基于ZooKeeper协调管理的分布式流平台的功能强大的消息系统。

1.2.关键特性

• 能够允许发布和订阅流数据
• 存储数据流时提供相应的容错机制
• 当流数据到达时能够被及时处理

2.基本结构

　　作为一个消息系统，其基本结构柱宏至少要有产生消息的组建（消息生产者，Producer）以及消费消息的组件（消费者，Consumer）。

生产者——>生产消息——>写入kafka集群<——消费者拉取消息

 那么问题来了，生产者如何将生产消息写入kafka？消费者如何从kafka集群消费消息？kafka如何存储消息？kafka集群如何管理调度？如何进行消息负责均衡？以及各组件如何进行通信？

 

3.基本概念

3.1）主题（topic）

　　kafka将一组消息抽象归纳为一个主题（topic），也就是说，一个主题就是对消息的一个分类，生产者将消息发送到特定主题，消费者订阅主题或主题的某些分区进行消费。

3.2消息（Message）

　　消息是kafka通信的基本单位，由一个固定长度的消息头和一个可变长度的消息体构成，在老版本中，每一条消息称为Messge，在由Java重新实现的客户端中，每一条消息称为Record。

3.3）分区和副本

　　kafka将一组消息归纳为一个主题，而且每个主题又被分成一个或多个分区（Partition），每个分区由一系列、不可变的消息组成，是一个有序队列。

每个分区在物理上对应一个文件夹，分区的命名规则为主题名称后接“—”连接符，之后再接分区编号，分区编号从0开始，编号最大值为分区的总数减1，每个分区又有一至多个副本（Replica），分区的副本分布在集群的不同代理，每个主题对应的分区数在kafka启动时所加载的配置文件中配置，也可以在创建主题时指定，当然，客户端还可以在主题创建后修改主题的分区数。

分区使得kafka在并发处理上变得更加容易，理论上来说，分区数越多吞吐量越高，但这要根据集群实际环境及业务场景而定，同时，分区也是kafka保证消息被顺序消费以及对消息进行负载均衡的基础。

kafka只能保证一个分区之内消息的有序性，并不能保证跨分区消息的有序性。

3.4）Leader副本和Follower副本

　　kafka副本的存在，需要保证一个分区的多个副本之间数据的一致性,kafka会选择该分区的一个副本作为Leader副本，而该分区其他副本即为Follower副本。

引入Leader副本后，客户端只需有Leader副本进行交互，这样数据一致性及顺序性就有了保证，Follower副本从Leader副本同步消息，对于n个副本只需n-1条通路即可，使得系统简单高效。

3.5）偏移量

　　任何发布到分区的消息会被直接追加到日志文件（分区目录下以".log"为文件名后缀的数据文件）的尾部，每条消息在日志文件中的位置都会对应一个按需递增的偏移量，偏移量是一个分区下严格有序的逻辑值，消费者可以通过控制消息偏移量来丢消息进行消费，如消费者可以指定消费的起始偏移量，为了保证消息被顺序消费，消费者已消费的消息对应偏移量也需要保存。旧版消费者将消费偏移量保存造ZooKeeper当中，新版的是保存到kafka内部一个主题当中，当然也可以自已在外部系统保存消费偏移量，无需保存到kafka。

3.6）日志段

　　日志段是kafka日志对象分片的最小单位，与日志对象一样，日志段也是一个逻辑概念，一个日志段对应磁盘上一个具体日志文件和两个索引文件，日志文件是以‘.log’为文件名后缀的数据文件，用于保存消息实际数据，两个索引文件分别以‘.index’与‘.timeindex’作为文件名后缀，分别表示消息偏移量索引文件和消息时间戳索引文件。

3.7）代理

　　kafka集群就是由一个或多个kafka实例构成，将每一个kafka实例称为代理（Broker），通常也称代理为Kafka服务器（KafkaServer），在生产环境中Kafka集群一般包括一台或多台服务器，可以在一台服务器上配置一个或多个代理，每一个代理都有唯一标识id，这个id是一个非负整数，保证在整个kafka集群中唯一，这个id就是代理的名字，也就是在启动代理时配置的broker.id对应的值，有时也称brokerId，对代理的迁移就变得很方便，对消费者来说是透明的，不会影响消费者对消息的消费。

3.8）生产者

　　生产者（Producer）负责将消息发送给代理，也就是像Kafka代理发送消息的客户端。

3.9）消费者和消费组

　　消费者（Comsumer）以拉取（pull）方式拉取数据，它是消费的客户端，在Kafka中每一个消费者都属于一个特定消费组，可以为每个消费者指定一个消费组，以GroupID代表消费组名称，通过group.id配置设置，如果不指定消费组，则消费组属于默认消费组test-consumer-group，同时，每个消费者也有一个全局唯一的id，通过配置项client.id指定，如果客户端没有执行消费者的id，kafka会自动为消费者生成一个全局唯一的id，格式为：${groupid}-${hostName}-${timestamp}-${UUID前8位字符}，同一个主题的一个消息只能被同一个消费组下某一个消费者消费，但不同消费者组的消费者可同时消费该消息，消费组是Kafka用来实现对一个主题消息进行广播和单播的手段，实现消息广播只需指定各消费者均属于不同的消费组，消息单播则只需让各消费者属于同一个消费组。

3.10）ISR

　　Kafka在ZooKeeper中动态维护了一个ISR（In-sync-Replica），即保存同步的副本列表，改列表中保存的是与Leader副本半尺消息同步的所有副本对应的代理结点Id

3.11）ZooKeeper

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

总结：通过以上Kafka基本概念的介绍，大致对kafka基本结构图进行完善，如图：1-2

4.kafka设计概述

4.1kafka设计动机

kafka设计初衷是使kafka能够成为统一，实时处理大规模数据的平台，为了达到这个目标，支持以下几个应用场景：

　　1）高吞吐来支持诸如实时的日志集这样的大规模事件流

　　2）很好的处理大量积压的数据，以便能够周期性加载离线数据进行处理

　　3）能够低延迟处理传统消息应用场景

　　4）支持分区，分布式，实时处理消息，同时具有容错保障机制

3.2Kafka特性

1）消息持久化

　　kafka提供相关配置让用户自已决定消息要保存多久，更灵活的处理方式，同时kafka能够很好的支持在线或离线处理，与其他存储及流处理框架的集成。

2）高吞吐

　　kafka将数据写到磁盘，充分利用磁盘的顺序读写，经大多数公司应用验证，支持每秒数百万级别的消息。

3）扩展性

　　支持对大规模数据的处理，就必须能够对集群进行扩展，分布式是其特性之一，将多台廉价的PC服务器搭建成一个大规模的消息系统，依赖ZooKeeper来对集群进行协调管理。使得kafka更容易进行水平扩展，生产者，消费者和代理都为分布式，可配置多个。

4）多客户端支持

　　kafka核心模块用Scale语言开发，支持不同语言开发生产者和消费者客户端应用程序，默认使用Java版本的客户端，支持多种语言：如java，c，c++，python，go，Ruby等

5）kafka Streams

　　kafka Streams是一个用java语言实现的用于流处理的jar文件

6）安全机制

　　支持以下几种安全措施：

• 通过SSL和SASL（Kerberos），SASL/PLAIN验证机制支持生产者，消费者与代理连接时的身份认证
• 支持代理与ZooKeeper连接身份验证
• 通信时数据加密
• 客户端读、写权限认证
• kafka支持与外部其他认证授权服务的集成

7）数据备份

　　kafka可以为每个主题指定副本数，对数据进行持久化本分，可以一定程度上防止数据丢失，提高可用性。

8）轻量级

　　kafka代理时无状态的，即代理不记录消息是否被消费，消费偏移量的管理交由消费者自已或组协调器来维护，集群本身几乎不需要生产者和消费者的状态信息，使得Kafka非常轻量级。

9）消息压缩

　　kafka支持Gzip，Snappy，LZ4这三种压缩方式，通常把多条消息放在一起组成MessageSet，然后再把MessageSet放到一条消息里面去，从而提高压缩比率进而提高吞吐量。

5.Kafka应用场景

消息队列中间件是当前处理大数据一个非常重要的组件，用来解决应用解耦，异步通信，流量控制等问题，从而构建一个高效，灵活，消息同步和异步传输处理，存储转发，可伸缩和最终一致性的稳定系统。

当前比较流行的消息中间件有：kafka，RabbitMQ，Redis，ActiveMQ等

　　1）消息系统

　　2）应用监控

　　3）网站用户行为追踪

　　4）流处理

　　5）持久性日志

 

 

tips:

 

1.producer：
　　消息生产者，发布消息到 kafka 集群的终端或服务。
2.broker：
　　kafka 集群中包含的服务器。
3.topic：
　　每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。
4.partition：
　　partition 是物理上的概念，每个 topic 包含一个或多个 partition, topic 中的消息是以 partition 分区的形式存储的。kafka 分配的单位是 partition。
5.consumer：
　　从 kafka 集群中消费消息的终端或服务。
6.Consumer group：
　　high-level consumer API 中，每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。
7.replica：
　　partition 的副本，保障 partition 的高可用。Kafka 支持以 partition 为单位对消息进行冗余备份，每个 Partition 都必须配置至少1个 replication。replication-factor 参数指定了 replication 的个数，即 partition 的副本个数。
8.leader：
　　replica 中的一个角色， producer 和 consumer 只跟 leader 交互。
9.follower：
　　replica 中的一个角色，从 leader 中复制数据。
10.controller：
　　kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。
12.zookeeper：
　　kafka 通过 zookeeper 来存储集群的 meta 信息。
13.Offset   
　　每个 partition 中的消息都是顺序存储的，每个消息都是有编号的，编号是顺序增长的。这个编号叫 offset，offset 记录了消息在 partition 中的位置。注意：offset 在一个 partition 内是有序的，多个 partition 之间的 offset 是独立存在的。
14.Leader replica  
　　在partition 的多个副本 replication 中，有一个副本叫主副本（即Leader replica），所有消息消费者和消息生产者的读写请求都由 Leader replica 处理，这么做是为了保证一致性。其他副本叫从副本（即 Follower   replica）,从副本 从 主副本处把数据更新同步到本地。
15.ISR（全拼为：In-Sync Replica）
　　从副本中，如果从主副本处把数据更新同步到本地了，那么这个从副本处于ISR状态（已同步状态），如果没有完全与主副本同步，那么会被从ISR中踢出去，处于非同步状态。 

　一个 topic 有3个 partition，每个 partition 维护着独立的 offset。如 partition 0 中，最先发送到这个 partition 中的消息，offset 为0，后来的消息 offset 为1,2,3...依次类推。