Skip to content

Instantly share code, notes, and snippets.

@rektide
Last active December 20, 2015 04:29
Show Gist options
  • Save rektide/6071655 to your computer and use it in GitHub Desktop.
Save rektide/6071655 to your computer and use it in GitHub Desktop.
ZeroMQ for Use in Clustered HTTP serving

The concept of a clustered IP is just that there is a public IP which connects to multiple backend systems. Many front-end firewall boxes perform such a duty of standing at the front of that IP and forwarding incoming connections to application servers, also often offering services such as sticky sessions that help incoming HTTP traffic to continually make it to the same box. Apache itself, Nginx, HAProxy, all these are often used as forwarding agents, a front end recieving traffic on a bound address and forwarding it to destination application services.

Mongrel2 is another such HTTP forwarding layer. It's front end speaks HTTP and it's back end (where it forwards traffic) is ZeroMQ. It feeds the traffic to whomever picks the forward traffic up. This is a push/pull egress to the app server. The app server processes the request and sends it back over a pub/sub connection.

Hacking document on Sockets: https://github.com/zedshaw/mongrel2/blob/master/docs/manual/hacking.tex#L237

Visualized use of ZeroMQ sockets: http://www.slideshare.net/j2d2/zeromq-super-sockets-by-j2-labs/24

What does ZeroMQ have to say about these socket types?

The first pair mentioned is a push/pull egress:

The ventilator's PUSH socket distributes tasks to workers (assuming they are all connected before the batch starts going out) evenly. This is called load balancing... The sink's PULL socket collects results from workers evenly. This is called fair-queuing.

Mongrel2 front-ends the connection, talking to the HTTP server. Any requests it gets it immediately ventilates, PUSHing the data. Eventually one of the worker sinks will PULL that serialized request in and process it.

Once it's done, the app server egresses the response. Mongrel2 instances are SUBscribed to channels, and the application has only to PUBlish to the node it initially PULLED the request in from. Mongrel2 then takes that subscribed reply and sends it to the client that it is serving.

Interesting features:

  • load balancing of incoming work. Workers pick up synchronously as they are able, replying asychronously once they have completed processing. If the workers are busy, ZeroMQ buffers until workers arrive.
  • mongrel2 remains the front end point of presence for the client.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment