3 ms·
Not parent but the single threaded approach really shines when executing Lua scripts in Redis. Except for some very specific edge cases, the execution of a scri
by nicolaslem 7y ago
Not parent but the single threaded approach really shines when executing Lua scripts in Redis. Except for some very specific edge cases, the execution of a script is atomic and since no command is ever processed concurrently you can rule out data races.
I am sure it would be possible to provide these guaranties while offering concurrent execution but most likely at the expense of a simple design.
- jdsully 7y agoKeyDB provides that guarantee via a lock. However that does mean long running scripts don’t benefit from the multithreading. Ditto for modules. The goal is 100% Redis compatibility so I can’t compromise on atomicity.
- avar 7y agoIt shines right up until the moment someone writes a Lua command that takes more than a trivial amount of time, now your entire server is blocked in a pile-up of connections waiting on some relatively trivial amount of code being executed.
- aflag 7y agoCouldn't you just rollback the change or fix the lua script?
- thamer 7y agoOr just embrace modern hardware and use threads. This is the experience many people have running Redis in production with 21st-century hardware: https://twitter.com/rbranson/status/540565059337195520 https://twitter.com/rbranson/status/540565059337195520
- cal97g 7y agoThat guy is saying that alternatives to redis are better, meanwhile he's still using redis..
- aflag 7y agoThat's a different issue. If they're in that situation without any custom scripts and the latency is cropping up, they should consider using a different tool or changing their codebase.