|
|
|
|
|
by lucb1e
466 days ago
|
|
If sessions die when your system reboots, that means you can't reboot the system (update the service) without breaking whatever any users were currently doing on your site or in your software. That does sound bad to me and like a bad fit for Redis the memory cache. (I know it can do persistence optionally but that's what the person above you was complaining about: this is not what it's good at) Why not use a regular database for this (can be as simple as an sqlite file, depending on your needs), or the default thingy that comes with your framework or programming language? This is built into everything I've ever used, no need to reinvent session storage or overengineer the situation with jwt or some other distributed cryptographic system and key management |
|
A lot of depends on the scale and load pattern (e. g. ratio of active and inactive sessions). For a small scale sqlite could be a good choice.
Storing session in a regular DB (say Postgres) could be more expensive (hardware wise) than in Redis and there are cases when the load is high enough to matter but the budged is not unlimited (to use a DB at any cost). Also redundancy with a Redis cluster is easier than with Postgres. I don't think Redis always better, but at some load patterns it is.
> or the default thingy that comes with your framework or programming language?
Default PHP session store is files in /tmp - works for a home page but if load is high it explodes (millions files in /tmp is too slow to work with).