Why can't I store a session with memcached?

Memcached Creator Dormando wrote two articles very early [note]. Warn developers not to store session with Memcached.

The reason he gives in the first article is roughly that, assuming that the session is stored with memcached, the user will not be able to log in if there is a problem with the memcached cluster (for example, a memory overflow) or maintenance (such as upgrading, adding, or lowering the server). Or be kicked off the line. And in the second article. He pointed out. The memcached recovery mechanism may cause users to drop offline for no reason.

Titas Norkūnas is co-founder of the DevOps consulting service provider Bear Mountain.

He recently wrote a further elaboration on the Ruby/rails Community's ignorance of the problems that dormando the two articles pointed out.

The root of the problem, he thinks,is that memcached is a system designed to cache data instead of storing data. Therefore, it should not be used to store the session.



For Dormando's two articles, he felt that the reasons given in the first article were very easy to understand, and people often had insufficient knowledge of the reasons given in the second article.

So he made a concrete exposition of the reason:

Memcached uses the least recently used (LRU) algorithm to reclaim the cache. But Memcached's LRU algorithm runs for each slab class, not for the population as a whole .

This means that the entire session is assumed to be roughly the same size. Then they will be divided into two or three slab classes. All other data with roughly the same size will be put into the same slab. Contention for storage space with session. Once the slab is full. Even if there is room in the larger slab, the data will be recycled. Instead of putting in bigger slab ... In a particular slab, the oldest user of the session will be dropped.

The user will start to randomly drop the line. And worst of all, you're probably not even going to notice it. Until the user starts complaining ...

In addition, Norkūnas mentions that if new data is added to the session, then a larger session may also cause a drop-off problem.

It was proposed to use separate memcached caches for session and other data respectively. Only, because the memcached LRU algorithm is local, that way not only causes memory usage is not high, and also can not eliminate the user due to the session recycling and the risk of random drop.

Suppose the reader is eager to improve session reading speed with memcached. Then be able to draw on the Memcached+rdbms proposed by Norkūnas (in some cases.) NoSQL can also be a model:

When the user logs in, the session "set" to memcached. and write to the database.

Add a field to the session to identify when the session was last written to the database;

When each page is loaded, the session is read first from memcached. Second, read from the database.

Once n pages or y minutes are loaded, the session is written again into the database.

Gets the expired session from the database, giving priority to getting the latest data from the memcached.

Source of references:
Why can't I store a session with memcached?
Http://www.lai18.com/content/431361.html

Why can't I store a session with memcached?