edwingeng/doublejump

A revamped Google's jump consistent hash

doublejump's Issues

Remove是个危险操作，使用有隐患

场景：
假设有A,B,C,D,E五个节点提供服务，某时刻Remove了节点C，此时数据被hash到A,B,D,E四个节点，假设之后又过了一段时间，B发生了重启（无论B是从类似etcd中获得节点列表，还是通过其他方法发现其他存活的节点），那此时B节点对数据的hash是和其他节点完全不一致的。
假设再Remove节点C后，对A，B，D，E均调用Shrink，则Shrink之后各节点对数据的hash，和节点移除前基本是完全不一样的（测试和推理均可说明），这也是不合适的（违背了迁移数据最少的初衷）
感觉上面场景的问题，解决办法应该是，在B重启后，仍然获取A，B，C，D，E节点，然后调用Remove C节点。但这个在集群比较大时，就比较混乱了。
感觉这个实现应该是节点替换的场景比较适用，比如B节点挂了，立即添加F节点替换B。

====上面的推测分析是否正确，如何解决比较合适？

would be great to see meaningful names of members/variables

instead of single-character names such as n, a, f, m, etc. it would be more useful to see names that mean something.