TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Work Distribution with Jump Consistent Hashing

23 pointsby artellectualalmost 2 years ago

4 comments

User23almost 2 years ago
I’m surprised that rendezvous hashing[1] isn’t more popular given that it’s considerably easier to understand and implement than consistent hashing while having all the same pleasant properties.<p>[1] <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Rendezvous_hashing" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Rendezvous_hashing</a>
评论 #36244305 未加载
sacnoradhqalmost 2 years ago
Unfortunately, the purity of simplicity here is deceptive and doesn&#x27;t scale well to the real world where some jobs are resource hogs (job variance) and hang (nondeterminism and error handling). This is reinventing an HA job scheduler but without retries or load leveling. If you want even working sets without hotspots, then you need a job scheduler aware of workers&#x27; load state. This cannot happen by blindly rolling dice and giving it a cute name.
评论 #36252160 未加载
standapartalmost 2 years ago
Nice post! Couple things that might be useful:<p>1. While JCH will usually be the most performant hashing method, naively, removing a node will affect all nodes of higher order. This makes the logic of node deletions somewhat more complex than (say) Discord&#x27;s hash ring. This is why JCH is more common for long-term, distributed, redundant storage -- where the topology changes far less frequently.<p>2. For sharding, what makes distribution hard is not so much the hashing but consensus on the cluster state -- this is the hidden problem. Bryan Hunter&#x27;s talk on Waterpark (<a href="https:&#x2F;&#x2F;youtu.be&#x2F;9qUfX3XFi_4" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;9qUfX3XFi_4</a>) is a excellent example of what you can do when you can set things up so that the topology is fixed. In fact, this approach makes things so straight forward that it is shared by Riak, where the number of vnodes is fixed.<p>However, if you have a rapidly changing topology (like several Kubernetes clusters that are frequently scaling up and down), you can often need some sort of consensus mechanism to make sure every node has a consistent view of the cluster. In my experience, this usually ends up being the most complex part of distribution problem to solve.
评论 #36252191 未加载
Dowwiealmost 2 years ago
Worth noting Discord&#x27;s consistent hash ring implementation in pure Elixir. It&#x27;s very easy to use and maintained by Discord (yay): <a href="https:&#x2F;&#x2F;github.com&#x2F;discord&#x2F;ex_hash_ring&#x2F;">https:&#x2F;&#x2F;github.com&#x2F;discord&#x2F;ex_hash_ring&#x2F;</a>
评论 #36243320 未加载
评论 #36252032 未加载