最近有个帖子挺火的：某公司招“云原生消息平台内核开发实习生（Pulsar 方向）”。不少同学私信问我这个岗位到底值不值得投、面试会问什么、开始准备要从哪里下手。我聊过不少做消息中间件的人，也带过实习生，借着这个标题，把 Pulsar 内核开发这条线完整拆一遍。
先说结论：这个岗位是消息队列领域里少见的“硬核技术岗”，既踩在云原生风口上，又涉及存储、网络、分布式一致性这些底层能力。对实习生来说，它不是刷业务 CRUD 的岗位，而是真正能碰消息内核源码、调存储引擎、理解分布式系统骨架的岗位。下面从岗位价值、核心原理、实操方法到常见问题，一条条讲清楚。
1. 先把岗位标题拆透：每个关键词背后都是一整块知识体系
拿到这个标题，很多人只看到“实习生”三个字，其实前面每一个定语都是硬性技术指标。把这几个关键词拆开，基本就知道这家公司想要什么样的人，面试官会沿着哪些方向发问。
1.1 “Pulsar”到底是个什么级别的项目
Pulsar 是 Apache 软件基金会旗下的顶级开源项目，属于分布式消息流平台，支持发布订阅、消息队列、事件流处理三种场景。它的设计目标和 Kafka 类似，但底层实现差异非常大。
Pulsar 最核心的卖点是存储与计算分离架构。Broker 节点负责消息路由、权限校验、协议接入，而消息数据真正落在 Apache BookKeeper 里。这意味着 Broker 是无状态的，可以水平扩展，也可以缩容；BookKeeper 负责数据的持久化、复制和恢复。而 Kafka 的 Broker 同时承担存储和计算，扩节点往往需要把数据重新分布，操作重得多。
对实习生来说，“Pulsar 方向”意味着你进入团队后不是做上层业务 API，而是直接面对消息存储、复制协议、Backlog 管理、读路径优化这些硬骨头。简历上写“熟悉 Kafka”的人很多，真正读过 Pulsar 源码的人很少，这个差异化本身就是竞争力。
1.2 “云原生”不是营销词，而是架构约束
云原生三个字体现在 Pulsar 设计里是非常具体的：
- 无状态 Broker：可以随便扩缩容，可以跑在 Kubernetes 上，配合 HPA（Horizontal Pod Autoscaler）实现弹性伸缩。
- 存算分离：存储层独立扩展，Broker 挂了可以快速拉起，不需要搬数据。
- 多租户原生支持：Pulsar 在命名空间层面做隔离，一个集群服务多个业务团队，配额、权限、隔离策略都内置。
- 分层存储：消息可以自动从 BookKeeper 卸载到 S3、GCS 这类对象存储，控制存储成本。
所以面试官问“你怎么理解云原生消息平台”时，不是让你背概念，而是让你讲清楚：Broker 为什么可以做到无状态、数据持久化怎么解决、扩缩容时 Topic 的分布怎么调整、冷数据怎么降本。这些问题全都指向 Pulsar 的存储计算分离架构。
1.3 “内核开发”指的是哪个范围
Pulsar 生态可以分为三层：
- 接入层：包括各种客户端、协议适配（Kafka 协议兼容、AMQP 等）。
- 核心层：Broker 的消息路由、订阅模型、权限、Backlog、流量控制、函数计算。
- 存储层：Apache BookKeeper，包括 Ledger 管理、Segment 存储、复制、故障恢复。
“内核开发”大概率落在核心层和存储层，不会让你整天写客户端。
如果你做的是 Broker 侧，可能会接触到：Topic 的分片与负载均衡、Cursor 管理、消息 TTL 与 Retention 策略、延迟消息投递、事务消息等。如果你做的是 BookKeeper 侧，就会接触到：Write-ahead Log 的刷盘策略、Journal 和 Ledger 的关系、Quorum 写入机制、恢复时的数据校验等。
这两块要求都不一样。Broker 侧要求你有扎实的并发编程基础，能理解异步模型；BookKeeper 侧则对存储和文件系统操作要求更高。不管做哪边，Netty 和异步编程都是绕不开的基础。
1.4 “实习生”岗位为什么反而更难
很多人觉得实习生岗位要求肯定低一些，实际上这类内核开发岗的实习生筛选往往更严格。原因很简单：内核开发涉及核心模块，代码合并需要谨慎评估；实习生如果只做边角料，对团队没有产出价值，对实习生也没有成长价值。
实际面试中，算法题、Java 并发、网络编程、分布式理论都可能会问到，还会让你现场讲一段读过的源码。我认识的一个同学面试时被问到“Kafka 和 Pulsar 从写入路径上有什么本质区别”，光是这个问题就能筛掉一半没深挖过源码的人。
所以别抱着“我是实习生可以慢慢学”的心态，投这个岗位之前就应该具备独立阅读源码的能力。不要指望别人手把手教你，内核开发团队默认你能自己啃文档、跑实验、动手验证。遇到问题可以先查官方的 PIP（Pulsar Improvement Proposal）和社区邮件列表，找到答案后再向导师确认。
2. 核心架构拆解：为什么 Pulsar 值得作为内核学习的样本
如果只是找工作，背面试题就够了。但做技术的人应该搞清楚底层为什么这么设计。Pulsar 的架构设计非常完整，作为学习样本价值极高。下面把这套架构的核心逻辑拆开讲。
2.1 存储与计算分离：从职责划分看设计逻辑
Pulsar 集群中有一个 Broker 层和一个 BookKeeper 层。
Broker 负责一切和“计算”相关的事情：和客户端建立连接、处理 Produce/Consume 请求、维护订阅 Cursor、执行消息去重、管理 TTL 和 Retention。它不保存消息数据，只是转发消息到 BookKeeper 并更新游标位置。Broker 自己的状态只存在于 ZooKeeper 或元数据服务里，比如 Topic 与 Broker 的映射关系、命名空间的策略配置。
BookKeeper 则是一套分布式日志存储系统，对外提供 Append-Only 日志的读写能力。核心抽象是 Ledger，一个 Ledger 是一段有序日志，由若干 Entry 组成。每个 Entry 就是一个消息批次。BookKeeper 内部把 Ledger 切成 Segment，分布在多个 Bookie 节点上，并且每个 Segment 默认有 2 个副本。写入时客户端（这里是 Broker）向 Bookie 发起写请求，Bookie 先写 Journal（预写日志），再写内存缓存，异步刷盘到 Entry Log。
这套设计解决了一个核心问题：状态与数据分离。Kafka 里分区 Leader 挂了需要重新选主并做数据同步，期间该分区不可用。Pulsar 里 Broker 挂了只影响连接，消息数据还在 BookKeeper 里，新 Broker 拉起来后直接从 BookKeeper 读取 Cursor 和 Ledger 信息，继续服务。这种弹性是云原生环境特别看重的。
2.2 主题与分片的映射：订阅模型的关键支撑
Pulsar 的一个 Topic 可以横跨多个 Broker，靠的是分片机制。每个 Topic 会分成多个分片，分片是一个 Ledger，可以分布在不同 Broker 上。所以单个 Topic 的吞吐量不再受限于单台机器。
分片自动滚动：当当前 Ledger 达到一定大小或时间阈值时，Broker 会关闭旧 Ledger，创建新 Ledger 继续写入。这带来几个好处：
- 单个 Ledger 体积可控，恢复速度快。
- BookKeeper 可以更均匀地分布数据。
- 消息从旧 Ledger 被消费完成后，可以安全删除，不需要扫大文件。
订阅模型是 Pulsar 区别于 Kafka 的另一大亮点。Kafka 的消费组本质上是分区级别的独占消费；Pulsar 的 Subscription 有四种类型：Exclusive（排他）、Shared（共享）、Failover（故障转移）、Key_Shared（按键共享）。这四种模式让同一个 Topic 可以支持多种消息语义，比如一边做广播（每个订阅拿全量消息），一边做工作队列（Shared 模式下消息被不同消费者瓜分）。
从内核视角看，订阅模型意味着 Cursor 的管理方式不同。Exclusive 模式下每个订阅只有一个 Cursor，Shared 模式下每个消费者都有自己的 Cursor，Broker 需要维护的元数据量会成倍增加。这是内核开发中最容易出问题的地方：并发消费时 Cursor 推进的一致性。
2.3 多级存储：消息不是无限堆在内存里的
Pulsar 的存储分三个层次：
- 内存：Bookie 的写缓存和读缓存。
- 磁盘：Bookie 的 Entry Log 和 Journal。
- 对象存储：通过分层存储功能，把老消息卸载到 S3 等对象存储。
三层存储的关键在于文件格式设计。BookKeeper 的 Entry Log 文件是顺序追加的，多个 Ledger 的数据会交错写在同一个 Entry Log 文件里，通过索引来定位某个 Entry 的物理位置。这种设计让写入路径变成纯顺序写，磁头和 SSD 都友好得多。
分层存储的思路是：当 Ledger 的消息已经被消费并且超过 Retention 时间后，可以把整段数据上传到对象存储，本地只保留索引。读老消息时，从对象存储拉回来，不占用本地磁盘空间。这个机制在 Kafka 里没有严格对应物，它让 Pulsar 用户可以在一个集群里同时处理实时数据和历史数据，而不需要两套系统。
读到这里你应该明白了：Pulsar 内核开发 / 存储层开发，本质上就是一套分布式日志存储系统加一层高效的 Broker 调度器。学好这套架构，不光是会用一个消息中间件，而是把分布式存储的核心模型吃透了。
3. 实操过程：在没有生产环境的情况下，如何本地吃透 Pulsar 内核
下面这部分是实打实的操作内容。无论你是准备面试还是真心想学，都需要自己动手跑一遍。看十篇源码分析不如实际踩一遍坑。
3.1 单机环境搭建：五分钟跑起来 Pulsar
最简单的方式是下载官方二进制包，不依赖容器。我之前用 2.11.x 版本做过完整测试，步骤如下：
安装 Pulsar 单机版并启动：
# 下载并解压，这里用 2.11.0 版本做示例 wget https://archive.apache.org/dist/pulsar/pulsar-2.11.0/apache-pulsar-2.11.0-bin.tar.gz tar -xzf apache-pulsar-2.11.0-bin.tar.gz cd apache-pulsar-2.11.0 # 启动单机模式（会同时启动 Broker 和 BookKeeper） bin/pulsar standalone单机模式下，Pulsar 会启动一个 ZooKeeper、一个 Bookie、一个 Broker，这对于学习足够。
启动后，打开另一个终端验证服务是否正常：
# 查看集群状态 bin/pulsar-admin clusters list # 创建一个测试租户和命名空间 bin/pulsar-admin tenants create test-tenant bin/pulsar-admin namespaces create test-tenant/test-namespace然后使用自带的客户端工具生产消息：
# 第一个终端：消费消息 bin/pulsar-client consume test-tenant/test-namespace/topic1 \ --subscription-name test-subscription \ --num-messages 0 # 第二个终端：生产消息 bin/pulsar-client produce test-tenant/test-namespace/topic1 \ --messages "hello-pulsar,hello-kernel"如果你能看到消费端打印出消息内容，说明整个链路已经跑通。这一步看起来简单，但它是所有后续实验的基础。
单机模式适合验证业务逻辑，但 BookKeeper 的单节点行为和分布式场景差别很大。比如单机模式下数据复制是 1 副本，生产环境默认是 2 副本或 3 副本，Quorum 写满才返回成功。这些差异后面做实验时要注意。
3.2 观察消息写入路径：从 Produce 请求到 BookKeeper Entry
跑通了基本链路，接下来要观察一条消息从客户端发出后，在 Pulsar 内部经历了什么。这一步是理解内核的开始。
先打开 Broker 的日志观察写入情况：
# 实时查看 Broker 日志 tail -f logs/pulsar-broker.log然后生产一批消息，并观察日志中出现的关键字：
bin/pulsar-client produce test-tenant/test-namespace/topic1 \ --messages "msg-1","msg-2","msg-3" \ --batch-size 5在日志里，重点观察几个节点：
- 客户端和 Broker 建立连接后，Broker 会选择或创建一个 Ledger。
- Broker 收到 Producer 的 Send 请求后，会校验 Topic 是否存在、权限是否足够，然后通过 ManagedLedger 写入 BookKeeper。
- BookKeeper 客户端（嵌入在 Broker 进程中）将消息封装成 Entry，向 Bookie 发起写请求。
如果想看到更深层次的数据流，可以打开 Bookie 的日志和统计信息：
tail -f logs/bookkeeper.log正常你会看到 Bookie 接收到 Append 请求，并且 Journal 目录下出现日志文件（journal 和 entries 目录）。
我在本地上跑这个实验时踩过一个坑：单机模式下enableTopicPersistence=true时，消息不会真正刷盘到 Entry Log，而是只写 Journal，靠定时任务把 Journal 里的数据合并进 Entry Log。所以观察时别以为没有 Entry Log 文件就说明消息没写入，要理解 Journal 和 Entry Log 是两层职责。
为了更直观地理解数据分布，可以自己写一个小工具来读取 Ledger 的元数据：
# 列出当前 BookKeeper 上的所有 Ledger bin/pulsar-admin bookies list这个命令会展示集群中所有 Bookie 节点的信息。如果你之后想深入 BookKeeper，还可以用bin/bookkeeper shell ledgermetadata查看具体某个 Ledger 的元数据，包括 Entry 数量、大小、副本位置等。
3.3 消费端链路观察：Subscription 与 Cursor 的关系
消息写入只是前半程，消费链路同样重要。
Pulsar 消费的核心概念是 Cursor。每个 Subscription 会有一个 Cursor，记录了该订阅消费到了哪个位置。Pulsar 的消费确认有两种模式：单条确认（Individual Ack）和累积确认（Cumulative Ack）。Kafka 只有累积确认，Pulsar 的 Shared 订阅模式下必须用单条确认，因为不同消费者处理速度不同。
本地实验可以这样做：
开两个消费者，用同一个 Subscription 名，分别连接同一个 Topic：
# 终端一 bin/pulsar-client consume test-tenant/test-namespace/topic1 \ --subscription-name shared-subscription \ --subscription-type Shared # 终端二 bin/pulsar-client consume test-tenant/test-namespace/topic1 \ --subscription-name shared-subscription \ --subscription-type Shared然后生产 20 条消息，观察两个终端各自消费到的消息数量。如果假设这个 Subscription 只会被一个消费者独占，那你就误解了 Shared 模式的工作机制。Shared 模式下，消息会被尽可能均匀地分发给订阅下的消费者，并且消息确认后才会继续推送下一条。
用命令查看订阅的消费进度：
bin/pulsar-admin topics stats test-tenant/test-namespace/topic1输出里会包含订阅的名称、消费位置、Backlog 大小、消费者列表。
实际调试时，我发现一个常见问题：如果某个消费者挂了但没正确关闭连接，消息会被标记为“已发送但未确认”（unacked），一段时间后会被重新投递。这个“重新投递”逻辑在 Shared 订阅里尤其重要，因为它可能导致消息乱序。理解这个机制后，你在设计自己的应用时就要考虑是否接受乱序。这是内核层面做出的取舍，而不是上层应用能做特殊处理的。
3.4 用指标和源码定位一次消息积压的根源
理论说再多，不如实际排查一次问题。下面是一个模拟场景：Topic 有大量消息积压，消费速度上不去。
一台本地机器上，先生产 50 万条消息：
bin/pulsar-client produce test-tenant/test-namespace/backlog-topic \ --num-produce 500000 \ --max-outstanding 1000然后启动一个消费者订阅该 Topic：
bin/pulsar-client consume test-tenant/test-namespace/backlog-topic \ --subscription-name backlog-subscription \ --subscription-type Shared观察消费速度，通常不会太慢。这时人为制造一个慢消费者，比如在本地写一个消费消息后 sleep 500ms 的客户端，会发现 Backlog 不断增长，消费速率远低于生产速率。
这时打开 Broker 的指标端口（单机版默认是 http://localhost:8080/metrics），搜索pulsar_broker_subscription_backlog和pulsar_broker_subscription_consumers_available两个关键指标。前者显示积压消息数量，后者显示可用的消费者数量。如果可用消费者数量为 0，说明所有消费者都在处理中或连接断开，积压是必然的。
从内核视角看，任何性能问题都可能在三个层面出现：
- 客户端层：消费者的处理逻辑慢、网络超时设置不合理。
- Broker 层：分发线程池不足、订阅的 Cursor 更新频率过高。
- 存储层：Bookie 写入出现瓶颈，或 Journal 刷盘策略限制了整体吞吐。
排查的顺序应该从一层到三层逐步隔离，先确认消费端是不是瓶颈，再确认 Broker 的入站和出站流量是否匹配，最后看 Bookie 的 IO 指标。
实际操作里，我见过很多人一上来就查 GC 日志或者堆内存，但真正的原因常常是消费端没有批量确认，导致 Broker 每处理一条消息就要更新一次 Cursor，把存储层累垮了。所以做内核开发，一定要有全链路视角，不能只盯着自己负责的模块。
4. 常见问题与排查技巧实录
以下是消息平台内核开发岗最常见的问题场景。这些内容是我在实际调试中总结出来的，比文档里的流程更贴近真实情况。
4.1 Leader 迁移过程中出现消息延迟增大
Pulsar 的 Broker 无状态，但 Topic 的服务节点会变化。比如负载均衡把某个 Topic 分配到另一个 Broker 上时，前端可能观察到消息延迟明显增加。
排查思路：
- 确认迁移前后 Broker 的 JVM 堆内存和 GC 情况。迁移时旧 Broker 需要执行 Cursor 快照更新，新 Broker 需要重新打开 Ledger。这个过程会伴随 CPU 和 IO 的瞬时上升，并不一定代表故障。
- 检查 Pulsar 的
pulsar_broker_load_balance_*指标，确认迁移动作收敛时间。 - 如果延迟持续不恢复，检查 Bookie 的 Journal 目录所在磁盘的 IO 队列长度，迁移期间大量 Ledger 重新打开会挤占 Journal 写带宽。
我在实验环境里遇到超过 10 秒的延迟时，一开始以为是网络问题，后来排查发现是 Bookie 的 fsync 策略太频繁。将 Journal 的 gRPC 请求超时参数调大并优化journalSyncData配置后，延迟才降下来。单机环境里因为磁盘响应快，很难复现生产环境的问题，所以做这类实验时最好用磁盘限流工具模拟低速磁盘。
4.2 消费者活跃但 Backlog 一直不降
这是另一个非常经典的场景：消费端显示有消费者在线，也确实在拉消息，但 Backlog 呈锯齿状波动，不持续下降。
常见原因：消费端的确认方式不对。Pulsar Shared 模式必须逐条或批量确认，如果你使用累积确认方式，Broker 会一直等待所有前面消息确认后才推进 Cursor，导致 Backlog 显示异常。我在本地搭过 Demo 复现过这个现象，非常容易踩。
验证手段：查看 Broker 输出的pulsar_broker_subscription_backlog，和消费者实际收到的消息数量对比。如果两者差距很大，很大概率是确认路径有问题，需要打印客户端日志确认AckReceipt是否按时送达。
解决方式：确认客户端 Ack 超时配置是否合理。Pulsar 客户端默认会等待 Broker 返回确认结果，如果设置成了异步且不检查回调，就可能出现消息实际已被消费但 Cursor 不前进的情况。正确做法是让消费者每处理完一批消息，就批量 Ack 一次。
4.3 Bookie 节点磁盘使用不均衡
BookKeeper 节点之间磁盘使用不均匀是分布式存储常见的现象。Pulsar 的写入路径是根据 Ledger 的 DistributionSchedule 把数据段均匀分散开的，但看起来依然会出现个别节点磁盘偏高。
根因：创建 Ledger 时的 Ensemble 和 Write Quorum 配置。默认情况下，Ledger 分布是轮询的，但 Ledger 的大小和存续时间不同，有的 Ledger 生命周期内写入量特别大，有的特别小。磁盘使用率自然会有差异。
对策：不要只看磁盘使用率，要看 Bookie 的 Write IO 速率。如果能接受迁移数据，可以用bin/bookkeeper shell decommissionbookie下线高负载节点，让数据重新分布。如果不能接受迁移，只能通过控制 Topic 分片数量，把写入压力打散到更多 Ledger 上。
我在实际部署中发现，如果把大 Topic 不分片，只放在一个 Ledger 里写入，时间一长整个 Bookie 集群的负载会严重偏向某一个节点。Pulsar 支持 Topic 分片和自动滚动，但很多用户没有正确配置滚动阈值，导致单 Ledger 过大。建议检查自动滚动阈值相关的配置项，避免出现长尾热点。
4.4 “No such ledger” 错误出现在消费路径中
有时候消费者拉消息会碰到No such ledger的异常消息，有的人会怀疑是 Pulsar 的 bug，其实大部分情况是消息生命周期管理导致的。
Pulsar 默认会清理已经消费完的消息，也会按 Retention 策略删除过期消息。如果消费者使用的是最早位置读取，且 Backlog 已经被清理过，就会出现 Ledger 不存在的错误。
排查方式：先确认该 Topic 的 Retention 策略，再确认消费进度是否落后太多。如果消费进度落后于清理阈值之外，唯一的办法是把消费组重置到更早的位置，或者临时调整 Retention 策略再重放数据。
注意：这里的No such ledger错误通常出现在消费者刚接入的瞬间，并不会让集群整体不可用。验证方法就是用pulsar-admin topics stats检查该订阅的 Cursor 位置，再和 Ledger 列表比对。
4.5 网络抖动导致消息重复投递
消息重复在分布式系统里是常态，Pulsar 通过去重机制和消费确认来保证的是“至少一次”而不是“恰好一次”。内核开发实习生很常见的问题就是把重复投递当成 bug，花大量时间在无意义的日志排查上。
正确思路：在应用层做好幂等处理，或者在客户端开启去重。Pulsar 的分层存储和 Ledger 设计已经保证消息不丢失，但网络超时重试时会有重复写入的可能。Broker 侧支持基于 Producer 消息 ID 的去重，但这需要 Producer 在配置中开启相关参数，而不是默认行为。
实际操作中，如果看到消费端偶尔重复几条消息，不用太紧张。首先确认是网络重试还是消费者崩溃后的重新投递，然后根据业务容忍度决定是否需要幂等改造。消息中间件不是银弹，内核开发工程师要清楚哪些语义是系统保证的，哪些是业务侧必须兜底的。
5. 面向实习生的学习路线：从代码阅读到项目实践
最后聊点实际的：如果你看到这个岗位标题，打算准备一两个月再投递，该怎么规划时间。
5.1 按优先级排布知识硬通货
第一优先级：Java 并发和异步编程。Pulsar 的 Broker 和 BookKeeper 都是 Java 写的，大量使用 CompletableFuture、Netty、无锁队列。你至少要知道线程池的拒绝策略、Future 回调的线程模型、原子类与锁的性能差异。
第二优先级：分布式存储基础。BookKeeper 的 Journal 和 Entry Log 是最典型的预写日志实现，Raft 和 Quorum 机制也需要有概念。读过 Raft 论文或者亲手实现过 KV 存储，会有很大帮助。
第三优先级：消息队列语义。重点对比 Kafka 和 Pulsar 的差异，理解为什么 Pulsar 选择存储计算分离，Broker 无状态带来的运维优势，以及 Replication 和 Quorum 在不同场景下的取舍。
第四优先级：网络协议。至少能通过抓包工具看明白 Pulsar 二进制协议的请求格式，能说出生产消息的请求和消费请求的各自特征。
5.2 源码阅读路线图
我建议按下面的顺序读源码，而不是一上来从 Broker 入口开始啃：
先从 Apache BookKeeper 开始，理解 Ledger、Entry、Write Quorum 的关系。这个模块相对独立，不依赖 Pulsar 的其它部分。
然后读 Pulsar 的 ManagedLedger 模块。这个模块负责管理一个 Topic 对应的 Ledger 列表、滚动时机和 Cursor 持久化。理解了 ManagedLedger，就理解了消息存储的骨架。
接着读 Broker 的 MessageRouter 和 ConsumerDispatcher，搞清楚消息从生产者请求到 BookKeeper，再到消费者推拉的全链路。
最后读协议层，理解 Pulsar 二进制协议的消息帧结构。有了全链路视角后，再回头精读你感兴趣的模块。
源码阅读要边读边动手。改一个字段跑一下测试，比盯着代码看两小时有用得多。Pulsar 项目的测试框架比较完善，本地跑集成测试不算难。
5.3 把“读过源码”变成“可展示的项目”
面试时最怕的就是“我读过源码”但说不清楚。读源码一定要输出成果。我建议做三件小事：
- 自己写一份 Pulsar 写入路径的时序图，从客户端 Send 到 Broker 处理，再到 BookKeeper 落盘，每个环节标清楚涉及的核心类名和方法名。不要带代码库外发，自己留存。
- 跑一个压测实验，记录生产速率、消费速率、Backlog 变化趋势，分析瓶颈出现在哪一层，形成排查文档。这个本身就是一次完整的性能问题定位练习。
- 找一个 Pulsar 的原始 issue，尝试复现并提交补丁。不需要太大，哪怕是优化日志输出、补充一个测试用例、修复一个小文档错误，都能证明你有独立的代码贡献能力。
5.4 简历上怎么写才不露怯
简历千万不要写“熟悉 Pulsar”这种空话。可以这样写：
- “独立完成 Pulsar 写入链路源码分析，绘制完整时序图并定位到 BookKeeper 客户端写入超时的根因。”
- “基于 Pulsar 单机环境搭建消息积压实验，对比不同确认机制对 Backlog 的影响，输出测试报告。”
- “参与社区某个 issue 的讨论，理解 Ledger 滚动机制对存储利用率的影响。”
关键词写清楚：Pulsar、BookKeeper、分布式存储、消息确认机制、异步编程。这样面试官一眼就能判断你真有动手能力，而不是只看了几篇博客。
6. 写在最后：内核开发实习生的真实日常
看到这里，你应该对这个岗位有了比较清晰的认知。最后聊聊这类岗位实习生的真实日常是什么样的，算是给还在犹豫的同学打个底。
实习的第一周，大概率是读代码、搭环境、跑 Demo，熟悉仓库结构。第二周到一个月，导师会分给你一个具体的独立小任务，可能是一个模块的代码优化，可能是一个工具的开发，也可能是一个测试用例的补齐。真正的产出期在两个月以后，那时你已经能独立处理问题单，可以参与线上问题排查。
内核开发的节奏和业务开发不一样。业务开发一天能写很多业务逻辑，内核开发可能一周都在改一个并发 bug。改出来的代码要过 Code Review，社区要求高等，一个实现方案可能来回修改很多轮。这种节奏对新人来说会有点磨人，但你会形成很好的代码品味和追求极致习惯。
我在带实习生的过程中发现，最能拉开差距的素质不是基础好坏，而是遇到问题时的处置方式。内核开发会遇到大量“现象看着像 A，根因其实是 B”的情况，习惯于深挖、不满足于表面修复的人，成长速度会快得多。
如果你判断自己动手能力还可以，能静下心来啃代码，这个方向非常值得投入。消息平台是数据架构的中枢，Pulsar 又在存算分离这条路上走得比较靠前，今天花在源码上的每一分钟，之后都会有复利回报。祝顺利。
