Kafka基础知识总结

点击关注上方“ 知了小巷 ”，

设为“置顶或星标”，第一时间送达干货。

1.Kafka分区复制和多数据中心架构

A7ZRfyE.png!web

ry2a2ua.png!web

2.Kafka压测

Kafka官方自带压力测试脚本：

（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。

Kafka压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络IO）。 一般都是网络IO达到瓶颈。

3.Kafka的机器数量

Kafka机器数量 = 2*（峰值生产速度 * 副本数 / 100）+1

4.Kafka 的日志保存时间

默认7天，可修改

5.Kafka的硬盘大小

每天的数据量 * 7天 / 70%

6.Kafka监控

公司自己开发的监控器；

开源的监控器：KafkaManager、KafkaMonitor、kafkaeagle

7.Kakfa分区数

分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。

分区数一般设置为：3-10个

8.副本数设定

一般我们设置成2个或3个，很多企业设置为2个。

9.多少个Topic

通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。

10.Kafka丢不丢数据

Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。

Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。

Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。

Kafka消息送达语义说明

11.Kafka的ISR副本同步队列

ISR（In-Sync Replicas），副本同步队列。 ISR中包括Leader和Follower。如果Leader进程挂掉，会在ISR队列中选择一个服务作为新的Leader。

有 replica.lag.max.messages （延迟条数）和 replica.lag.time.max.ms （延迟时间）两个参数决定一台服务是否可以加入ISR副本队列，在 0.10 版本移除了 replica.lag.max.messages 参数，防止服务频繁的进出队列。

任意一个维度超过阈值都会把Follower剔除出ISR，存入 OSR（Outof-Sync Replicas）列表，新加入的Follower也会先存放在OSR中。

12.Kafka分区分配策略

在 Kafka内部存在两种默认的分区分配策略： Range和 RoundRobin。

Range是默认策略。 Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。

C1-0 将消费 0, 1, 2, 3 分区

C2-0 将消费 4, 5, 6 分区

C2-1 将消费 7, 8, 9 分区

第一步将所有主题分区组成 TopicAndPartition 列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

13.Kafka中数据量计算

每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60= 1150条/每秒钟

平均每秒钟：1150条

低谷每秒钟：50条

高峰每秒钟：1150条*（2-20倍）=2300条-23000条

每条日志大小：0.5k-2k

每秒多少数据量：2.3M-20MB

14.Kafka挂掉

Kafka本身日志

Kafka生产端日志

Kaf'ka消费端日志

网络内存

短期没事

15.Kafka消息数据积压，Kafka消费能力不足怎么处理？

1.如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

2.如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

16.Kafka幂等性

Producer的幂等性指的是当发送同一条消息时，数据在Server端只会被持久化一次，数据不丟不重，但是这里的幂等性是有条件的：

1.Producer（幂等性情况下，是无法获取之前的状态信息，因此是无法做到跨会话级别的不丢不重）。

2.幂等性不能跨多个Topic-Partition，只能保证单个Partition内的幂等性，当涉及多个 Topic-Partition时，这中间的状态并没有同步。

17.Kafka事务

Kafka从0.11版本开始引入了事务支持。事务可以保证Kafka在Exactly Once语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

1.Producer事务

为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID ，并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID。

为了管理Transaction，Kafka 引入了一个新的组件Transaction Coordinator。 Producer就是通过和Transaction Coordinator交互获得Transaction ID对应的任务状态。Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic ，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

2.Consumer事务

上述事务机制主要是从Producer方面考虑，对于Consumer而言，事务的保证就会相对较弱，尤其时无法保证Commit的信息被精确消费。这是由于Consumer可以通过offset访问任意信息，而且不同的Segment File生命周期不同，同一事务的消息可能会出现重启后被删除的情况。