1. kafka如何做到高吞吐量的？
采用批处理。如果一条一条的发消息，假如每条消息需要2毫秒，那么吞吐量不超过1000/2=500条/秒。如果采用批处理，假如此刻累积了100条消息，批处理需要等待一段时间比如8毫秒，加上发送一次的延时是2毫秒，那么一次批处理的时间是10毫秒。平均一条消息的耗时为10/100=0.1毫秒，那么此时的吞吐量为1000/0.1=10000条/秒。性能提升了近20倍。
2. 在kafka内部，是如何支撑起高吞吐/低延时的呢？
- 每次写入操作，都是先把数据写到操作系统的页缓存上（页缓存是在内存中分配的），然后由操作系统自行决定什么时候把页缓存上的数据写入到磁盘上。
- Kafka 不必直接与底层的文件系统打交道。所有烦琐的 I/O 操作都交由操作系统来处理
- Kafka 写入操作采用追加写入（ append ）的方式，避免了磁盘随机写操作。（磁盘的随机读写确实很慢，但是顺序读写却很快）
- 使用以 sendfile 为代表的零拷贝技术加强网络间的数据传输效率。
3. Topic、分区、副本、消费组、offset
- Topic：发送到Kafka的每一条消息都有一个类别，用主题（Topic）来表示。通常，不同应用产生不同类型的数据，可以设置成不同的Topic。
- 分区：每个Topic对应若干个分区，对于每个Topic，kafka都会维护一个分区日志。每个分区都是一个有序的，不可变的记录序列，不断附加到结构化的提交日志中。分区中的每个记录都被分配一个称为偏移量的顺序ID号，它唯一地标识分区中的每个记录。每个分区的偏移量都从0开始，不同分区之间的偏移量都是互相独立的，不会互相影响。kafka 以分区作为最小的粒度，将每个分区分配给消费组中不同的而且是唯一的消费者，并确保一个分区只属于一个消费者， 这个消费者就是这个分区的唯一读取线程。那么，只要分区的消息是有序的，消费者处理的消息顺序就有保证。每个主题有多个分区，不同的消费者处理不同的分区，所以Kafka不仅保证了消息的有序性，也做到了消费者的负载均衡。Kafka partition 实际上并没有太多的业务含义，它的引入就是单纯地为了提升系统的吞吐量，因此在创建 Kafka topic 的时候可以根据集群实际配置设置具体的 partition 数， 实现整体性能的最大化。
- 副本：为了故障容错，每个分区都会以副本的方式复制到多个消息代理节点上。其中一个节点为主副本，其它节点为从副本。主副本会负责所有的客户端读写操作，备份副本仅仅从主副本同步数据。当主副本出现故障时，备份副本中的一个副本会被选择为新的主副本。
- 消费组：生产者发布消息时根据消息是否有键采用不同的分区策略，消息没有键时，通过轮询方式进行客户端负载均衡；消息有键时，根据分区语义确保相同键的消息总是发送 到同一个分区。Kafka 消费者通过订阅主题来消费消息，并且每个消费者都会设置一个消费组名称，因为生产 者发布到主题的每一条消息都只会发送给消费组的一个消费者。所以，如果要实现传统消息系统的“队列”模型，可以让每个消费者都拥有相同的消费组名称，这样消息就会负载均衡到所有的消费者；如果要实现“发布－订阅”模型， 那么每个消费者的消费组名称都不相同，这样每条消息就会广播给所有的消费者。
- 注意：Kafka 的消费者消费消息时，只保证在一个分区内消息的完全有序性，并不保证同一个主题中多个分区的消息顺序。消费者读取一个分区消息的顺序和生产者写入到这个分区的顺序是一致的。比如，生产者写入“hello ”和“kafka ”两条消息到分区P1，则消费者读取到的顺序也一定是 hello 和 kafka，如果业务上需要保证所有消息完全一致，只能通过设置一个分区完成，但这种做法的缺点是最多只能有一个消费者进行消费。 一般来说，只需要保证每个分区的有序性，再对消息加上键来保证相同键的所有消息落入同一个分区，就可以满足绝大多数的应用。
- offset：topic partition 下的每条消息都被分配一个位移值。实际上 Kafka 消费者端也有位移（ offset ）的概念，但一定要注意这两个 offset 属于不同的概念。显然，每条消息在某个 partition 位移是固定的，但消费该 partition 的消费者的位移会随着消费进度不断前移，但终究不可能超过该分区最新一条消息的位移 。
- 总结：综合之前说的 topic partition offset ，我们可以断言 Kafka 中的一条消息其实就是一个 <topic,partition,offset>三元组（tuple ），通过该元组值我们可以在 Kafka 集群中找到唯一对应的那条消息。
4. 使用场景
- 消息传输：替代传统的消息总线或者消息代理
- 网站行为日志：Kafka最早就是用于重建用户行为数据追踪系统的。网站上的用户操作都会以消息的形式发送到Kafka的某个对应的topic上。
- 审计数据收集
- 日志收集
- 流式处理：0.10.0.0开始，推出了Kafka Streams。老牌流式处理框架有：Apache Storm、Spark Streaming、Apache Flink
5. kafka如何保证消息不丢失？不重复消费？
保证不丢失：
- 对于生产端：设置acks=all，让数据写入leader和所有follower后返回ack（为0：不等数据写入磁盘就返回，容易丢数据。为1：成功写入leader就返回，不管follower）
- 注意：producer.type参数从0.9.X开始就已经没有了
- 对于消费端：consumer 关闭自动提交位移，消息被成功处理之后手动提交位移。
不重复消费：消费端增加去重表
6. Kafka消息积压怎么办？
- 增加分区数量，同时增加消费组中消费者的数量，分区数量 = 消费者数量【kafka 的分区只能绑定一个消费组的一个消费者，消费者过多并不能产生实质性的作用】
- 增加消费组每批拉取数据的数量
7. 消费者分区分配策略（partition.assignment.strategy）
两种分配策略： range和roundrobin，默认是range。
range策略（针对的是某个topic的分区和其消费组）：
1. 把分区和消费者按照顺序排好
2. 用分区总数/消费者总数，如果除尽则平均分配，否则排在前面的每个消费者多负责一个分区
roundrobin策略（针对所有分区）：
1. 如果所有消费者订阅的topic都是相同的，则只需要顺序分配即可。
2. 如果消费者订阅的topic不是很一致，则要考虑：
- 消费者要消费对应topic上的分区
- 一个分区只能被同一个组的一个消费者消费
当以下事件发生时，Kafka 将会进行一次分区分配：
- 同一个 Consumer Group 内新增消费者
- 消费者离开当前所属的Consumer Group，包括shuts down 或 crashes
- 订阅的主题新增分区
8. 为什么Kafka支持增加分区却不能减少分区？
一个明显的原因就是，如果减少分区，分区所在的消息如何处置？
9. 为什么要有消费者组的概念？
消费组保证了：一个分区只能被同个消费组中唯一一个消费者消费，避免了消费者的争抢【同一个组中的多个消费者不能消费同一个分区】。
一个组的一个消费者可以消费多个分区，同一个组的消费者所消费的分区一定不重复。
10. 分布式模型
1. 生产者发布消息时根据消息是否有键采用不同的分区策略：消息没有键时，通过轮询方式进行客户端负载均衡；消息有键时，根据分区语义确保相同键的消息总是发送到同一个分区
2. 发布的消息包含键值和时间戳，到达指定的分区后，都会分配一个自增的偏移量。kafka以分区作为最小的粒度，将每个分区分配给消费组中唯一的消费者，确保一个分区只属于一个消费者。
3. 消费模型有两种：推模型和拉模型。
- 基于推送模型的消息系统，由消息代理记录消费者的消费状态。消息代理将消息推送给消费者后，将此条消息标记为已消费。如果在到达消费者之前消费者挂掉了，那么此条消息就会丢失（虽然被标记已消费，但没有真正消费）。
- kafka采取拉取模型，由消费者自己记录消费的状态。每个消费者互相独立的顺序读取每个分区的消息并记录自己的消费进度。
11. 如何确定分区数量？
创建只有一个分区的topic，然后测试生产和消费者二者的吞吐量取最大的一个T，然后生产目标吞吐量是M，则分区数 = M/T。
12. 生产者消息分区策略
1. 默认轮询策略：将消息以轮询的方式写入所有分区
2. 随机策略：将消息随机的写入分区
3. 按消息键保留策略：相同键的消息总会落到同一个分区
--