【深入理解Kafka】Kafka基础
目前Kafka已经定位为一个分布式流式处理平台,它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用。
目前越来越多的开源分布式处理系统如Clo?dera、Storm、Spark、Flink 等都支持与Kafka集成。
初识Kafka
Kafka之所以受到越来越多的青睐，与它所“扮演”的三大角色是分不开的：
- 消息系统：Kafka 和传统的消息系统（也称作消息中间件）都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
- 存储系统：Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于Kafka 的消息持久化功能和多副本机制，我们可以把Kafka作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置为“永久”或启用主题的日志压缩功能即可。
- 流式处理平台：Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。
基本概念
一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干Consumer，以及一个ZooKeeper集群。
- Producer：生产者，也就是发送消息的一方。生产者负责创建消息,然后将其投递到Kafka中。
- Consumer：消费者，也就是接收消息的一方。消费者连接到Kafka上并接收消息，进而进行相应的业务逻辑处理。
- Broker：服务代理节点。对于Kafka而言，Broker可以简单地看作一个独立的Kafka服务节点或Kafka服务实例。大多数情况下也可以将Broker看作一台Kafka服务器,前提是这台服务器上只部署了一个Kafka实例。一个或多个Broker组成了一个Kafka集群。一般而言,我们更习惯使用首字母小写的broker来表示服务代理节点。
主题与分区
在 Kafka 中 还 有 两 个 特 别 重 要 的 概 念 — 主 题 ( Topic ) 与 分 区(Partition)。Kafka中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题(发送到Kafka集群中的每一条消息都要指定一个主题)，而消费者负责订阅主题并进行消费。
主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题 , 很多时候也会把分区称为主题分区 ( Topic- Partition)。同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志(Log)文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量(offset)**。offset是消息在分区中的唯一标识，Kafka通过它来保证消息在分区内的顺序性，不过offset并不跨越分区，也就是说，Kafka保证的是分区有序而不是主题有序。**
多副本机制
Kafka 为分区引入了多副本(Replica)机制，通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息(在同一时刻，副本之间并非完全一样)，副本之间是“一主多从”的关系，其中leader副本负责处理读写请求，follower副本只负责与leader副本的消息同步。副本处于不同的broker中，当leader副本出现故障时，从follower副本中重新选举新的leader副本对外提供服务。Kafka通过多副本机制实现了故障的自动转移,当Kafka集群中某个broker失效时仍然能保证服务可用。
如下图所示，Kafka集群中有4个broker，某个主题中有3个分区，且副本因子(即副本个数)也为3，如此每个分区便有1个leader副本和2个follower副本。生产者和消费者只与leader副本进行交互，而follower 副本只负责消息的同步，很多时候follower副本中的消息相对leader副本而言会有一定的滞后。
Kafka 消费端也具备一定的容灾能力。Consumer 使用拉(Pull)模式从服务端拉取消息,并且保存消费的具体位置，当消费者宕机后恢复上线时可以根据之前保存的消费位置重新拉取需要的消息进行消费，这样就不会造成消息丢失。
服务端参数配置
Kafka服务端还有很多参数配置，涉及使用、调优的各个方面,虽然这些参数在大多数情况下不需要更改，但了解这些参数，以及在特殊应用需求的情况下进行有针对性的调优，可以更好地利用 Kafka为我们工作。下面挑选一些重要的服务端参数来做细致的说明，这些参数都配置在$KAFKA_HOME/config/server.properties文件中。
zookeeper.connect
该参数指明**broker要连接的ZooKeeper集群的服务地址(包含端口号)**，没有默认值,且此参数为必填项。可以配置为localhost:2181，如果ZooKeeper集群中有多个节点，则可以用逗号将每个节点隔开，类似于localhost1:2181，localhost2:2181，localhost3:2181这种格式。
listeners
该参数指明broker监听客户端连接的地址列表，即为客户端要连接broker的入又地址列表，配置格式为protocol1://hostname1:port1，protocol2://hostname2:port2，其中protocol代表协议类型，Kafka当前支持的协议类型有PLAINTEXT、SSL、SASL_SSL等，如果未开启安全认证，则使用简单的 PLAINTEXT 即可。如果不指定主机名，则表示绑定默认网卡，注意有可能会绑定到127.0.0.1，这样无法对外提供服务，所以主机名最好不要为空；如果主机 名 是 0.0.0.0，则表示绑定所有的网卡。
broker.id
该参数用来指定Kafka集群中broker的唯一标识，默认值为-1。
log.dir 和 log.dirs
Kafka 把所有的消息都保存在磁盘上,而这两个参数用来配置 Kafka 日志文件存放的根目录。一般情况下，log.dir 用来配置单个根目录，而 log.dirs 用来配置多个根目录(以逗号分隔)。log.dirs 的优先级比 log.dir 高，但是如果没有配置log.dirs，则会以 log.dir 配置为准。默认情况下只配置了 log.dir 参数，其默认值为/tmp/kafka-logs。
message.max.bytes
该参数用来指定 broker 所能接收消息的最大值，如果 Producer 发送的消息大于这个参数所设置的值，那么(Producer)就会报出RecordTooLargeException 的异常。为了避免修改此参数而引起级联的影响，建议在修改此参数之前考虑分拆消息的可行性。
参考
《深入理解Kafka：核心设计与实践原理》-朱忠华