5 ms·

Redis is used for plenty of things, not just memory caches. For example if you use it for session storage, you can't have your application read from a random i

• tossandthrow 3mo ago
  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 3mo ago
    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 3mo ago
      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 3mo ago
        Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.
        • trumpdong 3mo ago
          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 3mo ago
            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.
            • amtamt 3mo ago
              > Redis is a real database No, redis is a memory cache, with some ACID like features bolt on. Even real databases have hard time maintaining consistency across nodes. CAP is a real constraint.
            • trumpdong 3mo ago
              > Redis is a real database. Oh good, then you don't need to do any of the stuff that you suggested to do
              • 9dev 3mo ago
                These two concerns are not mutually exclusive, the kind of database or data stored within it doesn't give any availability guarantees on its own. Even a single Postgres instance, which I suppose fits your understanding of a real database, is a single point of failure and not a highly available setup: If your database server goes down, clients get errors and the database is thus unavailable.
        • tossandthrow 3mo ago
          Obviously these are application decisions. You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it. We use redis as infrastructure. To route events and as a cache. For us redis could go down and we would merely see a degradation of our service with no data loss. I recommend using redis like that. And then use a database that supports transactions for real data problems. But we are different. And that's OK.
    • tossandthrow 3mo ago
      I don't think you understand what HA means. The app would look up in both databases. If it exists in any, there would be a session. Thisnis strictly different from partitioning which I think you are mixing it up with. Paritioning is for performance not HA
      • 9dev 3mo ago
        That’s the precise point I’m making
      • n_e 3mo ago
        > The app would look up in both databases. If it exists in any, there would be a session. And if you find the session with differing values in both databases, how do you know which one is up-to-date? You need an algorithm to pick which data is right, such as electing a master instance. And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup HA (or reimplement it, which obviously is a bad idea). You can't read round robin from multiple non-HA instances.
        • tossandthrow 3mo ago
          Yes, you are pointing out exactly how HA is difficult. There is a whole slew of downstream things you need to take into consideration.
          • 9dev 3mo ago
            and as you've just confirmed... there is a need for good HA support in Redis. Which was the entire premise of this thread.