ZeroMQ

Republishing Updates from Clients

In our second model, changes to the key-value store came from the server itself. This is a centralized model that is useful, for example, if we have a central configuration file we want to distribute, with local caching on each node. A more interesting model takes updates from clients, not the server. The server thus becomes a stateless broker. This gives us a few benefits:

• We’re less worried about the reliability of the server. If it crashes, we can start a new instance and feed it new values.

• We can use the key-value store to share knowledge between active peers.

To send updates from clients back to the server, we could use a variety of socket patterns. The simplest plausible solution is a PUSH-PULL combination (Figure 5-5).

Figure 5-5. Republishing updates

Why don’t we allow clients to publish updates directly to each other? While this would reduce latency, it would remove the guarantee of consistency. You can’t get consistent shared state if you allow the order of updates to change depending on who receives them. If two clients make changes at the same time, but to different keys, there will be no confusion. But if the two clients try to change the same key at roughly the same time, they’ll end up with different notions of its value.

There are a few strategies for obtaining consistency when changes happen in multiple places at once. We’ll ...