Análise do princípio do pulsar
[TOC]
prefácio
Com a evolução dos tempos e as mudanças tecnológicas, novos middlewares de mensagens estão constantemente aparecendo e sendo usados. Este artigo discute e analisa as características do pulsar. Antes de ler este artigo, é recomendável aprender e usar as filas de mensagens gerais do setor (parte do o conteúdo é citado no artigo). Documentação da Internet)
fundo
- O que é pulasr: um middleware de mensagem para um modelo Pub/Sub
Pulsar 2021 desenvolvido dentro do Yahoo
Código aberto e doado ao Apache em 2016
Projeto de alto nível do Apache em 2018
Recursos
- Uma única instância do Pulsar oferece suporte nativo a vários clusters e pode concluir perfeitamente a replicação de mensagens entre clusters em salas de computadores
- Latência de publicação extremamente baixa e latência de ponta a ponta
- Escala perfeitamente para mais de um milhão de tópicos
- API de cliente simples, suporta Java, Go, Python e C++
- O tópico oferece suporte a vários modelos de assinatura (assinatura exclusiva, assinatura compartilhada, assinatura de failover)
- Entrega de mensagens garantida por meio do mecanismo de armazenamento de mensagens persistente fornecido pelo Apache BookKeeper
...
Conceitos Básicos
A estrutura do pulsar consiste em vários conteúdos centrais
Analisamos a estrutura acima
- Produtor : O produtor da mensagem, responsável por publicar a mensagem no tópico
- Consumidor : o consumidor da mensagem, responsável por assinar mensagens do tópico
- Broker : Camada de serviço sem estado, responsável por receber e entregar mensagens, balanceamento de carga de cluster, etc. Broker não persiste metadados, então pode ficar online e offline rapidamente
- Apache BookKeeper : Uma camada de persistência com estado que consiste em um conjunto de nós de armazenamento Bookie que podem armazenar mensagens de forma persistente
Tópico é o nome de uma categoria na qual as mensagens podem ser armazenadas e publicadas. Produtores escrevem mensagens para tópicos, consumidores leem mensagens de tópicos
Princípio de implementação
- Através da introdução acima, temos uma compreensão geral do pulasr, mas como a mensagem é produzida? Como é armazenado? Como o downstream o consome?
broker和bookie
这里就不得聊一聊pulsar中比较有意思的broker和bookie了，我们在使用kafka的时候，也经常会提到broker的概念，在kafka中broker扮演的角色作用主要是集群中的一个实例节点，但在pulsar中大不相同
broker是一个无状态组件，负责处理和负载均衡 producer 发出的消息，并将这些消息分派给 consumer
可以看到broker只是一个组件，并不负责存储消息，且是无状态的，便于快速上下线，更适合于云原生场景
bookie是BookKeeper集群中的存储节点，负责存储消息和游标
这里的设计，将 Broker 和 bookie 相互独立，方便实现独立的扩展以及独立的容错性 对于broker，在高负载场景下可以更方便的添加新节点 对于bookie，在存储不足时可以快速新增节点来平摊存储负载 在这种结构下消息存储分布均匀，单个分区数据量突出不会使整个集群出现木桶效应
生产到消费
有了以上的理解，消息的生产链路我们大概也能描绘出来
- Producer 生产消息
- 消息发送指定Topic
- 根据策略选择对应broker节点和Partition
- broker接收消息后，追加写入bookie分区下的segment分片
- 下游消费者拉取消息，按照指定模式消费
其中，生产模式分为 同步 和 异步
消费模式分为
- 独占(Exclusive) : 只能有一个消费者
- 灾备(Failover) : 支持多个消费者但同时只能一个消费，当上一消费者异常后按顺序依次执行消费
- 共享(Shared) : 多消费者共享消费，同一消息只会被一个消费者唯一消费
- KEY 共享模式(Key_Shared) : 消息根据key进行分发，同一key保证由同一消费者消费（
这样保证了同一KEY下的有序性）
延时队列
pulsar的延时队列，是另一个非常重要的特性
延时队列 ： 生产消息时指定时间，消息在等待特定时间后再被消费，pulsar支持秒级延迟消息投递
这个特性比较有意思，利用这个功能我们可以做一些额外的事，或者取代原先的定时任务 比如错误重试，订单取消，相较于定时任务，使用延时队列
- 更快
- 更稳定
- 效率更高
实现
那，延时队列是如何实现的？
结合上图可以简单看一下，pulsar与内存之中维护了一个delayed message tracker，它的作用即是存储所有的延时消息，底层存储结构为小顶堆，当然，其中的index指向了具体的消息内容，包括Timestamp、LedgerID、EntryID等
每次消费者拉取数据时，都会优先检查延时队列中的内容，如果发现堆顶的消息已经达到过期时间，那么即可消费该消息
挑战
那么，通过对延时队列的了解，可能会遇到什么问题呢？
- delayed index 队列受内存限制 ： 显然，你不能不限时间、不限数量的存储所有的延时消息
- delayed index 队列重建时间开销 ： 假如pulsar服务发生了重启或其他异常情况，必然要面临延时队列重建的问题
还会不会有其他问题呢？问题又是否可以优化？等待思考
业界组件对比与应用前景
说了那么多，我到底要不要用pulsar？在什么情况下应该用它？
对比
我们先来看看业界通用组件的对比
| 分类 | 功能 | Kafka | Pulsar | RocketMQ | Coelho MQ |
|---|---|---|---|---|---|
| Recursos | Modo push-pull de consumo | puxar | puxar + empurrar | puxar | Empurre |
| fila de atraso | 不支持 |
Apoio, suporte | Apoio, suporte | Apoio, suporte | |
| fila de letras mortas | 不支持 |
Apoio, suporte | Apoio, suporte | Apoio, suporte | |
| retorno de mensagem | Apoio, suporte | Apoio, suporte | Apoio, suporte | 不支持 |
|
| persistência da mensagem | Apoio, suporte | Apoio, suporte | Apoio, suporte | Apoio, suporte | |
| mecanismo de confirmação de mensagem | Desvio | Deslocamento+Único | Desvio | Solteiro | |
| Padrão de consumo | Modo de transmissão | Modo de fluxo + modo de fila | Modo de transmissão + modo de cluster | modo de fila | |
| atuação | Taxa de transferência de uma única máquina | 605 MB/s | 605 MB/s | 605 MB/s | 38 MB/s |
| atraso de mensagem | 5ms | 5ms | nível ms | microssegundo | |
| Operação e manutenção | Alta disponibilidade | Arquitetura Distribuída | Arquitetura Distribuída | arquitetura mestre-escravo | arquitetura mestre-escravo |
inscrição
- Cenários de uso de middleware de mensagem comum
- Se a solicitação de serviço for anormal, a solicitação anormal precisa ser colocada em uma fila separada e tentada novamente após 5 minutos;
- Se o usuário comprar o produto, mas ele estiver em estado não pago, o usuário precisa ser lembrado de pagar regularmente, e o pedido será fechado se o tempo for excedido;
- Entrevista ou agendamento de reunião, meia hora antes do início da entrevista ou reunião, enviar notificação para lembrar novamente;
Resumir
Como uma nova geração de filas de mensagens, o pulsar tem muitas novas funções, que podem ser usadas para resolver problemas de negócios em cenários específicos. Atualmente, o principal middleware de mensagens usado por nossa equipe ainda é o kafka, mas, ao mesmo tempo, o pulsar pode ser usado para nova tentativa de falha, cancelamento de tempo, etc. Cenas
Comparado com kafka, a experiência da comunidade pulsar não é tão rica no momento. Embora traga novas funções, também tem potenciais perigos ocultos e instabilidade. Se for 不需要使用到新特性assim, escolher kafka pode ser uma escolha melhor.
Documentação relacionada:
endereço do github: github.com/apache/puls…
site oficial do pulsar: pulsar.apache.org/
Documentação da Tencent Cloud: cloud.tencent.com/document/pr…