Kafka如何做到秒处理万条消息？.docxVIP

Kafka如何做到1秒处理1500万条消息？ 2021-07-01 —?扫描二维码?—加入架构集结群 ?? 对技术感爱好的同学可进群（备注:Java） Apache Kafka 是一款流行的分布式数据流平台，它已经广泛地被诸如 New Relic(数据智能平台)、Uber、Square(移动领取公司)等大型公司用来构建可扩展的、高吞吐量的、且高牢靠的实时数据流系统。 例如，在 New Relic 的生产环境中，Kafka 群集每秒能够处理超过 1500 万条消息，而且其数据聚合率接近 1Tbps。 可见，Kafka 大幅简化了对于数据流的处理，因而它也获得了众多应用开发人员和数据管理专家的青睐。 然而，在大型系统中 Kafka 的应用会比较简单。假如您的 Consumers 无法跟上数据流的话，各种消息往往在未被查看之前就已经消逝掉了。 同时，它在自动化数据保留方面的限制，高流量的发布+订阅(publish-subscribe，pub/sub)模式等，可能都会影响到您系统的功能。 可以毫不夸张地说，假如那些存放着数据流的系统无法按需扩容、或稳定性不行靠的话，估量您经常会寝食难安。 为了削减上述简单性，我在此共享 New Relic 公司为 Kafka 集群在应对高吞吐量方面的 20 项最佳实践。 我将从如下四个方面进行开放： Partitions(分区) Consumers(消费者) Producers(生产者) Brokers(代理) 快速了解 Kafka 的概念与架构 Kafka 是一种高效的分布式消息系统。在功能上，它具有内置的数据冗余度与弹性，也具有高吞吐力量和可扩展性。 在功能上，它支持自动化的数据保存限制，能够以“流”的方式为应用供应数据转换，以及依据“键-值(key-value)”的建模关系“压缩”数据流。 要了解各种最佳实践，您需要首先生疏如下关键术语： Message(消息) Kafka 中的一条记录或数据单位。每条消息都有一个键和对应的一个值，有时还会有可选的消息头。 Producer(生产者) Producer 将消息发布到 Kafka 的 topics 上。Producer 打算向 topic 分区的发布方式，如：轮询的随机方法、或基于消息键(key)的分区算法。 Broker(代理) Kafka 以分布式系统或集群的方式运转。那么群集中的每个节点称为一个 Broker。 Topic(主题) Topic 是那些被发布的数据记录或消息的一品种别。消费者通过订阅Topic，来读取写给它们的数据。 Topic Partition(主题分区) 不同的 Topic 被分为不同的分区，而每一条消息都会被安排一个 Offset，通常每个分区都会被复制至少一到两次。 每个分区都有一个 Leader 和存放在各个 Follower 上的一到多个副本(即：数据的副本)，此法可防止某个 Broker 的失效。 群集中的全部 Broker 都可以作为 Leader 和 Follower，但是一个 Broker 最多只能有一个 Topic Partition 的副本。Leader 可被用来进行全部的读写操作。 Offset(偏移量) 单个分区中的每一条消息都被安排一个 Offset，它是一个单调递增的整型数，可用来作为分区中消息的独一标识符。 Consumer(消费者) Consumer 通过订阅 Topic partition，来读取 Kafka 的各种 Topic 消息。然后，消费类应用处理睬收到消息，以完成指定的工作。 Consumer group(消费组) Consumer 可以依据 Consumer group 进行规律划分。Topic Partition 被均衡地安排给组中的全部 Consumers。 因而，在同一个 Consumer group 中，全部的 Consumer 都以负载均衡的方式运作。 换言之，同一组中的每一个 Consumer 都能看到每一条消息。假如某个 Consumer 处于“离线”形态的话，那么该分区将会被安排给同组中的另一个 Consumer。这就是所谓的“再均衡(rebalance)”。 当然，假如组中的 Consumer 多于分区数，则某些 Consumer 将会处于闲置的形态。 相反，假如组中的 Consumer 少于分区数，则某些 Consumer 会获得来自一个以上分区的消息。 Lag(延迟) 当 Consumer 的速度跟不上消息的产生速度时，Consumer 就会由于无法从分区中读取消息，而产生延迟。 延迟表示为分区头后面的 Offset 数量。从延迟形态(到“追逐上来”)恢复正常所需要的时间，取决于 Consumer 每秒能够应对的消息速度。 其公式如下：tim