基于docker搭建pulsar和使用攻略

老A技术联盟

已于 2024-12-10 15:14:16 修改

阅读量1.4k

点赞数 8

文章标签： docker 容器运维

于 2024-12-09 18:09:41 首次发布

本文链接：https://blog.csdn.net/qq_39962403/article/details/144291951

版权

pulsar

Pulsar是一个由yahoo公司于2016年开源的消息中间件，2018年成为Apache的顶级项目

我们先来看一下架构，从架构来看，和其他的消息中间件差不多，都是有消费者，生产者和broker,唯一一点不同的是pulsar的数据存储是存储在BookKeeper中的。
在这里插入图片描述

Producer:消息生产者，将消息发送到broker。
Consumer:消息消费者，从Broker读取消息到客户端，进行消费处理。
Broker: 可以看作是pulsar的server,Producer和Consumer都看作是client.消息处理的节点，pulsar的Broker和其他消息中间件的都不一样，他是无状态的没有存储，所以可以无限制的扩展。
Bookie: 负责所有消息的持久化，这里采用的是Apache Bookeeper。
ZK: 和kafka一样pulsar也是使用zk保存一些元数据，比如配置管理,topic分配，租户等等。
Service Discovery：可以理解为Pulsar中的nginx，只用一个url就可以和整个broker进行打交道，当然也可以使用自己的服务发现。客户端发出的读取，更新或删除主题的初始请求将发送给可能不是处理该主题的 broker 。如果这个 broker 不能处理该主题的请求，broker 将会把该请求重定向到可以处理主题请求的 broker。

安装

接下来我们安装一下，通过UI界面来看一下pulsar。以下是基于docker安装的

下载docker镜像

docker pull apachepulsar/pulsar:latest

启动服务

docker run --name pulsar \
-p 6650:6650 \
-p 8080:8080 \
--mount source=pulsardata,target=/pulsar/data \
--mount source=pulsarconf,target=/pulsar/conf \
-d apachepulsar/pulsar bin/pulsar standalone

6650端口：这是Pulsar Broker的默认二进制协议通信端口。是一个tcp协议。当你需要连接到Pulsar的Broker节点时，通常会使用这个端口。Broker节点是Pulsar的核心组件之一，负责接收和处理消息，以及提供主要的消息传递服务。如果你的应用程序是Pulsar的消息生产者或消费者，并且需要与Pulsar集群的Broker进行通信，那么就会使用6650端口。
8080端口：这是Pulsar Admin服务的默认REST API及Web界面端口。支持的是http协议。当你需要执行管理操作（例如创建或删除租户、命名空间、主题等），或者监控Pulsar集群的健康状况时，通常会使用8080端口。此端口提供了REST API接口以及Web界面，用于管理和监控Pulsar集群。

可视化管理

拉取web可视化管理平台

docker pull apachepulsar/pulsar-manager:latest

生成容器并启动

 
docker run -it \
  --name pulsar-manager \
  -p 9527:9527 -p 7750:7750 \
  --mount source=pulsarmanager,target=/pulsar-manager/pulsar-manager \
  -e SPRING_CONFIGURATION_FILE=/pulsar-manager/pulsar-manager/application.properties \
  apachepulsar/pulsar-manager:latest

9527：这个端口是提供web-ui的端口
7750：提供rest-api接口，比如初始化管理员用户名密码

设置管理员密码

CSRF_TOKEN=$(curl http://localhost:7750/pulsar-manager/csrf-token)
curl \
   -H 'X-XSRF-TOKEN: $CSRF_TOKEN' \
   -H 'Cookie: XSRF-TOKEN=$CSRF_TOKEN;' \
   -H "Content-Type: application/json" \
   -X PUT http://localhost:7750/pulsar-manager/users/superuser \
   -d '{"name": "admin", "password": "apachepulsar", "description": "test", "email": "username@test.org"}'

通过9527访问界面

在这里插入图片描述
pulsar-manager可以管理多个pulsar服务，可以在这里进行配置pulsar的信息。

在这里插入图片描述
我们看一下面板里面的元素

persistent/non-persistentPulsar 提供持久化、非持久化两种主题，如果选择的是非持久化主题的话，所有消息都在内存中保存，如果broker重启，消息将会全部丢失。如果选择的是持久化主题，所有消息都会持久化到磁盘，重启broker，消息也可以正常消费。
tenant顾名思义就是租户，pulsar最开始在雅虎内部是作为全公司使用的中间件使用的，需要给topic指定一些层级，租户就是其中一层，比如这个可以是一个大的部门，例如电商中台租户。
namespace命名空间，可以看作是第二层的层级，比如电商中台下的订单业务组topic消息队列名字

概念了解

生产者

异步发送

我们上面说了send分为async和sync两种模式，但实际上在pulsar内部sync模式也是采用的async模式，在sync模式下模拟回调阻塞，达到同步的效果，这个在kafka中也是采用的这个模式，但是在rocketmq中，所有的send都是真正的同步，都会直接请求到broker。
基于这个模式，在pulsar和kafka中都支持批量发送，在rocketmq中是直接发送，批量发送有什么好处呢？当我们发送的TPS特别高的时候，如果每次发送都直接和broker直连，可能会做很多的重复工作，比如压缩，鉴权，创建链接等等。比如我们发送1000条消息，那么可能会做1000次这个重复的工作，如果是批量发送的话这1000条消息合并成一次请求，相对来说压缩，鉴权这些工作就只需要做一次。
在这里插入图片描述

负载均衡

在消息队列中通常会将topic进行水平扩展，在pulsar和kafka中叫做partition,在rocketmq中叫做queue，本质上都是分区，我们可以将不同分区落在不同的broker上，达到我们水平扩展的效果。
在我们发送的时候可以自己制定选择partition的策略，也可以使用它默认轮训partition策略。当我们选择了partition之后，我们怎么确定哪一个partition对应哪一个broker呢？
在这里插入图片描述

Step1: 我们所有的信息分区映射信息在zk和broker的缓存中都有进行存储。
Step2: 我们通过查询broker，可以获取到分区和broker的关系，并且定时更新。
Step3: 在pulsar中每个分区在发送端的时候都被抽象成为一个单独的Producer,这个和kafka,rocketmq都不一样，在kafka里面大概就是选择了partition之后然后再去找partition对应的broker地址，然后进行发送。pulsar将每一个partition都封装成Producer，再代码实现上就不需要去关注他具体对应的是哪个broker,所有的逻辑都在producer这个代码里面，整体来说比较干净。