客户端

Pulsar公开了一个带有Java、Go、Python、c++和c#语言绑定的客户端API。客户端API优化并封装了Pulsar的客户端代理通信协议，并公开了一个简单而直观的API供应用程序使用。

在幕后，目前官方的Pulsar客户端库支持透明的重连接和/或连接故障转移到代理，消息排队直到得到代理的确认，以及启发式操作，如连接重试和回退。

客户端设置阶段

在应用程序创建生产者/消费者之前，Pulsar客户端库需要启动一个设置阶段，包括两个步骤:

• 客户机试图通过向代理发送HTTP查找请求来确定主题的所有者。该请求可以到达一个活动的代理，通过查看(缓存的)zookeeper元数据，该代理知道谁在为主题服务，或者，如果没有人为它服务，尝试将它分配给负载最少的Brokers。
• 一旦客户端库有了Brokers地址，它就创建一个TCP连接(或重用池中的现有连接)并对其进行身份验证。在这个连接中，客户机和代理交换来自自定义协议的二进制命令。此时，客户机向代理发送创建生产者/消费者的命令，代理在验证了授权策略后将遵守该命令。

每当TCP连接断开时，客户端立即重新启动这个设置阶段，并不断尝试指数回退，以重新建立生产者或消费者，直到操作成功。

Reader interface

在Pulsar中，“标准”用户接口包括使用用户侦听主题、处理传入消息，并在处理这些消息时最终确认这些消息。每当创建一个新的订阅时，它最初会被放置在主题的末尾(默认情况下)，与该订阅关联的消费者开始读取随后创建的第一条消息。每当使用者使用已存在的订阅连接到一个主题时，它就开始从该订阅中解压缩的最早消息中读取消息。总之，使用消费者接口，订阅

Pulsar的reader接口使应用程序能够手动管理游标。当使用阅读器连接到主题时(而不是使用者)，需要指定阅读器连接到主题时从哪个消息开始读取。当连接到一个主题时，阅读器界面使你可以这样开始:

• earliest
• latest
• 自选择message id

与订阅/消费者不同，reader在本质上是不可持久的，并且不会防止主题中的数据被删除，因此强烈建议配置数据保留。