¿Es una buena idea usar Memcached para el almacenamiento de sesiones con PHP? Tendremos muchos servidores y debemos acceder a los datos de sesión desde cualquier lugar, por lo que nos vemos obligados a utilizar una base de datos (en nuestro caso MySQL) como almacenamiento de sesión o Memcached. ¿Qué piensas?Memcached o MySQL para el almacenamiento de sesiones - PHP
Conozco a personas que han usado Memcached para esto: es muy rápido, ciertamente mucho más rápido que una base de datos, y está diseñado para manejar mucha más concurrencia.
La principal desventaja del almacenamiento puramente en la memoria es que todos los datos de la sesión se borrarán si/cuando reinicia el daemon. En mi experiencia, Memcached es sólido como una roca y nunca tuve que reiniciarlo por una falla, pero es una consideración si tus administradores de sistemas no están acostumbrados a trabajar de esa manera, o si tus sistemas se actualizan con frecuencia. También depende de si la pérdida de todas las sesiones de usuario una vez al mes o año es aceptable o no (es decir, en el comercio electrónico, a la gerencia probablemente no le guste esto).
La solución obvia, si ese es el caso, es ir a una de las muchas bases de datos de tabla NoSQL/hash basadas en disco, como MemcacheDB, que se basa en Memcached. O ver: CouchDB, MongoDB etc. Cada uno de estos daemons (incluido Memcached) también es mucho menos complejo cuando se trata de ajuste de rendimiento que MySQL (donde deben sincronizarse todo tipo de cosas, como búferes de claves y de ordenación, caché de consultas, etc. por instalación/caso de uso) - Es decir, con Memcached no hay mucho más que hacer que asignar memoria e iniciarla.
Personalmente, soy partidario de utilizar un almacenamiento más rápido y apropiado (no SQL) para cosas temporales como claves de sesión, pero si su base de datos no está cargada y no prevé que sea así, lo único Se pierde almacenando sesiones en la base de datos porque es un poco más lenta, por lo que los usuarios ven un poco más de latencia.
Independientemente de dónde vaya, le sugiero que escriba el código de administración de la sesión de tal forma que el motor de almacenamiento sea solo una capa y pueda intercambiar en un motor de almacenamiento diferente de manera relativamente fácil. No querrá recodificar su aplicación si encuentra que memcached o lo que elija no está funcionando bien, y quiere probar algo más. Por ejemplo, una vez escribí un sistema de almacenamiento en caché para una aplicación CMS en clúster que utilizaba memcached para almacenar en caché varias páginas y objetos, pero cuando el daemon no era alcanzable, fallaba alternar los backends que almacenarían en caché a la memoria compartida o disco en el servidores web individuales. (En su caso, no necesariamente necesita el failover automático, solo la capacidad de cambiar de opinión sobre el backend.)
Mencioné MemcacheDB porque usa el protocolo Memcache, por lo que es extremadamente fácil de intercambiar en Memcached para MemcacheDB o viceversa.
Según la situación, puede ser mejor usar cualquiera de las opciones. El uso de memcached te ofrece velocidad, pero está limitado por la memoria RAM. Las ventajas de MySQL, u otro motor de base de datos, es que ofrece una mayor capacidad de almacenamiento y, sobre todo, centraliza las sesiones cuando estamos utilizando múltiples servidores para una aplicación web específica.