This case is exactly what he talks about. To get HA just setup more than one redis cache - or rebuild the session if it was lost in the redis cache.

▲

9dev 2 hours ago | parent [-]

It’s not. Imagine a web app that stores your user information in a session store, mapped by your cookie-provided session ID. Your web app searches redis 1 for the session id, but since that key is on redis 2, the lookup fails and the application thinks there is no such session, and rejects the request.

Now you could solve this specific case by sharding by prefix, or by querying all instances, but then you still do not have high availability: if the instance a specific session is on is down, these users cannot authenticate. At that point you’re better off with a single instance.

▲

olavgg an hour ago | parent [-]

But that is his point. If you cannot find the session id in redis, you login again. If your Redis server crash, you start a new one and everyone just login again. No data is lost.

▲

9dev an hour ago | parent [-]

Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.

▲

trumpdong 22 minutes ago | parent [-]

If you consider it important, you have to store it in a real database. No buts. If you don't consider it important, sharded redis works fine.

	▲	9dev 15 minutes ago \| parent [-]
		Redis is a real database. If I wasn’t convinced it could retain data I hand it, I wouldn’t use it in the first place. Just because it works for your use case right now doesn’t mean there isn’t room for improvements to support others too.