Kafka

1、概述

1.1.定义

kafka是一个分布式的基于发布/订阅模式的消息队列，是使用Scala编写具有高水平扩展和高吞吐量的分布式消息系统，主要应用于大数据实时处理领域。

1.2.消息队列

MQ(Message Queue)从本质上来说，就是[发-存-消费]，是一个转发器。首先生产者将消息发送到一个队列容器中，再转发给消费者进行消费。  

消息队列模型

1.3.消息队列的优点

• 解耦: 允许独立扩展各自的处理过程，只要求确保遵守相同的接口约束
• 可恢复: 消息队列降低了进程间的耦合度，即使处理消息的进程挂掉，加入队列的消息可在系统恢复后被处理
• 缓冲: 有助于控制和优化数据流经过系统的速度
• 灵活&峰值处理能力: 使用消息队列可以解决组件访问的并发压力，避免流量洪峰压垮系统
• 异步: 消息队列提供异步处理机制，用户不用等待消息立即处理，可以继续执行其他进程

1.4.主要MQ对比

	ActiveMQ	RabbitMQ	rocketMq	Kafka
时效性	ms级	微妙	ms	ms
数据吞吐量	1万/秒	1万/秒	10万/秒	10万/秒
消息可靠性	低概率丢数据	参数优化后0丢失	参数优化0丢失
功能支持	MQ领域功能极其完备	局域Erlang开发，并发能力强，性能好，延时低	MQ功能较为完善，分布式，扩展性好	功能简单，支持简单MQ功能，在大数据领域的实时计算和日志采集大规模使用

2、kafka基本概念

2.1.特性

1. 可以发布和订阅流式记录
2. 可以存储流式的记录，有较好的容错性
3. 可以在记录产生时就进行处理

2.2.使用场景

kafka可以用于两大类别的场景：

1. 构造实时流数据管道，它可以在系统和应用之间可靠的获取数据(相当于message queue)
2. 构建实时流式应用程序，对这些流数据进行转换或者影响(流处理，通过kafka stream topic和topic之间内部进行变化)

2.3.基本概念

kafka通过topic对消息进行分裂，发送消息者为生产者，订阅消息者为消费者，kafka是一个或多个server组成的集群来运行，每个server称为一个broker。以下为官方示例： 

kafka有四个核心的API:

• Producer API: 允许一个应用程序发布一串流式数据到一个或多个kafka topic
• Consumer API: 允许一个应用程序订阅一个或多个topic，并且对发布给他们的流式数据进行处理
• Streams API: 允许一个应用程序作为一个流处理器，消费一个或者多个topic产生的输入流，然后生产一个输出流到一个或者多个topic中去，在输入输出流中进行有效的转换
• Connector API: 允许构建并运行可重用的生产者或消费者，将kafka topics连接到已存在的应用程序或者数据系统

kafka的一些基本概念

• topic：topic就是数据主题，是数据记录发布的地方，可以用来区分业务系统。topic总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。
• partition：每一个topic都可以被分割为一个或者多个分区，每个分区都是有序且顺序不可变的记录集。
  • 一般情况下partition数量是broker数量的整数倍，即partition % broker = 0
  • 一个分区只允许同一个消费者组的一个消费者消费
  • 一个分区可以允许不同的消费者组的消费者消费，每组有且只有一个消费者消费

• broker：kafka集群包括一个或多个服务器，每一个服务器节点称为broker。
• replication：分区副本，副本是一个分区的备份，为了防止消息丢失创建的分区备份。每个partition会有leader partition和follow partition，每个partition中的leader用来和consumer进行交互。

• producer：生产者，即消息的发布者，将某topic的消息发送到对应的partition中。生产者所生产的消息默认会平均分配到各个分区，也可以直接指定到要写入的分区，也可根据消息的key来计算路由。
• consumer：消费者，从broker中读取消息

