| First of all, these two statements seem to be at odds: > I/O threading is not going to happen in Redis AFAIK, because after much consideration I think it’s a lot of complexity without a good reason vs. > the way I want to scale Redis is by improving the support for multiple Redis instances to be executed in the same host, especially via Redis Cluster Having to run multiple Redis instances, with a separate "Redis Cluster [proxy]", sounds like "I didn't originally use threads, and while threads are technically the correct solution (because it's the standard way to do things and not all that complicated), I don't feel like rewriting Redis to use threads the way it should have been done from the start; thus I've come up with an alternative hack that is not ideal but makes my life easier". While I have always argued that memcached is not automatically better solely because it is multi-threaded, the idea that an additional point of failure – a technically unnecessary proxy/broker – is somehow a better solution than threads seems like an attempt to save face for mistakes made during early development. As for the ACL: > You get a library from the internet, and it looks to work well. Now why on the earth such library, that you don’t know line by line, should be able to call “FLUSHALL” and flush away your database instantly What can I say other than "give me a break". Every large codebase has hundreds/thousands of dependencies, and any one of them could slip in a malicious block of code. My analysis: anyone who would be concerned about some library calling FLUSHALL would never even install Redis - a C program that, for all we know, is spamming emails or running a Bitcoin miner while it runs. The fact is, all 3rd party software/dependencies come with risk; if I'm trusting your software not to screw me while I sleep, I think I can trust a basic library not to hijack my Redis server with a FLUSHALL command. Really, this is not even remotely a valid argument. Whatsoever. Then there's this: > maybe you just hired a junior developer that is keeping calling “KEYS” on the Redis instance, while your company Redis policy is “No KEYS command”. Ok, now you're just making shit up. Here's an idea: you don't need ACL to restrict access to KEYS, as that command should have been deprecated and entirely removed in favour of SCAN long ago. You mentioned "I think it’s a lot of complexity without a good reason" regarding multi-threaded Redis; yet here you are advocating an entire, complex ACL layer... for what purpose? For some imaginary malicious scenario where my Redis library is going to call FLUSHALL, or a "junior developer" is allowed to call "KEYS *" – a command that should not even be available in 2019? I started this comment intending to provide unfiltered – but polite/constructive – feedback. The more I reread your original post, the more frustrated I got at the fact you seem to have lost all common sense. You're trying to justify adding a massive amount of complexity, including a clustering/proxy strategy instead of simple threading, and ACL to save us from imaginary threats. I've previously been in the stage of development that I believe you might be in now – you've run out of truly "good ideas" that would actually benefit your user base, and are now attempting to justify new features as necessary, when the truth is you're just looking to write new code that you personally find to be "new and exciting", rather than iterating on the existing, boring codebase. I've spent the past 4-5 years advocating that memcached is effectively dead because of Redis. The more you try to make Redis some kind of ACL-secured, clustered database – rather than the lightweight cache store we learned to love – the more likely another project will step in and replace Redis the same way Redis replaced memcached. |