先说结论这场COSCon‘25期间的Pulsar Developer Day 2025专场是我今年参加过最“解渴”的消息队列技术活动。从早到晚的内容排得非常满不是那种念PPT式的分享而是真刀真枪地讲架构演进、生产落地方案和踩坑细节。作为一个长期跟MQ打交道、也维护过好几套生产消息中间件的人这一天下来很多东西都值得记录下来。这篇回顾文章就是想把当天的技术干货、社区动态和我个人的一些思考整理出来给关注消息队列选型、以及想深入了解Pulsar的读者一个参考。标题里那句“Make MQ Great Again”其实挺有意思它不是营销口号而是技术圈里的一种情绪表达。消息队列这些年一直被叫做“系统的血管”但说实话真正把消息队列当成核心基础设施来打磨的团队并不多。而Apache Pulsar这几年在存储计算分离、多租户和分层存储这些方向上的进展确实让这个领域重新变得性感起来。1. 先聊聊这一天的整体印象议程与技术主线1.1 从早到晚的节奏演讲、动手实验与自由交流那天我大概是早上八点半到的会场签到处已经排起了队。和很多技术会议一样大家胸前挂着胸牌背着双肩包但明显能感觉到这个场子里的“精准度”很高——来的人基本都是后端开发、架构师或者中间件负责人讨论的话题也始终围绕主题在转。上午场的安排以主题演讲为主。开场是项目动态和社区进展的介绍接着是几个核心议题的深度分享节奏大概在30到40分钟一个主题中间有短暂的茶歇。我最关注的是其中关于存储架构和生产环境实践的Session这些内容不是那种泛泛的产品介绍而是带着真实业务压力去讲的。下午场是动手实验Workshop的环节参与者可以跟着讲师一步步操作现场搭起一套单机版Pulsar环境跑通生产消费、了解分层存储的配置方式。这种一边讲一边跑的环节参与度明显比纯听高很多。我记得当时我旁边坐着一个做电商业务的工程师他一边敲命令一边跟同伴小声讨论“这个offload策略如果接到我们S3的桶里是不是就能把一年前的订单数据直接丢对象存储了”那种感觉就是技术分享真正产生了共鸣的时刻。除了正式的议程之外会场角落里还有一些自由交流的讨论角几个人围着一张桌子聊开源协议的兼容性、聊跨地域复制的同步延迟甚至还有人在现场给Pulsar提了一个关于客户端连接池问题的改进建议。这种交流的信息密度有时候比台上的演讲还高。1.2 “Make MQ Great Again”这句话背后的技术圈情绪这句口号挂在主会场背景板上乍一看有点戏谑但仔细想想它确实点出了消息队列圈子当下的状态。过去十几年Kafka几乎成了消息中间件的代名词稳定、吞吐高、生态好但它的存储模型和运维模型也带来了一堆让人头疼的问题分区数上去了之后均衡成本高冷数据占磁盘导致查询变慢多租户支持基本要靠多集群来堆。“Great Again”并不是说过去很好现在不行了而是说这个领域需要一点新的想象力。Pulsar的存算分离架构、原生多租户、分层存储和跨地域复制正好指向了Kafka时代那些不太好绕开的问题。它的兴起不只是一款产品的崛起更是整个MQ技术栈在向“云原生基础设施”方向演进的一种表现。我在现场听到有位分享者说了一句话大意是“我们把消息队列从通信组件变成了数据基础设施”。这句话其实很关键。当你把MQ当作通信管道时关心的就是吞吐、延迟当你把它当作数据基础设施时关心的就是持久性、可追溯性、隔离性和跨地域的容灾能力。Pulsar的很多设计正是在为后者铺路。2. 核心分享复盘Pulsar真正打动人的技术点2.1 存算分离不是噱头是架构长期主义的落点很多人在聊Pulsar时都会提到存算分离但说实话如果不是仔细读过它的架构设计很容易把这个概念和普通的“服务拆分开”混为一谈。Pulsar的存算分离指的是Broker承担计算和读写与BookKeeper承担存储是完全独立的两层各自可以单独扩缩容。给你打个比方。传统消息队列像一个小杂货铺老板既要站在柜台前招呼客人又要去仓库理货客人一多、货一多老板就会手忙脚乱。Kafka其实就是这个模式Broker既要处理读写请求又要管磁盘上的日志文件流量高峰期和存储压力混在一起互相拖累。而Pulsar更像一个大超市前台收银和后台仓储是两拨人哪边忙就给哪边加人。Broker层无状态扩容时不用搬数据BookKeeper层专注把数据安全可靠地写进持久化存储挂了一个节点也能通过副本机制快速恢复。现场有位嘉宾讲到了这个架构在生产环境中的实际价值他提到一个细节他们曾经在业务高峰期给Pulsar集群的Broker层扩容整个过程几乎没影响在线读写因为新Broker加入后只需要做一些负载接管不需要像Kafka那样做分区重分配和长时间的数据迁移。这个“弹性”带来的运维体感是用过Kafka再转向Pulsar之后体会最深的一点。另外存算分离还有一个不那么显性但很重要的好处支持更大的Topic规模。Kafka的Topic数量一旦涨上去分区文件和小文件碎片会成为运维噩梦而Pulsar因为底层用BookKeeper的分段存储Segment机制单个集群能承纳的Topic数量高出不少。对于有大量业务线、每个业务线都有自己Topic的团队来说这个差异是实打实的成本差异。2.2 多租户模型一个集群服务几十条业务线的底气Pulsar的多租户模型是我觉得它在架构上做得最优雅的部分。它把资源逻辑拆成了三层租户Tenant、命名空间Namespace和主题Topic。你可以把租户理解为一栋写字楼命名空间是某一层Topic就是这一层里的一个个办公室。每个层级都可以独立地设置权限、配额、隔离策略和消息保留策略。这意味着什么意味着一个Pulsar集群可以服务多个业务部门或团队每个团队放在自己的租户或命名空间里互不干扰。比如A团队的消息设置了3天保留B团队的消息设置了30天回溯C团队设置了无限保留用于审计这些策略可以共存在同一个集群里而不是为每个团队单开一套集群。现场有个分享嘉宾介绍了一个典型案例他们公司用一套Pulsar集群同时支撑订单事件、用户行为日志、搜索索引构建、数据分析等多个业务场景每个业务线一个命名空间各自的存储策略、消费模式、权限互相独立。如果放在Kafka里要达到类似效果要么给每个团队搭一套集群要么就只能共用一个大集群然后自己维护非常复杂的ACL规则。前者浪费资源后者管理成本和风险都很高。多租户还带来一个很重要的能力资源隔离与配额保护。在Pulsar里你可以设置每个命名空间的存储配额、Backlog配额和消息速率限制。这样即使某个业务线出现了消费故障导致消息大量积压也不会影响其他业务线的正常读写。这一点对于中大型团队来说非常实用等于从平台层面给业务排障留出了缓冲带。2.3 分层存储与跨地域复制从“删日志”到“无限回溯”在我接触过的很多消息队列团队里围绕“消息能保留多久”这件事都有过痛苦的决定。Kafka的存储和计算耦合在一起数据只能存在本地磁盘上磁盘空间有限所以一般只能保留几天或几周的数据超过窗口的消息只能被删除。这在很多场景下是很可惜的因为那些老数据不只是日志它们还是审计证据、是数据重放的基础、是出问题之后排查的线索。Pulsar的分层存储机制正是解决这个问题的一把钥匙。它的基本思路是热数据先存在BookKeeper里当数据段达到一定条件比如时间或大小阈值可以自动把老的数据段卸载Offload到廉价的存储介质上最常见的是对象存储。数据卸载之后不会被删除消费者需要回溯消费时Broker能透明地从对象存储把数据重新读出来。这个机制转换意味着“无限保留”成为了一个实际可选的策略而不是一个奢望。我在现场看到演示时还是有点激动的操作员对着一个已经积累了几个月的Topic执行了一条命令BookKeeper上的磁盘占用立刻下降而用消费者去消费一个月前的消息依然能正常读到数据。整个过程对客户端完全是透明的和读热数据没有区别。跨地域复制则是另一个让我觉得“终于等到了”的功能。它允许你在多个机房或区域之间配置异步复制每个副本都保持消息的顺序和元数据一致性用于构建多活或者灾备架构。Kafka也有MirrorMaker这样的跨集群复制方案但使用起来相对粗糙更多是“同步数据”而Pulsar的复制是内建的、搭配多级安全和Topic策略来使用的。在现场问答环节有人问“跨地域复制会不会丢数据”嘉宾的回应也很实在异步复制天然存在一个极小的同步窗口但对大多数灾备场景来说它提供的保障已经远胜于没有复制如果你的业务要求强一致那还需要搭配其他方案来兜底。2.4 订阅模型和协议兼容让新老用户都有的选Pulsar的订阅模型也是这次大会里被反复讨论的话题。它支持独占Exclusive、共享Shared、故障转移Failover和按键共享Key_Shared四种模式。如果你用过其他消息队列这几种模式拆开来看都不陌生但Pulsar把它们在同一个Topic下统一支持了这就有意思了。独占模式保证严格的消息顺序适合事件排序敏感的场景共享模式把消息分发给多个消费者提升消费吞吐但顺序性被弱化故障转移模式则是在一个消费者挂掉之后由备用消费者无缝接管适合有状态但需要高可用的场景按键共享模式是很多人最喜欢用的一个它把相同Key的消息固定发给同一个消费者这样既保证了某个维度比如用户ID、订单ID的消息有序又能通过增加消费者来扩展消费能力。我记得现场有人问了一个特别实战的问题“我们订单系统想提高消费并行的能力但又不敢丢顺序到底该用共享还是按键共享”讲师的回答很干脆订单维度对同一个订单号必须严格有序那就用按键共享按订单号作为Key而如果只是系统通知、日志处理这类不需要顺序约束的消息直接用共享模式拉满消费线程就行。这种“按场景匹配订阅模式”的思维也正是Pulsar能同时吸引流计算和队列场景用户的原因。协议兼容方面Pulsar提供了Kafka兼容API。这个能力我一开始也有点怀疑毕竟客户端生态的兼容性不是一蹴而就的。但现场演示中他们用标准Kafka客户端直连Pulsar集群发消息、消费消息、查看消费组积压整个过程几乎是无感知的。对已经在用Kafka、但被运维问题困扰的团队来说这意味着可以分阶段地迁移先切一部分流量验证再逐步改成原生Pulsar客户端。这个过渡路径设计得相当务实。3. 实战视角从分享和Workshop看消息队列落地细节3.1 一个真实的迁移故事从旧MQ走到Pulsar的路径下午的某个环节分享嘉宾讲了一个他们团队从旧MQ迁移到Pulsar的过程。因为现场不允许提具体公司名我这里就拿“某团队”来代称。他们的背景很有代表性公司已经有一套成熟的Kafka集群跑了好几年但随着业务线增加分区数和Topic数增长很快运维团队开始疲于应付迁移、扩分区、重平衡这些事而且多个团队共用大集群权限和资源隔离做得不够精细偶尔还会因为某个业务疯狂写数据拖垮全集群。他们做的第一件事不是立刻换技术栈而是花了一个月时间做了压测和对比。他们在同样的硬件上分别部署了Kafka和Pulsar测试了高吞吐写入、消费积压恢复、网络抖动下的表现。最终Pulsar的打分最高尤其是在故障恢复这个维度上模拟Broker宕机后Pulsar集群很快就能恢复读写而Kafka那套在分区重平衡时耗时比较长。迁移策略上他们非常稳健第一阶段只迁非核心链路的日志和异步通知让团队熟悉运维和监控第二阶段把订单事件等核心消息切到Pulsar但在切换前保持了双写和双读并行了一个月用两边的数据对比来验证可靠性。他们提到一个很重要的经验不要做“大爆炸式”的迁移一定要给团队留出学习和适应的时间。他们也踩了一些坑。客户端版本不一致导致连接闪断是一个很典型的教训。Pulsar客户端和服务端之间的协议兼容性没有想象中那么“无限向后兼容”团队在开发环境用了新版本的客户端而生产环境还是老版本结果升级过程中出现了短暂的消息延迟。另外一个是消息大小上限的配置。他们在迁移初期没有调整消息最大尺寸结果某些业务发超过默认大小限制的消息时直接被拒绝排查了半天才找到原因。这些细节都是文档里不常见、但实战中一定会遇到的。3.2 性能调优到底要动哪些参数现场分享的调参清单在另一个技术分享里嘉宾列出了一组Pulsar性能调优的关键参数并把它们分成“一开始就要设对”和“运行后按需调整”两类。这个分类方式很实用我也把它整理成了一个清单方便大家对照。先说一开始就要设对的。存储层有一组关于副本和确认的参数包括分段大小、写法定和确认法定。默认的分段大小通常在几十到上百MB之间这个值会影响存储文件的读取效率和分层存储的卸载频率一般建议按消息体大小来粗略估算不要让一个分段里只有几条大消息也不要让分段太大导致读取热点过于集中。副本数和确认数的配置更多是可靠性与性能的权衡默认配置下能保证至少两个副本确认写入成功如果需要更高的容错性可以调整但也会带来额外的写入开销。然后是一些运行时需要关注的参数。内存缓存的大小很关键它决定了读热数据时的缓存命中率如果缓存太小Broker会频繁回源读取存储层延迟会明显上升。还有订阅的Backlog配额策略这个是要在业务上线前就定好的否则某个消费组挂了没人处理消息积压起来会拖垮存储。最后是生产端的批处理参数比如批处理大小、批处理时间窗口和最大排队消息数这三个参数直接影响吞吐和延迟的平衡点。如果你追求低延迟就要把批处理窗口调小如果你追求高吞吐就要适当牺牲一点延迟。这里我给一个我自己的经验调优不是一个“照着参数改一遍”就完事的过程而是必须先明确业务的目标到底是延迟敏感还是吞吐优先再去动对应的参数。很多团队上来就抄推荐配置结果发现完全不适合自己的场景最后又花了几周改回去。这个弯路我也是踩过的。3.3 从零跑通Pulsar单机版Workshop现场实操笔记下午的Workshop环节讲师带着我们从零搭了一个Pulsar单机版环境。虽然步骤不算复杂但我觉得对没有接触过Pulsar的人来说能亲手跑一遍“启动、发消息、消费消息、看策略配置”的完整流程比看多少页文档都管用。我先记一下核心步骤方便想自己动手尝试的读者参考。首先需要下载Pulsar的二进制发布包并解压然后直接启动单机模式wget https://archive.apache.org/dist/pulsar/pulsar-3.3.1/apache-pulsar-3.3.1-bin.tar.gz tar -xzf apache-pulsar-3.3.1-bin.tar.gz cd apache-pulsar-3.3.1 bin/pulsar standalone启动过程会拉起单机版的ZooKeeper、BookKeeper和Broker。等日志输出稳定后新开一个终端用CLI先创建一个租户和命名空间bin/pulsar-admin tenants create my-tenant bin/pulsar-admin namespaces create my-tenant/my-namespace然后生产一条消息再消费出来bin/pulsar-client produce my-tenant/my-namespace/my-topic --messages hello-pulsar bin/pulsar-client consume my-tenant/my-namespace/my-topic --subscription-name my-sub --num-messages 1如果你也想体验分层存储的配置过程可以执行bin/pulsar-admin namespaces set-offload-policies my-tenant/my-namespace \ --driver S3 --bucket pulsar-offload --region us-east-1 bin/pulsar-admin namespaces get-offload-policies my-tenant/my-namespace最后一条命令会把命名空间下的数据段卸载到对象存储中。在单机环境里这个操作不会真的产生巨大的数据迁移但能让你直观理解“分层存储策略是配置在命名空间这一层”这个事实。这种亲手操作带来的体感和单纯听PPT是完全不同的。4. 场外互动里的信息量社区正在变成一个“资源池”4.1 现场人群画像看看谁在关注Pulsar我很喜欢在技术大会上观察来参加的人因为这能反映出这个项目真实的用户基础。当天到场的人里面有相当一部分是已经在生产环境使用Pulsar的工程师他们来的目的是交流踩坑经验、看看新版本有没有解决自己的问题还有一部分是正在做选型调研的技术负责人手里可能握着几套消息中间件的对比表格想通过现场提问来验证一些疑虑另外还有一些学生和刚开始接触中间件的新人他们在Workshop环节问了很多基础但重要的问题。人群成分多样说明Pulsar已经不只是“大厂玩具”了。特别是那几位正在选型阶段的工程师给我印象很深他们的问题非常具体比如“我们团队对Kafka特别熟换Pulsar之后学习成本怎么控制”“Pulsar的监控面板有哪些关键指标要注意”这类问题是真正准备推动技术落地的团队才会关心的。4.2 现场高频提问速查选型、运维和兼容性的答案我把现场问答环节和私下交流中出现频率最高的几个问题整理了一下做成一个速查表每个问题的答案都来自当天多位分享者和社区老兵的回答。问题类型典型提问现场回复要点选型我们数据量不大有必要引入Pulsar吗如果看重多租户、无限追溯和跨地域容灾小规模也值得尝试如果只是单纯高吞吐管道Kafka更成熟。运维Pulsar组件多运维是不是很重真正有状态的是BookKeeper层Broker无状态依赖自动化运维面板后压力可控比Kafka多一个存储层要花时间。一致性跨地域复制会不会丢消息异步复制存在极小的同步窗口可通过监控和策略优化来缩小强一致场景需要额外方案。兼容存量Kafka客户端能直接迁移吗Pulsar提供Kafka协议兼容API标准客户端可以连入但生产切换前必须做完整压测。功能消息无限保留真的可以吗分层存储落地后冷数据卸载到对象存储回溯消费透明基本实现无限保留。这张表只是给一个大概的方向真正决策时还是要结合自己业务的流量模型、容灾目标和团队运维能力来综合判断。大会上没有任何一个嘉宾给出“无脑选Pulsar”这种结论反而都强调要理性对比。4.3 一个值得关注的细节项目健康度与社区贡献者除了内容本身我还特别关注了一个细节Pulsar项目的活跃度和治理模式。会场上有一些项目的维护者和核心贡献者他们会在展台旁边回答与会者的问题也会认真记录社区里反馈的需求和Bug。有人在现场提交了一个关于客户端线程模型的问题维护者当场就打开Issue看上下文然后约了会后细聊。这种“用户和核心贡献者之间几乎零距离”的互动状态对于一个开源项目长期健康发展来说价值远超一次大会本身。我也观察到Pulsar社区在文档和工具链上花了很大的功夫。官方文档的示例代码、运维脚本以及各个连接器的完善度比早期版本好了非常多。对一个开源中间件来说代码再强、文档跟不上用户上手就是灾难。而Pulsar社区明显意识到了这一点这从现场很多新人能快速完成Workshop这一点就能看出来。5. MQ选型观察从大会分享反推三款消息中间件的取舍5.1 三款主流MQ的定位差异与选择逻辑每次参加这类与中间件有关的活动我都会下意识地做一次横向对比。Kafka、RocketMQ和Pulsar是目前国内技术圈里被讨论最多的三款消息队列它们各有各的“舒适区”不是看几张性能对比图就能拍板的。Kafka的优势在于高吞吐和庞大的生态它天然适配大数据管道、日志收集、流计算这些场景。但如果你的业务追求多租户隔离、存储无限回溯和跨地域容灾Kafka就会显得比较费力因为这些能力要靠外部方案或自己搭建来补齐。RocketMQ在国内电商、金融场景落地非常广事务消息和延迟消息这些功能做得早Java生态也友好但它的架构设计和Pulsar的思路不太一样多租户和存储弹性没有Pulsar那么原生。Pulsar的差异化竞争力在于云原生的架构理念和统一的消息与流模型。它既能当消息队列用也能当流平台用既支持Kafka协议兼容又有自己原生客户端既能做多租户隔离又能做到分层无限存储。它的代价是组件更多学习曲线相对陡峭如果你的团队对Kafka体系已经很熟又没有强烈的架构变革需求那么迁移的成本可能大于收益。我用一个简单类比来理解这三款产品的定位Kafka像一个效率极高的装配流水线专门为大规模吞吐优化但它的灵活性一般RocketMQ像一个功能齐全的国产车间很多常用功能都内置好了用起来顺手Pulsar则像一个可以灵活分割、可以无限扩建的现代智慧园区前期规划复杂一点但后面扩展空间大。选哪个本质上是在“近期工程效率”和“长期架构弹性”之间做取舍。5.2 消息队列正在变成“数据基础设施”这对选型意味着什么这次大会给了我一个很明显的信号消息中间件正在从一个“通信管道”逐渐演变成“数据基础设施”。过去我们用MQ主要是为了削峰填谷、解耦系统现在越来越多的团队把消息流当作一种数据资产用来做审计、做数据重放、做事件溯源甚至直接作为实时数仓的一部分。这个趋势对选型的影响很大。如果你只是把MQ当成一个临时排队工具那吞吐、延迟这些指标就够了但如果你打算把消息数据长期留存、跨地域容灾、让多个团队安全地共享一套集群那就必须考虑存储架构、多租户能力和生态连接器这些“后置需求”。Pulsar的存算分离和多租户模型天然更适合这种“基础设施化”的方向。它可以把一个集群做成一个“消息中台”不同业务线以租户和命名空间的方式接入消息默认无限保留按需配置分层存储策略。这种模式下消息不再是被用完就丢的瞬时数据而是能回溯、能审计、能重放的数据底座。这次大会上不少分享者都在这个框架下介绍自己的实践。当然这不是说每个团队都要立刻拥抱Pulsar。基础设施的替换成本很高必须结合团队现状和业务未来规划来决策。但至少在未来三到五年的技术演进方向上我可以确定“存储计算分离”和“多租户云原生”会是消息队列领域的主流叙事。6. 给下次参加开源大会的你几条务实的参会建议6.1 会前准备不预习等于白来技术大会的议程通常非常密集如果你不带着目标和问题去一天下来很容易被灌输一堆零散的信息回来之后什么都记不住。我参加过不少大会踩过这个坑所以现在养成了习惯拿到议程表之后先圈出“必听”和“备选”并且提前把必听Session里可能涉及的关键词扫一遍。比如这次我提前在本地把Pulsar单机版跑通了所以听分享的时候能更快跟上嘉宾的思路也能在Workshop环节直接对标自己的操作。如果你正在做消息队列选型建议去之前先在本地用Pulsar发几条消息再看看Kafka和Pulsar的对比文档这样现场提问的时候就能问出“我们目前Kafka有200个分区换到Pulsar后分区模型要不要重新设计”这种具体问题而不是“Pulsar能不能替代Kafka”这种太宽泛的问题。6.2 会中互动提问和交流的正确姿势在开源技术大会上你是在一个信息密度极高的场子里。怎么从里面挖到最多的干货一定程度上取决于你怎么提问、怎么聊天。提问一定要具体。不要问“你们怎么看消息队列的未来”这种可以聊一晚但聊不出结论的开放问题。更好的问法是“我们的场景有跨地域容灾需求Pulsar的异步复制在极端网络故障下有哪些已知边界”。这种问题分享者一听就知道你是有备而来回答也会更有针对性。找维护者和核心贡献者聊天时也建议先展示自己的实践。比如你可以说“我最近在跑Pulsar单机版遇到一个连接池释放的问题”这样对方能快速进入你的上下文而不是要从零开始问你是什么人、遇到了什么。这种交流方式本质上是在节省双方的时间。6.3 会后沉淀把一天的热闹变成长期生产力大会结束之后的前两天是信息记忆的黄金期。我的习惯是当天晚上就把笔记整理成一份结构化的文档把每个Session的核心观点、自己当时的心得和后续要查的资料分开列好。隔一周再回头看往往会发现很多当时觉得“震撼”的内容已经过时而真正留下来的是几个自己最关心的技术点。如果Workshop里有动过手的内容一定要在本地重新跑一遍不要“看完就算”。很多时候现场有讲师引导、有同伴帮助你觉得一切简单但回到自己电脑前往往会有各种意想不到的环境问题。把Demo跑熟了知识才是你的。最后可以把这次大会的内容带回团队做一次十五分钟的mini分享这样不仅强化自己的理解也为团队后续技术选型做了一点铺垫。开源技术大会的入口是那一天的会议但出口其实是一个长期的社区和项目。真正有收获的人不会在散场之后就停下他们会把会上听到的问题带回工作中验证会在社区里继续讨论甚至可能从用户变成贡献者。说实话这一天参加下来我最深的体会是消息队列这个领域正在被重新定义。过去的MQ更像是一个“传输管道”用完即走现在的Pulsar这种新一代消息平台已经在试图成为整个系统架构中的数据底座——你可以在上面跑核心业务消息、做流式计算、做审计回溯、做跨地域容灾甚至把它当一个小型数据库来用它的事件存储能力。最打动我的不是某个单独的功能点而是这种“统一”的架构哲学一套系统能解决的问题越多团队需要维护的中间件工具链就越短。如果你也在做消息队列选型或者正在被Kafka的Topic膨胀、存储压力和多团队共享问题困扰我建议你先找一台机器把Pulsar单机版跑起来亲手体验一下“一条命令建租户、无限保留消息、分层存储”的感受再回来看这些分享内容可能你会得出和我类似的判断。那一天高潮迭起的分享也许可以成为你技术架构上做出一次重要决策的起点。