消息传输的设计方式(上)

写在前面

这几天拜读了郭斯杰的《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被设计来解决这一共有需求,也可以统一分歧,逐渐变成其他服务的基础组件,包括键值对数据库、订阅发布消息,以及跨数据中心的复制机制等等。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180102B0W8IP00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券