- 综合排序
- 最热优先
- 最新优先
- 来自专栏米奇爱编程
高吞吐量消息系统—kafka
主要的原因是因为kafka天然的百万级TPS，以及它对接其他大数据组件的流处理功能，比如可以更好的对接Apache storm。本文只是讨论kafka作为消息队列的功能及一些用法。 消息队列的优势 1.削峰填谷 用于上下游数据处理时长差别很大的应用场景。 比如购物网站，前端需要快速返回给用户，后端需要处理一系列的动作（查库存，扣费，发货等等，很有可能需要依赖其他第三方系统），所以如果前端和后端如果没有一个消息队列，前端的流量可能会压垮后端。 CAP原则，kafka提供了充分的参数让用户选择，数据一致性越强吞吐量越低，需要根据业务场景评估。 3.数据可以重复消费 不同于传统的消息队列，队列中的数据只能消费一次。 消费者进程重启后读取kafka存储的offset，那么之前崩溃没有处理的数据将会漏掉，无法感知消费。
87920发布于 2020-08-14 每秒处理数十万条消息？腾讯云消息队列CKafka如何成就高吞吐神话
这类高吞吐需求对消息中间件提出了极高要求：不仅要能高效处理海量数据，还要保证可靠性、低延迟和横向扩展能力。 01 高吞吐消息处理的挑战与需求高吞吐消息处理并非简单追求速度，而是需要在速度、可靠性和有序性之间取得精细平衡。传统消息系统在面对突发流量时往往容易出现性能瓶颈或消息丢失。 02 主流高吞吐消息中间件对比目前主流的高吞吐消息处理方案主要包括Apache Kafka、RabbitMQ、RocketMQ和腾讯云消息队列CKafka等。 腾讯云消息队列CKafka凭借其超过开源Kafka10%-20%的性能表现，以及自动弹性伸缩、高可靠性保障等特性，已成为高吞吐消息处理场景的理想选择。 随着企业数据规模持续增长，像CKafka这样能处理每秒数十万条消息的高吞吐消息中间件，将不再只是技术选项，而是业务不可或缺的数字基石。
40210编辑于 2025-09-19- 来自专栏携程技术
干货 | 高吞吐消息网关的探索与思考
二、唯品会消息网关的架构定位 在本次重构中，将原来耦合在一起的消息发送渠道，被拆分成逻辑消息网关和物理发送渠道。 消息的受理和分发 在实际的业务场景中，发送给会员，供应商和内部工作人员的消息，分为三种类型：关键性消息，通知类消息，以及营销类消息。关键性消息的特点是，低时延，低吞吐。 通知类消息的特点是中时延，高吞吐。营销类消息的特点是中时延，高吞吐。针对不同的消息类型，应该选择不同的受理和分发模块，避免互相干扰。如图3所示。 ? 消息队列用Kafka，应对高吞吐量消息场景。ETL使用自研VDP(类似于阿里开源的Canal)，解析binlog，同步数据到HDFS。图10演示了Venus框架的基本结构。 都是基于TCP协议上的私有协议，需要自行处理断包和粘包问题。
2.1K41发布于 2018-03-16 - 来自专栏维C果糖
Kafka：高吞吐量、消息精确一次语义以及保证消息顺序
高吞吐量 Kafka 是大数据领域无处不在的消息中间件，目前广泛使用在企业内部的实时数据管道，并帮助企业构建自己的流计算应用程序。 Kafka 虽然是基于磁盘做的数据存储，但却具有高性能、高吞吐、低延时的特点，其吞吐量动辄几万、几十上百万。 消费者拉取消息，处理消息，提交偏移量来说明它完成了处理。然后，即使消费者程序出故障重启也不会再收到“Hello Kafka”这条消息了。 然而，我们知道，我们不能总认为一切都是顺利的。 一般来说，为了使用 Kafka 的高吞吐量特性，我们需要为每个topic设置多个partition；同时，为了保证 Kafka 的高可用性，每个topic下的多个partition，又分被分散到不同的broker --------- 参考资料： Kafka是如何实现高吞吐率的 Kafka为什么吞吐量大、速度快？
3.6K01发布于 2020-06-16 - 来自专栏维C果糖
Kafka：高吞吐量、消息精确一次语义以及保证消息顺序
文章目录 前言 高吞吐量 顺序读写 Page Cache 零拷贝 分区分段+索引 批量读写 批量压缩 消息精确一次语义 消息系统语义概述 必须被处理的故障 Kafka 中的精确一次语义 幂等性：每个分区中精确一次且有序 高吞吐量 Kafka 是大数据领域无处不在的消息中间件，目前广泛使用在企业内部的实时数据管道，并帮助企业构建自己的流计算应用程序。 Kafka 虽然是基于磁盘做的数据存储，但却具有高性能、高吞吐、低延时的特点，其吞吐量动辄几万、几十上百万。 一般来说，为了使用 Kafka 的高吞吐量特性，我们需要为每个topic设置多个partition；同时，为了保证 Kafka 的高可用性，每个topic下的多个partition，又分被分散到不同的broker 参考资料： Kafka是如何实现高吞吐率的 Kafka为什么吞吐量大、速度快？ Apache kafka是如何实现消息的精确一次（Exactly-once-semantics）语义的？
1.8K31编辑于 2021-12-07 - 来自专栏架构师专栏
搭建高吞吐量 Kafka 分布式发布订阅消息 集群
搭建高吞吐量 Kafka 分布式发布订阅消息 集群 简介 Kafka 是一种高吞吐的分布式发布订阅消息系统，能够替代传统的消息队列用于解耦合数据处理，缓存未处理消息等，同时具有更高的吞吐率，支持分区、多副本 、冗余，因此被广泛用于大规模消息数据处理应用。 默认情况下，每行将作为单独的消息发送。 在 node5 运行生产者，然后在控制台中输入一些消息以发送到服务器。 在node6 运行消费者，将把消息转储到标准输出。 -订阅系统，Apache Kafka在Yahoo内部已经被很多团队所使用，例如媒体分析团队就将其应用到了实时分析流水线中，同时，Yahoo整个Kafka集群处理的峰值带宽超过了20Gbps（压缩数据）。
1.3K50发布于 2018-02-09 - 来自专栏我的技术专刊
消息队列吞吐量调整
关于吞吐量的一些思考 写入消息队列吞吐量取决于以下两个方面 * 网络带宽 * 消息队列（比如Kafka）写入速度 最佳吞吐量是让其中之一打满，而一般情况下内网带宽都会非常高，不太可能被打满，所以自然就是讲消息队列的写入速度打满 ，这就就有两个点需要平衡 * 批量写入的消息量大小或者字节数多少 * 延迟多久写入 go-zero 的 PeriodicalExecutor 和 ChunkExecutor 就是为了这种情况设计的 从消息队列里消费消息的吞吐量取决于以下两个方面 * 消息队列的读取速度，一般情况下消息队列本身的读取速度相比于处理消息的速度都是足够快的 * 处理速度，这个依赖于业务 这里有个核心问题是不能不考虑业务处理速度，而读取过多的消息到内存里，否则可能会引起两个问题 ： * 内存占用过高，甚至出现OOM，`pod` 也是有 `memory limit` 的 * 停止 `pod` 时堆积的消息来不及处理而导致消息丢失 解决方案和实现 借用一下 Rob Pike 的一张图 } case event := <-eventChan: consumer.OnEvent(event) } } 这里如果拿到消息就去处理
73800编辑于 2021-12-16 - 来自专栏Java极客技术
SpringBoot 整合 Kafka 实现数据高吞吐
下面，我将结合生产环境的真实案例，以SpringBoot技术框架为基础，向大家介绍 kafka 的使用以及如何实现数据高吞吐！ 逗号隔开 spring.kafka.bootstrap-servers=197.168.25.196:9092 #重试次数 spring.kafka.producer.retries=3 #批量发送的消息数量 spring.kafka.producer.batch-size=1000 #32MB的批处理缓冲区 spring.kafka.producer.buffer-memory=33554432 #默认消费者组 消费时间：{}ms", consumerRecords.size(), (System.currentTimeMillis() - start)); } } 此时，消费性能大大的提升，数据处理的非常快 三、小结 本文主要以SpringBoot技术框架为背景，结合实际业务需求，采用 kafka 进行数据消费，实现数据量的高吞吐，在下篇文章中，我们会介绍消费失败的处理流程。
1.1K30编辑于 2022-12-04 - 来自专栏前端杂货铺
高吞吐koa日志中间件
Midlog中间件 node服务端开发中少不了日志打点，而在koa框架下的日志打点在多进程环境中日志信息往往无法对应上下文，而且在高并发下直接进行写buffer操作（内核调用writev）也会造成内存泄漏
1.8K100发布于 2018-03-15 - 来自专栏Hyperledger实践
高吞吐框架Disruptor应用场景
官方的性能测试用例 1.1 JDK BlockingQueue的吞吐测试, 先来个一个生产者, 一个消费者用例 https://github.com/zealzeng/fabric-samples/blob 在老的四代I5貌似每秒吞吐也蛮高, 百万级。 , 一样的处理逻辑，吞吐是千万级别。 Disruptor消息处理方式 2.1 muti-cast 广播消息 官方入门例子给的蛮多都是这个模式, 即使用Disruptor.handleEventsWith(EventHandler... handlers 这就好比我要寄给合同到东北，有些快递确实快两天就到了，有些慢些可能3，4天，但快递只负责把东西送收件人手上， 收件人处理合同讲不好要个一两周，快递再快也解决不了合同处理慢的问题。
5.2K20发布于 2020-11-11 - 来自专栏SmartSi
Flink 使用Flink进行高吞吐，低延迟和Exactly-Once语义流处理
开源中第一个广泛使用的大规模流处理框架可能是Apache Storm。Storm使用上游备份和记录确认机制来保证在失败后重新处理消息。 微批处理可以实现高吞吐量和Exactly-Once语义保证，但是当前的实现是以抛弃低延迟，流量控制和纯流式编程模型为代价实现上述目标的。 显而易见的问题是，是否有两全其美的办法：保持连续计算模型的所有优势，同时还能保证Exactly-Once语义并提供高吞吐量。后面讨论的后流式架构实现了这种组合，并将微批处理作为流式处理的基本模型。 低 高 中到高（取决于分布式事务存储的吞吐量） 高 计算模型 流式 微批次 流式 流式 容错开销 高 低 取决于分布式事务存储的吞吐量 低 流控制 有问题 有问题 自然 自然 应用程序逻辑与容错分离 我们可以看到Flink的吞吐量比Trident高出20倍以上，吞吐量比Storm高300倍。在保持高吞吐的情况下，Flink还保证延迟为零。我们还看到，不使用微批次处理模型，高吞吐量不会以延迟为代价。
6.7K31发布于 2019-08-07 - 来自专栏性能与架构
Kafka是如何实现高吞吐率的
Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失 kafka主要使用了以下几个方式实现了超高的吞吐率 文件分段 kafka的队列topic被分为了多个区partition，每个partition又分为多个段segment，所以一个队列中的消息实际上是保存在N多个片段文件中 ? 通过分段的方式，每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力 批量发送 Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去 比如可以指定缓存的消息达到某个量的时候就发出去 ，或者缓存了固定的时间后就发送出去 如100条消息就发送，或者每5秒发送一次 这种策略将大大减少服务端的I/O次数 数据压缩 Kafka还支持对消息集合进行压缩，Producer可以通过GZIP 或Snappy格式对消息集合进行压缩 压缩的好处就是减少传输的数据量，减轻对网络传输的压力 Producer压缩之后，在Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是
2.2K60发布于 2018-04-03 - 来自专栏腾讯开源的专栏
【开源公告】“高可用、高吞吐、高可靠”分布式队列PhxQueue开源
PhxQueue PhxQueue 是微信开源的一款基于 Paxos 协议实现的高可用、高吞吐和高可靠的分布式队列，保证At-Least-Once Delivery，目前在微信内部广泛支持微信支付、 其设计出发点是高数据可靠性，且不失高可用和高吞吐，同时支持多种常见队列特性： * 同步刷盘，入队数据绝对不丢，自带内部实时对账 * 出入队严格有序 * 多订阅 * 出队限速 * 出队重放 * 所有模块均可平行扩展 * 存储层批量刷盘、同步，保证高吞吐 * 存储层支持同城多中心部署 * 存储层自动容灾/接入均衡 * 消费者自动容灾/负载均衡 高可用、高可靠、高性能的分布式队列PhxQueue正式开源 Github
1.1K61发布于 2018-03-02 - 来自专栏用户8851017的专栏
如何让消息队列达到最大吞吐量？
关于吞吐量的一些思考 写入消息队列吞吐量取决于以下两个方面 网络带宽 消息队列（比如Kafka）写入速度 最佳吞吐量是让其中之一打满，而一般情况下内网带宽都会非常高，不太可能被打满，所以自然就是讲消息队列的写入速度打满 ，这就就有两个点需要平衡 批量写入的消息量大小或者字节数多少 延迟多久写入 go-zero 的 PeriodicalExecutor 和 ChunkExecutor 就是为了这种情况设计的 从消息队列里消费消息的吞吐量取决于以下两个方面 消息队列的读取速度，一般情况下消息队列本身的读取速度相比于处理消息的速度都是足够快的 处理速度，这个依赖于业务 这里有个核心问题是不能不考虑业务处理速度，而读取过多的消息到内存里，否则可能会引起两个问题 ： 内存占用过高，甚至出现OOM，pod 也是有 memory limit 的 停止 pod 时堆积的消息来不及处理而导致消息丢失 解决方案和实现 借用一下 Rob Pike 的一张图，这个跟队列消费异曲同工 return } case event := <-eventChan: consumer.OnEvent(event) } } 这里如果拿到消息就去处理，当 ok 为 false
86520发布于 2021-07-22 - 来自专栏go-zero
如何让消息队列达到最大吞吐量？
你在使用消息队列的时候关注过吞吐量吗？ 思考过吞吐量的影响因素吗？ 考虑过怎么提高吗？ 总结过最佳实践吗？ 本文带你一起探讨下消息队列消费端高吞吐的 Go 框架实现。Let’s go! 关于吞吐量的一些思考 写入消息队列吞吐量取决于以下两个方面 网络带宽 消息队列（比如Kafka）写入速度 最佳吞吐量是让其中之一打满，而一般情况下内网带宽都会非常高，不太可能被打满，所以自然就是讲消息队列的写入速度打满 ，这就就有两个点需要平衡 批量写入的消息量大小或者字节数多少 延迟多久写入 go-zero 的 PeriodicalExecutor 和 ChunkExecutor 就是为了这种情况设计的 从消息队列里消费消息的吞吐量取决于以下两个方面 消息队列的读取速度，一般情况下消息队列本身的读取速度相比于处理消息的速度都是足够快的 处理速度，这个依赖于业务 这里有个核心问题是不能不考虑业务处理速度，而读取过多的消息到内存里，否则可能会引起两个问题 ，以及如何实现一个通用的消息队列处理框架，并通过 mock 示例简单展示了如何基于 core/queue 实现一个消息队列处理服务。
1.1K30发布于 2021-05-13 - 来自专栏韩伟的专栏
分布式本质论：高吞吐、高可用、可扩展
而这些对于“服务速度”的要求，实际上包含的部分却是以下几个：高吞吐、高并发、低延迟和负载均衡。 高吞吐，意味着你的系统，可以同时承载大量的用户使用。这里关注的整个系统能同时服务的用户数。 这个吞吐量肯定是不可能用单台服务器解决的，因此需要多台服务器协作，才能达到所需要的吞吐量。 而在多台服务器的协作中，如何才能有效的利用这些服务器，不致于其中某一部分服务器成为瓶颈，从而影响整个系统的处理能力，这就是一个分布式系统，在架构上需要仔细权衡的问题。 高并发是高吞吐的一个延伸需求。 ——所以，人们设计出更好进程间通讯机制：消息队列。 尽管通过各种Proxy或者Router进程能组建出强大的分布式系统，但是其管理的复杂性也是非常高的。 ，造成用户的响应延时增加，以及整体系统的吞吐量极度下降。
7.3K00发布于 2017-11-21 - 来自专栏涤生的博客
高吞吐低延迟 Java 应用的 GC 优化
基础 Feed 数据平台为我们的经济图谱（会员、公司、群组等）中各种实体的更新建立索引，它必须高吞吐低延迟地实现相关的更新。 这篇博文将通过一系列步骤来明确需求并优化 GC，它的目标读者是对使用系统方法进行 GC 优化来实现应用的高吞吐低延迟目标感兴趣的开发人员。 优化 GC 的步骤 下面是一些针对高吞吐量、低延迟需求优化 GC 的总体步骤。此外，还包括在 Feed 数据平台原型实施的具体细节。 像吞吐量和延迟一样，这些 GC 特征应该在长时间运行的测试中观察到，以确保应用程序能够在经历多个 GC 周期中处理流量的变化。 Stop-the-world 回收器回收垃圾时会暂停应用线程。 对于不受 CPU 限制的低吞吐量应用程序，GC 导致的高 CPU 使用率可能不是一个紧迫的问题。 !
2.1K30发布于 2019-04-24 - 来自专栏涤生的博客
高吞吐低延迟 Java 应用的 GC 优化
为了将这些高吞吐量、低延迟类型的 Java 应用程序用于生产，开发人员必须确保在应用程序开发周期的每个阶段都保持一致的性能。 这篇博文将通过一系列步骤来明确需求并优化 GC，它的目标读者是对使用系统方法进行 GC 优化来实现应用的高吞吐低延迟目标感兴趣的开发人员。 优化 GC 的步骤 下面是一些针对高吞吐量、低延迟需求优化 GC 的总体步骤。此外，还包括在 Feed 数据平台原型实施的具体细节。 像吞吐量和延迟一样，这些 GC 特征应该在长时间运行的测试中观察到，以确保应用程序能够在经历多个 GC 周期中处理流量的变化。 Stop-the-world 回收器回收垃圾时会暂停应用线程。 对于不受 CPU 限制的低吞吐量应用程序，GC 导致的高 CPU 使用率可能不是一个紧迫的问题。
1.4K21发布于 2019-05-07 - 来自专栏EffectiveCoding
Kafka “高吞吐” 之顺序访问与零拷贝
前言 上一篇所说的micr-batch 其实主要是针对producer 来实现的，Kafka整体吞吐量高可不只是依赖于micr-batch这一点，还有broker端及consumer端。 Kafka高吞吐的另一个依赖因素是磁盘的高速读写、sendFile 的零拷贝，顺序访问避免了磁盘IO速度缓慢的问题。而零拷贝直接降低了网络IO的代价。 这可能也是Kafka设计存储方式采用消息日志文件的原因，总体来说，这种写入之后就不会变，并且会大量读写操作的场景都可以使用这种方式的。 在关于producer 产生消息 broker底层读写日志采用的就是这种方式，有没有很方便呢～ 然后再来看看消费消息时所用到的FileChannel.transferTo函数，FileChannel是一个接口
1.5K30发布于 2019-07-31 - 来自专栏EMQ 物联网
车联网平台百万级消息吞吐架构设计
传统的互联网系统很难支撑百万量级的消息吞吐。在本文中，我们将主要介绍如何针对百万级消息吞吐这一需求进行新一代车联网平台架构设计。 车联网场景消息吞吐设计的关联因素 车联网的消息分为上行和下行。 采用 10 台 EMQX 组成一个大集群，把一百万的消息吞吐平均分到每个节点十万消息吞吐，同时满足高可用场景需求。 如有离线离线/消息缓存需求，可选用 Redis 作为存储数据库。 强大的规则引擎和数据桥接、持久化能力，支持百万级消息吞吐处理。 拥有丰富 API 与认证等系统能顺利对接。 百万吞吐场景验证 为了验证上述架构的吞吐能力，在条件允许的情况下，我们可以通过以下配置搭建百万级消息吞吐测试场景。 压测架构图如下： 性能测试部分结果呈现： EMQX 集群 Dashboard 统计 EMQX 规则引擎中可以看到每个节点速度为 10 万/秒的处理速度，10 个节点总共 100 万/秒的速度进行。
2.4K40编辑于 2022-06-30
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号