Wrapper Memcache

Wrapper Memcache per Cache nel ruolo di Azure

Aggiornamento: agosto 2015

ImportantImportante
Microsoft consiglia di usare Cache Redis di Azure per tutte le nuove attività di sviluppo. Per la documentazione aggiornata e le istruzioni per la scelta dell'offerta del Servizio Cache di Azure, vedere Quali offerte della Cache Redis è consigliabile usare?

Memcache è una soluzione distribuita di memorizzazione nella cache in memoria che consente di accelerare le applicazioni Web su larga scala riducendo la pressione sul database. Memcache è usato da numerosi siti Web più importanti di Internet ed è stato integrato con altre tecnologie in modi innovativi.

Azure supporta il protocollo Memcache per consentire ai clienti che possiedono le implementazioni Memcache esistenti di eseguire facilmente la migrazione ad Azure. Se questo protocollo è già usato in un'applicazione, non è necessario sostituire questo codice con uno nuovo.

È preferibile eseguire Caching di Azure con Memcache anziché, ad esempio, eseguire solo Memcache in un ruolo di lavoro. Questo perché Caching di Azure offre funzionalità a valore aggiunto quali arresto normale, disponibilità elevata, memorizzazione nella cache locale (nello shim client), notifiche (nello shim client), coerenza dei dati, disponibilità elevata (HA) oltre a scalabilità orizzontale e verticale trasparente per i client. Lo schema di hashing server e la gestione delle partizioni in Caching di Azure con Memcache, ad esempio, consentono il bilanciamento del carico e mantengono la coerenza dei dati.

Caching di Azure supporta il protocollo di trasmissione Memcache. Esistono due versioni del protocollo, una binaria e una testuale.

Caching di Azure supporta questo protocollo, oltre al proprio protocollo di trasmissione. Un client Memcache dovrebbe prevedere la compatibilità con Azure. Caching di Azure supporta quasi tutte le API supportate dalle altre implementazioni Memcache.

Pertanto, se un utente trasferisce un'applicazione Memcache in Azure e imposta l'applicazione affinché faccia riferimento all'implementazione di Memcache di Azure, egli potrà continuare a lavorare senza apportare altre modifiche all'applicazione.

Memcache supporta due diverse esperienze di sviluppo: l'uso di un "gateway server" e l'uso di uno "shim client".

Nonostante la semplicità in termini di implementazione, distribuzione e comprensione concettuale, un gateway server presenta anche importanti ostacoli che sono illustrati più avanti.

Quando si usa il gateway server, il cluster di cache server è in ascolto su un socket Memcache. In altri termini, apre un socket e resta in ascolto dei pacchetti sul protocollo Memcache. Non esiste un livello di conversione (illustrato più avanti).

Per attivare questa funzionalità, nel cluster di cache aprire un ulteriore endpoint interno, assegnargli un nome e impostarlo come porta Memcache. Tutto il traffico diretto a tale porta verrà ricevuto sul protocollo Memcache.

Il gateway server, tuttavia, riduce le prestazioni in scenari ad elevata sensibilità prestazionale rispetto allo scenario basato su shim client. Questo deriva dal fatto che nelle implementazioni Memcache l'hashing è implementato in modo diverso rispetto a Caching di Azure. Le implementazioni Memcache rimandano lo schema di hashing al client della cache. In Azure, il server di cache genera l'hash. Il comportamento della cache di Azure prevede che il server di cache specifichi il comportamento hash. Questo consente al server di bilanciare il carico, ingrandire, ridurre e assicurare l'assenza di perdita di dati e così via.

Quando Azure memorizza un elemento nella cache, viene generato un codice hash in base alla chiave dell'elemento. Azure usa l'hash per stabilire quale server nel cluster di cache conterrà l'elemento memorizzato nella cache. Di conseguenza, il gateway server di Azure deve eseguire nuovamente l'hashing della chiave e instradare l'elemento al server di destinazione nel cluster di cache. Questa operazione implica un hop di rete supplementare, con conseguente peggioramento delle prestazioni.

Lo shim client Memcache viene installato nel client che accede alla cache. In genere si tratta del ruolo Azure dell'applicazione stessa. Lo shim client supporta la cache locale.

