Kafka

Kafka基本原理详解-CSDN博客

调试工具：Offset Explorer

Define：

Kafka [1]  是一种高吞吐量 [2]  的分布式发布订阅消息系统，有如下特性：

通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。

高吞吐量 [2]  ：即使是非常普通的硬件Kafka也可以支持每秒数百万 [2]  的消息。

支持通过Kafka服务器和消费机集群来分区消息。

支持Hadoop并行数据加载。 [3] 

相关术语：

"Broker" Kafka集群包含一个或多个服务器，这种服务器被称为broker [5] 

"Topic" 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

"Partition" Partition是物理上的概念，每个Topic包含一个或多个Partition.

"Producer" 负责发布消息到Kafka broker

"Consumer" 消息消费者，向Kafka broker读取消息的客户端。

"Consumer Group" 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。它的主要目的是记录offset，如果创建了一模一样的goup, 那么Kafka会把它们当成一个goup来处理，从上一次记录的offset开始消费。

================================================

Performance：尤其优秀，写数据非常厉害；数据量大时，会动态调整动态支撑；（network io最影响程序性能，稍微好一点是disk io，影响再小的是memory io）

Distribution：集群概念，分布式系统，不易挂机；

Topic：Service里嵌套一个SDK作为Kafka的Producer，Kafka将通过其指定的topic将数据发送到目标地址；topic是一个虚拟/逻辑概念（logic concept）

Pull to consumer：consumer主动通过topic向kafka询问并下载msg ======会产生什么问题？？？？===一个consumer group中的各个consumer消费的消息进度可能不一样，在长时间的消耗下，网络环境以及进程处理速度都会影响到consumer的消费速度，因此不同的consumer在同一时间，读到的各自消费的partition的offset肯定会不一样。

Partition：一个topic下可以有多个partition，topicname+序号：partition_name；partition存在于实体机上，而这些实体机叫做Broker

Broker：一个实体机，partition是其上的一个文件夹；如果我有6个broker，而topic共有36个partition，那么broker会将这些partition均匀分布在这些broker上（Kafka自动计算）========具体怎么放？？？？？

转发时往哪里存？Kafka的数据不会丢，所以不会写到内存里，会写到磁盘里，即存在partition里

Segment：Partition下可以有多个segment，一个存放数据的文件：xxx.log(存消息), xxx.index（存索引）;xxxxxxx.log以数字为名，表示文件中第一个数据的offset。

Offset：消息编号，写入index，对应记录字节编号。每一行对应一条记录，使用二分法加快查找速度；然后随机读写指定磁盘字节位置（顺序读写很慢），可以加快速度。

Consumer Group(每个group中的consumer不会拿到同样的消息)：可以直接映射到partition，直接读.log；可以一次性拿6个partition，有负载均衡（round robbi）=====consumer会崩掉，有新服务进来（partition有的忙有的闲）; 有一个leader

Rebalance: 新增partition的时候会触发

replica: 副本

HA: 高可用

Producer：

ISR：Intime Sync Replica, leader候选人列表

消息有序性：为什么不保证topic层？

A: 在partition层保证消息有序性是为了最大限度地减少Disk io（consumer也顺序消费）。而topic是一个logic concept，producer产生的消息直接写入到对应的partition里，只需要保证单个partition有序即可。如果保证了topic有序，那么topic1下的partition阻塞了，topic2就一直不能写消息，会一直阻塞。

发送batch时有概率乱序,为什么？

homework：如果有两个device疯狂地发送online/offline消息，导致kafka一直 在处理它们的消息 ，而其他设备的正常消息不能被处理，此时 如果要改善这种情况，怎么处理？

A：当同一个device的消息在一定时间内积累到一定数量，就新增一个topic，将这个device的消息发送给这个topic，consumer group消费这个新topic里 的数据，相当于专门给这个device的消息开了一个线程组来消费。

集群配置 replica设置为1，相当于没有备份，任何一台broker挂掉，数据都会丢失

===========

kafka常见问题：

1. 消息堆积：partition和dsn是一对多的关系，这样可以保证同一个dsn消息的有序性，但是如果其中某个dsn短时间内产生大量消息，那么就会造成消息堆积，其他dsn的消息无法被处理（这里也设计到数据倾斜）。如果broker和consumer挂掉，而又没有立即重启，也有可能产生消息堆积。如果partition分配不合理或consumer消费能力不足，也会产生消息堆积。
2. 数据倾斜：而这里的数据倾斜是指有的partition里的消息多，有的partition里的消息少。producer发送消息到partition里，有的partition里的dsn产生消息多，有的产生消息少，这就造成某个partition的压力非常大，进而造成某个broker运行慢，且容易造成OOM（out of memory,JVM 没有足够的内存空间可供分配）
3. 消息幂等：保证消息不被重复消费，消息重复消费的情况：1. broker宕机，没有回复offset，切换broker leader后就会重复消费；2. consumer挂掉(推测机制 应该为：kafka一段时间内没有收到consumer的心跳包，判断其死亡，随后向consumer leader报告，consumer leader向coordinater发送消息并触发consumer rebalance，移除已死亡的consumer，加入新的consumer；但若已死亡的consumer没来得及上报offset到_consumer_offsets(旧机制为 zookeepre),此时新的consumer就会重复消费)；3. 网络延迟（上报offset不及时）
   1. Rebalance：如果先消费 ，后提交offset，当一个消息A还没消费完时，加入了另一个新的consumer，从而导致消息A没有消费成功，rebalance后，另一个consumer又把这条消息消费一遍。
   2. producer宕机：因为业务问题导致的宕机，再重启 后可能会重发数据。
4. 消息漏消费：
   1. offset设置为自动提交，提交后数据还在内存中未处理，此时kill掉线程，那么offset已经提交 ，下一次会从该 offset+1开始上报新的offset，但是之前的offset对应的数据还在内存中，没有处理到DB中，所以这部分数据就会被漏消费。
   2. producer的消息应答机制 ，acks!=all。那么就无法确认所有的partition leader和followers都收到了消息 ，并且在broker挂掉时，zookeeper会选举一个follower作为新的leader，此时如果该新leader的offset和旧leader的offset不同步，也会造成消息 漏消费。
   3. consumer宕机，先提交了offset，但是消息还没被消费完。