Uso de los mensajes de Amazon SQS

Las siguientes directrices pueden ayudarlo a procesar los mensajes de forma eficaz mediante Amazon SQS.

Procesamiento de los mensajes a tiempo

La configuración del tiempo de espera de visibilidad depende de lo que tarde la aplicación en procesar y eliminar un mensaje. Por ejemplo, si la aplicación necesita 10 segundos para procesar un mensaje y establece el tiempo de espera de visibilidad en 15 minutos, debe esperar un tiempo relativamente largo para intentar procesar el mensaje de nuevo si el intento de procesamiento anterior produce un error. Asimismo, si la aplicación requiere 10 segundos para procesar un mensaje pero el usuario establece el tiempo de espera de visibilidad en solo 2 segundos, otro consumidor recibe un mensaje duplicado mientras que el consumidor original sigue trabajando en el mensaje.

Para asegurarse de que hay tiempo suficiente para procesar los mensajes, utilice una de las siguientes estrategias:

• Si sabe (o puede calcular razonablemente) el tiempo que se tarda en procesar un mensaje, amplíe el tiempo de espera de visibilidad del mensaje al tiempo máximo que se tarda en procesar y eliminar el mensaje. Para obtener más información, consulte Configuración del tiempo de espera de visibilidad.

• Si no sabe cuánto tiempo tarda en procesarse un mensaje, cree un latido para su proceso consumidor: especifique el tiempo de espera de visibilidad inicial (por ejemplo, dos minutos) y, a continuación, mientras su consumidor siga trabajando en el mensaje, continúe ampliando el tiempo de espera de visibilidad en dos minutos cada minuto.

  importante

  El tiempo máximo de visibilidad es de 12 horas desde el momento en que Amazon SQS recibe la solicitud ReceiveMessage. La ampliación del tiempo de espera de visibilidad no restablece el máximo de 12 horas.

  Además, es posible que no pueda establecer el tiempo de espera de un mensaje individual en 12 horas completas (por ejemplo, 43 200 segundos), ya que la solicitud ReceiveMessage inicia el temporizador. Por ejemplo, si recibe un mensaje e inmediatamente establece el máximo de 12 horas mediante el envío de una llamada ChangeMessageVisibility con VisibilityTimeout igual a 43 200 segundos, es probable que se produzca un error. No obstante, utilizar un valor de 43 195 segundos funcionará a menos que exista un retraso significativo entre la solicitud del mensaje a través de ReceiveMessage y la actualización del tiempo de espera de visibilidad. Si su consumidor necesita más de 12 horas, considere usar Step Functions.

Gestión de los errores de solicitud

Para gestionar los errores de solicitud, utilice una de las siguientes estrategias:

• Si utiliza un AWS SDK, ya dispone de lógica automática de reintento y retardo. Para obtener más información, consulte Reintentos de error y retroceso exponencial en AWS en la Referencia general de Amazon Web Services.

• Si no utiliza las características de un AWS SDK para el reintento y el retardo, haga una pausa (por ejemplo, 200 ms) antes de reintentar la acción ReceiveMessage después de que no se reciba ningún mensaje, un tiempo de espera o un mensaje de error de Amazon SQS. Si quiere utilizar posteriormente ReceiveMessage con los mismos resultados, haga una pausa mayor (por ejemplo, 400 ms).

Configuración del sondeo largo

Cuando el tiempo de espera de la acción de la API ReceiveMessage es superior a 0, se está realizando un sondeo largo. El tiempo máximo de espera de sondeo es de 20 segundos. El sondeo largo ayuda a reducir el costo de uso de Amazon SQS al eliminar el número de respuestas vacías (cuando no hay ningún mensaje disponible para una solicitud ReceiveMessage) y las falsas respuestas vacías (cuando los mensajes están disponibles en la cola, pero no se incluyen en una respuesta). Para obtener más información, consulte Sondeos cortos y largos de Amazon SQS.

Para obtener un procesamiento óptimo de los mensajes, utilice las siguientes estrategias:

• En la mayoría de los casos, puede establecer el tiempo de espera de ReceiveMessage en 20 segundos. Si 20 segundos es demasiado tiempo para su aplicación, establezca un tiempo de espera de ReceiveMessage más corto (1 segundo como mínimo). Si no utiliza un AWS SDK para obtener acceso a Amazon SQS, o si configura un AWS SDK para tener un tiempo de espera más corto, es posible que tenga que modificar el cliente de Amazon SQS; para que permita solicitudes más largas o para que use un tiempo de espera más breve para el sondeo largo.

