Al actualizar la especificación de tráfico de una instancia de ApsaraMQ for Kafka, el clúster puede escalar horizontalmente mediante la adición de brokers. Tras este escalado, las particiones de los temas existentes permanecen en los brokers originales y están sujetas a los límites de tráfico previos a la actualización. Reequilibre el tráfico de temas para redistribuir las particiones entre todos los brokers, incluidos los nuevos, de modo que los temas existentes puedan aprovechar la capacidad adicional.
Los temas creados después del escalado se distribuyen automáticamente entre todos los brokers y no están sujetos a los límites de tráfico previos a la actualización.
En las instancias serverless de ApsaraMQ for Kafka, el reequilibrio de temas se activa automáticamente. No se requiere ninguna acción manual.
Requisitos previos
Antes de empezar, asegúrese de contar con lo siguiente:
Una instancia de ApsaraMQ for Kafka en estado Running (Pending Rebalancing)
Una instancia entra en estado Running (Pending Rebalancing) tras un escalado horizontal del clúster. Para obtener más información sobre cómo actualizar las especificaciones de tráfico y las condiciones que activan el escalado, consulte Upgrade instance configurations.
Reequilibrar el tráfico de temas desde la consola
Inicie sesión en la consola de ApsaraMQ for Kafka.
En la sección Resource Distribution de la página Overview, seleccione la región donde reside su instancia.
En la página Instances, haga clic en el nombre de la instancia que desea gestionar.
En la página Instance Details, haga clic en Rebalance Topic Traffic en la esquina superior derecha de la sección Overview.
En el panel Rebalance Topic Traffic for Instance, seleccione un Traffic Rebalancing Method. Para obtener detalles sobre cada método, consulte Rebalancing methods.
Tras seleccionar un método, todos los temas de la instancia pasan al estado Pending Rebalancing. Compruebe el estado del tema en la columna Status de la página Topics.
Resultado
Una vez reequilibrado el tráfico de temas, todos los temas vuelven al estado Running. Compruebe el estado del tema en la columna Status de la página Topics.
Métodos de reequilibrio
Seleccione un método de reequilibrio según los requisitos de su carga de trabajo. A continuación, la tabla resume los métodos disponibles:
|
Método |
Duración |
Cambio en el número de particiones |
Impacto en el orden de los mensajes |
|
Migrate Data from Partitions of All Topics (Recommended) (recomendado) |
De segundos (almacenamiento en la nube) a horas (almacenamiento local) |
No |
No |
|
Add Partitions to All Topics |
Segundos |
Sí |
Sí |
|
Do Not Rebalance (Not Recommended) |
Inmediato |
No |
No |
Migrar datos de las particiones de todos los temas (recomendado)
Redistribuye las particiones existentes entre todos los brokers sin modificar el número de particiones. Este es el método recomendado para todos los escenarios de escalado horizontal.
El comportamiento depende del motor de almacenamiento:
|
Motor de almacenamiento |
Mecanismo |
Impacto |
Duración |
|
Almacenamiento en la nube |
Modifica la asignación de particiones a brokers sin migrar datos. |
No se genera tráfico interno temporal. |
Segundos. Cada tema tarda aproximadamente 30 segundos. |
|
Almacenamiento local |
Utiliza la herramienta |
Se genera tráfico interno temporal durante la migración. |
De minutos a horas, según el volumen de datos. En conjuntos de datos grandes, la migración puede tardar varias horas o más. |
Solo puede especificar almacenamiento local como motor de almacenamiento al crear temas en instancias Professional Edition. Para las migraciones con almacenamiento local, ejecute el reequilibrio fuera de las horas pico para minimizar el impacto del tráfico interno temporal en sus cargas de trabajo.
Agregar particiones a todos los temas
Agrega nuevas particiones en los nuevos brokers para todos los temas existentes. Es el método más rápido, pero modifica el número total de particiones.
Duración: Segundos.
Impacto:
Los nuevos mensajes en las particiones agregadas pueden llegar desordenados.
El número total de particiones aumenta. Si su cliente no detecta automáticamente las nuevas particiones, reinicie el cliente o actualice su código. Esto aplica a escenarios de extracción, transformación y carga (ETL), así como a casos donde los mensajes se envían o consumen desde particiones específicas.
Más indicado para: Cargas de trabajo donde no se requiere orden por partición, no se especifica una partición destino para la producción de mensajes y el modo de consumo es por suscripción.
No reequilibrar
No se realiza ninguna acción. Los temas existentes permanecen en los brokers anteriores al escalado. Los temas creados después del escalado se distribuyen uniformemente entre todos los brokers.
Duración: Entra en vigor de inmediato.
Impacto:
Los temas existentes siguen sujetos a la especificación de tráfico adquirida antes del escalado.
Si el volumen de tráfico de los temas existentes es alto, el tráfico entre brokers puede quedar desbalanceado.
Recomendado cuando: El tráfico de los temas existentes es bajo y poco probable que aumente, o cuando la mayor parte del tráfico se dirige a nuevos temas creados tras el escalado.
Omitir el reequilibrio implica que los temas originales no podrán utilizar la capacidad actualizada.
Notas de uso
Mientras una instancia se encuentra en estado Running (Pending Rebalancing):
Puede continuar enviando y recibiendo mensajes.
No puede crear recursos como temas ni grupos de consumidores hasta que finalice el reequilibrio.
El reequilibrio es opcional. Si no necesita que los temas originales utilicen la capacidad actualizada, seleccione Do Not Rebalance. Para más detalles, consulte No reequilibrar.