消息传输的设计方式（上）

写在前面

这几天拜读了郭斯杰的《Messaging，Storage，or both?》一文，原文地址在这里，大有感触，作者分享了自己过去几年时间里在工作中使用Apache Pulsar、DistributedLog，以及BookKeeper的实际经验。

郭斯杰7年前作为雅虎北京的推送消息团队成员开始使用BookKeeper，大约5年前，也就是2012年，郭斯杰转战到了位于旧金山的Twitter公司，开始致力于利用BookKeeper解决分布式数据库的一致性问题，根据他的描述，这一工作内容最终促成了Apache DistriutedLog的诞生。

郭斯杰的这篇文章主要是围绕Pulsar、DistriutedLog两者如何与BookKeeper协作完成实时处理的经验分享。本文我将会解读他的这篇文章，并且加入我自己的实际理解和使用经验。

预备知识

郭斯杰最早开始接触的是BookKeeper，从后面的文章介绍中我们可以知道，BookKeeper是很多组件的基础，可以帮助进行分布式环境的信息协同管理，正是由于拥有BookKeeper的实际工作经验，郭斯杰也有了接触Pulsar和DistributedLog的机会。我先谈谈自己整理的一些相关知识，介绍这三个东西究竟是什么？

Apache Pulsar

Pulsar是分布式订阅发布消息传输系统，最早有由Yahoo公司开发的，并在2016年正式开源。

Pulsar提供了灵活消息传输、多租户、跨地理位置数据复制等特性。Pulsar的创始人Joe和Matteo等人认为需求是Pulsar项目启动的原因，如果应用程序提供实时服务，需要保证平均5ms以内的发布延迟，99%的请求不会超过15ms的延迟，同时满足分类、强持久性以及传输保证等特征的消息传输系统，这个系统必须满足提交到各个磁盘或者节点达到99.99%的准确性。

Pulsar对于消息的相关概念和角色定义与Kafka很相近，它们都把数据的接入方叫做生产者，都把数据的接收方叫做消费者（订阅者），如下图所示。

Pulsar是如何实现对于多租户用例的支持的？通过属性（Property）和命名空间(NameSpace)。属性表示系统中的租户，在Pulsar集群内部，一个属性可以包含多个命名空间，如下图所示。

命名空间是Pulsar集群的最基本管理单元，在命名空间级别，你可以设置权限、调优复制策略、管理跨集群的消息数据复制、控制消息过期，以及其他关键操作。同一个命名空间里的主题共享相同的配置。

在Pulsar内部存在几个一对多的关系。一个命名空间对应多个主题（Topic），一个主题对应多个订阅者（Subsribes），一个订阅者可以接收主题上的所有消息。为了提供更加灵活的订阅方式，Pulsar提供了三种不同的订阅类型：

独占式订阅：每个主题有且仅有一个消费者；

共享式订阅：多个消费者可以共享一个订阅/主题，每个消费者可以收到订阅的某一部分内容；

失败切换模式：多个消费者可以连接到一个主题，但是同时有且仅有一个消费者可以收到消息，其他的消费者只有在当前在线的那个消费者离线时才能竞争上岗（同样只会有一个竞争获胜者，其它竞争失败者还是需要继续守候下一次竞争）。

除此之外，Pulsar支持将主题进行分区，一旦分区，数据也会被自动分区，如下图所示，和Kafka类似，Pulsar也引入了“Broker”概念，每个Broker管理多个主题。

Apache DistributedLog

DistributedLog的出现是数据层面抽象的必然结果。2012年底这个时间段正好是Twitter公司内部的实时消息基础设施的杂乱无章阶段。Kestrel是一款队列系统，被设计用来处理在线服务的关键消息，Kafka则被用于进行离线服务的日志收集和分析，郭斯杰的团队则使用BookKeeper进行数据库备份。

DistributedLog也被称为“共享日志基础设施”。日志存储是几乎所有分布式系统都需要解决的问题，而DistributedLog被设计来解决这一共有需求，也可以统一分歧，逐渐变成其他服务的基础组件，包括键值对数据库、订阅发布消息，以及跨数据中心的复制机制等等。

