Apache Pulsar崛起 | Meetup北京站全解析

该篇演讲由来自腾讯的刘德志提供。

腾讯的计费场景如下：

针对自己的业务场景，腾讯对Pulsar做了四个方面的优化：

• 支持延迟消息和定时重试（2.4.0 支持）。

• 支持二级 Tag。

• 完善控制台，支持消息查询和消费追踪。

• 完善的监控和告警体系。

整体架构如下：

• Broker 作为消息队列代理层，负责消息的生产和消费请求，支持水平扩展，根据负载按 Topic 自动进行均衡。

• BookKeeper 作为消息队列的分布式存储中心，可配置多个消息副本，在异常情况下具备 Failover 能力。

• ZooKeeper 作为消息队列的元数据和集群配置中心。

• 支持多种消费模式，其中 Shared 模式下的消费者突破对分区个数的依赖， function 模式非常适合简单的交易流水清洗场景。

• 提供了统一的 HTTP proxy 接入能力，方便其它语言接入。

• 腾讯计费还有部分业务是 JS 和 PHP 等语言，提供了统一的 HTTP proxy 接入能力，并对客户端加上生产失败重试能力，提升生产成功率。集群出现异常时，客户端会做降级处理，将消息发送至本地或发送至容灾集群。

该篇演讲作者：Rocky Jin，产品总监，杭州映云科技有限公司 EMQ X 产品负责人。

ActorCloud选择Pulsar的原因包括：

• 高可用、高扩展性、部署简单、易运维。 

• 高吞吐：单个分区高达 1.8 M 消息/秒，这一特点完全符合我们数据量大的需求。

• Pulsar Functions 是一个轻量化的计算平台，能从一个或多个 Pulsar 主题中消费消息，把用户提供的处理逻辑应用于每个消息，把计算结果发布到另一个主题。Pulsar Functions 支持 Thread、Process、Kubernetes 等运行时，这为我们编写、运行和部署 Functions 提供了很好的灵活性，所以我们只用关心计算逻辑，无需处理复杂的配置或管理，更便捷地构建基于消息触发的流平台。

• 存储计算分离，IO 隔离，能够灵活处理数据，处理和存储可以独立扩展。

ActorCloud 把基于 SQL 的业务规则通过 API 的方式传入到数据处理规则管理引擎中，并将这些业务规则翻译为 Pulsar 中对应的 Source、Functions 和 Sink。Pulsar 的 Source 通过共享订阅的方式对接入 EMQ X Broker 设备数据进行消费，Pulsar 将这些数据进行持久化 ，并通过扩展 Pulsar 的 Functions 来对消息进行实时处理，处理完后通过 Sinks 将数据发送到相关的外部系统中。

我们看一个案例：

本文作者：Nozomi Kurihara 雅虎日本消息平台团队经理

雅虎日本选择Pulsar的主要原因如下：

• 可扩展性

• 多租户支持

• 异地备份

雅虎日本使用Pulsar的架构如下：

• 内容更新通知

• 邮箱服务队列

• 日志收集

• 日志过滤收集