amazon-web-services - que - sqs programa

¿La mejor forma de mover mensajes de DLQ en Amazon SQS?

Question

¿Cuál es la mejor práctica para mover los mensajes de una cola muerta de vuelta a la cola original en Amazon SQS?

Podría ser

1. Reciba un mensaje de DLQ
2. Escribir mensaje en cola
3. Eliminar mensaje de DLQ

¿O hay una manera más simple?

Además, ¿AWS eventualmente tendrá una herramienta en la consola para mover los mensajes del DLQ?

Answer 1

Aquí hay un truco rápido. Esta definitivamente no es la mejor opción ni la recomendada.

1. Establezca la cola principal de SQS como DLQ para el DLQ real con Maximum Receives como 1.
2. Ver el contenido en DLQ (Esto moverá los mensajes a la cola principal ya que este es el DLQ para el DLQ real)
3. Elimine la configuración para que la cola principal ya no sea el DLQ del DLQ real

Answer 2

Esa parece ser tu mejor opción. Existe la posibilidad de que su proceso falle después del paso 2. En ese caso, terminará copiando el mensaje dos veces, pero su aplicación debería manejar la re-entrega de mensajes (o no importar) de todos modos.

Answer 3

Hay otra forma de lograr esto sin escribir una sola línea de código. Considere que su nombre de cola real es SQS_Queue y el DLQ porque es SQS_DLQ. Ahora sigue estos pasos:

1. Establezca SQS_Queue como el dlq de SQS_DLQ. Dado que SQS_DLQ ya es un dlq de SQS_Queue. Ahora, ambos están actuando como el dlq del otro.
2. Establezca el recuento máximo de recepción de su SQS_DLQ en 1.
3. Ahora lea los mensajes de la consola SQS_DLQ. Como el recuento de recepción de mensaje es 1, enviará todo el mensaje a su propia dlq, que es su cola SQS_Queue real.

Answer 4

No es necesario mover el mensaje porque vendrá con muchos otros desafíos, como mensajes duplicados, escenarios de recuperación, mensaje perdido, verificación de deduplicación, etc.

Aquí está la solución que implementamos:

Por lo general, usamos el DLQ para errores transitorios, no para errores permanentes. Así que tomó el enfoque a continuación -

1. Lee el mensaje de DLQ como una cola normal

   Beneficios
   • Para evitar el procesamiento de mensajes duplicados
   • Mejor control en DLQ: como puse un cheque, para procesar solo cuando la cola normal se procesa por completo.
   • Amplíe el proceso según el mensaje en DLQ

2. Luego sigue el mismo código que sigue la cola normal.

3. Más confiable en caso de abortar el trabajo o el proceso se rescindió durante el procesamiento (por ejemplo, instancia muerta o proceso terminado)

   Beneficios
   • Reutilización de código
   • Manejo de errores
   • Recuperación y reproducción de mensajes

4. Extienda la visibilidad del mensaje para que ningún otro hilo lo procese.

   Beneficio
   • Evite procesar el mismo registro por múltiples hilos.

5. Elimine el mensaje solo cuando haya un error permanente o sea exitoso.

   Beneficio
   • Continúe procesando hasta que obtengamos un error transitorio.

Answer 5

aquí:

import boto3
import sys
import Queue
import threading
work_queue = Queue.Queue()
sqs = boto3.resource(''sqs'')
from_q_name = sys.argv[1]
to_q_name = sys.argv[2]
print("From: " + from_q_name + " To: " + to_q_name)
from_q = sqs.get_queue_by_name(QueueName=from_q_name)
to_q = sqs.get_queue_by_name(QueueName=to_q_name)
def process_queue():
while True:
messages = work_queue.get()
bodies = list()
for i in range(0, len(messages)):
bodies.append({''Id'': str(i+1), ''MessageBody'': messages[i].body})
to_q.send_messages(Entries=bodies)
for message in messages:
print("Coppied " + str(message.body))
message.delete()
for i in range(10):
t = threading.Thread(target=process_queue)
t.daemon = True
t.start()
while True:
messages = list()
for message in from_q.receive_messages(
MaxNumberOfMessages=10,
VisibilityTimeout=123,
WaitTimeSeconds=20):
messages.append(message)
work_queue.put(messages)
work_queue.join()