Memcached is a general-purpose distributed memory caching system.
It is often used to speed up dynamic database-driven websites by caching data and objects in RAM
to reduce the number of times an external data source must be read.
Memcached is free and open-source software, subject to the terms of the Revised BSD license.
Memcached runs on Unix-like and on Microsoft Windows.
To build it use Autoconf, Automake, GNU build system and libevent.
Memcached's APIs provide a giant hash table distributed across multiple machines.
When the table is full, subsequent inserts cause older data to be purged in least recently
used order.
Applications using Memcached typically layer requests and additions into RAM before falling
back on a slower backing store, such as a database.
The size of this hash table is often giant.
It is limited by available memory across a large number of servers in a data centre.
Where high volume, wide audience web publishing requires it, this may stretch to many GB.
Memcached can be equally valuable for situations where either the number of requests for content
is high, or the cost of generating a particular piece of content is high.
Memcached was originally developed by Danga Interactive for LiveJournal, but is now used
by many other systems, including MocoSpace, YouTube, Reddit, Zynga, Facebook, Orange,
Twitter, Tumblr and Wikipedia.
Engine Yard and Jelastic are using Memcached as part of their platform as a service technology
stack and Heroku offers several Memcached services as part of their platform as a service.
Google App Engine, AppScale, Microsoft Azure and Amazon Web Services also offer a Memcached
service through an API.
History Memcached was first developed by Brad Fitzpatrick
for his website LiveJournal, on May 22, 2003.
It was originally written in Perl, then later rewritten in C by Anatoly Vorobey.
Software architecture The system uses a client–server architecture.
The servers maintain a key–value associative array; the clients populate this array and
query it.
Keys are up to 250 bytes long and values can be at most 1 megabyte in size.
Clients use client-side libraries to contact the servers which, by default, expose their
service at port 11211.
Each client knows all servers; the servers do not communicate with each other.
If a client wishes to set or read the value corresponding to a certain key, the client's
library first computes a hash of the key to determine the server to use.
Then it contacts that server.
This gives a simple form of sharding and scalable shared-nothing architecture across the servers.
The server will compute a second hash of the key to determine where to store or read the
corresponding value.
The servers keep the values in RAM; if a server runs out of RAM, it discards the oldest values.
Therefore, clients must treat Memcached as a transitory cache; they cannot assume that
data stored in Memcached is still there when they need it.
MemcacheDB, Couchbase Server and other database servers provide persistent storage while maintaining
Memcached protocol compatibility.
If all client libraries use the same hashing algorithm to determine servers, then clients
can read each other's cached data.
A typical deployment will have several servers and many clients.
However, it is possible to use Memcached on a single computer, acting simultaneously as
client and server.
Security Most deployments of Memcached exist within
trusted networks where clients may freely connect to any server.
There are cases, however, where Memcached is deployed in untrusted networks or where
administrators would like to exercise control over the clients that are connecting.
For this purpose Memcached can be compiled with optional SASL authentication support.
The SASL support requires the binary protocol.
A presentation at BlackHat USA 2010 revealed that a number of large public websites had
left Memcached open to inspection, analysis, retrieval, and modification of data.
Even within a trusted organisation, the flat trust model of memcached may have security
implications.
For efficient simplicity, all memcached operations are treated equally.
Clients with a valid need for access to low-security entries within the cache gain access to all
entries within the cache, even when these are higher-security and that client has no
justifiable need for them.
If the cache key can be either predicted, guessed or found by exhaustive searching,
its cache entry may be retrieved.
Some attempt to isolate setting and reading of a memcached service may be made in situations
such as high volume web publishing.
A farm of outward-facing content servers have read access to memcached containing published
pages or page components, but no write access.
Where new content is published, a request is instead sent to content generation servers
that are not publically accessible to create the content unit and add it to memcached.
The content server then retries to retrieve it and serve it outwards.
Example code Note that all functions described on this
page are pseudocode only.
Memcached calls and programming languages may vary based on the API used.
Converting database or object creation queries to use Memcached is simple.
Typically, when using straight database queries, example code would be as follows:
After conversion to Memcached, the same call might look like the following
The client would first check whether a Memcached value with the unique key "userrow:userid"
exists, where userid is some number.
If the result does not exist, it would select from the database as usual, and set the unique
key using the Memcached API add function call.
However, if only this API call were modified, the server would end up fetching incorrect
data following any database update actions: the Memcached "view" of the data would become
out of date.
Therefore, in addition to creating an "add" call, an update call would also be needed
using the Memcached set function.
This call would update the currently cached data to match the new data in the database,
assuming the database query succeeds.
An alternative approach would be to invalidate the cache with the Memcached delete function,
so that subsequent fetches result in a cache miss.
Similar action would need to be taken when database records were deleted, to maintain
either a correct or incomplete cache.
See also
phpFastCache - Supported MemCached, MemCache, WinCache, APC and Files.
Couchbase Server Redis
Mnesia MemcacheDB
MySQL - directly supports the Memcached API as of version 5.6.
Oracle Coherence - directly supports the Memcached API as of version 12.1.3.
GigaSpaces XAP - support Memcached with high availability, transaction support
Hazelcast Cassandra
References
External links Official website
Memcached wiki and faq PHP Memcached Manager with Tag Support
membase Memcached and Ruby
go-memcached - Memcached implementation in Go
QuickCached - Memcached server implementation in Java
nsmemcache - memcache client for AOL Server Memcached implementation on Windows 8/8.1
Commercially supported distributions Couchbase Server offers a Memcached "bucket
type" GigaSpaces Java based Memcached
Hazelcast Memcached clustered, elastic, fault-tolerant, Java based Memcached