Pulsar 运维与流存储架构

• ledger/ensemble 概念
• 写入确认（quorum）与多数派
• bookie 扩缩容

BookKeeper 以 ledger（日志）为存储单位，数据写入时按 ensemble（一组 bookie）分布，每个 segment 写入到 ensemble 的多个 bookie。写入确认（quorum）指写操作需一定数量的 bookie（quorum，如 write quorum=2）确认成功才返回，reads 同样需多数确认，保证数据可用性。bookie 扩缩容：新增 bookie 后通过 rebalance 或写入新 ledger 分布到新 bookie，减少则需迁移数据（关闭后 ledger 由剩余 bookie 重建）。自动恢复：当一个 bookie 中的某 ledger 片段缺失时，BookKeeper 的 auditor 会检测并触发修复，从其他副本恢复缺失的片段，将 ledger 重新复制到可用 bookie。运维上需监控 bookie 健康、ledger 修复与磁盘。

BookKeeper 是 Pulsar 的存储层，基于"多副本 + 多数派确认"保证数据安全。ensemble 决定数据分布，quorum 决定写入确认的副本数。扩缩容与自动恢复是容灾的关键，auditor 机制保障数据自愈。

• Broker 与 BookKeeper 分离
• 计算与存储分离的收益
• 运维影响

Pulsar 采用分层架构：Broker 负责计算（协议处理、路由、消费管理），BookKeeper 负责存储（ledger 持久化）。收益：计算与存储可以独立扩容，Broker 是无状态的（可水平扩展），BookKeeper 提供数据持久化与多副本；Broker 故障不影响数据（数据在 BookKeeper），存储扩容不影响计算。运维影响：需要分别运维 Broker 与 BookKeeper 两套集群，监控两者的健康与容量；Broker 扩容只需加 Broker 节点，存储扩容需加 bookie；故障隔离更好，Broker 宕机可快速替换，BookKeeper 故障有自动恢复。此外，Broker 无状态利于弹性伸缩与滚动升级。

分层架构是 Pulsar 与 Kafka 的重要区别。计算与存储分离让"Broker 可无状态弹性伸缩 + BookKeeper 提供可靠存储"，运维上更灵活但需管理两套组件。Broker 无状态是故障恢复快的关键。

• ack 机制与累计 ack
• persistent/non-persistent 持久化级别
• 重试机制

Pulsar 的 ack 机制：消费者确认（ack）消息后，Broker 更新游标（cursor）并会触发累计 ack，即确认到某位置时，之前的所有消息一并视为已确认（按消息 ID 顺序），减少重复消费。持久化级别：persistent topic 的数据写入 BookKeeper 并多副本持久化，可靠性高；non-persistent topic 只存内存，Broker 重启即丢失，可靠性低但性能高。重试与死信：消费失败可重试（设置重试次数与退避），多次失败进入死信队列（DLQ）。运维上需根据业务选择持久化级别，配置重试与死信策略，监控 ack 与 backlog。

累计 ack 是 Pulsar 的优化，减少确认开销。持久化级别决定可靠性与性能的权衡。重试与死信是"至少一次"语义下的兜底。运维需结合业务可靠性要求选择 persistent/non-persistent。

• Pulsar Functions 概念
• 资源管理
• 失败重试

Pulsar Functions 是轻量级处理模型，可在流数据上执行无状态/有状态计算。资源管理：Functions 运行在 Function Worker 中，可配置实例数（parallelism）、CPU/内存配额，通过 Function 的 resources 配置，或部署为独立进程/容器。失败重试：Functions 失败时消息会重试（配置最大重试次数），重试耗尽进入死信，支持重试退避。集群运维：Function Worker 可独立部署或与 Broker 共置，需监控 Function 的状态、吞吐、失败率与资源使用，管理 Function 的生命周期（增加/删除/更新）。运维上需合理分配 Function 资源，避免与 Broker 争抢资源。