Lo shim è un livello di conversione. Converte le chiamate del client Memcache all'API di Caching di Azure. Lo shim comprende due parti: un gestore protocollo Memcache e un client Caching di Azure. Lo shim, ossia il livello di conversione, viene installato sul client stesso, indipendentemente da dove vengono effettuate le chiamate Get e Put all'API di Caching di Azure.

Quando il client Memcache punta a localhost come server Memcache, le operazioni Put vengono gestite inizialmente dall'istanza locale dello shim anziché dal server di cache in Azure. Lo shim determinerà quindi il server di destinazione corretto nel cluster di cache e reindirizzerà l'operazione Put ad Azure.

In questo modo viene eliminato l'hop di rete supplementare presente nello scenario basato su gateway server. Lo svantaggio è dato dalla necessità di ottenere questo shim e inserirlo nell'app.

Esistono due topologie di memorizzazione nella cache: basata su risorse condivise e basata su ruolo di cache dedicato.

Per distribuire un cluster di cache in un ruolo di lavoro della cache dedicato, usare lo shim Memcache dal client della cache. Questo determina il miglioramento delle prestazioni ed evita la necessità di codice di individuazione automatica.

Quando si usa la memorizzazione nella cache con risorse condivise e il client della cache è ospitato nello stesso ruolo, usare il gateway server Memcache. L'uso dello shim client implica un livello di elaborazione e reindirizzamento supplementare che non è necessario quando si accede alla cache dallo stesso ruolo. Il reindirizzamento supplementare comporta l'aggiunta di un sovraccarico non necessario.

Non esiste alcun modello di programmazione per usare il gateway server o lo shim client. È sufficiente apportare modifiche alle impostazioni di configurazione. Lo shim client richiede inoltre un'installazione.

L'uso di un gateway server o di uno shim client è più un'operazione di distribuzione che non un modello di programmazione. Un programmatore chiamerà sempre le stesse API Get o Put, tuttavia l'applicazione sarà connessa in modo leggermente differente. Anziché fare riferimento al server di memorizzazione nella cache originale, ora punterà al gateway server o allo shim client.

Infine, né il gateway server né lo shim client considerano la libreria client Memcache in uso poiché le implementazioni Memcache standard usano lo stesso protocollo. Il server di cache è interessato ai pacchetti di dati che aderiscono al protocollo Memcache standard e non alle implementazioni client Memcache stesse.

  1. Nel ruolo che ospiterà il server di cache, passare alle proprietà del ruolo e visualizzare la scheda Caching

  2. Selezionare la casella di controllo "Abilita Caching". Questo consentirà di aggiungere gli endpoint di input in csdef, l'elemento importModule e altre impostazioni csdef/cscfg. L'esperienza di distribuzione prevede quindi l'aggiunta manuale di un endpoint di input denominato "memcache_default" nella scheda Endpoint.

  3. A questo punto è necessario configurare il client in modo che faccia riferimento a questo cluster. Se si usa un gateway server con la memorizzazione nella cache basata su risorse condivise e/o lo shim client con la memorizzazione nella cache dedicata, è possibile impostare l'applicazione affinché faccia riferimento a "localhost_thisrolename": l'individuazione automatica non è necessaria.

  1. Nel ruolo che include il client Memcache fare clic con il pulsante destro del mouse sul nome del ruolo e selezionare "Aggiungi riferimento al pacchetto di librerie" per visualizzare la finestra di NuGet

  2. Cercare il pacchetto "Azure Caching Memcache Shim". Installare il pacchetto NuGet

  3. Il pacchetto creerà l'attività di avvio, aggiungerà un endpoint interno per memcache_default, ne eseguirà il mapping a 11211 e aggiungerà le sezioni dataCacheClients appropriate a App.config e Web.config. Questi dati possono essere modificati nella scheda relativa agli endpoint interni.

  4. Specificare il nome del ruolo nell'elemento autoDiscovery di App.config o Web.config

  5. Il client deve essere ora configurato affinché "faccia riferimento" allo shim. Modificare la configurazione del client memcache e impostare il server su "localhost". È necessario impostare anche i numeri di porta corretti.

Mostra:
© 2016 Microsoft