[zeromq-dev] RPC design pattern
sustrik at 250bpm.com
Mon Apr 19 10:11:36 CEST 2010
> OK, that part is starting to make more sense now. I'm playing around
> with putting my service definitions in SRV RR records (actually
> DNS-SD, but same concept). The RFC  spells out a load balancing
> algorithm for client programs based on the weight and priority of each
> record. It's not round robin, but similar. The idea is that the
> person registering the service knows the attributes of the hardware
> that it's running on and can hint to the client agent that X node has
> more capacity than Y node although they are both offering the same
> service. Just thinking out loud, but is there a way to provide those
> hints to 0MQ or should we just trust that 0MQ is better at dynamic
> load balancing than we could hope to be using deployment time hints?
0MQ does a dumb load-balancing (round robin). The assumption is that we
don't know processing capacity of each peer in advance. If a particular
peer is not able to keep up, it's queue gets filled up and no more
messages are dispatched to it. Once it processes some messages, and thus
empties the queue, we can add the connection back to round-robin.
If we knew the weights in advance (as specified with RFC 2782) we can in
theory write a load-balancing that would hit the queue limits less
1. Do we even care?
2. User has to manually set the weights = work = increased cost.
3. There's no guarantee that user will set the weights so that they
reflect the reality.
>> When one of them fails, up to ZMQ_HWM requests is queued for it and once
>> the limit (HWM) is reached it no more request will be sent to that
>> server. Once it gets back online queued requests will be sent to it and
>> load-balancing starts to dispatch new requests to it automatically.
> The part that confuses me about this is in a traditional RPC scenario
> you may be calling services that have side effects or that lack
> idempotence, per se. You'd want the message to be handled by the
> first reachable service provider and no others. Unless I
> misunderstand what you're saying, it seems counter-intuitive that
> RPC-style messages would queue up rather than failover to alternate
> instances or fail fast when there are no reachable instances?
The question is: How do you know the instance is reachable. You can
never tell before you actually get a reply from it. To get a reply you
have to send a request. That means that at least 1 message (the request)
is "queued" for delivery to the service with unknown availability.
There's no way to avoid that.
As for why 0MQ allows more than one message in the queue - it's for
efficiency's sake. Having at most one message sent to particular
instance means that processing of requests proceeds in lock-step
fashion, which can be severely inefficient, especially in scenarios
where there's non-negligible roundtrip time between client and the service.
> I probably need to go back and read the whitepapers again now that I'm
> becoming more familiar with the concepts.
Please, keep the list posted about your experience with 0MQ and RFC
2728. The matter is of critical importance for further development of
0MQ and the more experience we as a community can gather about
addressing and naming issues, the better.
More information about the zeromq-dev