Memcached Creator Dormando wrote two articles early on, warning developers not to store sessions with memcached. The reason he gives in the first article is roughly that if you store the session with Memcached, the user will not be able to log in or be kicked off when the memcached cluster fails (such as a memory overflow) or maintenance (such as upgrading, increasing, or reducing the server). In the second article, he points out that memcached's recycling mechanism may cause users to fall out of line 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 neglect of the problems identified in the two articles of Dormando. He thinks the root of the problem is that
memcached is a system designed to cache data instead of storing data, so it should not be used to store session。
For Dormando's two articles, he thinks the reasons given in the first article are easy to understand, and people often do not understand the reasons given in the second article. So he elaborated on this reason in detail:
Memcached uses the least recently used (LRU) algorithm to reclaim the cache. But
the LRU algorithm for memcached is executed for each slab class, not for the overall。
This means that if all sessions are roughly the same size, they will be divided into two or three slab classes. All other data of roughly the same size will be placed in the same slab with the session contention 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 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 probably won't even 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. However, because Memcached's LRU algorithm is local, that approach not only leads to low memory usage, but also eliminates the risk that users will be randomly dropped due to session recycling.
If the reader is very interested in using memcached to improve the session reading speed, then you can draw on the Norkūnas proposed Memcached+rdbms (in some cases, NoSQL can) mode:
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 loads, it takes precedence to read the session from Memcached, followed by reading from the database;
After each load n pages or Y minutes, the session is written to the database again;
Gets the expired session from the database, giving priority to getting the latest data from the memcached.
Reference Source:
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?
