Kafka框架详解

Kafka

1、Kafka介绍

​ Kafka是最初由linkedin公司开发的，使用scala语言编写，kafka是一个分布式，分区的，多副本的，多订阅者的消息队列系统。

2、Kafka相比其他消息队列的优势

​ 常见的消息队列：RabbitMQ，Redis ，zeroMQ ,ActiveMQ

Kafka的优势：

• 可靠性：分布式的，分区，复制和容错的。
• 可扩展性：Kafka消息传递系统轻松缩放，无需停机。
• 耐用性：Kafka使用分布式提交日志，这意味着消息会尽可能快速的保存在磁盘上，因此它是持久的。
• 性能：Kafka对于发布和定于消息都具有高吞吐量。即使存储了许多TB的消息，他也爆出稳定的性能。
• Kafka非常快：保证零停机和零数据丢失。

3、Kafka的术语

3.1、Kafka中的术语名词

Broker：kafka集群中包含一个或者多个服务实例，这种服务实例被称为Broker

Topic：每条发布到kafka集群的消息都有一个类别，这个类别就叫做Topic

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

Producer：负责发布消息到kafka的Broker中。

Consumer：消息消费者,向kafka的broker中读取消息的客户端

Consumer Group：每一个Consumer属于一个特定的Consumer Group（可以为每个Consumer指定 groupName）

4、Kafka的架构

5、Kafka能做到消费的有序性吗

• 一个主题（topic）下面有一个分区（partition）即可

5.1、为什么topic下多个分区不能保证有序

• 生产者生产数据到borker的多个分区，每个分区的数据是相对有序的，但整体的数据就无序了。因为消费者在消费的时候是一个个的分区进行消费的，所以不能保证全局有序。

6、分区与消费者组间的关系

• 消费组： 由一个或者多个消费者组成，同一个组中的消费者对于同一条消息只消费一次。
• 某一个主题下的分区数，对于消费组来说，应该小于等于该主题下的分区数。

7、生产者分区策略

• 没有指定分区号、没指定key根据轮询的方式发送到不同的分区
• 没有指定分区号、指定了key，根据key.hashcode%numPartition
• 指定了分区号，则直接将数据写到指定的分区里面去
• 自定义分区策略

//可根据主题和内容发送
public ProducerRecord(String topic, V value)
//根据主题，key、内容发送
public ProducerRecord(String topic, K key, V value)
//根据主题、分区、key、内容发送
public ProducerRecord(String topic, Integer partition, K key, V value)
//根据主题、分区、时间戳、key，内容发送
public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value)

如果没有指定分区号，也没有指定具体的key（轮询）
如果没有指定分区号，指定了具体的key（hash）
	前缀+date.getTime()   fixlog_1564388581914
如果指定了具体的分区号，（按照分区号）
自定义分区
	

8、数据丢失

8.1、生产者保证数据不丢失

• 同步模式：配置=1 （只有Leader收到，-1 所有副本成功，0 不等待）Leader Partition挂了，数据就会丢失

解决：设置 -1 保证produce 写入所有副本算成功 producer.type = sync request.required.acks=-1/all

• 异步模式，当缓冲区满了，如果配置为0（没有收到确认，一满就丢弃），数据立刻丢弃

解决：不限制阻塞超时时间。就是一满生产者就阻

8.2、broker保证数据不丢失

​ broker采用分片副本机制，保证数据高可用。

8.3、customer保证数据不丢失

• 拿到数据后，存储到hbase中或者mysql中，如果hbase或者mysql在这个时候连接不上，就会抛出异常，如果在处理数据的时候已经进行了提交，那么kafka上的offset值已经进行了修改了，但是hbase或者mysql中没有数据，这个时候就会出现数据丢失。 主要是因为offset提交使用了异步提交。

• 解决方案

  • Consumer将数据处理完成之后，再来进行offset的修改提交。默认情况下offset是 自动提交，需要修改为手动提交offset值。
  • 流式计算。高级数据源以kafka为例，由2种方式：receiver (开启WAL，失败可恢复) director （checkpoint保证）

9、数据重复

• 落表（主键或者唯一索引的方式，避免重复数据）
  业务逻辑处理（选择唯一主键存储到Redis或者mongdb中，先查询是否存在，若存在则不处理；若不存在，先插入Redis或Mongdb,再进行业务逻辑处理）

10、Kafka当中数据的查找过程

第一步：通过offset确定数据保存在哪一个segment里面了，

第二步：查找对应的segment里面的index文件 。index文件都是key/value对的。key表示数据在log文件里面的顺序是第几条。value记录了这一条数据在全局的标号。如果能够直接找到对应的offset直接去获取对应的数据即可

​ 如果index文件里面没有存储offset，就会查找offset最近的那一个offset，例如查找offset为7的数据找不到，那么就会去查找offset为6对应的数据，找到之后，再取下一条数据就是offset为7的数据。

11、Kafka auto.offset.reset值详解

earliest

• 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费

latest

• 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据

none

• topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出异常

  latest 这个设置容易丢失消息，假如Kafka出现问题，还有数据往topic中写，这个时候重启Kafka，这个设置会从最新的offset开始消费,中间出问题的哪些就不管了。