Controlar la concurrencia de roles de trabajadores azules en varias instancias

Question

Tengo una función de trabajo simple en azul que procesa algunos datos en una base de datos SQL azure. El trabajador básicamente agrega datos de un origen de datos de un tercero a mi base de datos cada 2 minutos. Cuando tengo dos instancias del rol, obviamente esto se duplica innecesariamente. Me gustaría tener 2 instancias para la redundancia y el tiempo de actividad 99.95, pero no quiero que ambos procesen al mismo tiempo, ya que solo duplicarán el mismo trabajo. ¿Hay un patrón estándar para esto que me falta? Sé que podría establecer indicadores en la base de datos, pero espero que haya otra manera más fácil o mejor de gestionar esto. Gracias

Answer 1

Como Mark sugirió, puede usar una cola de Azure para publicar un mensaje. Puede hacer que la instancia de rol de trabajador publique un mensaje de seguimiento en la cola como lo último que hace al procesar el mensaje actual. Eso debería tratar con el problema que Mark planteó con respecto a la necesidad de un semáforo. En su mensaje de cola, puede insertar una marca de fecha y hora cuando se puede procesar el mensaje. Al crear un mensaje nuevo, solo agregue dos minutos a la hora actual.

Y ... en caso de que no sea obvio: en el caso de que la instancia de rol de trabajo falle antes de completar el procesamiento y no vuelva a publicar un nuevo mensaje de cola, está bien. En este caso, el mensaje de cola actual simplemente reaparecerá en la cola y otra instancia podrá procesarlo.

Answer 2

No hay una manera muy fácil de hacer esto, no lo creo.

Puede usar un semáforo como Mark ha mencionado, para registrar básicamente el inicio y el final del procesamiento. Entonces puede tener cualquier cantidad de instancias ejecutándose, cada una inspeccionando el registro del semáforo y actuando solo si el semáforo lo permite.

Sin embargo, la advertencia aquí es ¿qué ocurre si una de las instancias se bloquea en el medio del procesamiento y nunca libera el semáforo? Puede implementar un valor de "tiempo de espera" después de lo cual otras instancias intentarán iniciar el procesamiento si no ha habido un desbloqueo durante un período de tiempo de X.

Como alternativa, puede utilizar un tercer servicio de monitoreo de fiesta como AzureWatch mirar para casos que no responden en Azure y comenzar una nueva instancia si la cantidad de casos de "listo" está en 1. Esto le ahorrará puede ahorrar algo de dinero al no tener que tener 2 instancias ejecutándose todo el tiempo, pero hay un ligero retraso entre cuando falla una instancia y cuando se inicia una nueva.

Answer 3

Un Semaphor como se sugiere sería el camino a seguir, aunque probablemente vaya con un simple latido del corazón en la tienda blob.

El otro pensamiento es, ¿qué tan necesario es? Si sus cargas pueden mantenerse bajas durante unos minutos, ¿tal vez solo permita que el papel se recicle?

Answer 4

Captura pequeña en la solución de David. Volver a publicar el mensaje en la cola sería lo último en la ejecución actual, de modo que si la máquina se bloquea en el camino, el mensaje actual caducará y volverá a aparecer en la cola. Eso supone que el mensaje fue visto originalmente y requiere una operación de eliminación de cola de la cola. La eliminación de cola debe ocurrir antes de insertar el nuevo mensaje en la cola. Si el rol falla entre estas 2 operaciones, no habrá tokens en el sistema y se detendrán. La comprobación del duplex de ESB suena como un enfoque factible, pero tampoco parece que sea determinante, ya que el bus solo puede verificar si existen mensajes idénticos en una cola. Pero si uno de los mensajes aparece justo después de que se haya desactivado el anterior, existe la posibilidad de que termine con 2 procesos que se ejecutan en paralelo.

Una solución alternativa, si se lo puede permitir, habría que nunca se des-cola y simplemente arrendar el mensaje a través de operaciones de la ojeada. Debería asegurarse de que el tiempo de espera de invisibilidad nunca exceda el tiempo de procesamiento en su rol de trabajador. En cuanto a la creación del token en primer lugar, la misma estrategia de inicio de rol de trabajador descrita anteriormente combinada con la verificación de duplicación de ASB debería funcionar (ya que los mensajes nunca se moverían de la cola).