1、Kafka介绍
Kafka最初由Linkedin公司开发，是一个分布式的、⽀持分区的（partition）、多副本的（replica）、多订阅者，基于zookeeper协调的分布式消息系统（也可以当做MQ系统），也是一个分布式流处理平台（Distributed Streaming Platform）。常用于web/nginx日志、访问日志、消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
1.1、Kafka是一个分布式数据流平台，可以从如下几个层面来理解：
- 我们可以向kafka发布数据以及从kafka订阅数据，即 我们可以将kafka看做一个消息队列，所起到的作用：缓冲（消峰限流），实现生产与消费的解耦。
- Kafka可以存储数据，并提供容错机制，即：数据丢失后可以进行恢复。
- 当数据到达kafka之后，可以马上的被消费处理，即 kafka的延迟很低。
- Kafka的数据，无论消费与否，数据会一直存在，不会删除。
1.2、kafka版本命名
前面的版本号：是编译 Kafka 源代码的 Scala 编译器版本，示例中为：2.12。
真正的 Kafka 版本号，示例中为： ：2.5.0
那么这个 2.5.0 又表示什么呢？
前面的 2 表示大版本号，即 Major Version；
中间的 5 表示小版本号或次版本号，即 Minor Version；
最后的 1 表示修订版本号，也就是 Patch 号。
2、kafka的特性
- 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；
- 可扩展性：kafka集群支持热扩展；
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止丢失；
- 容错性：允许集群中的节点失败(若分区副本数量为n,则允许n-1个节点失败)；
- 高并发：单机可支持数千个客户端同时读写；
3、kafka的相关概念
3.1、Broker ：kafka节点
一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Kafka代理(broker)是无状态的，即代理并不知道消费者是否已经使用了该消息，当消息在代理中超过一定时间后，将会被自动删除。
集群中每个broker都有一个唯一broker_id，不得重复。
3.2、Producer：消息生产者
向主题发布消息的客户端应用程序，称为生产者（Producer），生产者用于持续不断的向某个主题发送消息。
消息生产者，数据的分发策略由producer决定，默认是:
defaultPartition = Utils.abs(key.hashCode) % numPartitions
生产者可以发布数据到指定的主题（topic）中，并可以指定在主题（topic）中哪些消息分配到哪些分区。
生产者直接把消息发送给对应分区的broker，而不需要任何路由层。
批处理发送：当message积累到一定数量或等待一定时间后进行发送。
3.3、Consumer：消息消费者
消息传递通常由两种模式，queuing（队列）和publish-subscribe （发布-订阅）
- queuing：每个Consumer从消息队列中取走一个消息。
- pub-scrib：消息被广播到每个Consumer。
Kafka通过提供了一个对Consumer的抽象来同时实现这两种模式--ConsumerGroup。
Consumer实例需要给自己指定一个ConsumerGroup的名字，如果所有的实例都用同一个ConsumerGroup名字，那么这些Consumer就会以queuing的模式工作；如果所有的实例分别用的不同的ConsumerGroup名字，那么它们就以public-subscribe模式工作。
如下图所示：两台server的集群一共有p0~p3四个Partition，两个Consumer Group，在Group内部是以queuing的模式消费Partition，在Group之间是以pub-scrib模式消费。
消息顺序性：
Kafka是如何确保消息消费的顺序性的呢？消息在一个Partition中的顺序是有序的，但是Kafka只保证消息在一个Partition中有序，如果要想使整个topic中的消息有序，那么一个topic仅设置一个Partition即可。
3.4、Consumer Group：消费者组
-
Consumer Group可以有多个，每个Consumer Group消费的数据都是一样的。可以把多个consumer划分为一个组，组里面所有成员共同消费一个topic的数据，组员之间不能重复消费。
-
3.5、Topic ：主题
-
通过对消息指定主题（topic）可以将消息分类，消费者可以只关注自己需要的Topic中的消息。
这是一个逻辑上的概念，落到磁盘上是一个partition的目录。partition的目录中有多个segment组合(index,log)。一个Topic对应多个partition[0,1,2,3…]，一个partition对应多个segment组合。一个segment有默认的大小是1G。 -
每个partition可以设置多个副本(replication-factor 1), 会从所有的副本中选取一个leader出来。所有读写操作都是通过leader来进行的。特别强调，在kafka中读写操作都是leader。无论发布的消息是否被消费，kafka都会持久化一定时间（可配置，默认7天），每个消费者都会持久化offset到日志中，且offset的位置由消费者控制。
-
3.6、Partition：分区
-
在topic基础上做了进一步区分，
-
为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition（partition是一个磁盘目录），每个partition是一个FIFO的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
-
3.7、offset ：偏移量
-
kafka为每条在分区的消息保存一个偏移量offset，这也是消费者在分区的位置。比如一个偏移量是5的消费者，表示已经消费了从0-4偏移量的消息，下一个要消费的消息的偏移量是5。
kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka
-
-
-
-
上图所示，从分区中消费数据，kafka底层有一个offset机制。Kafka会记录消费者的offset（消费的位置偏移量），便于下一次从正确的位置进行消费。
- Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中。存在的问题：会频繁的和zookeeper进行通信交互，即可能为zookeeper带来较高的访问负载。
- 从 0.9 版本开始，consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为__consumer_offsets
Offset验证思路：
- 启动一个消费者线程（需要带有消费者组 属性）
sh kafka-console-consumer.sh --bootstrap-server localhost:90923 --topic book --from-beginning --group 20220707
- 会发现多出了一些目录，是因为 kafka底层是通过一个主题来进行管理offset的，主题名为：__consumer_offsets ,该主题有50个分区。
- 某个消费者组的offset就存在这50个分区目录中的其中一个。
存储规则：
Math.abs(groupId.hashCode())%50 该结果在：0~49之间
说明：Math.abs()返回指定数字的绝对值。
-
4、Topic & Partition
-
Topic相当于传统消息系统MQ中的一个队列queue，producer端发送的message必须指定是发送到哪个topic，但是不需要指定topic下的哪个partition，因为kafka会把收到的message进行load balance，均匀的分布在这个topic下的不同的partition上（hash(message) % [broker数量] ）。
-
物理存储上，这个topic会分成一个或多个partition，每个partiton相当于是一个子queue。在物理结构上，每个partition对应一个物理的目录（文件夹），文件夹命名是[topicname]_[partition]_[序号]，一个topic可以有无数多的partition，根据业务需求和数据量来设置。在kafka配置文件中可随时更改num。partitions参数来配置更改topic的partition数量，在 创建Topic时通过参数指定parittion数量。 Topic创建之后通过Kafka提供的工具也可以修改partiton数量。
一般来说，
-
（1）一个Topic的Partition数量大于等于Broker的数量， 可以提高吞吐率。
-
（2）同一个Partition的Replica尽量分散到不同的机器， 高可用。
当add a new partition的时候，partition里面的message不会重新进行分配，原来的partition里面的message数据不会变，新加的这个partition刚开始是空的，随后进入这个topic的message就会重新参与所有partition的load balance
Partition Replica：每个partition可以在其他的kafka broker节点上存副本，以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。
-
例如有5个kafka broker节点，某个topic有3个partition，每个partition存2个副本，那么partition1存broker1,broker2，partition2存broker2,broker3。。。以此类推（replica副本数目不能大于kafka broker节点的数目，否则报错。这里的replica数其实就是partition的副本总数，其中包括一个leader，其他的就是copy副本）。这样如果某个broker宕机，其实整个kafka内数据依然是完整的。但是，replica副本数越高，系统虽然越稳定，但是回来带资源和性能上的下降；replica副本少的话，也会造成系统丢数据的风险。
-
如上图所示，向一个主题生产数据，数据最终是存储到各个分区中。
分区从逻辑上来看，实际上是一个队列。
分区从物理上来看，实际上是一个分区目录。
向分区中存储数据，最终是存到分区目录下的log文件中。
-
底层实际上是数据磁盘的顺序写操作。（即：往文件末尾追加。）所以kafka的写入性能较高。
5、kafka的应用场景
日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口开放给各种消费端，例如hadoop、Hbase、Solr等。
消息系统：解耦生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索记录、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。
流式处理。
6、知识点
-
6.1、controller : 控制进程
- kafka集群中，controller控制进程会随机在某台broker上启动，此进程用于leader的选举，以及失败恢复。Controller进程的信息由zookeeper来维护，如果controller宕机后，会在其他剩下的broker服务器上启动。
-
6.2、zookeeper
-
-
-
-
-
-
Zookeeper ：负责管理、监控kafka集群运行（临时节点+监听机制），包括存储一些元数据信息（比如：主题名、主题的分区数、分区的副本数、副本leader的位置信息、controller位置等）
-
示例说明：
①进入zookeeper客户端：进入bin目录，执行sh zkCli.sh，进入zookerper客户端，查看kafka节点信息。
-
6.3、分区的副本机制
-
kafka支持数据的容错机制，即分区数据丢失后，可以恢复，通过副本冗余机制来实现，即我们在创建主题时，可以指定每个分区有多个副本。
-
分区的副本机制，是为了数据容错。
补充说明：
- 分区副本的数量不能超过broker服务器数量。
- 分区的副本数不宜过多，副本数量越多，集群磁盘的利用率越低，比如：3个副本，集群磁盘的利用率只有33%。
- 在实际生产环境下，一般3个副本足够了，2个副本也可以。如果副本数是1，则没有容错机制。
综上，kafka最基础、最核心的概念就是topic主题。因为无论是向kafka生产数据，还是从kafka消费数据，都需要指定主题。
主题topic的属性：
- 主题名 topic
- 分区数量 partition
- 分区的副本数量 replication
6.4、分区副本知识点
- kafka是有leader和follower概念的。注意：是针对分区的副本而言的，不是针对broker来说的。
- 分区的副本leader的作用：无论是生产数据，还是消费数据，都是和分区副本的leader交互的。
- 如果分区副本的leader挂掉了，kafka会从剩余的follower中选出新的leader。
1812
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
