We use keydb at work, and I absolutely do NOT recommend it due to its extreme instability, in fact we're currently in the process of switching to dragonfly precisely due to keydb's instability.
Multimaster replication is convenient, but if you accidentally add the IP of the current replica to the replicaset, the entire cluster will crash if any of the nodes shuts down for any reason (note, not immediately, but days or even weeks after starting the cluster with everything working perfectly until one of the nodes crashes or shuts down).
Enabling diskless replication in multimaster mode causes either deadlocks, or immediate crashes, depending on the overall LA of the system (!).
These are just the issues I remember right now, because the related issues I opened in the repo are still open almost a year later; we had other crashes we had to workaround, too.
Yep in general when people consider Redis forks or alternaives that use more complex models, they don't realize the cost associated to the fact Redis is made in a certian way to be very stable and solid, and different choices lead to more fragility. Things that sometimes gets unnoticed:
1. The non threaded architecture of Redis need more management since you have to shard to many instances, but it is optimal from the POV of CPU utilization, especially if you do pinning to different NICs and so forth. And the risk of bugs in threaded code is very large.
2. Redis threadoffs such as copy-on-write during persistence is not optimal all the times, but the worst case behavior is predictable, and whatever is the layout of the data structure, you copy 4k pages. When more complex techniques are emplyed, sometimes you can do much better, sometimes you fail in a quite pathological way.
3. In general simplicity is there for a reason, and if you go with a fork that is more compelx, has ways less users, less developers and so forth, things can be less pleasent than they appear in READMEs with fancy benchmarks.
4. Redis is conceived to be easy to understand and modify by the folks that run it at scale. So the simplicity also is a way to say: come in, change things in your fork, make it particularly adapt for your use case: it's not going to be too complex to do it. Hackability is the contrary of vendor lock-in.
If someone wanted to truly master redis as a tool, is there a book or a starting point you would recommend?
Have used redis for years, have scratched more than the surface but I feel like there is so much more underneath I'm missing and my knowledge is (as is often the case) cobbled together from using it, reading bits of the docs and blog posts.
Unfortunately the book I wish existed didn't exist. I was about to write one for O'Reilly, but after the first exchanges I understood they were not the right match for me, so I abandoned the project. This happened several years ago, now I'm outside the Redis project so I'll not certainly write this book anymore. Later I started writing fiction, and during the process I understood that the bad vibes I had with O'Reilly were justified: the editor I had worked with tried to impose me a given shape for the book, a shape that I thought was not the right one. Their editing is massive and in the case of the Redis book they were destrying the book I had in mind. Writing a book is an insane amount of work, if you can't make it as you wish it is not worth the effort at all.
Thank you for answering, in a way it's a good answer since I looked for a book but none of them really looked like they'd fit what I wanted so at least I didn't miss an obvious one.
Sorry it didn't work well for you. In the 6.3 release we tried to pack in too much although we've ironed out most of the issues. The hardest change has been moving away from fork() for background saving which has historically caused a lot of pain for running it in production and makes it difficult to do persistence.
I definitely would have paced things out better if I could go back in time.
Multimaster replication is convenient, but if you accidentally add the IP of the current replica to the replicaset, the entire cluster will crash if any of the nodes shuts down for any reason (note, not immediately, but days or even weeks after starting the cluster with everything working perfectly until one of the nodes crashes or shuts down).
Enabling diskless replication in multimaster mode causes either deadlocks, or immediate crashes, depending on the overall LA of the system (!).
These are just the issues I remember right now, because the related issues I opened in the repo are still open almost a year later; we had other crashes we had to workaround, too.