Document RedisNg

[mvhirsch]

Hey @LKaemmerling ,

I'm using the artprima/prometheus-metrics-bundle Symfony bundle (which is built on this library) and need to add \RedisCluster support. Currently it fails connecting to multiple hosts (like a redis-cluster). I also noticed lack of predis support in #79. Well, I cannot add support for redis, but need to add support for \RedisCluster.

Starting to taking a deep look at this code, I noticed an undocumented RedisNg which you already suggested as (production-ready?) to ppl: #92, #98, #105. Looks like it's the next generation (focus on performance), but backwards-incompatible to Redis, is it?

Could you please share some thoughts on this, so I could propose a documentation/PR?

Thank you in advance!

[LKaemmerling]

RedisNG is basically an more optimized version of Redis. It contains a few breaking changes compared to the old Redis Storage.

[LKaemmerling]

#99

[mvhirsch]

Thank you for answering.

RedisNG is basically an more optimized version of Redis. It contains a few breaking changes compared to the old Redis Storage.

I see, so it's safe to use it (production-ready)?

Question is: supporting both (Redis and RedisNg) will add more maintenance load over time. What's your current plan on this? Will there be a v3 dropping support for Redis and only go for RedisNg? If so it does make sense (at least to me) to build support for more Redis variations on that:

• RedisCluster support #153
• Redis Sentinel? #95
• Added support of Predis library as storage adapter #127

Is it possible to create a migration-script or upgrade guide for users switching to new RedisNg?
That said it might be a chance to get rid of some legacy and win more support with less maintenance work.

[LKaemmerling]

Currently, it is not planned to remove the old Redis storage, however, it might make sense as you mentioned. Adding support for more redis variations makes sense IMHO. I'm not sure if this would make sense to build everything into one big Redis Adapter or if there should be a dedicated adapter for every variation.

RedisNG is production ready, a migration guide is not quite possible, it is as simple as "drop the whole content of all Redis Keys", they should not be used together.

(Same goes for APCng)