4 ms·

If you have a datacenter of your own and several VMs, redis would be fine as a persistent store. I wouldn't do it but it would be fine. If you are in the cloud

If you have a datacenter of your own and several VMs, redis would be fine as a persistent store. I wouldn't do it but it would be fine. If you are in the cloud and have any hint of using kubernetes then DO NOT USE redis as a persistent store. The problem is that redis' master/slave and replication pattern goes against the load balancing and Service objects of kubernetes. Redis was created in a time when it expected physical nodes to be available 24/7 and is not designed for nodes to go away. It can handle it but it isn't designed for it. Two different things. Redis as a single pod and a cache works great. I would never use redis as a DB. We have DBs specifically designed to be DBs.

dangerbird2 5y ago
Theoretically, redis-sentinel would be perfect for a clustered system like kubernetes. In practice, I've always found it a nightmare to deploy and use due to its hacked-on service discovery (which is redundant in kubernetes), and lack of client compatibility with vanilla redis
- cbushko 5y ago
  I spent months trying to get some clustering solution of redis running in kubernetes. Every single solution was a huge hack such as running a HAProxy in front on it and having that point to the master. The best solution I found was running keydb in a multi-master, multi-replica mode. All of the pods are masters, any pod can be written to and the keys will be copied over to the other masters/replicas. Performance is decent too.
  - dangerbird2 5y ago
    So I guess keydb is pretty solid in production? I considered it when running into problems with redis, but opted against it since none of my co-workers had any experience with it
    - cbushko 5y ago
      So far it seems to be ok. My stack is 1 customer per namespace and I am running it across around 100+ namespaces, 3 keydb pods each. Some customers are very bursty - I don't have an RPS - but they are holding up for us. I would still only do redis as a single non-persistent cache if it was up to me.

dangerbird2 5y ago

Theoretically, redis-sentinel would be perfect for a clustered system like kubernetes. In practice, I've always found it a nightmare to deploy and use due to its hacked-on service discovery (which is redundant in kubernetes), and lack of client compatibility with vanilla redis

cbushko 5y ago
I spent months trying to get some clustering solution of redis running in kubernetes. Every single solution was a huge hack such as running a HAProxy in front on it and having that point to the master. The best solution I found was running keydb in a multi-master, multi-replica mode. All of the pods are masters, any pod can be written to and the keys will be copied over to the other masters/replicas. Performance is decent too.
- dangerbird2 5y ago
  So I guess keydb is pretty solid in production? I considered it when running into problems with redis, but opted against it since none of my co-workers had any experience with it
  - cbushko 5y ago
    So far it seems to be ok. My stack is 1 customer per namespace and I am running it across around 100+ namespaces, 3 keydb pods each. Some customers are very bursty - I don't have an RPS - but they are holding up for us. I would still only do redis as a single non-persistent cache if it was up to me.