Kafka 基本概念

L、先森

2019-10-08 0 4470

> Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

[TOC]

#### Kakfa的设计思想
Kakfa Broker Leader的选举：Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。

Consumergroup:各个consumer（consumer 线程）可以组成一个组（Consumer group），partition中的每个message只能被组（Consumer group）中的一个consumer（consumer 线程）消费，如果一个message可以被多个consumer（consumer 线程）消费的话，那么这些consumer必须在不同的组。Kafka不支持一个partition中的message由两个或两个以上的同一个consumer group下的consumer thread来处理，除非再启动一个新的consumer group

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

kafka offset
kafka 0.9 以前的版本是将offset 存储在zookeeper上的
kafka 0.9 以后，offset的使用了内部的broker来管理
将zookeeper维护offset 的方式称为 low level API
将kafka broker 维护offset的方式称为high level API

使用high level API 更新offset具体设置
自动提交，设置enable.auto.commit=true，更新的频率根据参数【auto.commit.interval.ms】来定。这种方式也被称为【at most once】，fetch到消息后就可以更新offset，无论是否消费成功。
手动提交，设置enable.auto.commit=false，这种方式称为【at least once】。fetch到消息后，等消费完成再调用方法【consumer.commitSync()】，手动更新offset；如果消费失败，则offset也不会更新，此条消息会被重复消费一次

#### 分区分配策略
最简单的取模算法
例如：topic test有 p0,p1,p2,p3四个分区，有三台broker b1,b2,b3。那么分区分配到broker上面的策略就是
b1:p0,p3
b2:p1
b3:p2
简单来说就是topic排序后所在序号对broker 的size取模，结果就是所在broker。

#### 消费发送分区策略
kafka的消息内容包含了key-value键值对，key的作用之一就是确定消息的分区所在。默认情况下， kafka 采用的是 hash 取模的分区算法。如果Key 为 null，则会随机分配一个分区。这个随机是在这个参数”metadata.max.age.ms”的时间范围内随机选择一个。对于这个时间段内，如果 key 为 null，则只会发送到唯一的分区。简单来说就是：hash(key) % partitions.size。
自定义消息发送分区策略

#### kafka消息消费策略
- 固定分区消费
- reblance分区消费
在实际生产过程中，每个 topic 都会有多个 partitions，多个 partitions 的好处在于，一方面能够对 broker 上的数据进行分片有效减少了消息的容量从而提升 io 性能；另外一方面，为了提高消费端的消费能力，一般会通过多个consumer 去消费同一个 topic ，也就是消费端的负载均衡机制，一般来说时一个comsumer group的所有消费者来协调消费topic里面的所有分区，一个分区只能被一个消费者消费，那么消费者被分到哪个分区的过程就是reblance
Zookeerper中保存这每个topic下的每个partition在每个group中消费的offset
有两种reblance策略来指定消费者消费分区

- Range strategy（范围分区）
Range 策略是对每个主题而言的，首先对同一个主题里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。 假设我们有 10 个分区， 3 个消费者，排完序的分区将会是 0, 1, 2, 3, 4, 5, 6, 7, 8, 9；消费者线程排完序将会是C1-0, C2-0, C3-0。然后将 partitions 的个数除于消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

这样的分配策略弊端就是前面的消费者需要消费更多的分区消息，负载更高，不平衡。
- RoundRobin strategy（轮询分区）
轮询分区策略是把所有 partition 和所有 consumer 线程都列出来，然后按照hashcode 进行排序。最后通过轮询算法分配 partition 给消费线程。如果所有 consumer 实例的订阅是相同的，那么 partition 会均匀分布。类似于分区取模分配到不同broker，这里先把分区按照hashcode排序，假如排序结果为，2，3，6，9，8，7，4，1，5，消费者group内部消费者c0,c1,c2，那么分区结果为。

reblance触发
1.当消费者group内部有新的消费者加入时。
2.当有消费者离开消费者group时
3.topic新增分区时
以上三种情况触发reblance策略，重新制定消费者消费分区。

大数据

Java 8最快的垃圾搜集器是什么？

OpenJDK 8 有多种 GC（Garbage Collector）算法，如 Parallel GC、CMS 和 G1。哪一个才...

L、先森

10个实用的PHP正则表达式

正则表达式是程序开发中一个重要的元素，它提供用来描述或匹配文本的字符串，如特定的字符、词或算式等

L、先森

Spring知识点提炼

spring框架

L、先森