Saltar a contenido

Zeebe Broker

Motor distribuido de orquestacion de workflows que constituye el nucleo de Camunda 8. Procesa comandos BPMN de forma determinista mediante un modelo de actor single-threaded por particion, persiste estado en RocksDB y replica el log de eventos via protocolo Raft.

Contexto

El broker es el componente central de la arquitectura Camunda 8. Toda instancia de proceso, job, timer, message y signal pasa por el broker. No ejecuta logica de negocio directamente — su rol es orquestar: decidir que paso sigue, asignar jobs a workers externos, y garantizar consistencia del estado del workflow.

Rol en la arquitectura

Zeebe Broker es un cluster de nodos que:

  • Recibe comandos desde el entities/zeebe-gateway (crear instancia, completar job, publicar mensaje, etc.)
  • Procesa esos comandos contra el estado actual del workflow
  • Produce eventos que representan los cambios de estado
  • Replica esos eventos a los demas nodos del cluster para tolerancia a fallos
  • Exporta eventos a sistemas externos (Elasticsearch/OpenSearch) via concepts/exporter-system

Hosting de particiones

El espacio de datos se divide en particiones (ver concepts/partitioning). Cada broker puede hostear multiples particiones simultaneamente:

  • Para cada particion, un broker es leader (procesa escrituras) o follower (replica pasivamente)
  • El leader se elige mediante concepts/raft-consensus — si el leader cae, un follower toma el control
  • La distribucion de particiones entre brokers se configura al desplegar el cluster (partitionCount, replicationFactor, clusterSize)
  • Un broker con 3 particiones puede ser leader de la particion 1, follower de la 2 y leader de la 3

Este modelo permite escalar horizontalmente agregando brokers y redistribuyendo particiones.

Procesamiento de comandos: StreamProcessor

Cada particion tiene un StreamProcessor que opera como un actor single-threaded (ver concepts/stream-processing):

  • Los comandos entrantes se escriben en el log append-only
  • El StreamProcessor los lee secuencialmente y los procesa uno a uno
  • Cada comando produce cero o mas eventos (patron concepts/command-sourcing)
  • El procesamiento es determinista: dado el mismo log, se reconstruye el mismo estado
  • No hay locks ni concurrencia dentro de una particion — el modelo single-threaded elimina race conditions

El StreamProcessor delega a procesadores especificos segun el tipo de record: ProcessInstanceProcessor, JobProcessor, MessageProcessor, TimerProcessor, etc.

Estado en RocksDB

El estado de cada particion se persiste en una instancia local de RocksDB (ver concepts/rocksdb-state-store):

  • 142+ column families organizan los datos: una por cada tipo de entidad y sus indices
  • Column families tipicas: PROCESS_INSTANCE, JOB, MESSAGE, TIMER, VARIABLE, ELEMENT_INSTANCE
  • El state es una proyeccion materializada del log — se puede reconstruir replaying el log desde cero
  • RocksDB provee snapshots consistentes para backups sin detener el procesamiento
  • Las column families funcionan como tablas logicas con prefijos de key para particion/scope

Log append-only replicado

El log es la fuente de verdad del sistema:

  • Cada comando y evento se serializa y appende al log de la particion
  • El log se replica a los followers via concepts/raft-consensus antes de confirmar al cliente
  • Solo cuando la mayoria de replicas confirman (quorum), el comando se considera committed
  • El log permite recovery: un nodo que se reinicia replays el log para reconstruir su estado en RocksDB
  • La compactacion del log (snapshotting) evita crecimiento infinito

No ejecuta logica de negocio

Distincion clave: el broker orquesta pero no ejecuta:

  • Los service tasks se delegan a job workers externos via el patron poll-and-complete
  • Los script tasks y expressions se evaluan en el broker (FEEL engine), pero la logica de negocio real vive fuera
  • Los entities/connectors son job workers especializados que el broker trata como cualquier otro worker
  • Esta separacion permite que los workers escalen independientemente y fallen sin afectar al broker

Exporters

Los exporters son plugins del broker que transmiten eventos a sistemas externos:

  • ElasticsearchExporter / OpenSearchExporter alimentan entities/operate, entities/tasklist y entities/optimize
  • CamundaExporter es la variante moderna que escribe indices estructurados para las webapps
  • Los exporters leen del log de forma asincrona — no bloquean el procesamiento de comandos
  • Cada exporter mantiene su propia posicion en el log (ver concepts/exporter-system)

Relaciones

Abierto / gaps

  • Detalles del mecanismo de rebalanceo de particiones cuando se agrega o remueve un broker
  • Comportamiento exacto del broker durante un split-brain
  • Metricas de performance del StreamProcessor bajo carga (throughput por particion)