• 一个消费者可以消费多个topic中的消息
• 一个消费者可以消费同一个topic中的多个partition中的消息
• 一个分区中的消息允许多个无关的消费者（不在同一个group）同时消费

• consumer group：消费者组，kafka提供的可扩展且具有容错性的消费者机制，一个组内可以有多个消费者，组内的消费者会协调平均消费订阅主题的所有分区。

• ISR/AR/OSR：ISR，In-SyncReplicas是指副本同步列表，ISR列表是由leader负责维护；OSR，Outof-Sync Replicas，不可用副本列表；AR，Assigned Replicas，AR全副本列表初始化时AR=ISR+OSR
• offset：偏移量，每条消息都有一个在当前partition下的唯一64位字节的offset，它是相对于当前分区下的第一条消息的偏移量。kafka采用分片和索引的机制，将每个partition分为多个segment，每个segment对应两个文件index和log。

例如：需要查找第103消息，通过和当前分区第一条消息偏移量比较，得到偏移量为3，通过偏移量3在xxxx.log文件中获取到m0103这条消息。

• Broker Controller：kakfa集群的多个broker ，有一个被选举为controller，负责整个集群中partition和replicas的状态，如partition leader故障，controller 会负责从ISR中的follow中选取一个新的leader，选举算法为轮询算法
• HW和LEO：HW，HighWatermark，高水位，表示consumer可以消费到的最高partition偏移量，hw保证了kafka集群消息的高可用，保证了partition的leader和follower之间的数据一致性。LEO，Log End Offset，日志最后消息的偏移量，当前最后一个写入的消息在partition中的偏移量。

3、Kafka的rebalance机制和ACK机制

3.1.Rebalance机制

rebalance意思为再平衡，本质上是一组协议，规定了一个consumer group是如何达成一致来来分配订阅的topic的分区。比如一个topic有6个分区，一个consumer group有三个consume，每个consumer消费两个，这就是rebalance。Rebalance是相对于consumer group而言的，每个消费者组会从kafka broker中选取一个组协调者(group coordinator)，coordinator负责对整个consumer group进行管理，当rebalance条件出发后，生成新的分配方案

触发rebalance条件

• consumer group中成员发生改变，新增或减少消费者
• consumer group订阅的topic发生改变
• consumer group订阅的topic的分区发生改变

rebalance分区分配策略 分区分配策略决定了将topic中的partition分配给consumer group中的consumer实例的方式。可以通过kafka配置文件进行配置，kafka提供了三种Rebalance分配方式。

• range：按消费者总数和分区总数的整除运算来获得一个跨度，然后将分区按照跨度进行平局分配，以保证分区尽可能的分配给消费者。如：P(partition) C(consumer)；N=P/C、M=P%C，那么前M个消费者每个分配（N+1）个分区，其余的消费者每个分配N个分区。
• round-robin：将消费者组中的消费者所有的主题分区按照字典排序，然后通过轮询的方式分配给消费者
• sticky：分区的分配要尽可能均匀；分区的分配尽可能与上次的分配保持一致。

3.2.ACK确认机制

ACK参数指定了必须要有多少个分区副本收到消息时，生产者才认为该消息时写入成功的。参数配置如下：

• acks=0: 表示消息写入之前不会收到任何来自服务器的响应。容易造成数据的丢失.
• acks=1: 表示只要集群的leader分区副本收到消息，就会向生产者发送一个成功响应的ack。生产者收到ack即认为该消息写入成功。
• acks=-1/all: 表示所有的参与复制的节点(ISR列表的副本)都收到消息，生产者才会收到来自服务器的响应。

最小同步副本
acks=all时，所有的副本都同步成功了才会向生产者发送ack响应，kafka的broker提供了一个参数min.insync.replicas，该参数设置了是消息至少被写入到多少副本才算成功。 假设有三个分区p0、p1、p2，p0为leader分区，p1、p2为follower

