amazon-web-services - sns - amazon sqs example

Entrega múltiple de mensajes de Amazon SQS

Question

Entiendo que para brindar una gran escalabilidad y confiabilidad, SQS realiza una paralelización extensa de los recursos. Utiliza servidores redundantes incluso para colas pequeñas e incluso los mensajes publicados en las colas se almacenan de forma redundante como copias múltiples. Estos son los factores que lo impiden exactamente en una entrega como en RabbitMQ. Incluso he visto mensajes eliminados.

Las implicaciones para los desarrolladores es que necesitan estar preparados para la entrega múltiple de mensajes. Amazon afirma que no es un problema, pero lo es, entonces el desarrollador debe usar alguna construcción de sincronización como una escritura condicional de base de datos-transacción o dinamo-db. ambos reducen la escalabilidad.

La pregunta es,

A la luz del problema de entrega duplicada, ¿cómo se cumple la característica de mensaje de período invisible ? El mensaje no está garantizado para ser invisible. Si el desarrollador tiene que hacer arreglos propios para la sincronización, ¿qué beneficio tiene el período de invisibilidad? He visto mensajes entregados nuevamente, incluso cuando se suponía que eran invisibles.

Editar

aquí incluyo algunas referencias

1. ¿Cuál es una buena práctica para lograr el comportamiento "Exactamente una entrega" con Amazon SQS?
2. http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message
3. http://aws.amazon.com/sqs/faqs/#How_does_Amazon_SQS_allow_multiple_readers_to_access_the_same_message_queue_without_losing_messages_or_processing_them_many_times
4. http://aws.amazon.com/sqs/faqs/#Can_a_deleted_message_be_received_again

Answer 1

La invisibilidad del mensaje resuelve un problema diferente para garantizar una única entrega. Considere una operación de larga ejecución en un artículo en la cola. Si el procesador genera un desperfecto durante la operación, no desea eliminar el mensaje, desea que vuelva a aparecer y que otro procesador lo maneje nuevamente.

Entonces el patrón es ...

1. Escribir (empujar) el elemento en la cola
2. Vista (peek) elemento en la cola
3. Marcar elemento invisible
4. Ejecutar el proceso en el artículo
5. Escribir resultados
6. Eliminar elemento (pop) de la cola

Entonces, ya sea que obtenga una entrega duplicada o no, aún debe asegurarse de procesar el artículo en la cola. Si lo elimina al sacarlo de la cola, y luego su servidor muere, puede perder ese mensaje para siempre. Permite escalamiento agresivo mediante el uso de instancias puntuales y garantías (utilizando el patrón anterior), para que no pierda un mensaje.

Pero - no garantiza una sola entrega y solo una vez. Pero no creo que esté diseñado para ese problema. Tampoco creo que sea un problema insalvable. En nuestro caso (y puedo ver por qué nunca antes había notado los problemas), estamos escribiendo resultados para S3. No es gran cosa si sobrescribe el mismo archivo con la misma información. Por supuesto, si se trata de una transacción de débito que va a un banco de aire acondicionado, es probable que desee algún tipo de ID de correlación ... y la mayoría de los sistemas ya los tienen. Entonces, si obtiene un valor de correlación duplicado, lanza una excepción y continúa.

Buena pregunta. Destacó algo para mí.