kafka入门

分布式流式处理平台，具有高吞吐、可持久化、可水平扩展、支持流数据处理等特性。其常扮演的3大角色：

• 消息系统：和其他消息系统一样都具备系统解耦、冗余存储、流量削峰、异步通信等功能，但是它还提供了消息顺序性保障和回溯消费的功能。
• 存储系统：可以将数据持久化到磁盘，与基于内存的存储系统相比降低了数据丢失的风险。将数据保留策略设置为“永久”可以作为长期的数据存储系统。
• 流式处理平台：为流式处理框架提供可靠的数据来源，并具备一套完整的流式处理类库。

一、基本概念

其体系中基本概念包含生产者producer、服务节点broker、消费者consumer、消费者组group、服务注册中心zookeeper、主题topic、分区partition、偏移量offset、桶文件segment。

• zookeeper：负责管理集群元数据、通过主从选举实现故障转移。
• producer：负责生产消息并发送到broker。
• broker：负责接收并存储消息到磁盘。
• consumer：负责从broker订阅并消费消息。
• group：给一个或多个consumer设置相同的groupId即形成一个消费者组。
• topic：主题是一个逻辑概念，kafka中的消息以主题为单位进行归类，producer将消息发送到特定的主题，consumer订阅特定主题并消费。
• partition：由topic细分出来的，一个分区只属于单个topic，同一topic下的不通分区存储的消息是不相同的。存储层面上可以理解为一个可追加的日志文件。
• offset：消息被追加到分区日志文件时都会分配一个偏移量，其是消息在分区里的唯一标识，因为offset不能跨越分区，所以kafka只能通过它来保证消息在分区内的顺序性，而不能保证在主题内有序。
• segment：partition在物理上由多个segment数据文件组成，每个数据文件大小相同，按顺序读写，文件以该段中最小的offset命名，如：0000.log，方便使用二分查找定位到消息。

二、灾备能力

1、消费者consumer

consumer使用拉（pull）模式从broker拉取消息，并保存消费的具体位置，当consumer宕机后恢复上线时可以根据之前保存的消费位置重新拉取消息消费，这样就不会造成数据丢失。

2、分区partition

消息被顺序追加在每个分区日志文件的末尾，分区可以分布在不同的broker上，一个topic可以横跨多个broker。每条消息被发送到broker之前，会根据分区规则选择存储到哪个分区。如果一个topic只对应一个partition，那么这个partition主节点所在服务器的I/O将会成为主题的性能瓶颈。

kafka为分区引入了多副本机制，通过增加副本数量提升容灾能力，同一分区的不同副本中保存的是相同消息（主从完全同步之时），副本之间一主多从，主（leader）副本处理读写请求，从（follower）副本只负责从leader中同步消息。副本处于不同broker中，当leader故障时，在众多follower中选举出新的leader对外提供读写服务，通过多副本机制实现故障转移，当kafka集群中某个broker失效时仍可保证服务可用。

三、consumer拉取规则

HW是Hight Watermark的缩写，俗称高水位，它标识了一个特定的消息偏移量，消费者只能拉取到这个offset之前的消息。如图一所示：一个日志文件，其中有9条消息，第一条消息的offset（LogStartOffset）为0，最后一条消息的offset为8，offset为9的消息用虚线框表示，称之为LEO（Log End Offset），代表下一条待写入的消息。日志文件的HW为6，表示consumer只能拉取offset在0-5之间的消息，而offset为6的消息对consumer是不可见的。

假设当前分区有1个leader和2个follower，此时分区的HW和LEO都为3，消息3和消息4从生产者发出之后会先存入leader中，如图二所示：

在消息写入leader之后，follower会发送拉取请求来拉取消息3和消息4以进行消息同步，在同步过程中，不通副本的同步效率也不尽相同，某一时刻follower1完全跟上了leader的脚步，而follower2只同步了消息3，leader和follower的LEO为5，follower2的LEO为4，那么当前分区的HW取最小值4，此时consumer只能消费到offset为0-3之间的消息。如图三所示：

当所有副本都成功写入了消息3和消息4以后，整个分区的HW和LEO都变成了5，此时consumer可以消费到offset为0-4之间的消息。如图四所示：

由此可见，kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。同步复制要求所有能工作的follower都复制完，该消息才会被确认为提交成功，这种复制方式极大地影响了性能。而在异步复制方式下，follower异步地从leader中复制数据，数据只要被leader写入就认为是提交成功，如果follower还没有复制完而落后于leader，此时leader宕机则会造成数据丢失。

四、服务端参数配置

1、zookeeper.connect

broker要连接的zookeeper集群地址，zookeeper为多节点时，节点之间用逗号隔开，类似于localhost1:2181,localhost2:2181,localhost3:2181。

2、listeners

该参数指明broker监听客户端连接的地址列表，即为客户端要连接broker的入口地址列表，格式为protocol://hostname:port，多个地址之间用逗号隔开。protocol代表协议，目前支持的协议有PLAINTEXT、SSL、SASL_SSL等，如果未开启安全认证，就使用简单的PLAINTEXT即可；hostname代表主机名；port代表服务端口。比如PLAINTEXT://192.168.0.12:9092,PLAINTEXT://192.168.0.13:9092,PLAINTEXT://192.168.0.14:9092。如果不指定主机名，表示绑定默认网卡，就有可能会绑到127.0.0.1上导致无法对外提供服务，如果主机名为0.0.0.0，表示绑定所有网卡。因为公有云上的机器通常配备多块网卡，包含私网网卡和公网网卡，所以需要advertised.listeners参数来绑定公网IP对外提供服务，而listeners参数只能绑定内网IP。

3、broker.id

该参数用来指定kafka集群中broker的唯一标识，默认值为-1，如果集群中没设置，kafka会自动生成一个。

4、log.dir和log.dirs

kafka把所有消息都保存在磁盘上，log.dir用来配置单个根目录，log.dirs用来配置多个根目录（用逗号隔开）。log.dirs优先级高于log.dir（多高于单）。

5、message.max.bytes

指定broker所能接收消息的最大值，默认为1000012B，约等于976.6KB，producer发送的消息大于该值时，producer的send方法就会报RecordTooLargeException异常。