老师
我想问下，我的理解如下
这个一致性哈希的架构应该有3个组件，
1 哈希环（所有的机器），
2 zookeeper存每个机器负责的范围，
3 然后负载均衡
每次加机器或者减少机器，机器要和zookeeper进行交流，更改每个机器负责的数据范围，并且建立心跳保证每个机器在线
request 来了以后，首先过LB， LB有缓存的从zookeeper拿到的在线机器的数据，然后根据LB策略选一个机器IP，如果选的机器不负责该request，机器自己会forward到正确的机器处理请求，这个地方LB不缓存每个机器对应的数据范围，只是单独的根绝负载均衡策略选机器
我的理解正确吗？
我理解的两种实现方式,
config service, 像你说的zookeeper, 每台新机器都会在这里register 并且和config service 同步statue, request 来了以后talk wtih config service, 获得具体host 的信息
pros:
强一致, zookeeper 本身提供强一致
cons:
引入了extra 的service, 增加了复杂度
去中心化, 所有的机器都一个样, 用gossip protocol 一类的eventual cinsistency 相互之间传输信息
每台机器上都有整个集群的信息, rerquest 来了以后, 通过LB 和任意一台机器唠嗑, 如果不属于当前机器服务范畴, 则forward request
pros: 不需要config service
cons: 会有数据delay
1 这种没有LB是吧 client先从config service拿到host信息 再由client直接访问server是吧
2这种感觉就是我说的吧 我觉得这种还是输需要config service吧 就是注册中心 因为要维护心跳 并且host有疑问的时候需要问config service
config service 也有LB, 这个并不冲突, 是client 直接访问server
第二种是没有的, 整个集群人人平等, 这个心跳是host 与host 之间相互ping, 比如A ping B , b 没反应, 这个时候有两种情况, 要么A 自己歇菜了, 要么B 歇菜了, 这个时候A 会去ping C, 如果C 有了回复, 就说明是B 歇菜了
host 之间如果有数据冲突就投票, Paxos 就是一种方式,
第二种是没有config service的哈，一般是使用gossip protocol去propagate membership change。
有数据冲突可能会来个read repair ？
也是一种方式， ddia 有解释
我觉得大家已经讨论出了结果，大家主要讨论了 node membership 的问题，需不需要 LB。我认为这个问题的答案像 @vincent.g 说的，是有几个不同方案的。 Consistent Hashing 并没有规定具体用户则怎么能找到这个 node。