Functions 让流处理在 Pulsar 内闭环。资源管理要控制实例数与配额，失败重试与死信是可靠性兜底。运维需监控 Function 健康与资源，合理部署 Function Worker 避免相互影响。

• Pulsar 元数据存储
• ZooKeeper/etcd 的角色
• 备份

Pulsar 使用 ZooKeeper（非 K8s 部署）或 etcd（K8s 部署）存储集群元数据，包括租户、namespace、topic 的元数据、配置、broker 注册信息等。这些元数据是集群运行的基础，需高可用部署（ZooKeeper 通常 3-5 节点形成 quorum）。备份：对 ZooKeeper/etcd 的数据目录进行定期快照备份，或使用其内置快照机制，备份需在 quorum 一致状态下进行。恢复：当 ZooKeeper/etcd 数据损坏或丢失时，利用备份恢复元数据；恢复要保证一致性，避免部分恢复导致数据不一致。运维上需监控 ZooKeeper/etcd 的健康、延迟与磁盘，重要元数据变更定期备份。

元数据存储是 Pulsar 的"大脑"，丢失会破坏集群配置。备份与恢复是保障。ZooKeeper/etcd 的 quorum 决定可用性，运维需高可用部署并定期备份，恢复时验证一致性。

• 认证机制（TLS/OAuth2）
• 授权（namespace 策略）
• 传输加密

认证：Pulsar 支持 TLS 客户端认证、JWT、OAuth2 等认证方式，客户端通过认证建立可信连接。授权：基于 namespace 的策略，为不同的 role（角色）配置对 namespace 内 topic 的读写权限，实现租户级授权。加密：通过 TLS 加密传输，支持 broker 与客户端之间的 TLS，以及 topic 级端到端加密（应用层加密）。审计：记录认证与授权事件、管理操作日志，用于安全审计。运维上需配置认证与授权策略、启用 TLS、建立审计日志，定期轮换密钥与证书。

Pulsar 安全是"认证 + 授权 + 加密 + 审计"。namespace 是租户隔离与授权的基本单元，role 策略控制访问。TLS 保障传输安全，端到端加密保障数据机密性。审计用于追溯。

• bookie 磁盘/内存/网络规划
• journal 与 ledger 存储分离
• IO 隔离

bookie 是 Pulsar 的存储节点，需合理规划磁盘（容量与 IO）、内存与网络。bookie 将日志分为 journal（写日志，顺序写，用于快速写入与恢复）与 ledger（数据文件，顺序写）。为提升性能，journal 与 ledger 应使用不同的磁盘（journal 用高速 SSD，ledger 用容量盘），实现 IO 隔离，避免写日志与写数据互相干扰。容量规划：根据消息量、副本数、保留策略估算磁盘，预留缓冲；内存用于缓存与索引，网络需支撑写入带宽。运维上需监控 journal 与 ledger 的 IO、磁盘空间与网络。

bookie 的性能核心是"顺序写 + IO 隔离"。journal 与 ledger 分离部署是关键，journal 用 SSD 保证低延迟，ledger 用容量盘。容量规划要结合副本与保留，留足余量。IO 隔离避免写放大与相互干扰。

• Broker 与 Bookie 独立扩容
• 负载均衡（unload）
• 流量迁移

Pulsar 中 Broker 与 Bookie 可独立扩容：Broker 无状态，新增 Broker 加入集群即可承担更多连接与流量；Bookie 存储扩容需新增 bookie 并迁移 ledger 数据。负载均衡（unload）：Broker 通过负载均衡器将 topic 的 ownership 从过载 Broker 卸载（unload）到其他 Broker，实现负载均衡；可通过 pulsar-admin brokers unload 手动触发。流量迁移：新 bookie 加入后，通过 rebalance 或让新写入的 ledger 落到新 bookie，逐步迁移数据。扩容时需监控负载均衡状态与流量分布，避免过度迁移。

