4 ms·
> If our first choice for a server goes offline, we simply move the key to the second server in the list (which becomes our new first choice). It doesn't make
by zvrba 5y ago
> If our first choice for a server goes offline, we simply move the key to the second server in the list (which becomes our new first choice).
It doesn't make sense: how do you move the keys from an offline server? The pictures in the post suggest that keys are not redundantly stored on other servers.
- pkhuong 5y agoMany load-balancing use cases (e.g., caches or stateless services that simply work better with affinity) don't need the old data. If you need redundancy, the ordering also tells you where to duplicate the data: durably send updates to the first k + 1 servers in the list, and you're safe against up to k failures.
- henns 5y agoYou can couple Rendezvous Hashing with a redundancy method like replication or erasure coding. The default for Tahoe-LAFS (a distributed filesystem that uses a form of Rendezvous Hashing) uses erasure coding to split each file into (by default) 10 segments of which any 3 are necessary to reconstruct the file. Those 10 segments are then stored across the first 10 servers in the list. [https://tahoe-lafs.readthedocs.io/en/latest/architecture.html#server-selection https://tahoe-lafs.readthedocs.io/en/latest/architecture.htm...] That way, even when servers go away with your data (whether due to crash or even network partitions(!)), you still have a decent chance to locate your data.