标签：订阅 消费者 确认 broker topic 消息 pulsar 基本概念

学习pulsar有一段时间了，对其基本概念和工作原理也比较了解了，也搭建过几次集群并添加了prometheus监控，这两天有时间把pulsar的基础知识以问题的形式的整理了一下，以加深自己的理解，也便于以后查阅。

1.pulsar优势

高吞吐，低延迟，多租户，计算存储分离，跨机房复制，分层存储等；

所谓 下一代云原生消息平台。

2.一个消息包含哪些内容

数据、key、属性、生产者名称、序列ID、发布时间等，其中数据是必须项；

默认的消息最大值是 5 MB，可通过配置文件修改。

3.支持消息类型

普通消息、压缩消息、批量消息、分块消息、延迟消息、顺序消息、广播消息、消息重试、死信队列、事务消息。

4.生产和消费

1）客户端

生产者和消费者都是一个进程，发送和消费消息即为和broker进程间交互；

2）生产者

两种发送模式：

同步发送-生产者在发送消息后等待broker确认，否则认为发送失败，可设置超时时间；

异步发送-生产者将消息放到阻塞队列里，并立即返回，在后台将消息发送给broker，如果队列已满，则根据客户端参数阻塞或返回失败；

三种访问模式：

Shared共享-一个topic可以同时有多个生产者，默认模式；

Exclusive独占-一个topic同时只能有一个生产者，返回错误；

WaitForExclusive等待独享-如果一个topic已经连接了生产者，那么新的生产者创建将挂起（而不是超时），直到该生产者获得Exclusive访问权，领导者选举；

3）消费者

在 Consumer 端有一个队列，用于接收从 broker 推送来的消息，队列的默认长度是1000，可通过参数配置，每当 consumer.receive() 被调用一次，就从缓冲区（buffer）获取一条消息。

两种接收模式：

同步接收-在收到消息之前都是被阻塞的，常用模式；

异步接收-立即返回一个 future 值，一旦收到新的消息就立刻完成；

两种确认模式：

单条确认-每一条消息都需要返回确认，常用模式；

累计确认-消费者只需要确认最后一条收到的消息，所有之前（包含此条）的消息，都不会被再次重发给该消费者；

取消确认：

当消费者在某个时间没有成功的消费某条消息，消费者想重新消费到这条消息，这个消费者可以发送一条取消确认消息到 broker，broker 会将这条消息重新发给消费者；

注意取消确认可能会打乱原有的消息顺序，批量消息会一起重发；

确认超时：

如果消息没有被成功消费，可以通过设置确认超时时间，让 broker 自动重新交付这个消息，客户端会跟踪超时时间范围内所有未确认的消息，并且在指定超时时间后会发送一个 重发未确认的消息 请求到 broker；

注意取消确认是以更高的精度在控制单条消息的重新传递，批量消息会一起重发。

重试主题：

很多在线的业务系统，由于业务逻辑处理出现异常，消息一般需要被重新消费。 若需要允许延时重新消费失败的消息，你可以配置生产者同时发送消息到业务主题和重试主题，并允许消费者自动重试消费。 配置了允许消费者自动重试，如果消息没有被消费成功，它将被保存到重试主题当中，并在指定延时时间后，自动重新消费重试主题里面的消费失败消息；

需要消费者开启重试；

死信主题：

在消费者无法成功消费某些消息时，消费失败的消息存储在一个单独的主题中，称为死信主题，您可以决定如何处理死信主题中的消息；

一般是在重试一定次数后放到死信主题中，即，取消确认/确认超时--消息重试--死信主题；

需要消费者开启死信主题并指定重试次数。

5.tenant，namespace和topic

租户是 topic 的最基本单位，可以跨集群分布，每个租户可以有单独的授权机制和集群配置，它不属于某个集群，而是能够访问某个或某些集群，和集群是access to的关系；

命名空间是租户内部逻辑上的命名术语，指租户的管理单元，命名空间上设置的配置策略适用于在该命名空间中创建的所有 topic；

Pulsar 通过租户和命名空间这两个关键概念支持多租户；

主题名称是具有明确定义结构的 URL：

{persistent|non-persistent}://tenant/namespace/topic

默认是持久化的，所有的消息都会被持久化的保存到磁盘当中，租户可以跨越实例中的多个集群，命名空间是管理topic的基本单元；

非持久topic的消息不会被保存在硬盘上，只存活于内存中，broker会立即发布消息给所有连接的订阅者，使得非持久topic的消息比持久topic稍微变快，有更低的发布延迟；当使用非持久topic分发时，杀掉Pulsar的broker或者关闭订阅者，此topic上所有的瞬时消息都会丢失，意味着客户端可能会遇到消息缺失。

6.订阅

订阅是命名好的配置规则，指导消息如何投递给消费者；

四种订阅模式：

