Hacker News Reader

Comment by moab | Hacker News Reader

Can you elaborate on why? As someone who works on parallel/concurrent algorithms and data structures a single-threaded system design seems anathema to most research over the past decade (maybe excluding H-Store, which uses local single-threadedness in an interesting way).

View on HN

This reminds me of LMAX, who found the fastest way to build their stock exchange was to make the core logic single-threaded, surrounded by multithreaded I/O:

https://www.martinfowler.com/articles/lmax.html

I believe other (grown-up/legacy!) exchanges work the same way.

I wonder how much of the direction of concurrency research is driven by the fact that there is much more publishable work to be done in managing concurrency rather than avoiding it!

The disruptor isn’t single threaded at all. Maybe you mean it can pin a core to a consumer that just busy waits on the queue. That is a common technique used in very low latency systems when not running on a real time OS.

The matching engine is single threaded. It uses disruptors to communicate with IO threads.

Disruptor benefits from lock free access using a ring buffer. You can get amazing results with a single thread but that aspect isn't central to the pattern.

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.

KeyDB 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.

It 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.

Couldn't you just rollback the change or fix the lua script?

Or 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

That'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.

You can run multiple instances of redis on the same machine, which gets you parallelism from multiple processes instead of multiple threads. There's some extra deployment effort in doing so, but it's not generally a big issue.

It also isn't exactly single threaded. It calls fork when it wants to persist data to disk, which is functionally similar to starting up a thread to do disk IO.

Going from a single processes holding all your data to having your data sharded across multiple processes can be more than a little effort.

Also, it might now have any benefit for you. Imagine a certain key is particularly hot. Having one multithreaded redis process handling access to it might speed things up. Running multiple sharded redis processes won't, since only one of them will have that key.

Most redis users are running multiple instances regardless. That some of them happen to be on the same machine is largely a detail.

It would make a little difference if there was a single hot key, but that's a bit unusual. Typically there's some subset of keys that are hot, and you can get them to hash across instances. People also tend to cache those values on the clients, as banging on redis constantly is a waste.

> but that's a bit unusual

It's pretty common when using a single Redis stream as a lightweight Kafka.

Doesn't that end up duplicating lots of data and work since the processes are independent? They don't share data do they?

fork() on Linux (and many other OSes) shares pages between the parent/child processes in a copy-on-write scheme

That doesn’t mean multiple long running processes will share memory though unless they actually create a shared mapping, which I think the gp is referring to. In addition to tremendous memory waste this also kills cache performance.

I'd presume the persistence / I/O process would be pretty short lived: its job is to save a snapshot to disk so there's not much reason to let it live long.

How does that share data between multiple Redis processes?

Reply on news.ycombinator.com