ContacteOrdre, Clau i Particionat a EventHub
Navegació
| ⬅️ Paral·lelisme | Guia-de-disseny-de-Topics-i-schemas ➡️ |
|---|
Quan he de consultar aquest document?
Consulta aquest document quan:
- el cas d’ús requereix ordre funcional,
- has de definir o revisar la clau del missatge,
- cal equilibrar ordre, paral·lelisme i rendiment.
Aquest document complementa les decisions de particionat.
Ordre, Clau i Particionat a EventHub
Canigó – Estàndard tècnic per a aplicacions
Aquesta pàgina explica com dissenyar correctament el particionat d’un topic per garantir ordre, rendiment i escalabilitat.
1. Regla fonamental de Kafka
Kafka només garanteix l’ordre dins d’una partició.
❌ No existeix ordre global a nivell de topic.
2. Ús de la clau del missatge
La clau:
- Determina la partició.
- És obligatòria quan es requereix ordre per entitat.
Regla:
- Mateixa clau → mateixa partició → ordre garantit
Exemples de bones claus (cardinalitat alta; reparteixen bé i garanteixen ordre per entitat):
idPacient— ordre dels esdeveniments per pacient.idExpedient— ordre per expedient assistencial.idEpisodi— ordre per episodi.
Exemples de males claus (eviteu-les):
codiCentreocodiHospital— cardinalitat baixa: poques particions actives i càrrega desequilibrada.estatotipus— molt pocs valors: gairebé tots els missatges cauen a la mateixa partició.- Un camp que canvia durant la vida de l’entitat: repartiria els missatges d’una mateixa entitat entre particions diferents i trencaria l’ordre.
3. Errors habituals
- No utilitzar clau quan hi ha dependència temporal.
- Sobre‑particionar “per si de cas”.
- Infra‑particionar i bloquejar el creixement.
- Assignar particions de forma fixa al consumidor.
4. Validació obligatòria
La clau i el nombre de particions:
- Han de declarar‑se a la Fitxa de Topic.
- Són validats per l’Oficina EventHub.
Vegeu també
Data d'actualització:
01-01-0001