Pular para o conteúdo
thiagoetipadrões

Contatos

apps/messaging-streaming/point-to-point

053 · Comunicação & Mensageria · ≈ 6 min de estudo

Point-to-Point

Cada mensagem enfileirada é processada por exatamente um worker — sem fan-out, sem duplicação. Garante exclusividade de processamento mesmo com múltiplos workers concorrendo pela fila.

passos
6
arquivos
7
teste
1
tecnologias
5
Infraestrutura realTypeScriptBunRedisBullMQDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

O serviço de transferências recebe picos (início do dia, fim do mês). Cada transferência vira um job numa fila de liquidação; um grupo de workers compete pelos jobs e cada transferência é liquidada por exatamente um deles. Se um worker cai no meio, o job volta e outro assume — e o razão não move o dinheiro duas vezes.

Planta

Sequência
8/8
add TRF-001 (jobId transfer-TRF-001)1add TRF-003 de novo: mesmo jobId, mesmo job2TRF-001 (só para um worker)3TRF-0034Lua: marcador + débito + crédito5Lua: marcador + débito + crédito6TED-006 acima do limite7UnrecoverableError: direto para failed, sem retry8ProdutorFila transfer-settlementworker-aworker-bRazão Redis
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Uma fila, um único consumidor por mensagem.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

jobId+1
UnrecoverableError+1
  1. 01

    O produtor enfileira cada transferência com jobId = id da transferência: enfileirar de novo a mesma transferência é o mesmo job

  2. 02

    Vários workers consomem a mesma fila; o BullMQ entrega cada job a um worker só, com lock renovado enquanto roda

  3. 03

    A liquidação é um script LuaMarcador de liquidada, débito e crédito no mesmo passo — job reexecutado encontra o marcador e não move nada

  4. 04

    Falha transitória → retry com backoff exponencial e jitter (3 tentativas)

  5. 05

    TED acima do limite diário → UnrecoverableError: vai direto ao conjunto failed, sem gastar tentativas

  6. 06

    removeOnComplete e removeOnFail limitam o crescimento do Redis; o conjunto failed é a DLQ

apps/messaging-streaming/point-to-point

7 arquivos

src/

  • queue_transfer.tsFila compartilhada, conexão do Bun para o BullMQ, jobId de negócio e política de retry
  • settlement_transfer.tsRegra do limite de TED e liquidação idempotente em Lua no razão
  • worker_transfer.tsWorker que compete pela fila e registra quem liquidou
  • config_transfer.tsVariáveis de ambiente validadas no boot
  • worker_transfer.test.tstesteIntegração com Redis real: dois workers sem liquidação dupla, enfileiramento repetido, reexecução idempotente, limite do TED e retry transitório
  • demo.tsdemoDois workers dividem seis transferências, uma enfileirada duas vezes e uma recusada

./

  • docker.shinfraSobe o Redis 7 com AOF e noeviction na porta 6379

Executar · com Docker

  1. ./docker.sh up# sobe Redis
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
Redis

Relações

Onde ele se encaixa

Mapa
  1. Point-to-Point
  • Combina com5
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Point-to-point × Publish-subscribe

Aspecto Point-to-point Publish-subscribe
Quem recebe Um consumidor por mensagem Todo assinante recebe cópia
Escala Mais workers dividem a carga Mais assinantes multiplicam o trabalho
Uso Liquidar, cobrar, emitir — fazer uma vez Notificar, auditar, projetar — todos precisam saber

Teste rápido

Qual destes combina com Point-to-Point?

Próximo projeto · Comunicação & MensageriaDead-Letter Queue (DLQ)
Esc

↑ ↓ navegarEnter abrir191 resultados