114

I'm currently using MySql to store my sessions. It works great, but it is a bit slow.

I've been asked to use Redis, but I'm wondering if it is a good idea because I've heard that Redis delays write operations. I'm a bit afraid because sessions need to be real-time.

Has anyone experienced such problems?

Jordan Dodson
  • 415
  • 5
  • 5
Trent
  • 5,785
  • 6
  • 32
  • 43
  • 1
    Since Redis says it has optional durability, then I'd say it's safe to use it if you opt for persistence on HDD. However, for session data - I'd definitely save them to RAM (meaning I wouldn't worry about durability part of the whole ordeal). The worst that should happen in case you lose session data is having your users logged out. – N.B. Apr 23 '12 at 10:22
  • 1
    yeah but this is part of my requirement, users should not have to login back, by the way some users data are persisted across session while users are not logged in (guest users). They'll go for Redis RAM but with logging and/or backup enabled. If we lost some sessions it's acceptable. – Trent Apr 23 '12 at 10:28
  • Well, if you are using a hard disk storage, what's the point of using Redis? It probably delays the actual commit to disk to increase performance, same thing that MySQL might do if configured that way. Did you consider moving your MySQL to faster I/O subsystem? It's not like Redis will magically work 50 times faster on same hardware, if it has to use the same I/O subsys. – N.B. Apr 23 '12 at 10:30
  • 1
    my main concerns is about the delayed write, what happens if an user logs in and the session is written with delay, he'll be redirected but not logged in – Trent Apr 23 '12 at 10:31
  • well I though we could use Redis with RAM but still have a physical backup – Trent Apr 23 '12 at 10:45
  • you can, but you need to see how the delayed write works. I know that majority of systems, even MySQL, store the data to a buffer located somewhere in heap and then when the buffer is full - it's flushed to the disk. Swapping from MySQL to Redis, having Redis store data to disk, will not benefit you from performance point of view sadly, which arises the question - is it worth swapping to Redis, if disk persistence **has** to be used? – N.B. Apr 23 '12 at 10:48
  • Well the idea was to move to Redis for performance reasons but keep a way to restore session in case of a crash, as I said if some sessions are lost it's acceptable. I also read that redis was able to log all operations to restore in case of a crash that may help to improve performance by still using RAM while not persisting it to harddisk – Trent Apr 23 '12 at 10:56
  • Redis docs say that you can set it up to dump a snapshot every few minutes on the disk, so if you can live to lose the session data that is a few minutes old - that might be a great option. It also supports replication so if you have more than one node, I see no reason why you'd have to worry about losing sessions. – N.B. Apr 23 '12 at 11:00
  • 2
    imagine a ecommerce site, if the session is lost, the current cart is lost too, that's not terrible but that may be odd for users. Guests users are identified only with a session so there is no way to recover their cart. – Boris Guéry Apr 23 '12 at 11:09
  • 1
    @BorisGuéry - it's not that I disagree, but if one has to boost performance - compromises must be set when something goes wrong. Yes, it'll be odd for users to suddenly get logged out, that's for sure - but the question is how often is it expected to happen? If it's once or twice a year that all Redis nodes go down, then I see no reason to decimate performance for a few isolated times when the whole cluster is unavailable. But that's just me. – N.B. Apr 23 '12 at 11:15

3 Answers3

169

Redis is perfect for storing sessions. All operations are performed in memory, and so reads and writes will be fast.

The second aspect is persistence of session state. Redis gives you a lot of flexibility in how you want to persist session state to your hard-disk. You can go through http://redis.io/topics/persistence to learn more, but at a high level, here are your options -

  1. If you cannot afford losing any sessions, set appendfsync always in your configuration file. With this, Redis guarantees that any write operations are saved to the disk. The disadvantage is that write operations will be slower.
  2. If you are okay with losing about 1s worth of data, use appendfsync everysec. This will give great performance with reasonable data guarantees
Sripathi Krishnan
  • 30,948
  • 4
  • 76
  • 83
20

This question is really about real-time sessions, and seems to have arisen partly due to a misunderstanding of the phrase 'delayed write operations' While the details were eventually teased out in the comments, I just wanted to make it super-duper clear...

You will have no problems implementing real-time sessions.

Redis is an in-memory key-value store with optional persistence to disk. 'Delayed write operations' refers to writes to disk, not the database in general, which exists in memory. If you SET a key/value pair, you can GET it immediately (i.e in real-time). The policy you select with regards to persistence (how much you delay the writes) will determine the upper-bound for how much data could be lost in a crash.

Jordan Dodson
  • 415
  • 5
  • 5
14

Basically there are two main types available: async snapsnots and fsync(). They're called RDB and AOF respectively. More on persistence modes on the official page.

The signal handling of the daemonized process syncs to disk when it receives a SIGTERM for instance, so the data will still be there after a reboot. I think the daemon or the OS has to crash before you'll see an integrity corruption, even with the default settings (RDB snapshots).

The AOF setting uses an Append Only File that logs the commands the server receives, and recreates the DB from scratch on cold start, from the saved file. The default disk-sync policy is to flush once every second (IIRC) but can be set to lock and write on every command.

Using both the snapshots and the incremental log seems to offer both a long term don't-mind-if-I-miss-a-few-seconds-of-data approach with a more secure, but costly incremental log. Redis supports clustering out of the box, so replication can be done too it seems.

I'm using the default RDB setting myself and saving the snapshots to remote FTP. I haven't seen a failure that's caused a data loss yet. Acute hardware failure or power outages would most likely, but I'm hosted on a VPS. Slim chance of that happening :)

Morten Jensen
  • 5,818
  • 3
  • 43
  • 55