Original author here. Feel free to ask anything.
* the last code commit was 8 months ago (and was very minor)
* there are 120 open issues
* it's written in C
Now this is far from abandaomware (imo), but it still seemed like a risky dependency to lean on. Have you guys moved past it already? Any thoughts on the cost-benefit analysis there or alternative solutions?
Note: I mention C like a detriment because I myself cannot write production C and therefore would think twice to using a library/service I myself could not fork (and probably many other devs).
Every bug we fix we apply this as a PR. A few PRs from the repository we have cherry-picked internally and deployed. But we have also a few issues with it like this one here: https://github.com/twitter/twemproxy/issues/442 or live reconfiguration would be a nice feature. Think about it if you really need this, because it is not only fun. A few pain points:
* Deployments of new configs and restarting twemproxy on your server farm
* New redis version with new commands? Extend twemproxy for those command support
I don't now any _real_ alternative to it, right now. I know from https://github.com/Netflix/dynomite which is a twemproxy fork. When we had only memcached and no redis (we are using both with twemproxy), then we would try https://github.com/facebook/mcrouter from facebook. But it is specialized on memcached.
If you come up with an alternative, please let me know.
Do you use it or something else for Redis production server monitoring? something with little impact on performance.