消息中间件之kafka

消息中间件的场景

如果是在分布式系统中，两个服务之间需要通过这种异步队列（生产消费者模式）的方式来处理任务，那单进程级别的队列就无法解决这个问题了。 因此，引入了消息中间件，也就是把消息处理交给第三方的服务，这个服务能够实现数据的存储以及传输，使得在分布式架构下实现跨进程的远程消息通信。 所以，简单来说： 消息中间件是指利用高效可靠的消息传输机制进行平台无关的数据交流，并且基于数 据通信来进行分布式系统的集成。

可以先从基本的消息中间件需求开始思考

• 最基本的是要能支持消息的发送和接收
• 需要涉及到网络通信就一定会涉及到NIO
• 消息中心的消息存储（持久化/非持久化）
• 消息的序列化和反序列化
• 是否跨语言
• 消息的确认机制，如何避免消息重发

高级功能

• 消息的有序性
• 是否支持事务消息
• 消息收发的性能，对高并发大数据量的支持
• 是否支持集群
• 消息的可靠性存储
• 是否支持多协议

安装和启动

下载解压 

tar -xzf kafka_2.13-2.8.0.tgz

cd kafka_2.13-2.8.0

bin/kafka-server-start.sh config/server.properties

 启动后会在zookeeper上创建如下目录

kafka常见应用场景

消息传递

Kafka具有更好的吞吐量，内置的分区，复制和容错能力

网络活动跟踪

将网站活动（页面浏览量，搜索或用户可能采取的其他操作）发布到中心主题，每种活动类型只有一个主题。这些提要可用于一系列用例的订阅，包括实时处理，实时监控，以及加载到Hadoop或脱机数据仓库系统中以进行脱机处理和报告

日志汇总

Kafka提取了文件的详细信息，并将日志或事件数据作为消息流进行了更清晰的抽象。这允许较低延迟的处理，并更容易支持多个数据源和分布式数据消耗。与Scribe或Flume等以日志为中心的系统相比，Kafka具有同样出色的性能，由于复制而提供的更强的耐用性保证以及更低的端到端延迟

kafka的发送和确认消息

kafka对于消息的发送，可以支持同步和异步，从本质上来说，kafka都是采用异步的方式来发送消息到broker，但是kafka并不是每次发送消息都会直 接发送到broker上，而是把消息放到了一个发送队列中，然后通过一个后台线程不断从队列取出消息进 行发送，发送成功后会触发callback。kafka客户端会积累一定量的消息统一组装成一个批量消息发送出 去，触发条件是配置batch.size和linger.ms

kafka消息分发策略

在kafka中，一条消息由key、value两部分构成，在发送一条消息 时，我们可以指定这个key，那么producer会根据key和partition机制来判断当前这条消息应该发送并 存储到哪个partition中。我们可以根据需要进行扩展producer的partition机制。

消息默认的分发机制

默认情况下，kafka采用的是hash取模的分区算法。如果Key为null，则会随机分配一个分区。这个随机 是在这个参数”metadata.max.age.ms”的时间范围内随机选择一个。对于这个时间段内，如果key为 null，则只会发送到唯一的分区。这个值值哦默认情况下是10分钟更新一次 

kafka消息消费原理

在多个partition以及多个consumer的情况下，消费者是如何消费消息的？

1. 如果consumer比partition多，是浪费，因为kafka的设计是在一个partition上是不允许并发的， 所以consumer数不要大于partition数

2. 如果consumer比partition少，一个consumer会对应于多个partitions，这里主要合理分配 consumer数和partition数，否则会导致partition里面的数据被取的不均匀。最好partiton数目是 consumer数目的整数倍，所以partition数目很重要，比如取24，就很容易设定consumer数目

3. 如果consumer从多个partition读到数据，不保证数据间的顺序性，kafka只保证在一个partition 上数据是有序的，但多个partition，根据你读的顺序会有不同

4. 增减consumer，broker，partition会导致rebalance，所以rebalance后consumer对应的 partition会发生变化

coordinator执行Rebalance以及管理consumer的group

当consumer group的第一个consumer启动的时候，它会去和kafka server确定谁是它们组的coordinator。之后该group内的所有成员都会和该 coordinator进行协调通信。消费者向kafka集群中的任意一个broker发送一个 GroupCoordinatorRequest请求，服务端会返回一个负载最小的broker节点的id，并将该broker设置 为coordinator

JoinGroup的过程

在rebalance之前，需要保证coordinator是已经确定好了的，整个rebalance的过程分为两个步骤， Join和Sync

对于每个consumer group子集，都会在服务端对应一个GroupCoordinator进行管理， GroupCoordinator会在zookeeper上添加watcher，当消费者加入或者退出consumer group时，会修 改zookeeper上保存的数据，从而触发GroupCoordinator开始Rebalance操作

当消费者准备加入某个Consumer group或者GroupCoordinator发生故障转移时，消费者并不知道 GroupCoordinator的在网络中的位置，这个时候就需要确定GroupCoordinator，消费者会向集群中的 任意一个Broker节点发送ConsumerMetadataRequest请求，收到请求的broker会返回一个response 作为响应，其中包含管理当前ConsumerGroup的GroupCoordinator，

 消费者会根据broker的返回信息，连接到groupCoordinator，并且发送HeartbeatRequest，发送心 跳的目的是要要奥噶苏GroupCoordinator这个消费者是正常在线的。当消费者在指定时间内没有发送 心跳请求，则GroupCoordinator会触发Rebalance操作