• case1: 当min.insync.replicas=2且acks=all时，如果ISR中只有[p0,p1]，p2被踢出ISR，只要保证两个分区副本同步成功，生产者就会收到成功的响应
• case2: 当min.insync.replicas=2时，如果ISR中只有[p0]，p1、p2被踢出ISR，当acks=all时，则不能成功写入
• case3: 如果acks=all且min.insync.replicas=2，此时ISR列表为[1,2,3],那么还是会等到所有的同步副本都同步了消息，才会向生产者发送成功响应的ack。因为min.insync.replicas=2只是一个最低限制，即同步副本少于该配置值，则会抛异常，而acks=all，是需要保证所有的ISR列表的副本都同步了才可以发送成功响应。

4、Kafka优化

4.1.kafka如何防止消息丢失和重复消费

消息丢失

• producer丢失消息： 生产者发送消息后，可能因为网络的原因导致消息并没有发送出去。kafka提供同步发送消息方法，返回一个future对象，通过阻塞的方式获取响应结果。针对生产者发送消息失败的情况，可以设置producer的重试次数，当网络异常后，可以自动发起重试，避免消息丢失
• consumer丢失消息： 消息被追加到partition后会被分配一个特定的偏移量offset。offset表示consumer当前消费到的partition分区的位置。当consumer拉取某个分区的消息后，消费者会自动提交offset。如果此时，偏移量提交成功，但是消息消费失败，则该消息视为丢失。可以通过设置enable.auto.commit设置为false，关闭自动提交offset，在每次消息消费成功后手动提交offset。
• broker丢失消息： 当消息发送到了分区的leader副本，leader 副本所在的 broker 突然挂掉，那么就要从 follower 副本重新选出一个 leader ，但是 leader 的数据还有一些没有被 follower 副本的同步的话，就会造成消息丢失。解决办法就是设置acks=all，ACK机制具体介绍参见 3.3 ACK确认机制

消息重复消费

• 生产者重复发送： 发送消息配置了重试机制，如：当网络波动，producer未收到broker的ack，就会触发重试。broker收到了消息，由于重试机制，导致消息的重复发送。
  解决办法: 关闭重试机制；开启kafka的消息幂等性，设置参数(enable.idempotence:true)

• 消费者重复消费： 可能的原因

  • 消费成功后，未提交offset，此时消费者挂了
  • 消费成功后，未提交offset，broker挂了
  • 消费成功后，未提交offset，超过了配置的超时时间，消费者被踢出，触发rebalance，导致消费成功但未提交的offset的消息被重新消费
    解决办法：
  • 消费端设置唯一键(分布式数据库不可用)
  • 提高消费端的处理能力，避免rebalance，或者修改消费消息的超时时间和减少每次拉取的消息数量

4.2.如何保证消息的顺序性

kafka只保证单个partition有序，如果需要保证多个partition有序，不仅broker保存的数据要保持顺序，消费者也要顺序消费。如果为了保证partition消息顺序消费，kafka退化为单一队列，无并发而言。

保证顺序消费

• 全局顺序消费，实现方式：一个topic只创建一个partition，这样就保证所有的消息都分配到同一个分区，保证了消息的顺序消费。
• 局部顺序，实现方式：生产者发送消息指定要发送到哪个partition

4.3.消费者数量和partition的对应关系

• 单播模式1：topic有一个partition，consumer group有多个consumer，此时只能由消费者组中的一个consumer消费，其他consumer处于空闲状态。

• 单播模式2：topic有多个partition，consumer group多个consumer，根据分区策略，consumer可以实现并行消费。

• 广播模式1：topic有一个partition，多个consumer group，topic的partition只能被同一个consumer group中的一个consumer消费。

• 广播模式2：topic有多个partition，多个consumer group，topic的partition，根据分区策略，同一个consumer group中的consumer可以并行消费。

5.kafka在linux中安装及基础命令

详情请参见：kafka安装