分层架构让 Broker 与 Bookie 扩容独立。Broker 扩容简单（加节点），Bookie 扩容涉及数据迁移。unload 是 Broker 侧负载均衡手段，rebalance 是存储侧。扩容要渐进、监控对账。

• Broker/Bookie 故障
• 写放大
• ledger 修复

Broker 故障：Broker 无状态，故障后其上的 topic 由其他 Broker 接管（ownership 转移），客户端需重连；需检查 Broker 日志、资源与负载。Bookie 故障：数据多副本，故障 bookie 上的 ledger 由剩余副本恢复，需监控 ledger 修复与副本数。写放大：Bookie 的写入因副本与 journal/ledger 双写产生放大，需监控 IO 与吞吐，优化副本数与存储配置。ledger 修复：auditor 检测缺失片段并触发修复，通过 recover 工具手动修复。客户端重连风暴：Broker 故障或网络抖动导致大量客户端同时重连，冲击 Broker，需平滑重连（退避、随机抖动）、限制连接数。运维上需监控故障转移与重连，避免风暴。

排障要区分故障类型。Broker 故障靠 ownership 转移，Bookie 故障靠副本恢复，写放大是存储层问题，ledger 修复是自愈机制。重连风暴是故障转移的次生问题，需平滑重连策略。

• backlog 概念与监控
• 消息 TTL/保留策略
• 积压告警

backlog 是消费者未消费的消息积压，通过 topic 的 backlog 统计（消息数、字节数）监控。消息 TTL 与保留策略：TTL 设置消息在未消费时的过期时间，过期后消息可被丢弃；保留策略（retention）设置已确认消息的保留时间/大小（用于回溯消费）。积压告警：对 backlog 大小设置阈值告警，区分消费故障与正常积压。积压清理：清理已消费但保留的消息依赖 retention，清理未消费积压需提升消费能力或手动跳过（skip）/清除（clear）backlog。运维上需合理配置 TTL/retention，监控 backlog 并设置告警。

backlog 反映消费健康度。TTL 控制未消费消息的寿命，retention 控制已消费消息的保留。积压治理需区分"消费故障"（修复消费）与"正常积压"（扩容消费），清理操作需谨慎。

• exclusive 独占订阅
• shared 共享订阅
• failover 主备订阅

Pulsar 订阅模式：exclusive（独占）：同一时间只有一个消费者，消息只能由该消费者消费，适合强顺序场景；shared（共享）：多个消费者共享消息，消息被分发到各消费者，适合高吞吐、无强顺序场景；failover（主备）：一个主消费者消费，其余为备，主故障时备接管，适合需顺序又需容灾的场景；key_shared（键共享）：按消息 key 路由，同一 key 的消息由同一消费者消费，兼顾并行与 key 内顺序，适合按 key 分片且需 key 内顺序的场景。运维上需根据业务对顺序、并行的要求选择订阅模式。

订阅模式决定消费语义。exclusive 强顺序但无并行，shared 并行但无顺序，failover 主备兼顾顺序与容灾，key_shared 按 key 并行 + key 内顺序。选择取决于业务需求。

• geo-replication 拓扑
• 复制配置
• 复制延迟监控

Pulsar 的 geo-replication 支持跨集群复制，通过配置 namespace 的 replication 集群列表，将 topic 的消息异步复制到多个集群。拓扑可以是双活（active-active，多个集群都接受写入，双向复制）或主备。复制依赖内置的复制处理器，在目标集群创建 replicator 消费者。复制延迟监控：通过 replicator 的 backlog 与复制延迟指标监控，理想接近 0。冲突处理边界：双活时同一消息可能被多地写入，Pulsar 通过消息 ID 与复制去重避免重复，但业务级的冲突（如同一 key 的并发更新）需业务自行处理，Pulsar 不提供业务冲突解决，只保证复制不重复。运维上需配置复制拓扑、监控复制延迟与 backlog。

geo-replication 是异步复制，有延迟与最终一致性。双活需业务处理冲突。Pulsar 保证复制层面不重复（去重），业务冲突需业务层解决。监控复制延迟与 backlog 是运维关键。

