雅虎日本如何用 Pulsar 构建日均千亿的消息平台

雅虎日本是一家雅虎和软银合资的日本互联网公司，是日本最受欢迎的门户网站之一。雅虎日本的互联网服务在日本市场占主导地位。

下图从三个维度显示了雅虎日本的经营规模。第一个是服务数量，雅虎日本提供上百种互联网服务；第二个是服务器数量，雅虎日本使用超过 150,000 台服务器（大多为裸机服务器）全天候支持这上百种互联网服务的正常运作；第三个是每月总页面浏览量，2017 年的数据显示，雅虎日本每月浏览量超过 700 亿。由此可见，雅虎日本的服务规模之大。 

挑战

运营规模巨大对雅虎日本来说是个挑战。高性能和可扩展的服务才能满足海量用户的需求。同时还需要提供多租户支持来满足运营众多服务的需求。有时需要处理敏感消息或关键任务，因此持久性也很重要。此外，雅虎拥有众多的数据中心，对跨地域复制有强烈的需求。在诸多方面，我们面临着巨大挑战，希望找到一个稳定且可扩展的消息平台，能满足上述需求并大规模地运行服务，同时能确保数据的完整性。

为什么选择 apache pulsar

为了解决这些挑战，我们开始调研各种消息平台。

apache pulsar vs apache kafka

首先，我们比较了 apache pulsar 和 apache kafka，这两个业界不同的消息系统，结果如下。

这两个系统最主要的不同在于数据分布。在数据负载均衡方面，pulsar 比 kafka 处理得更胜一筹。以下图为例，图中有 1 个分区，3 个存储节点，每个分区数据存储两个副本。kafka 中，分区中的所有数据都保存在 leader broker（broker 2）中，然后复制到另一个 follower broker（broker 1）中。broker 3 既不是 leader 也不是 follower，因此没有任何数据。在 kafka 中，由于一个分区中的所有数据都由一个 broker 保存，因此分区的容量受 broker 的容量限制。一旦要扩展分区，就需要重新分布数据；否则就会出现负载不均衡的情况。而 pulsar 中，分区中的数据被划分为粒度更细的单元，称为分片（segment）。它们均匀地分布和保存在 bookies 中，分区容量不受单个 bookie 节点容量的限制，扩展分区时不需要重新分布数据。因此，pulsar 比 kafka 更灵活，更容易扩展。

另一个区别是跨地域复制。kafka 使用 mirrormaker 来处理跨地域复制，但需要使用额外的机器来运行和管理 mirrormaker。而 pulsar 内置了跨地域复制功能，不需要额外部署跨地域复制组件。

openmessaging benchmark

使用 openmessaging benchmark 可以很容易比较不同消息处理系统。据报道，apache pulsar 处理吞吐量和延迟的性能更好。图中蓝线代表 pulsar，红线代表 kafka。左图显示吞吐量，上方线条说明吞吐量更高。右图显示延迟，下方线条说明延迟更低。

雅虎日本如何用pulsar构建日均千亿的消息平台？

为什么 apache pulsar 最适合

这些对比说明 apache pulsar 比 apache kafka 更好，所以我们决定进一步研究 apache pulsar，并总结了 pulsar 更适合我们的原因。

高性能

即使主题数量巨大，还要保证数据的可靠性，apache pulsar 也能实现高吞吐和低延迟。例如，oath inc. 每天要处理 230 万个 topic，1000 亿条消息。在这个巨大的体量下，要确保消息不能丢失且必须按顺序处理。apache pulsar 不仅能满足这些需求，还实现了 1,000,000 吞吐量（msg / s）和 5 ms 的延迟。

易扩展

apache pulsar 扩展性很好。要实现扩容，只需添加服务器即可。pulsar 的服务层和存储层是分开的，可以根据数据路径灵活地添加 broker 或 bookie。如果需要提升服务容量，添加 broker 即可。如果需要扩大存储容量，添加 bookie 即可。

多租户

多租户是指多种服务共用一个 pulsar 系统。每个服务和应用程序作为 “租户” 使用 pulsar。因此，不同的服务无需单独维护各自消息系统。apache pulsar 有不同的认证和授权机制，可保护消息不被拦截。可以配置认证和授权机制，并共享到命名空间或主题，从而保护消息。因此，可以在一个 pulsar 系统上运行多种服务，有效降低维护和劳动力成本。

