ContacteParal·lelisme i Escalabilitat a EventHub
Navegació
| ⬅️ Decisió: ksqlDB vs Flink | ➡️ Ordre, Clau i Particionat |
|---|
Quan he de consultar aquesta guia?
Consulta aquesta guia quan:
- dissenyes consumidors amb requisits de rendiment,
- analitzes problemes de throughput,
- valores canvis en paral·lelisme o particions.
Aquest document orienta el disseny, no substitueix l’estàndard de particionat.
Paral·lelisme i Escalabilitat a EventHub
Canigó – Guia pràctica
Aquesta pàgina explica com escalar correctament el consum d’esdeveniments.
1. Paral·lelisme a Kafka
- Un consumer group consumeix en paral·lel fins al nombre de particions.
- Més instàncies ≠ més rendiment si no hi ha prou particions.
2. Regles clau per a consumidors
- ❌ No assumir assignació fixa de particions.
- ✅ Delegar sempre el rebalanceig al clúster.
- ✅ Dissenyar consumidors idempotents.
3. Quan augmentar particions
Només quan:
- Se supera el throughput suportat.
- Es necessita més paral·lelisme efectiu.
⚠️ Incrementar particions és un canvi governat.
⚠️ Impacte sobre consumidors existents quan s’incrementen particions:
En topics amb clau, incrementar el nombre de particions redistribueix els missatges futurs entre les noves particions. Missatges amb la mateixa clau que fins ara anaven a la partició X poden anar a una partició diferent després del canvi, trencant la garantia d’ordre per clau per als consumidors actius.
Quan es planifiqui un increment de particions en un topic amb clau, cal coordinar l’aturada i el reinici dels consumidors que depenguin de l’ordre per clau durant la finestra de canvi.
4. Guia orientativa de dimensionament (PRODUCCIÓ)
Xifres orientatives, basades en la guia de dimensionament de Confluent i ajustades al clúster de PRODUCCIÓ (6 brokers, RF 3, emmagatzematge per nivells). El dimensionament final es mesura al vostre entorn i el valida l’Oficina EventHub a la fitxa.
Fórmula base (Confluent). Nombre mínim de particions = max(t/p, t/c), on:
t= throughput objectiu del topic (MB/s),p= throughput per partició en producció,c= throughput per partició en consum.
Punt de partida (si no hi ha mesures). Una sola partició pot produir a desenes de MB/s, però depèn del batching, la compressió, l’ack i el factor de rèplica; useu un valor conservador. Si no teniu mesures, partiu de p ≈ 10 MB/s per partició i mesureu al vostre maquinari.
Consumidors. Dins d’un grup, com a màxim un consumidor per partició (els que sobren queden inactius): particions ≥ nombre de consumidors en paral·lel. El paral·lelisme d’una aplicació de stream processing (ksqlDB/Flink) queda igualment acotat pel nombre de particions del topic d’entrada.
Marge de creixement. Multipliqueu el resultat per 1,5–2, especialment en topics amb clau.
Exemples orientatius:
| Volum | Càlcul | Particions suggerides |
|---|---|---|
Baix (~1 MB/s, p. ex. episodi-alta) |
max(1/10) → 1 | 1–3 |
| Mitjà (~10 MB/s) | max(10/10) → 1, amb marge i consumidors | 3–6 |
| Alt (~50 MB/s, 6 consumidors) | max(50/10)=5 per throughput, però ≥6 per consumidors | 6 (marge 8–12) |
Sostre pràctic. Per a un clúster de 6 brokers, fins a ~2× brokers (≈12 particions) en topics d’alt volum. Eviteu sobre-particionar «per si de cas»: té cost (descriptors de fitxer, eleccions de líder, latència).
⚠️ Topics amb clau: augmentar el nombre de particions trenca el mapatge clau→partició. Dimensioneu bé des del principi i no amplieu en calent (vegeu l’avís de la secció 3).
5. Validació
- Els canvis de particions requereixen:
- actualització de la fitxa,
- validació,
- CRQ en PRE/PRO.