写在前面

这几天拜读了郭斯杰的《Messaging，Storage，or both?》一文，原文地址在这里，大有感触，作者分享了自己过去几年时间里在工作中使用Apache Pulsar、DistributedLog，以及BookKeeper的实际经验。

郭斯杰7年前作为雅虎北京的推送消息团队成员开始使用BookKeeper，大约5年前，也就是2012年，郭斯杰转战到了位于旧金山的Twitter公司，开始致力于利用BookKeeper解决分布式数据库的一致性问题，根据他的描述，这一工作内容最终促成了Apache DistriutedLog的诞生。

郭斯杰的这篇文章主要是围绕Pulsar、DistriutedLog两者如何与BookKeeper协作完成实时处理的经验分享。本文我将会解读他的这篇文章，并且加入我自己的实际理解和使用经验。

预备知识

郭斯杰最早开始接触的是BookKeeper，从后面的文章介绍中我们可以知道，BookKeeper是很多组件的基础，可以帮助进行分布式环境的信息协同管理，正是由于拥有BookKeeper的实际工作经验，郭斯杰也有了接触Pulsar和DistributedLog的机会。我先谈谈自己整理的一些相关知识，介绍这三个东西究竟是什么？

Apache Pulsar

Pulsar是分布式订阅发布消息传输系统，最早有由Yahoo公司开发的，并在2016年正式开源。

Pulsar提供了灵活消息传输、多租户、跨地理位置数据复制等特性。Pulsar的创始人Joe和Matteo等人认为需求是Pulsar项目启动的原因，如果应用程序提供实时服务，需要保证平均5ms以内的发布延迟，99%的请求不会超过15ms的延迟，同时满足分类、强持久性以及传输保证等特征的消息传输系统，这个系统必须满足提交到各个磁盘或者节点达到99.99%的准确性。

Pulsar对于消息的相关概念和角色定义与Kafka很相近，它们都把数据的接入方叫做生产者，都把数据的接收方叫做消费者（订阅者），如下图所示。

Pulsar是如何实现对于多租户用例的支持的？通过属性（Property）和命名空间(NameSpace)。属性表示系统中的租户，在Pulsar集群内部，一个属性可以包含多个命名空间，如下图所示。

命名空间是Pulsar集群的最基本管理单元，在命名空间级别，你可以设置权限、调优复制策略、管理跨集群的消息数据复制、控制消息过期，以及其他关键操作。同一个命名空间里的主题共享相同的配置。

在Pulsar内部存在几个一对多的关系。一个命名空间对应多个主题（Topic），一个主题对应多个订阅者（Subsribes），一个订阅者可以接收主题上的所有消息。为了提供更加灵活的订阅方式，Pulsar提供了三种不同的订阅类型：

独占式订阅：每个主题有且仅有一个消费者；

共享式订阅：多个消费者可以共享一个订阅/主题，每个消费者可以收到订阅的某一部分内容；

失败切换模式：多个消费者可以连接到一个主题，但是同时有且仅有一个消费者可以收到消息，其他的消费者只有在当前在线的那个消费者离线时才能竞争上岗（同样只会有一个竞争获胜者，其它竞争失败者还是需要继续守候下一次竞争）。

除此之外，Pulsar支持将主题进行分区，一旦分区，数据也会被自动分区，如下图所示，和Kafka类似，Pulsar也引入了“Broker”概念，每个Broker管理多个主题。

Apache DistributedLog

DistributedLog的出现是数据层面抽象的必然结果。2012年底这个时间段正好是Twitter公司内部的实时消息基础设施的杂乱无章阶段。Kestrel是一款队列系统，被设计用来处理在线服务的关键消息，Kafka则被用于进行离线服务的日志收集和分析，郭斯杰的团队则使用BookKeeper进行数据库备份。

DistributedLog也被称为“共享日志基础设施”。日志存储是几乎所有分布式系统都需要解决的问题，而DistributedLog被设计来解决这一共有需求，也可以统一分歧，逐渐变成其他服务的基础组件，包括键值对数据库、订阅发布消息，以及跨数据中心的复制机制等等。