-
Notifications
You must be signed in to change notification settings - Fork 24.4k
Description
Hi all, especially @oranagra, @soloestoy, @yossigo (and possibly others) that in the past dealt with related issues.
In the latest days I tried to find what is the link between different issues that we had in the past, and recently since the introduction of PSYNC2. As well as the issues you recently fixed while I was in vacation, regarding the "DEL before script" issue. I made certain considerations, together with a general willingness that I've about the future of Redis: when we discover bugs, I think we should not just fix them, but understand if they are due to a design error.
All those considerations make me think that there is a design error in Redis currently. I believe that we should only allow effects replication, and totally remove the previous mechanism to replicate the script verbatim. The major drawback of this, is the use of more bandwidth. Performance-wise however this may turn to be at least as fast as replicating the script as we do now, especially since @soloestoy fixed the problem with large pipelines. Dispatching commands from the network should not be slower than the Lua invocation of commands.
The amount of simplification possible after this change is incredible, especially now that also the problem of slaves expiring keys is fixed, it means that slaves are more and more completely dependent on the master stream of commands. So we could gain:
- No longer need to explain to users side effects into scripts. They can do whatever they want.
- No need for a cache about scripts that we sent or not to the slaves.
- No need to sort the output of certain commands inside scripts (SMEMBERS and others): this both simplifies and gains speed.
- No need to store scripts inside the RDB file in order to startup correctly.
- No problems about evicting keys during the script execution.
Many of the points above resulted into bugs in the past, it's not just a matter of code complexity, but also a problem with future bugs that we risk to have every time a new feature may have an interaction with the scripting feature. To execute a complex script into a different instance and end with exactly the same dataset is an hard problem in general...
I believe that we should boldly go to that direction, and this should be just the start of a series of simplifications that should be made to Redis key mechanisms in order to reduce the complexity and improve the long term ability to keep it bug-free.