• Si implementa el sondeo largo para varias colas, utilice un subproceso para cada cola en lugar de un solo subproceso para todas las colas. El uso de un único subproceso para cada cola permite que la aplicación procese los mensajes de cada una de las colas en cuanto estén disponibles, mientras que el uso de un único subproceso para sondear varias colas podría impedir que su aplicación procesara los mensajes disponibles en otras colas mientras la aplicación espera (hasta 20 segundos) para la cola que no tiene ningún mensaje disponible.

importante

Para evitar errores HTTP, asegúrese de que el tiempo de espera de respuesta HTTP de las solicitudes ReceiveMessage sea mayor que el parámetro WaitTimeSeconds. Para obtener más información, consulte ReceiveMessage.

Captura de mensajes problemáticos

Para capturar todos los mensajes que no se pueden procesar y garantizar la exactitud de las métricas de CloudWatch, configure una cola de mensajes fallidos.

• La política de redireccionamiento redirige los mensajes a una cola de mensajes fallidos después de que la cola de origen no puede procesar un mensaje un número especificado de veces.

• El uso de una cola de mensajes fallidos reduce el número de mensajes y la posibilidad de exponer el sistema a mensajes de píldoras venenosas (mensajes que se reciben pero no se pueden procesar).

• La inclusión de un mensaje de píldora venenosa en una cola puede distorsionar la métrica ApproximateAgeOfOldestMessage de CloudWatch y ofrecer una antigüedad incorrecta de un mensaje de píldora venenosa. Cuando se utiliza esta métrica, la configuración de una cola de mensajes fallidos ayuda a evitar falsas alarmas.

Configuración de la retención de la cola de mensajes fallidos

En el caso de las colas estándar, la caducidad de un mensaje siempre se basa en su marca temporal original. Cuando un mensaje se mueve a una cola de mensajes fallidos, la marca temporal de la cola no se modifica. La métrica ApproximateAgeOfOldestMessage indica cuándo el mensaje pasó a la cola de mensajes fallidos, no cuándo se envió originalmente. Por ejemplo, supongamos que un mensaje pasa un día en la cola original antes de ser trasladado a una cola de mensajes fallidos. Si el periodo de retención de la cola de mensajes fallidos es de cuatro días, el mensaje se elimina de la cola de mensajes fallidos al cabo de tres días y ApproximateAgeOfOldestMessage es de tres días. Por lo tanto, se recomienda establecer siempre un periodo de retención de una cola de mensajes fallidos superior al periodo de retención de la cola original.

Para las colas FIFO, la marca temporal de entrada se restablece cuando el mensaje se mueve a una cola de mensajes fallidos. La métrica ApproximateAgeOfOldestMessage indica cuándo el mensaje ha pasado a la cola de mensajes fallidos. En el mismo ejemplo anterior, el mensaje se elimina de la cola de mensajes fallidos al cabo de cuatro días y ApproximateAgeOfOldestMessage es de cuatro días.

Cómo evitar el procesamiento incoherente de los mensajes

Debido a que Amazon SQS es un sistema distribuido, es posible que un consumidor no reciba un mensaje aunque lo marque como entregado al regresar correctamente de una llamada de método de API ReceiveMessage. En este caso, Amazon SQS registra el mensaje como entregado al menos una vez, aunque el consumidor no lo haya recibido. Dado que no se realizan intentos adicionales de entregar mensajes en estas condiciones, no recomendamos establecer el número máximo de recepciones en 1 para una cola de mensajes fallidos.

Implementación de sistemas de solicitud-respuesta

Al implementar un sistema de solicitud-respuesta o de llamada a procedimiento remoto (RPC), tenga en cuenta las siguientes prácticas recomendadas:

• No cree colas de respuestas por mensaje. En su lugar, cree colas de respuestas durante el inicio, por productor, y utilice un atributo de mensaje de ID de correlación para mapear las respuestas a las solicitudes.

• No permita que sus productores compartan colas de respuestas. Esto puede provocar que un productor reciba mensajes de respuesta destinados a otro productor.

Para obtener más información acerca de cómo implementar el patrón de solicitud de respuesta utilizando el Cliente de colas temporales, consulte Patrón de mensajes de respuesta a solicitudes (colas virtuales).