[Recap] Huobi & GitChat Meetup
作者：Susan
编辑：Susan
内容导读：Apache Pulsar 于 2016 年由雅虎开源，并于 2018 年成为 Apache 顶级项目。 Apache Pulsar 是云原生新一代的消息流数据平台，它具有统一的消息消费模型、存储计算分离的架构、高可用和高可扩展性、以及多租户等丰富的企业级特性。本篇介绍 Pulsar 的特性及其背后的系统架构。
2019 年 6 月 1 日，Huobi 和 Gitchat 在北京举办主题为“分布式高可用消息队列的原理与实践”的 meetup。我司 CTO 翟佳受邀参加本次分享，发表“Apache Pulsar 特性及其系统架构”主题演讲。本篇为演讲内容导航，干货满满，欢迎查看！
翟佳
Pulsar 和 BookKeeper 的 Committer & PMC 成员
Pulsar 简介
Apache Pulsar 是灵活的发布-订阅消息系统（Flexible Pub/Sub messaging），采用分层分片架构（backed by durable log/stream storage）。
消息系统有很多，Yahoo 为什么研发自己的消息系统呢？
- 用户需求 -
已有的消息系统无法解决 Yahoo 遇到的问题和规模，Yahoo 需要多租户，能够支撑上百万的 topics，同时满足低延迟、持久化和跨地域复制要求。
- 存在问题 -
分区模型紧耦合存储和计算，不是云原生（Cloud Native）的设计。
存储模型过于简单，对文件系统依赖太强。
IO 不隔离，消费者在清除 Backlog 时会影响其他生产者和消费者。
运维复杂，替换机器、服务扩容需重新均衡数据。
- 解决方法 -
为解决上述问题，Pulsar 应运而生，Pulsar 的特性如下:
持久化：采用 BookKeeper 作为存储层，灵活性强。
Ordering：每个消息有全局唯一的 ID，消息重发简单。
Delivery Guarantees：At least once, at most once 和 effectively once。
高吞吐：单个分区高达 1.8 M 消息/秒。
低延迟：99% 的生产延迟小于 5 ms。
统一消息模型：同时支持两种消费模型，流和队列。
多租户：单个群集可支持多租户和用例。
跨地域复制：原生可用。
高可用、高扩展性、易运维
Pulsar 的差异化亮点
统一的消费模型
Pulsar 的独特之处在于，在 partition 和 consumer 中间添加了订阅模型，订阅模型有 exclusive、failover、shared 模式。通过 shared 模式，producer 端和 consumer 端相互解耦，producer 并发高，增加 partition 的数量；consumer 消费慢，增加 consumer 的数量，互不影响，可实现真正意义上的解耦。
下图介绍了 Pulsar 如何管理订阅（视频回放 3:28:15）。在 Pulsar Broker端，有一个数据结构 Cursor 来持久保存每一条消息的消费状态。
在 Pulsar 2.4.0 版本中，增加了 Key-Shared 订阅模式（视频回放 3:31:30），既能保证一个 partition 的并发度，同时 consumer 能保证每个 key 的单独顺序。
企业级特性
企业要维护大的集群，多租户特性显示得尤为重要。Pulsar 的多租户特性能满足企业的管理需求，可提供隔离、共享、和丰富策略来管理 topic。
每个租户下面有 namespace，namespace 下又有一个或多个 topic。租户层通过角色控制实现消息的共享和隔离。namespace 层提供了丰富的策略，可对 topic 进行管理。例如，你可以在 namespace 中设置管理策略，如消息副本数、backlog 超过阈值后如何处理等等。
应用 namespace 管理，可应用 Pulsar 的跨地域复制（视频回放 3:36:20），实现异地互备，在创建时添加一个参数指定一个 topic 在几个机房之间做互备即可。Pulsar Geo-replication 的优点如下：
Broker 原生，方便易用
Pub-Sub 一体
管理简单
配置灵活
部分内容在 EventStreaming Meetup 中有详细介绍，请参阅 [Recap of EventStreaming Meetup No.1]。
分层分片的架构
- 分层 -
分层指存储和计算的分离。在 server 端，每个 broker 作为存储层的一个 client，将 topic 数据存储到底层存储层 bookie 中。该架构的特点和优势是：
broker 节点不存储任何数据，如果宕机，topic 可很快迁移到其他 topic。
broker 节点对等，底层存储节点也提供了对等架构。易于负载平衡和扩容，管理容易，数据可用性强。
- 分片 -
Pulsar 给用户提供了 partition 的逻辑抽象，底层物理存储将逻辑的 partition 划分为多个分片，均匀存储在所有节点上。该结构的好处在于存储容量不再受限于单个存储节点容量，扩容无需进行数据搬移，数据分布均匀。
Pulsar 的分层分片架构
▲ 存储层概念：Entry，Ledger 和 Log
Log/Stream/topic 暴露给用户，在此之下每个 topic 拆分成不同分片，在 BookKeeper 中称为 ledger，一个 ledger 写完就被关闭。最下层每个 entry 对应 Pulsar 中的 messge。
▲ 存储层：Apache BookKeeper
Pulsar 使用 BookKeeper 作为存储层。BookKeeper 提供的是WAL（Write Ahead Log）的抽象。解决的问题是把受限于单个节点的 binlog 分散到集群中，并提供高带宽和低延迟。支持读和写的高可用，节点宕机后，新节点换入，不会影响用户应用。
优点：便捷运维+无感知容错
▲ 无感知容错，零数据 Catch up，运维便捷。对存储层来说，分层分片架构和底层并发架构让数据恢复简单，应用无感知，且控制灵活。
▲ 存储扩容方便。存储容量不再受限于单个存储节点容量，扩容无需数据搬移，数据分布均匀。
▲ 分区 vs 分片
Kafka：前两个节点已经满了，新加节点需要数据搬移和平衡，不能立即用。
Pulsar：不同于 Kafka 物理和逻辑的绑定性，存储是平均分配的，每个 topic 分成小块，分布更均匀。加入新的节点后，可以立即使用。
下面这张图形象直观地看到 Pulsar 和 Kafka 的不同。
优点：IO 的并发和隔离
常见模式分为写（Write）、读最新数据（Tailing Read）、读老数据（Catchup Read）三种。 Kafka 把读写集中在单一节点上，而 Pulsar 的读写隔离更能保证读写质量。
最新数据可应用 pub-sub 接口读取，老数据应用 segment readers 接口并发地读取底层数据。得益于分层分片架构，Pulsar 可将老数据分片搬移至二级存储。这样最新的数据在 broker 中有缓存，比较新的数据放在 BookKeeper 中，更老的数据放在其他存储，比如 S3 上。
Pulsar 的生态和社区
统一的消费模型
Pulsar 在 Messaging 和 Stream Storge 的基础上，上层提供 Pulsar IO - Connector 接口。在 Messaging 层提供 Pulsar Functions。在 Stream storage 层主要做二级存储，且提供用户直接访问接口，提供 Pulsar SQL、Hive 的集成。
演讲 PPT，请参阅：
https://www.slidestalk.com/s/ApachePulsar64933
视频回顾，请参阅视频回放（3:13:00 开始）：
http://www.itdks.com/index.php/Act/apply_upgrade/id/2934/mUid/0/tpl/tpltwo.html#dingbu
- Apache Pulsar 社区 -
Twitter：@apache_pulsar
微信公众号：ApachePulsar
邮件列表：
dev@pulsar.apache.org
users@pulsar.apache.org
Slack：
登录：https://apache-pulsar.slack.com (#china)
注册：https://apache-pulsar.herokuapp.com/
翻译：
https://crowdin.com/project/apache-pulsar
GitHub：
https://github.com/apache/pulsar
https://github.com/apache/bookkeeper
更多 Pulsar 相关的干货和动态分享，请关注公众号 ApachePulsar。
点击观看视频回放，本部分内容于 3:13:00 开始。