Compartir a través de

Captura previa de mensajes de Azure Service Bus

  • Artículo

La característica Captura previa captura los mensajes en segundo plano en un búfer de captura previa local hasta el recuento de capturas previas. Los mensajes se sirven desde el búfer. Según sucede, el espacio se libera en el búfer y el receptor capturará previamente más en segundo plano.

Para habilitar la característica de captura previa, establezca el recuento de captura previa del cliente de cola o suscripción en un número mayor que cero. Si se establece el valor en cero, se desactivará la captura previa. Si hay mensajes en el búfer de captura previa después de desactivar la característica, la aplicación recibe esos mensajes del búfer primero y, a continuación, va al servicio.

Establezca la propiedad prefetch count en los objetos ServiceBusReceiverOptions y ServiceBusProcessorOptions.

Nota

El SDK de Javascript no admite la característica Captura previa.

Aunque los mensajes están disponibles en el búfer de captura previa, las llamadas de recepción subsiguientes se realizan directamente desde el búfer. Este se repone en segundo plano a medida que haya espacio disponible. Si no hay ningún mensaje disponible para la entrega, la operación de recepción vacía el búfer y, después, lo espera o bloquea, como esté previsto.

¿Por qué la captura previa no es la opción predeterminada?

La captura previa acelera el flujo de mensajes al hacer que el mensaje esté fácilmente disponible para la recuperación local antes de que la aplicación lo solicite. Esta ganancia de rendimiento es el resultado de una compensación que el autor de la aplicación debe hacer explícitamente.

Cuando usted usa el modo de recibir y eliminar, todos los mensajes que son adquiridos en el buffer de prefetch ya no están disponibles en la cola. Los mensajes permanecen solo en el búfer de captura previa en memoria hasta que se reciben en la aplicación. Si la aplicación finaliza antes de que se reciban los mensajes en la aplicación, estos no se pueden recuperar (se pierden).

Cuando usted usa el modo de recepción peek lock, los mensajes buscados en el buffer prefetch son adquiridos en el buffer en un estado bloqueado. El temporizador de bloqueo se inicia desde el momento en que el mensaje se captura previamente en el búfer. Si el búfer de captura previa es grande y el procesamiento tarda tanto tiempo que expiran los bloqueos de ese mensaje mientras permanece en el búfer de captura previa o incluso mientras la aplicación está procesando el mensaje, puede haber algunos eventos confusos que aplicación tenga que controlar. La aplicación podría adquirir un mensaje con un bloqueo que haya expirado o que esté a punto a punto de expirar. Si es así, la aplicación puede procesar el mensaje, pero, después, encuentra que no puede completarlo debido a la expiración de un bloqueo. La aplicación puede comprobar la propiedad LockedUntilUtc, pero tenga en cuenta que hay asimetría de reloj entre el agente y el reloj del equipo local.

Si el bloqueo expira en modo silencioso en el búfer de captura previa, el mensaje se trata como abandonado y de nuevo estará disponible para su recuperación desde la cola. A continuación, el mensaje se volverá a capturar en el búfer de captura previa y se colocará al final. Si el búfer de captura previa no se puede trabajar normalmente durante la expiración del mensaje, los mensajes se capturan previamente de forma repetida, pero nunca se entregan de forma eficaz en un estado utilizable (bloqueado válidamente), y, finalmente, se mueven a la cola de mensajes fallidos una vez que se supera el número máximo de entregas.

Si una aplicación abandona explícitamente un mensaje, es posible que el mensaje vuelva a estar disponible para la recuperación de la cola. Cuando la captura previa está habilitada, el mensaje se vuelve a capturar en el búfer de captura previa y se coloca al final. A medida que los mensajes del búfer de captura previa se purgan en el orden primero en salir (FIFO), la aplicación puede recibir mensajes desordenados. Por ejemplo, la aplicación puede recibir un mensaje con el identificador 2 y después un mensaje con el identificador 1 (que fue abandonado anteriormente) desde el buffer.

Si necesita un alto grado de confiabilidad para procesar los mensajes y el procesamiento requiere un trabajo y tiempo considerable, se recomienda usar la característica de captura previa de manera conservadora o no utilizarla en absoluto. Si necesita un elevado rendimiento y el procesamiento de mensajes es normalmente barato, la captura previa aporta ventajas de rendimiento significativas.

El número máximo de captura previa y la duración del bloqueo configurado en la cola o suscripción deben equilibrarse de forma que el tiempo de espera del bloqueo supere al menos el tiempo de procesamiento de mensajes acumulativo para el tamaño máximo del búfer de captura previa, además de un mensaje. Al mismo tiempo, la duración del bloqueo no debe ser tan larga que los mensajes puedan superar su tiempo máximo de vida mientras se bloquean, ya que esto significaría que se quitarán si no se pudieron completar cuando se capturaron previamente.

El 30 de septiembre de 2026, retiraremos del SDK de Azure Service Bus las bibliotecas WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus y com.microsoft.azure.servicebus, que no se ajusten a las directrices del SDK de Azure. También retiraremos el soporte del protocolo SBMP, por lo que ya no podrás usar este protocolo después del 30 de septiembre de 2026. Migre a las bibliotecas más recientes del SDK de Azure, que ofrecen actualizaciones de seguridad críticas y funcionalidades mejoradas, antes de esa fecha.

Aunque las bibliotecas anteriores todavía se pueden usar después del 30 de septiembre de 2026, ya no recibirán soporte técnico oficial ni actualizaciones de Microsoft. Para obtener más información, consulte el anuncio de retirada de soporte técnico.