Exclusive独占-只有一个消费者可以绑定到订阅上，否则报错，默认模式；

Failover灾备-多个消费者可以绑定到同一个订阅上，主消费者消费消息，主断开后，下一个消费者接着消费；

Shared共享-多个消费者可以绑定到同一个订阅上，消息通过轮询机制分发给不同的消费者，并且每个消息仅会被分发给一个消费者，消息顺序不被保证；

Key_Shared key共享-多个消费者可以绑定到同一个订阅上，消息跨消费者分布式传递，具有相同键或相同排序键的消息仅传递给一个消费者，无论消息被重新传递多少次，它都会传递给同一个消费者，需要为消息指定键或排序键；

　　

注意-订阅都是对于同一个topic来说的，不同topic之间互不影响；如果一个订阅没有消费者，则订阅模式是未定义的；一个消费者可以同时订阅多个topic，但顺序则不被保证。

7.分区topic

分区topic一种特殊类型的topic，可以被多个broker处理，允许更高的吞吐量，实际是通过在底层拥有 N 个内部主题来实现的，这个 N 的数量就是等于分区的数量，当向分区topic发送消息时，每条消息被路由到其中一个broker上，对应其中一个分区，Pulsar自动处理跨broker的分区分布，一个broker可能有多个分区；

路由模式确定每条消息该发往哪个分区，而订阅模式确定消息传递给哪个消费者；

三种路由模式：

RoundRobinPartition-生产者以轮询的方式将消息发布到所有分区，批量消息作为整体处理，如果消息指定了key，则根据key的hash值分配到对应分区，默认模式；

SinglePartition-生产者将会随机选择一个分区，并发布所有消息到这个分区，如果消息指定了key，则根据key的hash值分配到对应分区；

CustomPartition-使用自定义消息路由器实现来决定特定消息的分区；

可以通过指定路由模式以及消息是否有key来保证消息的顺序。

8.消息保留和过期

默认策略：

立即删除所有已经被消费者确认过的的消息；

以backlog的形式，持久保存所有未被确认的消息；

两个特性：

消息保留让你可以保存consumer确认过的消息；

消息过期让你可以给未被确认的消息设置存活时长（TTL）；

　　

说明：

所有消息保留和过期在namespace层面管理。

9.消息去重

当生产者再次发送同一个消息时，broker知道已经收到这个消息了，所以不会再持久化这个消息；保证一条消息只能在 Pulsar 服务端被持久化一次，能够阻止不必要的消息重复，它保证了即使消息被消费了多次，也只会被保存一次；

可以在namespace或topic层设置。

10.消息延迟

允许消费者能够过一段时间才能消费到这条消息，而不是消息发布后，就马上可以消费到；

Broker 保存消息是不经过任何检查的，当消费者消费一条消息时，如果这条消息是延时消息，那么这条消息会被加入到DelayedDeliveryTracker当中，订阅检查机制会从DelayedDeliveryTracker获取到超时的消息，并交付给消费者。

11.pulsar系统架构

　　

12.客户端

Pulsar提供了基于多种开发语言的客户端API，创建过程如下：

客户端会先和任意一个broker建立连接，发送一个http请求查询topic所在broker，然后和该broker建立一个tcp连接并进行认证和鉴权，通过后，客户端会为该broker创建一个生产者或消费者，当tcp连接断开时，客户端会进行重连，直到成功或超时；

当topic不存在时，如果开启了自动创建，pulsar会自动创建该topic并将其分配给负载最少的broker，如果不允许自动创建则会报错；如果认证和鉴权失败也会报错。

13.Reader接口

在Pulsar中，标准的消费者接口包括订阅topic、处理消息、ack确认；

对于新创建的订阅，默认位于topic的末端，消费者从之后的第一条消息开始读取，对于已经存在的订阅，消费者将从该订阅内最早的未确认消息开始读取，总之，消费者接口是基于消息确认机制来自动管理订阅游标位置；

Pulsar 的 reader 接口允许应用程序手动管理游标，当您使用 reader（而不是消费者）连接 topic 时，需要指定 reader 在连接到该 topic 时从哪条消息开始消费，reader 接口支持的开始位置包括：

1) Topic 中最早的可用消息earliest；

2) Topic 中最新的可用消息latest；

3) 如果你想开始的位置在最早和最新之间， 则需要显示的指定消息ID MessageId；

注意，reader本质上是非持久的，并且不会阻止topic中的数据被删除，因此强烈建议配置数据保留策略，如果topic没有配置足够长的消息保留时间，就会出现消息还没有被读取就被删除的情况。

 

参考 pulsar官方文档 http://pulsar.apache.org/docs/zh-CN/next/concepts-messaging/

标签：订阅,消费者,确认,broker,topic,消息,pulsar,基本概念
来源： https://www.cnblogs.com/zlw-xyz/p/15022878.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。