大数据平台组件部署说明1.安装前准备JDKopenlookeng和pulsar要求JDK1.8+，参考附录9.1安装教程。Zookeeper集群pulsar运行需要zookeeper集群进行资源调度服务，参考附录9.2安装教程。MySQL默认推荐使用MySQL，参考附录9.3节MySQL的安装说明，如已经安装请跳过。如果你使用其他类型的数据库，请参考对应厂商说明帮助手册进行安装。SSH免密登录Hadoop集群要求Master节点可以免密登录到其他节点，参考附录9.4安装教程2.安装说明本手册以在linuxx86_64环境下为例进行安装过程说明。创建大数据平台组件安装根目录，指定PATH为实际路
ApachePulsar是Apache软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体。该系统源于Yahoo，最初在Yahoo内部开发和部署，支持Yahoo应用服务平台140万个主题，日处理超过1000亿条消息。Pulsar于2017年由Yahoo开源并捐赠给Apache软件基金会进行孵化，2018年成为Apache软件基金会顶级项目。滴滴大数据于2021年01月开始调研Pulsar，建立内部Pulsar2.7版本分支；并于2021年08月04日，正式上线了第一个Pulsar数据通道同步任务集群，主要为数据开发平台-同步中心产品提供服务，涉及Log->E
文章目录一、各消息队列的简介1.1、ActiveMQ1.2、Kafka1.3、RabbitMQ1.4、RocketMQ1.5、Pulsar二、AMQP协议三、消息队列对比四、消息队列选择建议公众号：MCNU云原生，欢迎搜索关注，更多干货，第一时间掌握！消息队列是当代分布式系统架构中非常重要的一部分，在应用解耦、流量削峰、异步通信等方面有非常多的应用场景。目前最为我们所熟知的消息队列有：ActiveMQ、Kafka、RabbitMQ、Pulsar和RocketMQ，他们都有哪些优势和劣势，我们应该如何选择呢？相信这是摆在很多开发者面前的问题。本文试图对这些广为人知的消息队列进行各方面的比对，为开
升级后所遇到的问题先来个欲扬先抑，聊聊升级后所碰到的问题吧。其中有两个问题我们感知比较明显，特别是第一个。topic被删除我们在上个月某天凌晨从 2.11.2 升级到 3.0.1 之后，进行了上一篇文章中所提到的功能性测试，发现没什么问题，觉得一切都还挺顺利的，半个小时搞定后就下班了。结果哪知道第二天是被电话叫醒的，有部分业务反馈业务重启之后就无法连接到Pulsar了。图片最终定位是topic被删除了。其中的细节还蛮多的，修复过程也是一波三折，后面我会单独写一篇文章来详细梳理这个过程。在这个issue和PR中有详细的描述：https://github.com/apache/pulsar/iss
本文分享自华为云社区《Pulsar消息积压topic级别策略老化的两种方案》，作者：张俭。Pulsar像大多数消息中间件一样,支持按时间和大小对消息积压进行老化。但是默认的策略只能在namespace级别配置。本文将介绍如何在topic级别实现老化策略的两种方案。方案一：开启TopicLevelPolicy来实现默认的策略配置通过在Zookeeper上配置对应的策略，可以通过./pulsarzookeeper-shell命令来登录zookeeper集群查询。但是如果将这一实现方式扩展到topic级别，将会产生大量的（百万、千万级别）的ZooKeeper节点，这对于ZooKeeper集群来说几乎
KafkaApacheKafka实现了一个经典的分布式系统。为了处理一个分区的数据，Kafka将整个分区数据存储在每个节点（即Broker）中，该节点负责计算和存储。一个分区可以有多个副本，相应的副本存储在分区leader和in-sync副本（ISR）中。这种突破性的分布式处理方法有效地解决了Kafka诞生时的一系列挑战，如削峰和异步通信。它具有高性能（高吞吐量、低延迟）和数据持久性，满足了大数据时代的数据迁移需求。多年来，由于蓬勃发展的开源社区和支持该项目的商业公司，一个全面的Kafka生态系统已经形成。许多大大小小的企业都支持Kafka，这充分说明了它作为一种产品的成熟性。尽管Kafka的
本文分享自华为云社区《Pulsar消息积压topic级别策略老化的两种方案》，作者：张俭。Pulsar像大多数消息中间件一样,支持按时间和大小对消息积压进行老化。但是默认的策略只能在namespace级别配置。本文将介绍如何在topic级别实现老化策略的两种方案。方案一：开启TopicLevelPolicy来实现默认的策略配置通过在Zookeeper上配置对应的策略，可以通过./pulsarzookeeper-shell命令来登录zookeeper集群查询。但是如果将这一实现方式扩展到topic级别，将会产生大量的（百万、千万级别）的ZooKeeper节点，这对于ZooKeeper集群来说几乎
背景之前写过一篇文章VictoriaLogs：一款超低占用的ElasticSearch替代方案讲到了我们使用 Victorialogs 来存储Pulsar消息队列的消息trace信息。图片而其中的关键的埋点信息是通过Pulsar的 BrokerInterceptor 实现的，后面就有朋友咨询这块代码是否开源，目前是没有开源的，不过借此机会可以聊聊如何实现一个 BrokerInterceptor 插件，当前还没有相关的介绍文档。其实当时我在找 BrokerInterceptor 的相关资料时就发现官方并没有提供对应的开发文档。只有一个additionalservlet的开发文档，而 Broker
背景最近在测试将 Pulsar 2.11.2升级到 3.0.1的过程中碰到一个鉴权问题，正好借着这个问题充分了解下 Pulsar 的鉴权机制是如何运转的。Pulsar支持 Namespace/Topic 级别的鉴权，在生产环境中往往会使用 topic 级别的鉴权，从而防止消息泄露或者其他因为权限管控不严格而导致的问题。图片我们会在创建 topic 的时候为 topic 绑定一个应用，这样就只能由这个应用发送消息，其他的应用尝试发送消息的时候会遇到401鉴权的异常。同理，对于订阅者也可以关联指定的应用，从而使得只有规定的应用可以消费消息。鉴权流程以上的两个功能本质上都是通过 Pulsar 的 a
前言对于pulsar的特性以及优异,这里不多讲解,直接上干货,主要讲一下Pulsar的docker部署,生产者/消费者几种不同模式,以及Topic的使用规则复制代码Docker部署pulsardockerrun-it-p80:80-p8080:8080-p6650:6650-dapachepulsar/pulsar-standalone复制代码部署问题因为我用的是腾讯云最基础的服务器,在执行docker命令后,发现Pulsar会启动失败或启动不久便停止,查看日志发现是内存顶不住复制代码查看官网Pulsar默认启动是2g,因此把启动配置修改成机器支持的即可;dockerexec-itpulsar
