继上一篇初识Streams Messaging Manager之后。我们开始逐渐介绍使用SMM的用例。
导语：本文介绍了腾讯云消息队列 CKafka 监控的最佳实践指南，帮助开发者免除繁琐的运维工作，并快速发现问题，提高工作效率。
作者：朱丹阳，腾讯云监控开发工程师 腾讯云消息队列 CKafka 简介 消息队列 CKafka（Cloud Kafka）是基于开源 Apache Kafka 消息队列引擎，提供高吞吐性能、高可扩展性的消息队列服务。消息队列 CKafka 完美兼容 Apache Kafka 0.9、0.10、1.1、2.4 版本接口，在性能、扩展性、业务安全保障、运维等方面具有超强优势，让您在享受低成本、超强功能的同时，免除繁琐运维工作。 产品特点: 收发解耦：有效解耦生产者、消费者之间的关系。在确保同样的接口约束的前提
Apache Kafka有许多针对其操作的度量，这些度量指标非常多，会让人混淆哪些是重要的，哪些是可以忽略的。这些度量的范围从关于通信量总体速率的简单度量，到针对每种请求类型的详细时间度量，再到每个topic和每个分区的度量。他们提供了broker中的每个操作的详细视图，但也可能使你成为负责管理监视系统的人员的缺点。 本节将详细介绍一直要监控的最关键的度量标准，以及如何响应他们。我们还将描述一些再调试问题的时候需要账务的更重要的度量标准，然而，这并不是可用的度量标准的详细列表，因为列表经常发生变化，而且其中有许多只对硬编码的kafka开放人员有用。
Broker：在Kafka中，Broker是Kafka集群中的一个节点，负责处理Kafka中的核心功能。从物理层面来看，Broker可以是单独的一台服务器，也可以是集群中的一个节点。从逻辑层面来看，Broker是Kafka服务端的实现，负责接收生产者发送的消息，并将这些消息转发给消费者。Broker是Kafka实现分布式、高吞吐、高可靠性的关键组件。
什么是Kafka Apache Kafka是一个基于分布式日志提交机制设计的发布订阅系统。数据在kafka中持久化，用户可以随时按需读取。另外数据以分布式的方式存储，提高容错性，易于扩展。 Message和Batches Kafka中最基本的数据单元是消息message，如果使用过数据库，那么可以把Kafka中的消息理解成数据库里的一条行或者一条记录。消息是由字符数组组成的，kafka并不关系它内部是什么，索引消息的具体格式与Kafka无关。消息可以有一个可选的key，这个key也是个字符数组，与消息
每个企业都离不开数据，我们接收数据、分析数据、加工数据，并将数据输出。每个应用程序都在创造数据，无论是日志消息、指标、用户活动、输出消息或者其他。每个字节的数据背后都有一些潜在线索，一个重要的线索会带来下一步的商机。为了更好的得到这些信息，我们需要将数据从创建的地方获取出来加以分析。我们每天都能在亚马逊上看到这样的场景：我们点击了感兴趣的项目，一小会之后就会将建议信息推荐给我们。 我们越是能快速的做到这一点，我们的组织就会越敏捷，反应越是灵敏。我们在移动数据上花费的时间越少，我们就越能专注于核心业务。这就是为什么在数据驱动的企业中，数据管道是核心组件的原因。我们如何移动数据变得和数据本身一样重要。
在大数据和流处理领域，Apache Kafka已经成为了一个非常重要的组件。Kafka不仅提供了高吞吐、低延迟的消息传递功能，还通过其独特的设计和机制确保了消息的可靠传输。其中，消息确认机制是Kafka确保消息可靠传递的关键环节。本文将深入探讨Kafka的消息确认机制，包括其工作原理、相关配置以及对系统性能的影响。
HubSpot 采用在多个 Kafka 主题（称为泳道，swimlanes）上为同一生产者路由消息的方式，避免了消费者群组滞后的积压，并且能够优先处理实时流量。通过自动和手动相结合的方式探测流量峰值，该公司能够确保大多数消费者的工作流能够在无延迟的情况下执行。
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目
Kafka的默认分区算法，即DefaultPartitioner，是Kafka生产者发送消息到不同分区时所采用的一种默认策略。该算法主要基于消息的key和主题的分区数，来决定消息应该被发送到哪个分区。
假设我们正在运行一个基于 Web 的服务。请求处理变慢最终将会导致服务不可用。实际上，并不是所有的请求都需要立即处理。有些请求只要确认已收到即可。你有没有问过自己这样的问题：“我是否能够从异步请求处理中获益？如果确实如此的话，我该如何在一个实时的、大规模的关键任务系统中做出这种转变？”
# **kafka release reviews: what happen from kafka 0.10 to 2.6*
继之前《Kafka运维篇之初识Streams Messaging Manager》、《Kafka运维篇之使用SMM监控Kafka集群》和《Kafka运维篇之使用SMM预警策略管理Kafka预警》之后。我们今天介绍使用SMM来监控Kafka端到端的延迟。
Kafka （该论文发表于 2011 年 6 月 [1]）是日志处理和消息队列系统的集大成者。较低的延迟、极高的容量和吞吐，使其可以应用于在线服务和离线业务。为了兼顾性能和可扩展性，Kafka 做了一些看起来反直觉但是却很实用的设计。例行总结一下其设计特点：
本书大部分内容都在讨论单个kafka集群的配置、维护和使用。但是，在一些场景中，可能需要多集群架构。 在某些情况下，集群是完全分离的，他们属于不同部门的不同实例，没有理由将数据从一个集群复制到另外一个集群。有时，不同的SLA或者工作负载使得单个集群提供多个用例服务的集群很难调优。在某些时候，还有不同的安全需求。这些场景非常容易管理多个不同的集群，就像多次允许单个集群一样。 在其他场景中，不同的集群是互相依赖的，管理有要不断地在集群之间复制数据。在大多数数据库中，在数据库服务之间持续复制数据称为复制。由于我们使用复制来描述属于同一集群的kafka节点之间的数据移动，因此我们将把kafak集群之间的数据复制称之为镜像。Apache kafka内置的跨集群 的复制器称为mirrormaker。 在本章中，我们将讨论所有或者部分数据的跨集群镜像。我们将首先讨论跨集群的镜像的一些常用用例。然后我们将展示一些用于实现这些用例的架构，并讨论每种架构的优缺点。然后我们将讨论MirrorMaker本书以及如何使用它。我们将分享一些操作技巧，包括部署的性能调优。最后我们将讨论mirrorMaker的一些替代方案。
Kafka消费者组 您可以通过用例或功能将消费者组合成消费者组。一个消费者组可能负责将记录传送到高速的、基于内存的微服务，而另一个消费者组将这些记录传输到Hadoop。消费者组有自己的名称以便于从其它消费者组中区分出来。 消费者组具有唯一的ID。每个消费者组是一个或多个Kafka主题的订阅者。每个消费者组维护其每个主题分区的偏移量。如果您需要多个订阅者，那么您有多个消费者组。一个记录只交付给消费者组中的一个消费者。 消费者组中的每个消费者处理记录，并且该组中只有一个消费者将获得相同的记录。消费组内的
本文翻译自国外论坛 medium，原文地址：https://medium.com/better-programming/rabbitmq-vs-kafka-1ef22a041793
在这个博客系列的第1部分之后，Apache Kafka的Spring——第1部分:错误处理、消息转换和事务支持，在这里的第2部分中，我们将关注另一个增强开发者在Kafka上构建流应用程序时体验的项目:Spring Cloud Stream。
导语 | 消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。本文对Kafka、Pulsar、RocketMQ、RabbitMQ、NSQ这几个消息队列组件进行了一些调研，并整理了相关资料，为业务对MQ中间件选型提供参考。 一、概述 消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。分布式系统可以借助消息队列的能力，轻松实现以下功能： 解耦，将一个流程的上游和下游拆开，上游专注生产消息，下游专注处理消息。 广播，一个上游生产的消息轻松被
Kafka是⼀个分布式、分区的、多副本的、多⽣产者、多订阅者，基于zookeeper协调的分布式⽇志系统（也可以当做MQ系统），常⻅可以⽤于web/nginx⽇志、访问⽇志，消息服务等等。 Kafka主要应⽤场景：⽇志收集系统和消息系统
Consumer Group ：Kafka提供的可扩展且具有容错性的消息者机制。 1、重要特征： A：组内可以有多个消费者实例（Consumer Instance）。 B：消费者组的唯一标识被称为Group ID，组内的消费者共享这个公共的ID。 C：消费者组订阅主题，主题的每个分区只能被组内的一个消费者消费 D：消费者组机制，同时实现了消息队列模型和发布/订阅模型。 2、重要问题： A：消费组中的实例与分区的关系： 消费者组中的实例个数，最好与订阅主题的分区数相同，否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。 B：消费者组的位移管理方式： （1）对于Consumer Group而言，位移是一组KV对，Key是分区，V对应Consumer消费该分区的最新位移。 （2）Kafka的老版本消费者组的位移保存在Zookeeper中，好处是Kafka减少了Kafka Broker端状态保存开销。但ZK是一个分布式的协调框架，不适合进行频繁的写更新，这种大吞吐量的写操作极大的拖慢了Zookeeper集群的性能。 （3）Kafka的新版本采用了将位移保存在Kafka内部主题的方法。 C：消费者组的重平衡： （1）重平衡：本质上是一种协议，规定了消费者组下的每个消费者如何达成一致，来分配订阅topic下的每个分区。 （2）触发条件： a，组成员数发生变更 b，订阅主题数发生变更 c，定阅主题分区数发生变更 （3）影响： Rebalance 的设计是要求所有consumer实例共同参与，全部重新分配所有用分区。并且Rebalance的过程比较缓慢，这个过程消息消费会中止。
可靠的数据传输是系统的属性之一，不能在事后考虑，就像性能一样，它必须从最初的白板图设计成一个系统，你不能事后把系统抛在一边。更重要的是，可靠性是系统的属性，而不是单个组件的属性，因此即使在讨论apache kafka的可靠性保证时，也需要考虑其各种场景。当谈到可靠性的时候，与kafka集成的系统和kafka本身一样重要。因为可靠性是一个系统问题，它不仅仅是一个人的责任。每个卡夫卡的管理员、linux系统管理员、网络和存储管理员以及应用程序开发人员必须共同来构建一个可靠的系统。 Apache kafka的数据传输可靠性非常灵活。我们知道kafka有很多用例，从跟踪网站点击到信用卡支付。一些用例要求最高的可靠性，而另外一些用例优先考虑四度和简单性而不是可靠性。kafka被设计成足够可配置，它的客户端API足够灵活，允许各种可靠性的权衡。 由于它的灵活性，在使用kafka时也容易意外地出现错误。相信你的系统是可靠的，但是实际上它不可靠。在本章中，我们将讨论不同类型的可靠性以及它们在apache kafka上下文中的含义开始。然后我们将讨论kafka的复制机制，以及它如何有助于系统的可靠性。然后我们将讨论kafka的broker和topic，以及如何针对不同的用例配置它们。然后我们将讨论客户，生产者、消费者以及如何在不同的可靠性场景中使用它们。最后，我们将讨论验证系统可靠性的主体，因为仅仅相信一个系统的可靠是不够的，必须彻底的测试这个假设。
消费者提交偏移量的主要是消费者往一个名为_consumer_offset的特殊主题发送消息，消息中包含每个分区的偏移量。
自Redis快速入门系列结束后，博主决定后面几篇博客为大家带来关于Kafka的知识分享~作为快速入门Kafka系列的第一篇博客，本篇为大家带来的是消息队列和Kafka的基本介绍~
每个集群都有一个broker是集群控制器（自动从集群的活跃成员中选举出来） 控制器负责管理工作： 将分区分配给broker 监控broker 集群中一个分区属于一个broker，该broker称为分区首领。 一个分区可以分配给多个broker，此时会发生分区复制。 分区的复制提供了消息冗余，高可用。副本分区不负责处理消息的读写。
今天要介绍的是消息中间件KafKa，应该说是一个很牛的中间件吧，背靠Apache 与很多有名的中间件搭配起来用效果更好哦 ，为什么不用RabbitMQ，因为公司需要它。 网上已经有很多怎么用和用到哪的内容，但结果很多人都倒在了入门第一步 环境都搭不起来，可谓是从了解到放弃，所以在此特记录如何在linux环境搭建，windows中配置一样，只是启动运行bat文件。 想要用它就先必须了解它能做什么及能做到什么程度，先看看它是什么吧。 当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工
在分布式系统中，消息队列扮演着至关重要的角色，而Kafka作为其中的佼佼者，以其高吞吐量、低延迟和可扩展性赢得了广泛的应用。然而，在实际应用中，我们不可避免地会遇到数据丢失、错误处理、版本升级以及数据分析等场景，这时就需要消息回溯消费的能力。
本文主要讨论Kafka组件中的消费者和其消费进度。我们将通过一个使用Scala语言实现的原型系统来学习。本文假设你知道Kafka的基本术语。
一个功能健全的kafka集群可以处理相当大的数据量，由于消息系统是很多大型应用的基石，因此broker集群在性能上的缺陷，都会引起整个应用栈的各种问题。
富兰克林·罗斯福曾经说过，我们往往过多地考虑了早起的鸟儿运气好，却不怎么想早起的虫子运气差。我从来不玩彩票。彩票的失败率大到惊人；实际上，成为圣人或美国总统的可能性都比赢得彩票（例如欧洲的 EuroMillions 或美国的 Powerball）大。
Kafka 起初是由 LinkedIn 公司采用 Scala 语言开发的一个多分区、多副本且基于 Zookeeper 协调的分布式消息系统，现已被捐献给 Apache 基金会。目前 Kafka 已经定位为一个分布式流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性被广泛使用。目前越来越多的开源式分布处理系统如：Storm、Spark、Flink 等都支持与 Kafka 集成。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 优势：
“流媒体”：发布者（“生产者”）经常发送的大量消息（想想数万或数十万）。许多订阅者（“消费者”）经常进行消息轮询。
当大数据运动开始时，它主要集中在批处理上。分布式数据存储和查询工具（如MapReduce，Hive和Pig）都旨在分批处理数据而不是连续处理数据。企业每晚都会运行多个作业，从数据库中提取数据，然后分析，转换并最终存储数据。最近，企业发现了分析和处理数据和事件的能力，而不是每隔几个小时就会发生一次。然而，大多数传统的消息传递系统不能扩展以实时处理大数据。所以LinkedIn的工程师构建并开源Apache Kafka：一种分布式消息传递框架，通过扩展商用硬件来满足大数据的需求。
Streams Replication Manager（SRM）是一种企业级复制解决方案，可实现容错、可扩展且健壮的跨集群Kafka主题复制。SRM提供了动态更改配置的功能，并使Topic属性在高性能的集群之间保持同步。SRM还提供了自定义扩展，可促进安装、管理和监视，从而使SRM成为针对任务关键型工作负载而构建的完整复制解决方案。Streams Replication Manager由两个主要组件组成：流复制引擎和流复制管理服务。
Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
来源：专知本文约700字，建议阅读5分钟Kafka in Action介绍了Kafka的核心特性，以及如何在实际应用中使用它的相关例子。 Kafka in Action介绍了Kafka的核心特性，以及如何在实际应用中使用它的相关例子。在其中，您将探索最常见的用例，如日志记录和管理流数据。当你完成之后，你就可以在一个以Kafka为中心的团队中处理基于开发者和管理员的基本任务了。 https://www.manning.com/books/kafka-in-action 这本书分三部分，共十二章。第一部分介
不了解 Kafka 的朋友建议先看一看我的下面这几篇文章，第一篇一定要看，其他的可以按需学习。
在我们之前的博客文章中，我们主要关注跟踪，这是0.14.0版本中的一个新特性。但是跟踪并不是我们在0.14.0中对监视功能进行的惟一改进。我们还对Prometheus的监控进行了一些重大改进。Strimzi几乎从一开始就支持Prometheus的Kafka指标。但是在0.14.0中，通过添加对Kafka导出器（Kafka Exporter ）的支持，我们做出了一些重大改进。Kafka导出器增加了Kafka代理中缺少的一些额外指标。在这篇博文中了解更多关于它们的信息。
Streams Messaging Manager（SMM）是一种操作监视和管理工具，可在企业ApacheKafka®环境中提供端到端的可见性。使用SMM，您可以获得有关Kafka集群的清晰见解。您可以了解从生产者到Topic再到消费者的消息流的端到端流。SMM帮助您对Kafka环境进行故障排除，以识别瓶颈、吞吐量、消费者模式、流量等。SMM使您能够使用各种过滤器来分析生产者和消费者之间的流动态。您可以根据从各种Broker和Topic收集的关键性能见解来优化Kafka环境。通过Apache Atlas的紧密集成，您可以跨多个Kafka跃点、生产者和消费者获得完整的数据沿袭的数据流可视化。
Apache Kafka 是分布式发布-订阅消息系统，在 kafka 官网上对 kafka 的定义：一个分布式发布-订阅消息传递系统。
Kafka搭建好投入使用后，为了运维更便捷，借助一些管理工具很有必要。Kafka社区似乎一直没有在监控框架方面投入太多的精力，目前Kafka监控方案看似很多，然而并没有一个"大而全"的通用解决方案，各家框架也是各有千秋。很多公司和个人都自行着手开发 Kafka 监控框架，其中并不乏佼佼者。今天我们就来全面地梳理一下常用监控指标与主流的监控框架。
在流处理和大数据领域，Apache Kafka已经成为了一个不可或缺的工具。作为一个分布式流处理平台，Kafka不仅提供了高性能的数据传输能力，还具备强大的数据持久化和状态管理功能。其中，消费状态跟踪是Kafka保障数据一致性和可靠性的关键机制之一。本文将详细探讨Kafka是如何维护消费状态跟踪的。
总第526篇 2022年 第043篇 Kafka在美团数据平台承担着统一的数据缓存和分发的角色，随着数据量的增长，集群规模的扩大，Kafka面临的挑战也愈发严峻。本文分享了美团Kafka面临的实际挑战，以及美团针对性的一些优化工作，希望能给从事相关开发工作的同学带来帮助或启发。 1. 现状和挑战 1.1 现状 1.2 挑战 2. 读写延迟优化 2.1 概览 2.2 应用层 2.3 系统层 2.4 混合层-SSD新缓存架构 3. 大规模集群管理优化 3.1 隔离策略 3.2 全链路监控 3.3 服务生命周期
一，KafkaConsumer使用要点解释 1，基本介绍 该客户端用户透明的处理kafka Broker的失败，透明的适应topic在集群中的迁移。这种客户端也可以使用消费者组的概念与kafka cluster进行交互，来进行均衡消费负载。 消费者维护着到必要的Broker上的TCP链接，用以获取data。使用之后未关闭消费者的话会导致链接泄漏。该消费者不是线程安全的，具体详见下文的多线程版本。 2，跨版本的兼容性 该版本的适用于kafka0.10+版本。老版本或者过新的版本会导致一些特征失效。比如，0.1
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
