Estoy usando sesiones en PHP para rastrear si un usuario está conectado. No lo uso para almacenar ningún otro dato sobre el usuario; esencialmente es como verificar una tabla hash para ver si el usuario se ha autenticado.redis vs sesiones nativas
¿Habría alguna ventaja con el uso de redis en lugar de sesiones PHP nativas?
Tengo curiosidad por el rendimiento, la escalabilidad y la seguridad (no me preocupa realmente la complejidad del código).
¿Habría alguna ventaja de utilizar Redis en lugar de las sesiones de PHP nativas?
Rendimiento - Las sesiones de PHP son mejores. Serán más rápidos que Redis porque están leyendo RAM en lugar de algo en la red.
Escalabilidad - Las sesiones de Redis son mejores. Las sesiones PHP solo funcionan en una máquina. Si necesita más de una máquina para atender solicitudes, deberá implementar sesiones adhesivas. Con Redis, varias máquinas pueden compartir el estado de la sesión. Una solicitud de los usuarios puede ir a cualquier servidor sin ningún problema.
Durabilidad - Si un servidor web se cuelga por algún motivo, perderá todo el estado de la sesión. Con Redis, puede tener varias opciones de persistencia. Puede asegurarse de no perder información de sesión incluso si un servidor de Redis en particular deja de funcionar
Seguridad - Puede lograr una gran seguridad con ambos enfoques, y puede desordenar por completo utilizando ambos enfoques. En igualdad de condiciones, yo diría que las sesiones de PHP serían un poco más seguras porque hay una cosa menos de qué preocuparse.
Las sesiones de PHP no se almacenan en la memoria RAM sino como archivos en el disco. ¿Y quién te dijo que están perdidos cuando se reinicie el servidor web? – ThiefMaster
@ThiefMaster - No me di cuenta de que las sesiones de PHP se almacenaban en el disco. Dicho eso, mi punto sobre la durabilidad se mantiene. Si el servidor se bloquea (en lugar de reiniciar), perderá sus datos de sesión. Con las sesiones respaldadas por Redis o MySQL, tiene una mejor durabilidad. –
Incluso entonces no necesariamente los pierde. A menos que el sistema operativo falle y el archivo de sesión esté dañado o aún no se haya escrito realmente en el disco duro. – ThiefMaster
Realmente no creo que deba preocuparse mucho por las sesiones a menos que obtenga MASIVAS cantidades de tráfico, PHP maneje las sesiones muy bien, y si almacena solo esa poca información, debería estar bien incluso con un montón de solicitudes, y sobre el rendimiento, debería estar cerca, ya que el redis no es nativo de PHP.
Con 10k usuarios, si cada usuario usa datos de sesiones de 1kb, consumiría 10,000kb o 10 ~ mb, que no es mucho; PHP es lo suficientemente inteligente como para utilizar una estructura de datos lo suficientemente buena como para contener y escribir y leer rápidamente esos valores. El problema es si los datos de la sesión son demasiado grandes o, por alguna razón, el servidor consume demasiados recursos leyendo los datos de la sesión, pero normalmente es así si los datos son demasiado grandes.
desea que el manejador de sesiones para ser rápido. Esto se debe al hecho de que una sesión de PHP bloqueará todas las demás solicitudes simultáneas del mismo usuario hasta que finalice la primera solicitud.
Hay una variedad de controladores que puede utilizar para sesiones de PHP en varios servidores: Archivo w/NFS, Base de datos MySQL, Memcache y Redis.
El método de la base de datos (usando InnoDB) fue el más lento en mi experiencia seguido de File w/NFS. La contención de bloqueo y escritura son los principales factores. Memcache y Redis ofrecen un rendimiento similar y son, con mucho, las mejores alternativas ya que todas las operaciones están en RAM. Redis es mi elección porque puede habilitar la persistencia del disco y Memcache solo se basa en la memoria.
Explico Redis Sessions in PHP with Kohana si quiere más detalles. Aquí está nuestro tablero de instrumentos para la gestión de claves Redis:
usando algo como Redis para el almacenamiento de sesiones es una gran manera de obtener más rendimiento de servidores con equilibrio de carga.
Por ejemplo, en Amazon Web Services, los balanceadores de carga tienen lo que se denomina 'sesiones adhesivas'. Lo que esto significa es que cuando un usuario se conecta por primera vez a su aplicación web, p. cuando inicie sesión en él, el equilibrador de carga seleccionará uno de sus servidores de aplicaciones y este usuario continuará atendido desde este servidor hasta que salga de su aplicación. Esto se debe a que las sesiones utilizadas por PHP, por ejemplo, se almacenarán en el servidor de la aplicación que primero comiencen a usar.
Ahora, si utiliza Redis en un servidor separado, configure PHP en cada uno de sus servidores de aplicaciones para almacenar sus sesiones en Redis, puede desactivar estas 'sesiones adhesivas'. Esto significa que cualquiera de sus servidores puede acceder a las sesiones y, por lo tanto, el servidor puede ser servido desde un servidor diferente con cada solicitud a su aplicación. Esto finalmente hace un uso más eficiente de su configuración de equilibrio de carga.
Realmente no creo que deba preocuparse mucho por las sesiones a menos que obtenga MASIVAS cantidades de tráfico, PHP maneje las sesiones muy bien, y si almacena solo esa poca información, debería estar bien incluso con un montón de solicitudes, y sobre el rendimiento debería estar cerca, ya que el redis no es nativo de PHP. – gosukiwi
@gosukiwi gracias! ¿Qué quieres decir con masivo? como 10k usuarios a la vez, o como 1mil? Entiendo que depende de mi máquina, pero estoy tratando de ver si php podría tener algún límite superior (como si fuera a almacenar cada sesión como un archivo individual, haciéndolo sujeto al rendimiento del sistema de archivos OS). – tau
Bueno, me preocuparía el uso de memoria del servidor en ese caso, ya que está todo almacenado en RAM, con 10k usuarios, si cada usuario usa datos de sesiones de 1kb, consumiría 10,000kb o 10 ~ mb, lo que no es mucho, PHP es lo suficientemente inteligente como para usar una estructura de datos lo suficientemente buena como para contener y escribir y leer rápidamente esos valores, el problema es si los datos de la sesión son demasiado grandes o por alguna razón el servidor consume demasiados recursos leyendo los datos de la sesión, pero eso es normalmente si los datos son demasiado grandes. – gosukiwi