共计 3692 个字符，预计需要花费 10 分钟才能阅读完成。
背景
Apache Pulsar 是下一代分布式音讯流平台，采纳计算存储分层架构，具备多租户、高统一、高性能、百万 topic、数据平滑迁徙等诸多劣势。越来越多的企业正在应用 Pulsar 或者尝试将 Pulsar 利用到生产环境中。
腾讯把 Pulsar 作为计费零碎的音讯总线来撑持千亿级在线交易。腾讯计费体量宏大，要解决的外围问题就是必须确保钱货统一。首先，保障每一笔领取交易不呈现错账，做到高统一、高牢靠。其次，保障计费承载的所有业务 7*24 可用，做到高可用、高性能。计费音讯总线必须具备这些能力。
Pulsar 架构解析
在一致性方面，Pulsar 采纳 Quorum 算法，通过 write quorum 和 ack quorum 来保障分布式音讯队列的正本数和强统一写入的应答数(A>W/2)。在性能方面，Pulsar 采纳 Pipeline 形式生产音讯，通过程序写和条带化写入升高磁盘 IO 压力，多种缓存缩小网络申请放慢生产效率。
Pulsar 性能高次要体现在网络模型、通信协议、队列模型、磁盘 IO 和条带化写入。上面我会一一具体解说。
网络模型
Pulsar Broker 是一个典型的 Reactor 模型，次要蕴含一个网络线程池，负责解决网络申请，进行网络的收发以及编解码，接着把申请通过申请队列推送给外围线程池进行解决。首先，Pulsar 采纳多线程形式，充分利用古代零碎的多核优势，把同一工作申请调配给同一个线程解决，尽量避免线程之间切换带来的开销。其次，Pulsar 采纳队列形式实现了网络解决模块及外围解决模块的异步解耦，实现了网络解决和文件 I/O 并行处理，极大地提高了整个零碎的效率。
通信协议
信息（message）采纳二进制编码，格局简略；客户端生成二进制数据间接发送给 Pulsar 后端 broker，broker 端不解码间接发送给 bookie 存储，存储格局也是二进制，所以音讯生产生产过程没有任何编解码操作。音讯的压缩以及批量发送都是在客户端实现，这能进一步晋升 broker 解决音讯的能力。
队列模型
Pulsar 对主题（topic）进行分区（partition），并尽量将不同的分区调配到不同的 Broker，实现程度扩大。Pulsar 反对在线调整分区数量，实践上反对有限吞吐量。尽管 ZooKeeper 的容量和性能会影响 broker 个数和分区数量，但该限度下限十分大，能够认为没有下限。
磁盘 IO
音讯队列属于磁盘 IO 密集型零碎，所以优化磁盘 IO 至关重要。Pulsar 中的磁盘相干操作次要分为操作日志和数据日志两类。操作日志用于数据恢复，采纳齐全程序写的模式，写入胜利即可认为生产胜利，因而 Pulsar 能够反对百万主题，不会因为随机写而导致性能急剧下降。
操作日志也能够是乱序的，这样能够让操作日志写入放弃最佳写入速率，数据日志会进行排序和去重，尽管呈现写放大的状况，然而这种收益是值得的：通过将操作日志和数据日志挂在到不同的磁盘上，将读写 IO 拆散，进一步晋升整个零碎 IO 相干的解决能力。
条带化写入
条带化写入可能利用更多的 bookie 节点来进行 IO 分担；Bookie 设置了写缓存和读缓存。最新的音讯放在写缓存，其余音讯会批量从文件读取退出到读缓存中，晋升读取效率。
从架构来看，Pulsar 在解决音讯的各个流程中没有显著的卡点。操作日志长久化只有一个线程来负责刷盘，可能会造成卡顿。依据磁盘个性，能够设置多块盘，多个目录，晋升磁盘读写性能，这齐全可能满足咱们的需要。
测试
在腾讯计费场景中，咱们设置雷同的场景，别离对 Pulsar 和 Kafka 进行了压测比照，具体的测试场景如下。
压测数据如下:
以上数据能够看到，网络 IO 方面，3 个正本多分区的状况下，Pulsar 简直要把 broker 网卡出流量跑满，因为一份数据须要在 broker 端散发 3 次，这是计算存储拆散的代价。
Kafka 的性能数据有点让人悲观，整体性能没有下来，这应该和 Kafka 自身的正本同步机制无关：Kafka 采纳的是 follow 同步拉取的策略，导致整体效率并不高。
提早方面，Pulsar 在生产端体现更优越些，当资源没有达到瓶颈时，整个时耗 99% 在 10 毫秒以内，在垃圾回收（Garbage Collection，GC）和创立操作日志文件时会呈现稳定。
从压测的后果来看，在高统一的场景下，Pulsar 性能优于 Kafka。如果设置 log.flush.interval.messages=1 的状况，Kafka 性能体现更差，kafka 在设计之初就是为高吞吐，并没有相似间接同步刷盘这些参数。
此外，咱们还测试了其余场景，比方百万 Topic 和跨地区复制等。在百万 Topic 场景的生产和生产场景测试中，Pulsar 没有因为 Topic 数量增长而呈现性能急剧下降的状况，而 Kafka 因为大量的随机写导致系统疾速变慢。
Pulsar 原生反对跨地区复制，并反对同步和异步两种形式。Kafka 在同城跨地区复制中，吞吐量不高，复制速度很慢，所以在跨地区复制场景中，咱们测试了 Pulsar 同步复制形式，存储集群采纳跨城部署，期待 ACK 时必须蕴含多地应答，测试应用的相干参数和同城统一。测试后果证实，在跨城状况下，Pulsar 吞吐量能够达到 28 万 QPS。当然，跨城跨地区复制的性能很大水平依赖于以后的网络品质。
可用性剖析
作为新型分布式音讯流平台，Pulsar 有很多劣势。得益于 bookie 的分片解决以及 ledger 抉择存储节点的策略，运维 Pulsar 非常简单，能够解脱相似 Kafka 手动均衡数据搅扰。但 Pulsar 也不是美中不足，自身也存在一些问题，社区仍在改良中。
Pulsar 对 ZooKeeper 的强依赖
Pulsar 对 ZooKeeper 有很强的依赖。在极限状况下，ZooKeeper 集群呈现宕机或者阻塞，会导致整个服务宕机。ZooKeeper 集群奔溃的概率绝对小，毕竟 ZooKeeper 通过了大量线上零碎的考验，应用还是绝对宽泛的。但 ZooKeeper 梗塞的概率绝对较高，比方在百万 Topic 场景下，会产生百万级的 ledger 元数据信息，这些数据都须要与 ZooKeeper 进行交互。
例如，创立一次主题（topic），须要创立主题分区元数据、Topic 名、Topic 存储 ledger 节点；而创立一次 ledger 又须要创立和删除惟一的 ledgerid 和 ledger 元数据信息节点，一共须要 5 次 ZooKeeper 写入操作，一次订阅也须要相似的 4 次 ZooKeeper 写入操作，所以总共须要 9 次写入操作。如果同时集中创立百万级的主题，势必会对 ZooKeeper 造成很大的压力。
Pulsar 具备扩散 ZooKeeper 部署的能力，可能在肯定水平上缓解 ZooKeeper 的压力，依赖最大的是 zookeeperServer 这个 ZooKeeper 集群。从之前的剖析来看，写操作绝对可控，能够通过控制台创立 Topic。bookie 依赖的 ZooKeeper 操作频率最高，如果该 ZooKeeper 呈现阻塞，以后写入并不会造成影响。
能够依照同样的思路优化对 zookeeperServerzk 的依赖。至多对于以后的服务能够继续一段时间，给 ZooKeeper 足够的工夫进行复原；其次缩小 ZooKeeper 的写入次数，只用于必要的操作，比方 broker 选举等。像 broker 的负载信息，能够寻求其余存储介质，尤其是当一个 broker 服务大量主题时，这个信息会达到兆（M）级别。咱们正在和 Pulsar 社区携手优化 broker 负载性能。
Pulsar 内存治理稍简单
Pulsar 的内存由 JVM 的堆内存和堆外存形成，音讯的发送和缓存通过堆外内存来存储，缩小 IO 造成的垃圾回收（GC）；堆内存次要缓存 ZooKeeper 相干数据，比方 ledger 的元数据信息和订阅者重推的音讯 ID 缓存信息，通过 dump 内存剖析发现，一个 ledger 元数据信息须要占用约 10K，一个订阅者者重推音讯 ID 缓存初始为 16K，且会持续增长。当 broker 的内存持续增长时，最终频繁进行整体垃圾回收（full GC），直到最终退出。
要解决这个问题，首先要找到能够缩小内存占用的字段，比方 ledger 元数据信息外面的 bookie 地址信息。每个 ledger 都会创建对象，而 bookie 节点十分无限，能够通过全局变量来缩小创立不必要的对象；订阅者重推音讯 ID 缓存能够把初始化管制在 1K 内，定期进行缩容等。这些操作能够大大晋升 Broker 的可用性。
和 Kafka 相比，Pulsar broker 的长处比拟多，Pulsar 可能主动进行负载平衡，不会因为某个 broker 负载过高导致服务不稳固，能够疾速扩容，升高整个集群的负载。
总结
总体来说，Pulsar 在高统一场景中，性能体现优异，目前已在腾讯外部宽泛应用，比方腾讯金融和大数据场景。大数据场景次要基于 KOP 模式，目前其性能曾经十分靠近 Kafka，某些场景甚至曾经超过 Kafka。咱们坚信，在社区和宽广开发爱好者的共同努力下，Pulsar 会越来越好，开启下一代云原生音讯流的新篇章。
本文作者：刘德志
腾讯专家工程师、TEG 技术工程事业群和计费零碎开发者
