共计 3671 个字符，预计需要花费 10 分钟才能阅读完成。
最近这个 Apache Pulsar 消息中间件十分的火，号称云原生时代的下一代音讯中件，明天，就一起来看看它到底有多牛逼？
Apache Pulsar 简介
Apache Pulsar 是一个企业级的分布式音讯零碎，最后由 Yahoo 开发并在 2016 年开源，目前正在 Apache 基金会下孵化。Plusar 曾经在 Yahoo 的生产环境应用了三年多，次要服务于 Mail、Finance、Sports、Flickr、the Gemini Ads platform、Sherpa 以及 Yahoo 的 KV 存储。Pulsar 之所以可能称为下一代音讯队列，次要是因为以下个性:
- 线性扩大。可能丝滑的扩容到成千盈百个节点(Kafka 扩容须要占用很多系统资源在节点间拷贝数据，而 Plusar 齐全不必)
- 高吞吐。曾经在 Yahoo 的生产环境中禁受了考验，每秒数百万音讯
- 低提早。在大规模的音讯量下仍然可能放弃低提早(< 5ms)
- 长久化机制。Plusar 的长久化机制构建在 Apache BookKeeper 之上，提供了写与读之前的 IO 隔离
- 基于地理位置的复制。Plusar 将多地区 / 可用区的复制作为首要个性反对。用户只需配置好可用区，音讯就会被源源不断的复制到其余可用区。当某一个可用区挂掉或者产生网络分区，plusar 会在之后一直的重试。
- 部署形式的多样化。既能够运行在裸机，也反对目前例如 Docker、K8S 的一些容器化计划以及不同的云厂商，同时在本地开发时也只须要一行命令即可启动整个环境。
- Topic 反对多种生产模式:exclusive、shared、failover
架构
从最上层来看，一个 Plusar 单元由若干个集群组成，单元内的集群能够相互之前复制数据, plusar 中通常有以下几种组件:
- Broker: 负责解决 Producer 发来的音讯并分发给消费者。通过一个全局的 ZK 集群来解决多种合作式工作，例如说基于地理位置的复制。并将音讯存储到 BookKeeper 中，同时单个集群内也须要有一套 ZK 集群，来存储一些元数据。
- BookKeeper 集群: 外部蕴含多个 bookies，用于长久化音讯。
- ZooKeeper 集群
Broker
Pulsar 的 Server 端，用来解决 Producer 和 Consumer 的数据收发逻辑. 每个 Broker 治理 topic 中的一些分区, 生产者和消费者连贯到主题分区的所有者 Broker 发送音讯或生产音讯.plusar 中的 broker 是一个无状态的节点，次要负责三件事件：
- 裸露 REST 接口用于执行管理员的命令以及 topic 所有者的查问等
- 一个用于节点间通信的异步的 TCP 服务器，协定目前采纳的是 Google 之前开源的 Protocol Buffer
- 为了反对地区复制，broker 会将本人 集群所在的音讯公布到其余可用区。
BookKeeper
BookKeeper 是一个可横向扩大的、谬误容忍的、低提早的分布式存储服务，BookKeeper 中最根本的单位是记录，实际上就一个字节数组，而记录的数组称之为 ledger，BK 会将记录复制到多个 bookies，存储 ledger 的节点叫做 bookies，从而取得更高的可用性和谬误容忍性。
Pulsar 中把每一个音讯认为是存储在 Apache BookKeeper 中的分布式日志, 每个分布式日志又被分为多个 Segment 分段, 每个 Segment
分段在 Apache BookKeeper 中叫做一个 Ledger，并扩散储在 BookKeeper 群集中的多个节点中. 通过 Segment 分段的形式，主题分区中的音讯能够平衡地散布在群集中的所有 Bookie 中. 并且所有的正本是对等的, 客户端能够从任何一个 Bookie 的正本中读取音讯. 数
据写入 Bookie 的一个根本过程:
咱们晓得 Kafka 在 0.8 版本之前是将生产进度存储到 ZK 中的，然而 ZK 实质上基于单个日志的核心服务，简略来讲，ZK 的性能不会随着你减少更多的节点而线性减少，会只会相同缩小，因为更多的节点意味着须要将日志同步到更多的节点，性能也会随之降落，因而 QPS 也会受单机性能影响，因而 0.8 版本之后就将生产进度存储到了 Kafka 的 Topic 中，而 RocketMQ 最后的版本也相似，有几种不同的实现例如 ZK、数据库等，目前版本采纳的是存储到本机文件系统中，而 Plusar 采纳了和 Kafka 相似的思维，Plusar 将生产进度也存储到了 BK 的 ledger 中。
Topic
公布订阅零碎中最外围的概念是 topic，简略来说，topic 能够了解为一个管道，producer 能够往这个管道丢音讯，consumer 能够从这个管道的另一端读取音讯，然而这里能够有多个 consumer 同时从这个管道读取音讯。
每个 topic 能够划分为多个分区，同一个 topic 下的不同分区所蕴含的音讯都是不同的。每个音讯在被增加到一个分区后都会调配一个惟一的 offset，在同一个分区内音讯是有序的，因而客户端能够依据比如说用户 ID 进行一个哈希取模从而使得整个用户的音讯都发往整个分区，从而肯定水平上防止 race condition 的问题。通过分区，将大量的音讯扩散到不同的节点解决从而取得高吞吐。默认状况下，plusar 的 topic 都是非分区的，然而反对通过 cli 或者接口创立肯定分区数目的 topic。
Pulsar 是反对多租户 (tenant) 的, 租户上面又分了命名空间(namespace). 所以 topic 的创立格局是 /tenant/namespance/topic. 为了兼容 kafka 等消息中间件. pulsar 预置了默认的租户和命名空间: pulibc/default. 举个例子，假如部署了一个 Pulsar 集群来反对多个应用程序，那么每个 tenant 都能够代表一个团队，一个外围的性能，或者一个产品线; 一个 tenant 上面能够蕴含多个 namespace，例如，每个应用程序为一个 namespace; 一个 namespace 能够蕴含多个 Topic，如下图:
Producer
生产者, 负责将音讯发送给 Broker 节点, 发送音讯的过程如下:
- 通过负载平衡策略, 动静的给 producer 调配一个适合的 broker 节点, 每个 broker 节点保护这 topic 的一些分区
- broker 将音讯并发的发送给 N 个 bookie，这个 N 是能够配置的。broker 持有 BookKeeper 的客户端 writer，writer 收到写申请后，会并发的写入 N 个 bookie。
- bookie 写完音讯后会给 broker 一个回复，broker 收到指定数量的确认音讯后就会认为写 BookKeeper 胜利。这个数量是可配置的, 越大写 BookKeeper 提早越大，数据一致性越高。
Subscription
订阅, 决定了音讯具体是如何被散发到消费者的，Plusar 反对几种不同的生产模式: exclusive、shared、failover。图示如下:
- Shared(共享订阅模式): 所应用共享订阅，在同一个订阅背地能够有任意多的消费者。订阅中的所有音讯以循环散发模式被动投递给订阅背地的多个消费者，并且一个音讯仅传递给一个消费者。当消费者断开连接时，所有传递给它然而未被确认（ack）的音讯将被重新分配和组织，以便发送给该订阅上残余的残余消费者。在这种模式下如果想进步生产的速度，用户不须要减少分区数量，只须要在同一个订阅中增加更多的消费者。下图是共享订阅的示例。消费者 C-1，C-2 和 C-3 都在同一主题上生产音讯。每个消费者接管大概所有音讯的 1/3。
- Key_shared(基于 Key 的共享模式): 联合了 FailOver 和 Shared 的劣势, 数据按肯定的 key 策略轮询的形式散发到每一个消费者. 这样既保证了有序性, 又能够很轻易的通过扩容 consumer 来减少生产速率
- Failover(故障切换模式): 每应用故障切换订阅，多个消费者（Consumer）能够附加到同一订阅。然而，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者, 其余消费者将被指定为故障转移消费者。当主消费者断开连接时，分区将被重新分配给其中一个故障转移消费者，而新调配的消费者将成为新的主消费者。产生这种状况时，所有未确认（ack）的音讯都将传递给新的主消费者, 相似于 kafka 的生产模式, 保障了生产的有序性.
下图是故障切换订阅的示例。消费者 B-0 和 B-1 通过订阅 B 订阅生产音讯。B- 0 是主消费者并接管所有音讯。B-1 是故障转移消费者，如果消费者 B-0 呈现故障，它将接管生产. - Exclusive(独占订阅模式): 顾名思义，独占订阅中，在任何工夫，一个消费者组（订阅）中有且只有一个消费者来生产 Topic 中的音讯。下图是独占订阅的示例。在这个示例中有一个有订阅 A 的沉闷消费者 A-0，音讯 m0 到 m4 按程序传送并由 A-0 生产。如果另一个消费者 A-1 想要附加到订阅 A，则是不被容许的.
总结
Pulsar 作为下一代分布式音讯队列，领有十分多吸引人的个性，也补救了一些其余竞品的短板，例如地区复制、多租户、扩展性、读写隔离等等.
本文由 mdnice 多平台公布