【kafka系列】

kafka初步认识

第一章 初识kafka
第二章 生产者
第三章 消耗者
第四章 kafka的可靠性保证及其运行机制
第五章 参数配置及如何清除线上题目

  

---

前言

本系列Kafka专题主要帮助小白快速理解kafka的一些根本原理，主要从kafka的根本概念，生产者，消耗者，broker，及实际项目中的日志排查入手。本事有限，主要由于给大家分享交流，如有不精确的地方，欢迎指出。文章泉源主要摘自《Kafka权威指南》这一本书，也联合了良好的博客和自己的见解。
一、kafka是什么？

说直白一点，kafka就是一个发布与订阅消息系统。数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息举行分类，接收者（订阅者）订阅它们，以便接收特定类型的消息。发布与订阅系统一样平常会有一个 broker，也就是发布消息的中心点。Kafka一样平常被称为“分布式提交日志”大概“分布式流平台”。文件系统或数据库提交日志用来提供全部事务的持久记录，通过重放这些日志可以重建系统的状态。同样地，Kafka 的数据是按照一定次序持久化生存的，可以按需读取。此外，Kafka 的数据分布在整个系统里，具备数据故障保护和性能伸缩本事。
二、kafka团体架构

2.1根本概念

图2.1
• Producer：消息生产者，就是向broker发送消息的客户端。
• Consumer：消息消耗者，就是从broker拉取数据的客户端。
• Consumer Group：消耗者组，由多个消耗者consumer构成。消耗者组内每个消耗者负责消耗差别的分区，一个分区只能由同一个消耗者组内的一个消耗者消耗；消耗者组之间相互独立，互不影响。全部的消耗者都属于某个消耗者组，即消耗者组是一个逻辑上的订阅者。Consumer Group中不能有比Partition数量更多的消耗者，否则多出的消耗者一直处于空等候，不会收到消息。
• Group Coordinator：消耗组协调器，管理消耗组状态和元数据，提供rebalance、offset管理，处置惩罚并发冲突等作用
• Offset：偏移量，分区中的消息位置，由Kafka自身维护，consumer消耗时也要生存一份offset以维护消耗过的消息位置。
• Controller：控制器，管理和协调整个Kafka集群，同时也是Broker身份。控制器只在一个broker上存在。
• Broker：一台服务器就是一个broker，一个集群由多个broker构成，一个broker可以有多个topic。
• Topic：事件的有序聚集，可以理解为一个队列，全部的生产者和消耗者都是面向topic的，达到逻辑上数据隔离的效果。
• Partition：分区，kafka中的topic为了提高拓展性和实现高可用而将它分布到差别的broker中，一个topic可以分为多个partition，每个partition都是有序的，即消息发送到队列的次序跟消耗时拉取到的次序是同等的。
• Replication：副本，一个topic对应的分区partition可以有多个副本，多个副本中只有一个为leader，其余的为follower。为了保证数据的高可用性，leader和follower会尽量均匀的分布在各个broker中，避免了leader所在的服务器宕机而导致topic不可用的题目。
• Replication Leader：一个Partition的多个副本上，须要一个Leader负责该Partition上与Producer和Consumer交互。一个Partition只对应一个Replication Leader。
• Replication Follower：Follower跟随Leader，全部写哀求都会广播给全部Follower，Follower与Leader保持数据同步。
• ReplicaManager：负责管理当前Broker全部门区和副本的信息，处置惩罚Controller发起的一些哀求，副本状态的切换、添加/读取消息等。
• Rebalance：消耗者组内某个消耗者实例挂掉后，其他消耗者实例自动重新分配订阅主题分区的过程。Rebalance是Kafka消耗者端实现高可用的紧张本领。
   `每一个Topic的信息被切分为多个Partitions。若Partition数量设置成1个，则可以保证消息消耗的次序性，但无法做到负载均衡。如果某Topic有N个Partition，集群有N个Broker，那么每个Broker存储该topic的一个Partition。如果某Topic有N个Partition，集群有(N+M)个Broker，那么此中有N个Broker存储该Topic的一个Partition，剩下的M个Broker不存储该Topic的Partition数据。如果某Topic有N个Partition，集群中Broker数目少于N个，那么一个Broker存储该Topic的一个或多个Partition。在实际生产环境中，尽量避免这种环境的发生，这种环境容易导致Kafka集群数据不均衡。``
    当Broker收到消息，根据分区算法选择将其存储到哪一个Partition。其路由机制为优先按照指定Partition来路由；若未指定patition但指定key，则通过对key的value举行hash选出一个patition；如果patition和key都未指定，则轮询选出一个patition。
  2.2消息和批次

Kafka 的数据单元被称为消息。消息由字节数组构成，以是对于 Kafka 来说，消息里的数据没有特别的格式或寄义。消息可以有一个可选的元数据，也就是键。键也是一个字节数组，与消息一样，对于 Kafka 来说也没有特殊的寄义。当消息以一种可控的方式写入差别的分区时，会用到键。最简朴的例子就是为键天生一个同等性散列值，然后利用散列值对主题分区数举行取模，为消息选取分区。这样可以保证具有雷同键的消息总是被写到雷同的分区上。后续章节介绍生产者的时候将详细介绍键的用法。
为了提高服从，消息被分批次写入 Kafka。批次就是一组消息，这些消息属于同一个主题和分区。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出衡量：批次越大，单元时间内处置惩罚的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储本事，但要做更多的计算处置惩罚。
2.3 主题和分区

Kafka 的消息通过主题举行分类。主题就比如数据库的表，大概文件系统里的文件夹。主题可以被分为多少个分区，一个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出的次序读取。要注意，由于一个主题一样平常包含几个分区，因此无法在整个主题范围内保证消息的次序，但可以保证消息在单个分区内的次序。图 2.3.1所示的主题有 4个分区，消息被追加写入每个分区的尾部。Kafka 通太过区来实现数据冗余和伸缩性。分区可以分布在差别的服务器上，也就是说，一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。

图2.3.1
2.4生产者和消耗者

Kafka 的客户端就是 Kafka 系统的用户，它们被分为两种根本类型：生产者和消耗者。
生产者创建消息。在其他发布与订阅系统中，生产者大概被称为发布者或写入者。一样平常环境下，一个消息会被发布到一个特定的主题上。生产者在默认环境下把消息均衡地分布到主题的全部门区上，而并不关心特定消息会被写到哪个分区。不过，在某些环境下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键天生一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到
同一个分区上。生产者也可以利用自定义的分区器，根据差别的业务规则将消息映射到分区。后续章节将详细介绍生产者。
消耗者读取消息。在其他发布与订阅系统中，消耗者大概被称为订阅者或读者。消耗者订阅一个或多个主题，并按照消息天生的次序读取它们。消耗者通过查抄消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消耗者把每个分区末了读取的消息偏移量生存在 Zookeeper 或 Kafka 上，如果消耗者关闭或重启，它的读取状态不会丢失。
消耗者是消耗者群组的一部门，也就是说，会有一个或多个消耗者共同读取一个主题。群组保证每个分区只能被一个消耗者利用。图 2.4.1 所示的群组中，有 3 个消耗者同时读取一个主题。此中的两个消耗者各自读取一个分区，另外一个消耗者读取其他两个分区。消耗者与分区之间的映射通常被称为消耗者对分区的全部权关系。通过这种方式，消耗者可以消耗包含大量消息的主题。而且，如果一个消耗者失效，群组里的其他消耗者可以接受失效消耗者的工作。后续章节将详细介绍消耗者和消耗者群组。

图2.4.1
2.5 broker和集群

一个独立的 Kafka 服务器被称为 broker。broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘生存。broker 为消耗者提供服务，对读取分区的哀求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个 broker 可以轻松处置惩罚数千个分区以及每秒百万级的消息量。
broker 是集群的构成部门。每个集群都有一个 broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包罗将分区分配给 broker 和监控broker。在集群中，一个分区从属于一个 broker，该 broker 被称为分区的首领。一个分区可以分配给多个 broker，这个时候会发生分区复制（见图 2.5.1）。这种复制机制为分区提供了消息冗余，如果有一个 broker 失效，其他 broker 可以接受领导权。不过，相干的消耗者和生产者都要重新连接到新的首领。后续章节将详细介绍集群的操作，包罗分区复制。

图2.5.1
生存消息（在一定期限内）是 Kafka 的一个紧张特性。Kafka broker 默认的消息生存计谋是这样的：要么生存一段时间（比如 7 天），要么生存到消息达到一定巨细的字节数（比如 1GB）。当消息数量达到这些上限时，旧消息就会过期并被删除，以是在任何时候，可用消息的总量都不会凌驾配置参数所指定的巨细。主题可以配置自己的生存计谋，可以将消息生存到不再利用它们为止。
三、Kafka的优势

3.1 多个生产者

Kafka 可以无缝地支持多个生产者，不管客户端在利用单个主题还是多个主题。以是它很适适用来从多个前端系统收集数据，并以统一的格式对外提供数据。例如，一个包含了多个微服务的网站，可以为页面视图创建一个单独的主题，全部服务都以雷同的消息格式向该主题写入数据。消耗者应用步伐会获得统一的页面视图，而无需协调来自差别生产者的数据流。
3.2 多个消耗者

除了支持多个生产者外，Kafka 也支持多个消耗者从一个单独的消息流上读取数据，而且消耗者之间互不影响。这与其他队列系统差别，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。另外，多个消耗者可以构成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处置惩罚一次。
3.3 基于磁盘的数据存储

Kafka 不但支持多个消耗者，还答应消耗者非及时地读取消息，这要归功于 Kafka 的数据生存特性。消息被提交到磁盘，根据设置的生存规则举行生存。每个主题可以设置单独的生存规则，以便满足差别消耗者的需求，各个主题可以生存差别数量的消息。消耗者大概会因为处置惩罚速度慢或突发的流量高峰导致无法及时读取消息，而持久化数据可以保证数据不会丢失。消耗者可以在举行应用步伐维护时离线一小段时间，而无需担心消息丢失或堵
塞在生产者端。消耗者可以被关闭，但消息会继续生存在 Kafka 里。消耗者可以从上次停止的地方继续处置惩罚消息。
3.4 伸缩性

为了可以或许轻松处置惩罚大量数据，Kafka 从一开始就被计划成一个具有灵活伸缩性的系统。用户在开辟阶段可以先利用单个 broker，再扩展到包含 3 个 broker 的小型开辟集群，然后随着数据量不断增长，部署到生产环境的集群大概包含上百个 broker。对在线集群举行扩展丝绝不影响团体系统的可用性。也就是说，一个包含多个 broker 的集群，即使个别 broker失效，仍然可以连续地为客户提供服务。要提高集群的容错本事，须要配置较高的复制系数。
3.5 高性能

上面提到的全部特性，让 Kafka 成为了一个高性能的发布与订阅消息系统。通过横向扩展生产者、消耗者和 broker，Kafka 可以轻松处置惩罚巨大的消息流。在处置惩罚大量数据的同时，它还能保证亚秒级的消息延迟
总结

以上就是Kafka的一些根本概念，通过上述了解信赖你已经对Kafka的工作流程有了根本了解了，如果感觉对你有帮助可以点个关注哈，后续也会更新更多的博客，也欢迎大家留言。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。