Out of the box, Magento has four methods available for storing session data: filesystem, database, memcached, and tmpfs. The default method is to store session information in the filesystem. I believe that storing sessions in Redis is actually superior to all of the aforementioned methods. Each of the four default methods has a particular weakness that Redis addresses.

filesystem

The filesystem method is the default and probably the worst. From my experience, when Magento uses the filesystem for storage of session files it tends to keep them all. Although this has the benefit of keeping sessions around forever (and who doesn't want their shopping cart intact three years later?), it has the drawback of putting potentially thousands of files in a single directory. If you've been around servers long enough, you know that directories become slower and slower as more files are added. Combine this with the speed limits of file access on a physical disk and you have the potential for a real meltdown.

Since Redis is stored in memory, it doesn't suffer from either of the affects created by spinning disks or large directories. Additionally, with automatic key expiration and eviction, it will ensure that session storage stays at a level appropriate for your server.

database

Storing sessions in the database avoids the directory size problem that the filesystem method creates. Additionally, a well-tuned database will keep much of the session information in memory. The real issue with keeping Magento sessions in the databases is one of scalability. From what I've seen, Magento sites really hit the database server hard. I've seen category pages that make thousands of database calls. I'm not suggesting these sites were well constructed, but there are some sites out there working that way. Adding session storage to the database just increases the number of database queries necessary to render pages.

Redis has the following benefits over databases for Magento session storage:

• With Redis, sessions are guaranteed to be stored in memory. The database can only make this guarantee if there is enough available memory.
• The Redis process is separate from the database process. Database queries for session data have to contend with other database queries.
• The Redis server can be run anywhere. If necessary, it can be given it's own dedicated server to ensure sessions are returned as quickly as possible.

memcached, tmpfs

I've lumped memcached and tmpfs together since they have similar advantages and drawbacks. Both options store session data in memory. This means fast access to session data. Unfortunately, neither system guarantees persistence. If the memcached service is restarted, or the server reboots, sessions are lost. Additionally, tmpfs has no automatic session eviction and can easily run out of space or run into directory size issues.

Redis keeps a copy of its data on disk. When properly shutdown, Redis will write out its data so that it can be reloaded when the service restarts. Additionally, Redis will make frequent updates to its backup data in case there is a failure that results in an improper shutdown. Together, this ensures that sessions are persistent across restarts of both the service and the server.