Storage Commands
set
Most common command. Store this data, possibly overwriting any existing data. New items are at the top of the LRU.
add
Store this data, only if it does not already exist. New items are at the top of the LRU. If an item already exists and an add fails, it promotes the item to the front of the LRU anyway.
replace
Store this data, but only if the data already exists. Almost never used, and exists for protocol completeness (set, add, replace, etc)
append
Add this data after the last byte in an existing item. This does not allow you to extend past the item limit. Useful for managing lists.
prepend
Same as append, but adding new data before existing data.
cas
Check And Set (or Compare And Swap). An operation that stores data, but only if no one else has updated the data since you read it last. Useful for resolving race conditions on updating cache data.
Retrieval Commands
get
Command for retrieving data. Takes one or more keys and returns all found items.
gets
An alternative get command for using with CAS. Returns a CAS identifier (a unique 64bit number) with the item. Return this value with the cas command. If the item's CAS value has changed since you gets'ed it, it will not be stored.
delete
Removes an item from the cache, if it exists.
incr/decr
Increment and Decrement. If an item stored is the string representation of a 64bit integer, you may run incr or decr commands to modify that number. You may only incr by positive values, or decr by positive values. They does not accept negative values.
If a value does not already exist, incr/decr will fail.
Statistics
There're a handful of commands that return counters and settings of the memcached server. These can be inspected via a large array of tools or simply by telnet or netcat. These are further explained in the protocol docs.
stats
ye 'ole basic stats command.
stats items
Returns some information, broken down by slab, about items stored in memcached.
stats slabs
Returns more information, broken down by slab, about items stored in memcached. More centered to performance of a slab rather than counts of particular items.
stats sizes
A special command that shows you how items would be distributed if slabs were broken into 32byte buckets instead of your current number of slabs. Useful for determining how efficient your slab sizing is.
WARNING this is a development command. As of 1.4 it is still the only command which will lock your memcached instance for some time. If you have many millions of stored items, it can become unresponsive for several minutes. Run this at your own risk. It is roadmapped to either make this feature optional or at least speed it up.
flush_all
Invalidate all existing cache items. Optionally takes a parameter, which means to invalidate all items after N seconds have passed.
This command does not pause the server, as it returns immediately. It does not free up or flush memory at all, it just causes all items to expire.
Expiration in memcached
Expiration in memcached is lazy. In general, an item cannot be known to be expired until something looks at it.
If you fetch an expired item, memcached will find the item, notice that it's expired, and free its memory. This gives you the common case of normal cache churn reusing its own memory.
Think of it this way: You can add billions of items to memcached that all expire at the exact same second, but no additional work is performed during that second by memcached itself. Only as you attempt to retrieve (or update) those items will memcached ever notice that they shouldn't be there. At this point, curr_items will be decremented by each item it has seen expired.
We may also notice expired items while searching for memory for new items, though this isn't likely to create an observable difference in curr_items because we'll be replacing it with a new item anyway.
Storing sets or lists
Storing lists of data into memcached can mean either storing a single item with a serialized array, or trying to manipulate a huge "collection" of data by adding, removing items without operating on the whole set. Both should be possible.
One thing to keep in mind is memcached's 1 megabyte limit on item size, so storing the whole collection (ids, data) into memcached might not be the best idea.
Steven Grimm explains a better approach on the mailing list: http://lists.danga.com/pipermail/memcached/2007-July/004578.html
Chris Hondl and Paul Stacey detail alternative approaches to the same ideal: http://lists.danga.com/pipermail/memcached/2007-July/004581.html
A combination of both would make for very scalable lists. IDs between a range are stored in separate keys, and data is strewn about using individual keys.
Reference
Click for more detail about memcached
Recommend to Read