-
kafaka架构
·Producer：生产者将消息发布到制定的主题中，默认使用简单的负载均衡机制选择分区，如果需要可以通过特定的分区函数选择分区，制定发布到哪个分区
·Broker：集群汇中的一台或多台服务器统称为broker
·consumer：负责消费主题中的数据，消费时由Consumer自己来维护会话产生的数据，实际上每个consumer唯一需要维护的数据是消息在日志中的位置，也就是offset，一般情况下随着Consumer不断的读取消息，这offset的值不断增加,从而实现连续读取数据
-
发送端的可选配置信息分析
·acks：producer 发送消息到 broker 上以后的确认值
0:表示producer不需要等待broker的消息确认。这个选项时延最小但同时风险最大(因为当 server 宕机时，数据将会丢失)。
1:表示producer只需要获得kafka集群中的leader节点确认即可，这个选择时延较小同时确保了 leader 节点确认接收成功。
all(-1):需要ISR中所有的Replica给予接收确认，速度最慢，安全性最高，但是由于 ISR 可能会缩小到仅包含一个 Replica，所以设置参数为 all 并不能一 定避免数据丢失
·batch.size
生产者发送多个消息到 broker 上的同一个分区时，为了减少网络请求带来的 性能开销，通过批量的方式来提交消息，可以通过这个参数来控制批量提交的 字节数大小，默认大小是 16384byte,也就是 16kb，意味着当一批消息大小达到指定的 batch.size 的时候会统一发送。
·linger.ms
Producer 默认会把两次发送时间间隔内收集到的所有 Requests 进行一次聚合 然后再发送，以此提高吞吐量，而 linger.ms 就是为每次发送到 broker 的请求 增加一些 delay，以此来聚合更多的 Message 请求。 这个有点想 TCP 里面的Nagle 算法，在 TCP 协议的传输中，为了减少大量小数据包的发送，采用了Nagle 算法，也就是基于小包的等-停协议。
batch.size和linger.ms这两个参数是kafka性能优化的关键参数，当二者都配置的时候，只要满足其中一个要 求，就会发送请求到 broker 上。
·max.request.size：设置请求的数据的最大字节数，为了防止发生较大的数据包影响到吞吐量，默 认值为 1MB。
-
消费端的可选配置分析
·group.id
consumer group 是 kafka 提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者或消费者实例(consumer instance)， 它们共享一个公共的 ID，即 group ID。组内的所有消费者协调在一起来消费订阅主题(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 间隔。
-
Topic&Partition
topic 是一个存储消息的逻辑概念，可以认为 是一个消息集合。每条消息发送到 kafka 集群的消息都有一个类别。物理上来说，不同的 topic 的消息是分开存储 的，每个 topic 可以有多个生产者向它发送消息，也可以有多 个消费者去消费其中的消息。
每个 topic 可以划分多个分区Partition(每个 Topic 至少有一个分 区)，同一 topic 下的不同分区包含的消息是不同的。每个 消息在被添加到分区时，都会被分配一个 offset(称之为偏 移量)，它是消息在此分区中的唯一编号，kafka 通过 offset保证消息在分区内的顺序，offset 的顺序不跨分区，即 kafka只保证在同一个分区内的消息是有序的。
上图名字为 test 的 topic，做了 3 个分区，分别是p0、p1、p2。每一条消息发送到 broker 时，会根据 partition 的规则，选择存储到哪一个 partition。如果 partition 规则设置合 理，那么所有的消息会均匀的分布在不同的 partition 中。
Partition 是以文件的形式存储在文件系统中，topic:test在kafka 的数据目录(/tmp/kafka-log)中就有 3 个目录， test-0~3， 命名规则是<topic_name>-<partition_id>
-
消息分发策略
消息是 kafka 中最基本的数据单元，在 kafka 中，一条消息 由 key、value 两部分构成，在发送一条消息时，我们可以 指定这个 key，那么 producer 会根据 key 和 partition 机 制来判断当前这条消息应该发送并存储到哪个 partition 中。 我们可以根据需要进行扩展 producer 的 partition 机制。默认情况下，kafka 采用的是 hash 取模的分区算法。如果Key 为 null，则会随机分配一个分区。
-
消息消费策略
同一个group中的消费者对于一个 topic 中的多个 partition，存在一定的 分区分配策略。kafka 中，存在两种分区分配策略，一种是 Range(默认)、另一种另一种还是 RoundRobin(轮询)。通过partition.assignment.strategy 这个参数来设置
·Range strategy（范围分区）
是对每个主题而言的，首先对同一个主题里面 的分区按照序号进行排序，并对消费者按照字母顺序进行排序。
假设我们有 10个分区，3 个消费者，分区如下：
C1-0 将消费 0, 1, 2, 3 分区
C2-0 将消费 4, 5, 6 分区
C3-0 将消费 7, 8, 9 分区在消费多个topic时，会出现分区不均匀的弊端。
·RoundRobin strategy（轮询分区）
轮询分区策略是把所有 partition 和所有 consumer 线程都 列出来，然后按照 hashcode 进行排序。最后通过轮询算 法分配 partition 给消费线程。如果所有 consumer 实例的 订阅是相同的，那么 partition 会均匀分布。
-
·触发分区分配操作（kafka consumer 的 rebalance）的时机
- 同一个 consumer group 内新增了消费者
- 消费者离开当前所属的 consumer group，比如主动停机或者宕机
- topic 新增了分区(也就是分区数量发生了变化)
-
coordinator
作用：执行 Rebalance 以及管理 consumer 的 group
确定：消费者向 kafka 集群中的任意一个 broker 发送一个GroupCoordinatorRequest 请求，服务端会返回一个负载最小的 broker 节点的 id，并将该 broker 设置为coordinator，之后该 group 内的所有成 员都会和该 coordinator 进行协调通信。
-
Rebalance
上述确定coordinator后 -->进行 rebalance ，分为两步：Join + Sync join
·Join：表示加入到 consumer group 中，在这一步中，所有的成员都会向 coordinator 发送 joinGroup 的请求。一旦所有成员都发送了 joinGroup 请求，那么 coordinator 会选择一个 consumer 担任 leader 角色，并把组成员信息和订阅信息发送消费者。
protocol_metadata: 序列化后的消费者的订阅信息 leader_id: 消费组中的消费者coordinator 会选择一个作为leader，对应的就是 member_id member_metadata: 对应消费者的订阅信息 members:consumer group 中全部的消费者的订阅信息 generation_id:年代信息，对于每一轮 rebalance，generation_id 都会递增。主要用来保护 consumer group。 隔离无效的 offset 提交。也就是上一轮的 consumer 成员 无法提交 offset 到新的 consumer group 中。
·Synchronizing Group State：完成分区分配之后，就进入了 Synchronizing Group State阶段
过程：主要逻辑是向GroupCoordinator 发送SyncGroupRequest 请求，并且处理 SyncGroupResponse响应，简单来说，就是 leader 将消费者对应的 partition 分 配方案同步给 consumer group 中的所有 consumer。每个消费者都会向 coordinator 发送 syncgroup 请求不过只有 leader 节点会发送分配方案给coordinator，然后 coordinator 会把结果设置到 SyncGroupResponse 中。这 样所有成员都知道自己应该消费哪个分区。
consumer group 的分区分配方案是在客户端执行的，Kafka 将这个权利下放给客户端主要是因为这样做可以有更好的灵活性。
-
offset
每个 topic 可以划分多个分区(每个 Topic 至少有一个分区)，同一topic 下的不同分区包含的消息是不同的。每个消息在被添加到分区时，都会被分配一个 offset(称之为偏移量)，它是消息在此分区中的唯一编号，kafka 通过 offset 保证消息在分区内的顺序，offset 的顺序不跨分区，即 kafka 只保证 在同一个分区内的消息是有序的; 对于应用层的消费来说， 每次消费一个消息并且提交以后，会保存当前消费到的最近的一个 offset。
不定时更新.......
扫一扫
319
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
