Sincronización entre roles Azure

Question

Me preguntaba acerca de las mejores prácticas para sincronizar varias instancias azure que ejecutan el mismo rol. Más precisamente, quiero evitar que varias funciones de los trabajadores trabajen en la misma unidad de trabajo.

Las colas azules no parecen ayudar en este asunto. Una opción es usar una tabla SQL con bloqueos y procedimientos almacenados; pero usar la sincronización sql en Azure parece un poco incómodo.

¿Alguna idea?

Editar, mi detallada (pero simplificado problema) es el siguiente:

• Hay n objetivos.
• Se debe realizar una unidad de trabajo en cada objetivo en un intervalo específico (digamos 30 segundos, pero es diferente para cada objetivo).
• Tengo m trabajadores (alojado en h instancias).
• El procesamiento de una unidad de trabajo puede tardar entre 10 segundos y 1 hora.

La idea es que tengo un planificador que pone las unidades de trabajo en una cola de Azure, y cada uno de los m trabajadores a leer estos y procesarlos.

El problema:

• worker1 comienza a trabajar en unidad1 (que es con respecto a destino1) - éste tomará mucho tiempo, por ejemplo, 10 minutos
• transcurren 30 segundos
• la planificador pone otra unidad de trabajo para target1, digamos unit13
• worker2 comienza a trabajar en unit13, en contra de la misma destino1 - no es bueno

Tengo algunas ideas, pero que no parecen nublado suficiente, por lo que me interesa vea qué soluciones aplicaría para este problema.

Answer 1

Acabo de escribir un par de publicaciones en el blog sobre el uso de arrendamiento de blob para hacer este tipo de cosas. Ver http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases y http://blog.smarx.com/posts/building-a-task-scheduler-in-windows-azure.

Answer 2

dunnry es puntual: las colas funcionan perfectamente para evitar que varias instancias funcionen en el mismo elemento de trabajo. Cuando llame al GetMessage, el mensaje que recupera ahora es invisible para el período de tiempo que especifique (valor predeterminado: 30 segundos). En ese intervalo de tiempo, ningún otro lector puede recuperar este mensaje de cola.

Dicho esto: debe asegurarse de que su procesamiento sea idempotente. En el caso en que su procesamiento demore más tiempo que el intervalo de invisibilidad, el mensaje vuelve a ser visible. En este punto, el lector original no puede borrar el mensaje, y algún otro lector puede leer el mensaje (volviendo a ser invisible).En este caso, es posible que reproceses el mismo mensaje. Deberá configurar cuidadosamente la ventana de tiempo de espera para evitar esto como regla general.

Nota: Cada CloudQueueMessage tiene una propiedad DequeueCount, por lo que puede determinar si el mensaje se ha visto más de una vez (y también puede tratar con mensajes tóxicos).

Answer 3

CloudFX tiene una clase PrimaryInstanceManager que se puede utilizar para algunos de estos escenarios.