如何保存消费端的消费位置

offset

每个topic可以划分多个分区,每个消息在被添加到分区时，都会被分配一个 offset（称之为偏移量），它是消息在此分区中的唯一编号，kafka通过offset保证消息在分区内的顺 序，offset的顺序不跨分区，即kafka只保证在同一个分区内的消息是有序的

offset在哪里维护？

在kafka中，提供了一个consumer_offsets_* 的一个topic，把offset信息写入到这个topic中。 consumer_offsets——按保存了每个consumer group某一时刻提交的offset信息。 __consumer_offsets 默认有50个分区

计算公式：Math.abs(“groupid”.hashCode())%groupMetadataTopicPartitionCount ;

分区的副本机制

每个分区可以有多个副本，并且在副本集合中会存在一个leader的副本，所有的读写请求都是由leader 副本来进行处理。剩余的其他副本都做为follower副本，follower副本会从leader副本同步消息日志。需要注意的是，kafka集群中的一个broker中最多只能有一个副本，leader副本所在的broker节点的 分区叫leader节点，follower副本所在的broker节点的分区叫follower节点

副本的leader选举

副本根据角色的不同 可分为3类：

• leader副本：响应clients端读写请求的副本
• follower副本：被动地备份leader副本中的数据，不能响应clients端读写请求。
• ISR副本：包含了leader副本和所有与leader副本保持同步的follower副本——如何判定是否与leader同 步后面会提到每个Kafka副本对象都有两个重要的属性：LEO和HW。注意是所有的副本，而不只是 leader副本。

LEO：即日志末端位移(log end offset)，记录了该副本底层日志(log)中下一条消息的位移值。注意是下 一条消息！也就是说，如果LEO=10，那么表示该副本保存了10条消息，位移值范围是[0, 9]。另外， leader LEO和follower LEO的更新是有区别的。

HW：即上面提到的水位值。对于同一个副本对象而言，其HW值不会大于LEO值。小于等于HW值的所 有消息都被认为是“已备份”的（replicated）。同理，leader副本和follower副本的HW更新是有区别的

 

 

ISR

ISR表示目前“可用且消息量与leader相差不多的副本集合，这是整个副本集合的一个子集”。怎么去理解 可用和相差不多这两个词呢？具体来说，ISR集合中的副本必须满足两个条件

1. 副本所在节点必须维持着与zookeeper的连接

2. 副本最后一条消息的offset与leader副本的最后一条消息的offset之间的差值不能超过指定的阈值 (replica.lag.time.max.ms) replica.lag.time.max.ms：如果该follower在此时间间隔内一直没有追 上过leader的所有消息，则该follower就会被剔除isr列表

3. ISR数据保存在Zookeeper的 /brokers/topics//partitions//state 节点中

分区分配策略

在kafka中，存在三种分区分配策略，一种是Range(默认)、 另一种是RoundRobin（轮询）、 StickyAssignor(粘性)。 在消费端中的ConsumerConfig中，通过这个属性来指定分区分配策略

public static final String PARTITION_ASSIGNMENT_STRATEGY_CONFIG = "partition.assignment.strategy";

 

kafka常见配置

• batch.size

生产者发送多个消息到broker上的同一个分区时，为了减少网络请求带来的性能开销，通过批量的方式 来提交消息，可以通过这个参数来控制批量提交的字节数大小，默认大小是16384byte,也就是16kb， 意味着当一批消息大小达到指定的batch.size的时候会统一发送

• linger.ms

Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送，以此提高吞 吐量，而linger.ms就是为每次发送到broker的请求增加一些delay，以此来聚合更多的Message请求 

• group.id

consumer group是kafka提供的可扩展且具有容错性的消费者机制，组内必然可以 有多个消费者或消费者实例(consumer instance)。组内的所有 消费者协调在一起来消费订阅主题(subscribed topics)的所有分区(partition)。当然，每个分区只能由 同一个消费组内的一个consumer来消费

• enable.auto.commit

消费者消费消息以后自动提交，只有当消息提交以后，该消息才不会被再次接收到，还可以配合 auto.commit.interval.ms控制自动提交的频率。 也可以通过consumer.commitSync()的方式实现手动提交

• auto.offset.reset

这个参数是针对新的groupid中的消费者而言的，当有新groupid的消费者来消费指定的topic时，对于 该参数的配置，会有不同的语义

auto.offset.reset=latest情况下，新的消费者将会从其他消费者最后消费的offset处开始消费Topic下的 消息

auto.offset.reset= earliest情况下，新的消费者会从该topic最早的消息开始消费

auto.offset.reset=none情况下，新的消费者加入以后，由于之前不存在offset，则会直接抛出异常。

• max.poll.records

 此设置限制每次调用poll返回的消息数，这样可以更容易的预测每次poll间隔要处理的最大值。通过调 整此值，可以减少poll间隔