21

Mar

Windows Azure – Storage pt.5 – Queues

Le code sono state da sempre un meccanismo molto elegante per gestire le operazioni asincrone e per disaccoppiare sistemi complessi. Capiamo perchè:

  • Gestione delle operazioni asincrone: se avessimo un sistema in grado di ricevere in input dei work item da completare, vorremmo poter dire a chi effettua il submit dell’attività “abbiamo preso in carico la tua richiesta e la evaderemo il prima possibile”, esattamente come avviene nella vita reale. L’alternativa sincrona, cioè fare aspettare il “cliente”, non sarebbe praticabile.
  • Disaccoppiare sistemi complessi: abbiamo un sistema web che gestisce l’accesso unificato tra 100 succursarli della stessa multinazionale su paesi diversi, integra il sistemi di frontend e fa molte altre operazioni. Arriva il momento in cui ogni dipendente a fine giornata deve fare l’upload del rapportino e il sistema, prima di integrarne i contenuti, deve effettuare operazioni di conversione sul file (delle durata di circa 15 secondi). Se il sistema fosse sincrono l’utente rimarrebbe “pending” tutto quel tempo, che salirebbe esponenzialmente a causa dell’elevato traffico in quel particolare momento della giornata. Inoltre questo presupporrebbe che, al cambio della logica di questo codice di conversione, si dovrebbe mettere le mani sull’applicazione di frontend, con elevati costi dati dalla complessità della soluzione. Per cui la soluzione ad un problema simile è quasi sempre il disaccoppiamento del sistema con un sottosistema non dipendente che riceva le notifiche e/o il lavori da fare, tramite messaggi.

Questo è uno schema generico di come potrebbe funzionare il sistema di messaging asincrono noto come MSMQ (Microsoft Message Queuing):

Detto ciò, spiegare le Azure Storage Queues è semplice analogia. In Windows Azure infatti, l’astrazione necessaria per ottenere questo risultato sono proprio le code, accessibili tramite REST e comunque tramite le API .NET a disposizione. Possono produrre/consumare fino a 500 topic per secondo e lavorare su work item multipli. Quello che cambia da un sistema di code tradizionale è la gestione della cancellazione dell’elemento.

image

In una coda tradizionale, l’elemento “preso” (cioè quello corrente), viene cancellato dalla coda prima della computazione, proprio per evitare che un altro consumer lo prenda una seconda volta. Nel sistema di Azure, quando il consumer prende un messaggio, esso sparisce per 1 minuto, permettendo al worker di effettuare il lavoro e POI di cancellarlo manualmente. Accade questo per evitare che, una volta cancellato l’item, in caso di process failure del worker, il messaggio non venga processato e allo stesso tempo perso.

L’API principale fornisce i seguenti metodi:

  • Operazioni generali:
    • CreateQueue
    • DeleteQueue
    • Get/Set Metadata
    • Clear Messages
    • ListQueues
  • Operazioni sui messaggi:
    • PutMessage
    • GetMessages
    • PeekMessages
    • DeleteMessage
by Roberto Freato on 3/21/2011
Post archive