• batching 批量大小/时间窗
• 压缩配置
• 发送超时

Pulsar 生产端 batching 允许将多条消息合并为一个批次发送，提升吞吐、降低网络往返。配置项：batchingMaxMessages（批量大小上限）、batchingMaxPublishDelay（时间窗，等待多久凑满一批）、batchingMaxBytes（批量字节上限）。批处理能提升吞吐，但会引入延迟（等待凑批的时间），对端到端延迟有直接影响：批量越大、时间窗越长，吞吐越高但延迟越大。压缩通过 compressionType 配置（如 LZ4/ZSTD），减少网络与存储，但占用 CPU。发送超时（sendTimeout）控制发送失败的重试超时。运维上需根据吞吐与延迟要求权衡批量参数。

batching 是"吞吐 vs 延迟"的权衡。时间窗决定延迟上界，批量大小决定吞吐。压缩降低带宽但耗 CPU。需结合业务对延迟的敏感度配置，实时性要求高的场景应减小 batch 或时间窗。

• retention 与 backlog 配额
• 消息 TTL
• 限流（rate limit）

命名空间策略可在 namespace 级别配置多项治理参数：retention（保留策略，控制已确认消息保留时长/大小）、backlog 配额（backlogQuota，限制未消费积压的最大大小/条数，超限可触发丢弃或拒绝写入）、消息 TTL（未消费消息过期时间）、限流（rate limit，限制生产/消费速率）。组合治理积压：用 backlog 配额设置积压上限，超限触发策略；用 TTL 清理无人消费的过期消息；用 retention 控制已确认消息保留；用 rate limit 防止突发流量。运维上需按业务设置这些策略，监控积压并配合清理。

命名空间策略是 Pulsar 多租户治理的核心。backlog 配额是积压硬上限，TTL 清理过期，retention 控制保留，rate limit 限流。组合使用实现"积压防护 + 数据治理 + 资源保护"。

• 分区 Topic 概念
• key 路由/轮询/自定义路由
• 分区数规划

Pulsar 分区 Topic 将一个 topic 拆分为多个分区（partition），每个分区独立存储与消费，提升并行度。路由策略：key 路由（按消息 key 哈希到固定分区，同一 key 落到同一分区，保证 key 内顺序）、轮询（round-robin 平均分发，无顺序保证）、自定义路由（业务自定义选择分区）。分区数规划：根据吞吐与并行度需求设定，分区数越多并行度越高但元数据与 rebalance 开销增大。扩容影响：增加分区数后，key 路由的哈希结果会变化，导致同一 key 可能落到不同分区，破坏 key 内顺序，需评估；扩容时会影响消费分配。运维上需规划分区数并评估扩容对顺序的影响。

分区数是并行度与顺序的权衡。key 路由保证 key 内顺序但有分区数绑定，扩容分区数会改变哈希结果破坏顺序。轮询用于无顺序场景。规划分区数需考虑未来扩展与顺序需求。

• Pulsar Transactions 用途
• 跨 topic 原子写入
• 事务协调器运维

Pulsar Transactions 提供跨 topic 的原子写入（及流处理结果与输入的原子性），支持"要么全部提交要么全部回滚"，用于需要端到端一致性的场景（如流式作业把结果与消费进度原子提交）。事务通过事务协调器（Transaction Coordinator）管理，协调器基于 BookKeeper 存储事务状态，处理事务的 begin/commit/abort。事务协调器运维：需部署与监控协调器，协调器故障时事务恢复较复杂，需监控事务量、提交/回滚率与协调器健康。性能代价：事务引入额外协调开销（提交时需协调多副本），会降低吞吐与增加延迟，不适合所有消息。运维上需评估是否真需要事务，并监控事务性能。

事务解决"跨 topic 原子性"，是端到端一致性的关键。事务协调器是核心组件，需高可用与监控。性能代价使事务不适用于高吞吐场景，需权衡。运维中协调器健康与事务积压是重点。