跨地域复制

雅虎日本在多个数据中心运行很多服务。pulsar 提供内置的跨地域复制功能，在数据中心之间复制消息，可以有效处理灾备，恢复数据，提高服务质量。更重要的是，跨地域复制是 pulsar 的内置功能，方便启用和使用。

pulsar functions

pulsar functions 是轻量级计算框架（如 aws lambda 或 google cloud functions），不需要外部系统（如 apache heron，apache storm，apache spark 或其他类似系统）。只需构造逻辑并部署至 pulsar 集群。pulsar functions 支持 java、python 和 go 语言。

pulsar on kubernetes

kubernetes 有众多用户，雅虎日本也是其中之一。在 kubernetes 集群上部署 p​​ulsar 很容易。下图展示了 pulsar 在 kubernetes 引擎上的使用状态。

经过详细调研，我们发现 apache pulsar 不仅比 apache kafka 的性能更好，还能够满足我们企业运行的所有需求，在 kubernetes 上容易部署，所以我们最终决定采用 apache pulsar 作为内部消息平台。

apache pulsar 在雅虎日本的应用

雅虎日本在生产环境中使用 pulsar 已经好几年了。我来分享下 apache pulsar 在雅虎日本的应用场景。

下图是雅虎日本的系统构架。我们有两个数据中心：一个在东部，一个在西部。每个数据中心都有 broker、bookie、zookeeper 和 websocket 代理服务器。我们使用 prometheus 收集指标，并通过 grafana 将其可视化。

prometheus 可以用来监控 topic、生产者和消费者的数量，如下图所示。

自助服务工具

在雅虎日本，我们开发了一套工具，用来创建和管理租户、命名空间和主题。用户可以在 ui 界面自己创建租户和命名空间，并配置设置。目前，这个 ui 仅在雅虎日本内部使用，所以是日语的，没有开源。使用这个 ui，可以创建租户和命名空间，并查看 topic 的统计信息，如吞吐量、平均消息规模等。

案例 1: 内容更新通知

我们把 apache pulsar 作为通知服务系统使用。各种内容文件（例如天气，地图或新闻数据）从合作伙伴公司推送到雅虎日本。服务需要了解这些更新的内容，所以服务把文件当作 topic。内容更新时会向 topic 发送通知。服务一旦收到通知，就会从文件服务器获取更新的内容文件。

案例 2: 邮件服务中的工作队列

我们使用 apache pulsar 构建异步工作队列。邮件索引工作繁重，所以异步执行。首先，mail be 服务器中的生产者在 pulsar 中注册 job，消费者按照自己的节奏从 pulsar 获取 job。如果索引失败，生产者会重新注册。

案例 3: 日志管道

我们使用 apache pulsar 收集日志。雅虎日本几乎所有的服务和应用程序都运行 paas 平台（如 heron）或 caas 平台（如 kubernetes），我们想从中收集日志。首先，日志发布到 pulsar 后会分成 topic。根据使用 pulsar functions 的最终目的地和服务，日志最终会发送到其他数据库或平台，例如 hbase、prometheus 和 twilio。下图是雅虎日本的日志收集架构。

结论

apache pulsar 是一个快速、持久、可扩展的 pub-sub 消息系统，配备很多有用的内置功能，如跨地域复制、多租户、pulsar functions 等。

多年来，雅虎日本使用 apache pulsar，关注 pulsar 社区的新闻，更新和活动，在应用场景中使用 pulsar 新功能，pulsar 的稳定性一直很好。

pulsar 社区虽然年轻，但发展迅猛，在不同的应用场景下不断有新的案例落地。我们会持续关注并和 apache pulsar 社区深入合作，进一步完善、优化 pulsar 的特性和功能。

相关信息

以下是 apache pulsar 的相关信息:

• apache pulsar: 

• 联系:   

• 在线视频: 

• 演示文稿: 

关于作者

nozomi kurihara, 雅虎日本消息平台团队经理、apache pulsar 项目 committer。负责创建基于 apache pulsar pub-sub 为中心的消息处理平台，该平台能够处理海量服务和应用程序流量。

• 作者 | nozomi kurihara
• 审校 | jennifer + sijie + irene
• 编辑 | irene