[Go] Why can't I store session with memcached

The following is transferred from: http://www.infoq.com/cn/news/2015/01/memcached-store-session

-------------------------Split Line-----------------------------------------------

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. The root of the problem, he argues, is that memcached is a system designed to cache data instead of storing data, and therefore should not be used to store sessions. 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 explains the reason in detail: Memcached uses the least recently used (LRU) algorithm to reclaim the cache. But Memcached's LRU algorithm executes on each slab class, not on the whole. 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 read speed, then 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 that identifies the time at which the session was last written to the database, when each page is loaded, the session is read first from memcached, followed by the database, and the session is written to the database after each N-page or y-minute load ; Gets the expired session from the database, giving priority to getting the latest data from the memcached. For more information about memcached, check here [3]. Thank Guo for the review of this article.

[1]:http://www.dormando.me/articles/memcached_sessions/

[2]:http://dormando.livejournal.com/495593.html

[3]:http://work.tinou.com/2011/04/memcached-for-dummies.html

-----------------------------Split Line---------------------

PS:LRU algorithm and Memcache are available in the collation

[Go] Why can't I store session with memcached