Dormando, the creator of Memcached, wrote two articles [1] [2] very early , admonishing developers not to use memcached to store Sessions. The reason he gave in the first article is roughly that if memcached is used to store Sessions, when the memcached cluster fails (such as memory overflow) or maintenance (such as upgrading, adding or reducing servers), users will not be able to log in. Or get kicked out. In the second article, he pointed out that the recycling mechanism of memcached may cause users to be disconnected for no reason.
Titas Norkūnas is the co-founder of Bear Mountain, a provider of DevOps consulting services . Seeing that the Ruby/Rails community ignored the issues pointed out in those two articles by Dormando, he recently wrote an article to further elaborate on it. He believes that the root of the problem is that memcached is a system designed to cache data rather than store it, so it should not be used to store sessions.
For Dormando's two articles, he believes that the reasons given in the first article are easy to understand, while people often underestimate the reasons given in the second article. So he elaborated on the reason:
Memcached uses a "least recently used (LRU)" algorithm to reclaim the cache. But memcached's LRU algorithm is performed for each slab class, not for the whole .
This means that if all Sessions are roughly the same size, they will be split into two or three slab classes. All other data of roughly the same size will also fit into the same slabs, competing with the Session for storage space. Once the slab is full, even if there is room in the larger slab, the data will be recycled instead of being put into the larger slab... In a specific slab, the oldest user of the session will be dropped. Users will start dropping randomly, and worst of all, you probably won't even notice it until users start complaining...
In addition, Norkūnas mentioned that if new data is added to the session, the larger session may also cause the problem of disconnection.
It has been proposed to use separate memcached caches for Session and other data. However, because the LRU algorithm of memcached is local, that method not only leads to low memory usage, but also cannot eliminate the risk of random disconnection of users due to session recycling.
If readers really want to use memcached to improve the session reading speed, they can learn from the memcached+RDBMS (in some cases, NoSQL) model proposed by Norkūnas:
- When the user logs in, "set" the Session to memcached and write to the database;
- Add a field to the Session to identify the time when the Session was last written to the database;
- When each page is loaded, the Session is read from memcached first, and then from the database;
- Every time N pages or Y minutes are loaded, the session is written to the database again;
- Get expired sessions from the database, and get the latest data from memcached first.