You can have a look at Tengine. We are developing the consistent hash module: <a href="https://github.com/taobao/tengine/pull/68">https://github.com/taobao/tengine/pull/68</a><div><br></div><div>This module is current used in about 200 production servers. If you like it, we  can give you the pure Nginx consistent hash module.<br>
<br><div class="gmail_quote">2012/11/1 rmalayter <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Maxim Dounin Wrote:<br>
><br>
> Percentage values are stored in fixed point with 2 digits after<br>
> the point.  Configuration parsing will complain if you'll try to<br>
> specify more digits after the point.<br>
><br>
> > How many "buckets" does the hash table for split_clients<br>
> > have (it doesn't seem to be configurable)?<br>
><br>
> The split_clients algorithm doesn't use buckets, as it's not a<br>
> hash table.  Instead, it calculates hash function of the<br>
> original value, and selects resulting value based on a hash<br>
> function result.  See <a href="http://nginx.org/r/split_clients" target="_blank">http://nginx.org/r/split_clients</a> for<br>
> details.<br>
><br>
<br>
</div>So clearly I am down the wrong path here, and split_clients just cannot do<br>
what I need. I will have to rethink things.<br>
<br>
The 3rd-party ngx_http_consistent_hash module appears to be un-maintained,<br>
un-commented. It also uses binary search to find an upstream instead of a<br>
hash table, making it O(log(n)) for each request. My C skills haven't been<br>
used in anger since about 1997, so updating or maintaining it myself would<br>
probably not be a fruitless exercise.<br>
<br>
Perhaps I will have to fall back to using perl to get a hash bucket for the<br>
time being. I assume 4096 upstreams is not a problem for nginx given that it<br>
is used widely by CDNs.<br>
<br>
A long time ago Igor mentioned he was working on an variable-based upstream<br>
hashing module using MurmurHash3:<br>
<a href="http://forum.nginx.org/read.php?29,212712,212739#msg-212739" target="_blank">http://forum.nginx.org/read.php?29,212712,212739#msg-212739</a><br>
<br>
I suppose other work took priority. Maybe Igor has some code stashed<br>
somewhere that just needs testing and polishing.<br>
<br>
If not, it seems that the current "ip_hash" scheme used in nginx could be<br>
easily adapted to fast consistent hashing by simply<br>
  -using MurmurHash3 or similar instead of the current simple<br>
multiply+modulo scheme<br>
  -allowing arbitrary nginx variables as hash input instead of just the IP<br>
address during upstream selection<br>
  -at initialization utilizing a hash table of 4096 or whatever configurable<br>
number of buckets<br>
  -fill the hash table by sorting the server array on<br>
murmurhash3(bucket_number + server_name + server_weight_counter) and taking<br>
the first server<br>
<br>
Is there a mechanism for sponsoring development along these lines and<br>
getting it into the official nginx distribution? Consistent hashing is the<br>
one commonly-used proxy server function that nginx seems to be missing.<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?2,232428,232434#msg-232434" target="_blank">http://forum.nginx.org/read.php?2,232428,232434#msg-232434</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Weibin Yao<br>Developer @ Server Platform Team of Taobao<br>
</div>