Run your Memcache app with Azure Managed Cache Service
Updated: August 25, 2015
|Microsoft recommends all new developments use Azure Redis Cache. For current documentation and guidance on choosing an Azure Cache offering, see Which Azure Cache offering is right for me?|
Managed Cache Service provides support for migrating role-based Cloud Services Memcache client applications to use Managed Cache Service by providing a Memcache client shim. This topic provides guidance on using this shim to enable your Memcache client applications to use Managed Cache Service.
Memcache is a distributed, in-memory caching solution used to help speed up large scale web applications by taking pressure off the database. Memcache is used by many of the internet’s biggest websites and has been merged with other technologies in innovative ways.
Azure supports the Memcache protocol to enable customers with existing Memcache implementations to easily migrate to Azure. If an application already uses Memcache, there is no necessity to replace this code with new code.
Running Managed Cache Service with Memcache is a better option than, for example, running just Memcache itself in a worker role. This is because Managed Cache Service offers value-added features such as graceful shutdown, high availability, local caching, notifications, data consistency, high availability (HA), and easy scale-up and scale-down that’s transparent to the clients, to name a few. For example, the server hashing scheme and partition management in Managed Cache Service with Memcache help load balancing and preserve data consistency.
Managed Cache Service supports the Memcache wire protocol. There are two versions of the protocol, a binary version and a text version.
A Memcache client should expect compatibility with Azure. Managed Cache Service supports almost every API that other Memcache implementations support.
As such, should a user bring a Memcache application to Azure, point the application at Azure’s implementation of Memcache, it should continue to work as-is, with no additional application modifications.
The Memcache client shim is installed on the client that is accessing the cache. This is generally the Azure role that has the application itself. The client shim supports local cache.
The shim is a translation layer. It translates Memcache client calls to the Managed Cache Service API. The shim has two parts –a Memcache protocol handler, and an Managed Cache Service client. The shim – the translation layer – is installed on the client itself, wherever the Get and Put calls to Managed Cache Service API are made from.
When the Memcache client is pointed to localhost as the Memcache server, memcache operations will be initially handled by the local instance of the shim. The shim will translate the operation to a cache API request and send it to the Managed Cache Service.
|Before starting, ensure that you have the cache endpoint and the access key for your cache. For more information about creating a cache, see How to: Create a Cache for Azure Managed Cache Service. For more information about access keys, see Controlling Access using Access Keys.|
On the role which has the Memcache client, right click on the role name and select “Add Library Package Reference” to launch the NuGet window
Search for “Azure Caching Memcache Shim”. Install this NuGet package
The package will create the startup task, add an internal endpoint for memcache_default and map it to 11211, and add the appropriate dataCacheClients sections to App.config and web.config. This can be changed in the internal endpoints tab.
Provide the Managed Cache Service endpoint in the autoDiscovery element and the access key in the authorizationInfo in the dataCacheClientSection of the App.config or Web.config
The client must now be configured to “point” to the shim. Edit the memcache client configuration and set the server to “localhost”. The correct port number(s) must also be set (the default is 11211).