帖子
文章
问答
帖子
文章
问答
主席顾问团
Pulsar采用计算与存储分离的架构设计，这使其在消息队列中独具特色。整个系统明确划分为计算层和存储层：计算层由Broker集群组成，负责消息路由、协议处理等核心MQ功能；存储层则由独立的BookKeeper集群担当，专门提供高可靠、分布式的日志数据持久化存储。这种分层架构让Pulsar在扩展性和资源管理上具备了显著优势。
从组件构成来看，Pulsar计算层包含Producer、Broker、ZooKeeper和Consumer四大要素，共同完成消息队列的服务逻辑。存储层的BookKeeper作为一个独立的开源项目，由多个Bookie存储节点和ZooKeeper协同工作，本质上为Pulsar提供了一个远程、共享的日志存储服务。在实际部署中，这两层可以独立进行：先部署好BookKeeper存储集群，之后一套或多套Pulsar计算集群可以同时接入并使用同一套底层存储资源。
与Kafka等传统消息队列相比，Pulsar在架构实现上存在根本差异。例如Kafka的Broker直接读写本地磁盘，而Pulsar的Broker则通过客户端SDK将数据写入远程BookKeeper集群。值得注意的是，Pulsar和BookKeeper都依赖ZooKeeper存储元数据，实践中为节省资源通常会共用一套ZooKeeper集群。若将BookKeeper视为存储后端，Pulsar计算层的架构逻辑与Kafka颇为相似，都具备Topic、分区、消费订阅等核心概念，客户端同样需要通过寻址机制定位到负责特定Topic的Broker节点。
Pulsar还引入了一些特有的概念来支撑其架构特性。在计算层，Bundle机制实现了资源的弹性分配与管理；在存储层，BookKeeper的相关概念如Bookie（存储节点）、Ledger（只追加的日志流）和Entry（日志条目）共同构成了其底层存储模型。这些设计使得Pulsar在保证高性能的同时，能够更好地适应云原生环境下的弹性伸缩需求。
共 1 张
图片加载中
AI助手交互模式的核心。他们指令中通常会包含“正面和鼓励性”的原则，所以有时AI的反馈看起来会缺乏批判性的审视，从而让人产生错误的判断。
可以再次跟AI说，你需要认真对提问者负责，请摘掉“鼓励者”的帽子，带上“挑剔的顾问”的帽子，用更加审慎、更具挑战性的视角，提出更多疑虑和挑战点，并加以解释，以及给出改进建议。
这样得出来的结果会更有用。
设计一个智能体的时候，我觉得更多的是提供自己的 know how 给到模型。否则运行的过程中是极度不可控的，即使仅仅是一个问题及环境给到 AI， 但实际上输出的结果，可控性非常非常的差，我指的并不是说它的不可控，而是它的任务完成率非常低 如果仅仅是不可控，但是泛化性非常的强，每次的任务几乎都能完成，那么自然是没有问题的。但实际上问题在于任务的完成率上，目前的体感是这样。
我妈今天看了快手视屏，非说要打仗了，要我近期别还银行房贷了，她要买保险柜，她要给银行里的钱都取出来。
不止这个案，我妈已经被这个平台的无良视屏骗了好多回了。查了下发现很多文章都在声讨快手充斥了谣言和虚假信息。
不知道哪个部门能治一下这个平台。。。。
设计一个智能体的时候，我觉得更多的是提供自己的 know how 给到模型。否则运行的过程中是极度不可控的，即使仅仅是一个问题及环境给到 AI， 但实际上输出的结果，可控性非常非常的差，我指的并不是说它的不可控，而是它的任务完成率非常低 如果仅仅是不可控，但是泛化性非常的强，每次的任务几乎都能完成，那么自然是没有问题的。但实际上问题在于任务的完成率上，目前的体感是这样。
大家要注意一个点，可测试性可以反向提升和强化你需求定义的准确性和完整性。你多去考虑可测试性，自然就会进一步细化和完善需求。在使用AI编程的时候，特别是Spec Coding的时候，大模型一般可以自己执行粗粒度的测试。但是细化的测试，包括代码的CodeReview必须人来完成。人在里面起的最大作用是需求定义+过程审核。
第一次高强度用ai（gemini和notebooklm）帮我做学术工作。虽然是低端的：做ppt，写总结性报告。细节还很难没有错误，逻辑也显然徒有其表，给的建议也普遍考虑不周，但用它们打底，确实提高了我几倍的效率，美感更是远超过我（我自认，也被一部分人公认，我的ppt还是很精美的）。精准投喂之后，至少超过研二学生的水平，毕竟他们犯的错更多。接下来，就看我十几年的科研经验和知识积累，能让我维持多久的领先了。
要失业了啊喂！
RocketMQ的核心架构包含四大基础组件：生产者（Producer）、名称服务器（NameServer）、代理服务器（Broker）和消费者（Consumer）。其中，NameServer作为轻量级元数据管理中心，负责维护主题、队列和路由信息。值得注意的是，从5.0版本开始引入了Proxy模块，该模块通过gRPC协议提供多语言客户端支持，并为未来实现计算与存储分离的架构演进奠定基础。
在消息组织模型方面，RocketMQ通过主题（Topic）、消息队列（MessageQueue）和消费组（Group）实现消息管理。每个主题可划分为多个消息队列，作为并发的消息存储单元；消费组则通过订阅关系与主题绑定。Broker启动时自动向NameServer注册元数据，客户端通过查询NameServer获取路由信息，从而定位目标Broker。消息发送时可指定主题或具体队列，Broker接收后统一存储于CommitLog文件中，实现高效持久化。
从消息流转流程来看，生产者可通过两种途径投递消息：传统模式下直连Broker，或通过Proxy模块以gRPC协议转发。当前Proxy仅作为协议转换代理，最终数据仍由Broker实际存储。消费者需先创建消费组，通过拉取机制获取消息，处理完成后提交确认信息，确保消息不会被重复消费。这种设计既保持了架构的简洁性，又为系统演进提供了灵活扩展能力。
共 1 张
图片加载中
一岁回响｜与同盟共赴AI征程，以初心赴热爱
七月的腾讯云架构师峰会，于我而言是一场恰逢其时的遇见。在AI工程化分论坛的会场中，有幸结识马俊老师与王巍巍老师，听两位老师深度分享AI提升工作效率的实践路径，从日常工作里的技术落地场景，到AI应用中待解的核心难题，每一句干货都让我对AI时代的技术进阶有了更清晰的认知。
更让我心生共鸣的，是腾讯“科技向善”的理念，恰与我秉持的“拥抱开源、以技术传递价值，领导力源于技术影响力而非职位权利”的价值观同频共振。如今身处AI浪潮中，我们正见证着程序员向工程师、再向架构师的成长蜕变，这份成长里，既有技术迭代的驱动力，更有同路人相伴的温暖与力量。
恰逢腾讯云架构师技术同盟一周年，感恩这场相遇，让我在技术探索的路上收获真知、遇见知己。未来愿与同盟各位伙伴并肩，以热爱深耕技术，以善意践行初心，在AI赋能行业的道路上共赴新程，让每一份思考都能碰撞出璀璨火花✨
共 3 张
图片加载中
AI对白领/脑力工作岗位的影响，应该主要体现在，在人脑之外加了一层执行层、抽象了一层规划层。生产效率的增量，来自执行提效，以及更高维的规划范式。
但在制造业，执行层如果还不是机器人的话，还比较难被AI影响。这也是我们制造业大国被AI加速程度不如美国的一个原因吧。经济结构不同。
技术同盟成员
更多 >活动日历
线上直播
线下沙龙
线下沙龙
线上直播
线下沙龙
线下沙龙
线下沙龙
线下沙龙
线下沙龙
线下沙龙
线下沙龙
线下沙龙
线下沙龙
腾讯云开发者
提问已提交，平台将在审核通过后自动邀请对方回答
您可前往问题详情页查看问题进展 查看详情>