• Kop 概念
• 协议兼容实现
• 运维考量

Kop（Kafka on Pulsar）是一个协议处理器，让 Pulsar 同时支持 Kafka 协议，使 Kafka 客户端无需修改即可连接 Pulsar。实现上，Kop 作为 Pulsar 的 protocol handler，把 Kafka 协议的请求（produce/fetch/admin）转换为 Pulsar 的存储与消费模型。运维考量：Broker 需启用 Kop（配置 protocol handler），Kafka 客户端版本与 Kop 的兼容矩阵需验证，Kafka 的 topic 会映射到 Pulsar 的 topic，offset 通过 Pulsar 的 cursor 管理。迁移场景：存量 Kafka 客户端平滑迁移到 Pulsar，无需改客户端代码，逐步迁移以降低风险。运维上需监控 Kop 的吞吐、兼容性 bug 与 Kafka 客户端连接。

Kop 让 Kafka 生态无缝接入 Pulsar，是迁移的桥梁。协议兼容有边界（Kafka 特性与 Pulsar 语义差异），需验证。运维需关注兼容性矩阵与性能，迁移需灰度。

• Broker/Bookie 指标
• topic stats
• 背压机制

Pulsar 可观测性：Broker 指标（吞吐、连接数、消息速率、topic 负载）、Bookie 指标（磁盘 IO、写入延迟、ledger 状态），通过 Prometheus 采集（Pulsar 暴露 /metrics）。topic stats 提供单个 topic 的详细统计（生产/消费速率、backlog、batching、订阅游标），用于定位问题。背压机制：当消费者慢或存储满时，Broker 通过背压控制生产速率，避免无限积压。限流配置：通过 namespace 的 rate limit、producer/consumer 配额限制速率，防止突发流量。运维上需建立 Prometheus/Grafana 监控大盘，监控 topic stats 与背压状态。

可观测性是运维的"眼睛"。Broker/Bookie 指标看资源与健康，topic stats 看单 topic 行为，背压与限流是治理机制。监控要覆盖集群、Broker、topic 三级，设置告警。

• 集群联邦
• replication 拓扑
• 故障切换

Pulsar 多集群通过 geo-replication 实现集群联邦，多个集群通过 replication 拓扑（复制关系）互联，形成主备或双活。故障切换：当主集群故障时，可将流量切换到备集群（通过修改客户端连接或配置），备份集群凭借复制数据提供服务。数据一致性验证：通过对比各集群的 topic 消息数、offset、消息内容与复制状态，验证复制的一致性；对账需处理复制延迟与最终一致性。运维上需设计合理的 replication 拓扑（如环形、星型），定期验证故障切换与数据一致性，演练容灾。

多集群容灾依赖 geo-replication。拓扑决定复制关系，故障切换决定 RTO，一致性验证保障数据正确。容灾需演练，验证切换后数据完整、无脑裂。

• 2.x 到 3.x 升级路径
• Broker 协议兼容
• 客户端版本管理

Pulsar 2.x 到 3.x 升级：需遵循官方升级路径，先升级元数据、再升级 Broker、最后升级 BookKeeper 等组件，滚动升级保持集群可用；3.x 移除了一些旧特性，需确认兼容。Broker 协议兼容：Broker 升级后需保持与旧客户端协议的兼容（Pulsar 通常向后兼容），但要验证新客户端与旧 Broker 的兼容。客户端版本管理：统一客户端版本，建立兼容矩阵，避免客户端过老导致功能缺失或协议不兼容。升级风险：组件升级顺序错误、元数据不兼容、客户端不兼容可能导致故障。升级前备份、灰度、回退预案。

升级是高风险操作。Pulsar 组件多（Broker、BookKeeper、ZooKeeper），升级顺序与兼容性需严格控制。协议兼容决定客户端是否受影响，版本矩阵管理保障升级平滑。升级前演练与回退是必须。