Redis is used a lot, especially by @micstriit so the Lucee support is actively maintained, the Lucee extension uses BSON for efficient storage
but they did one of those licensing shifts, but there’s a fork
Lucee has some additional commands for Redis as well
To add to Zac’s helpful reply, redis replication is indeed easy, as shown in their docs on it or as other resources online (found easily via web searching/ai) will show.
As for that redis licensing change, I’ll add that it was not a change that directly affected those USING redis, including the open source community edition. Still, there’s no doubt it caused widespread consternation as well as acceleration of interest in and evolution of alternatives like Valkey.
But it was mainly aimed at protecting them against providers selling redis as a service (but not paying anything to redis) or creating competing redis engines or services. For more details, including frequent q & a’s, see Redis Adopts Dual Source-Available Licensing - Redis
FWIW, I discussed this and listed still more redis alternatives in my talk at cfcamp last year, which was on using it/them for cf or Lucee sessions specifically. That talk (pdf and youtube video) are available here.
Looking forward to seeing folks again in Munich next month! 
That’s great, thank you guys. I’ve got two servers talking to the same Redis (Valkey on ElastiCache), which is awesome. I just need to implement an alternative to the KEYS command (i.e. SCAN) as this isn’t supposedly supported with AWS for performance reasons. This errors when it tries to validate the cache connection in the Lucee admin, and also within our implementation when trying to clear a bunch of related entries.
I’ll work that out later, but back to the day job for now Thanks again!
ah interesting, I filed a ticket
https://luceeserver.atlassian.net/browse/LDEV-5502
btw, I have split this out in a new thread