peanutzhen
用到了etcd，也有注册也发现服务，但是这里的发现服务是有问题的
他用的官方的 etcd resolver 会自动帮我监听，发现修改和下线上线的节点，就是在传递回ip地址的时候etcd 为了负载均衡是 用负载均衡策略（比如轮询、随机）选一个连接（gRPC 收到后，会为这些地址分别建立连接（connection pool）并且使用一个内置的 负载均衡器 来管理这些连接）。我们需要的key对应的缓存是分别在特定的 节点上，并不是随机去选取的，因此这里并不能使用官方的库维护 etcd上面的节点，我们要自己手动维护etcd上面 组对应的ip地址列表。
官方 etcd resolver 的问题 在使用官方的 etcd resolver 时，它会自动监听 etcd 中服务节点的变化，并且采用负载均衡策略（如轮询、随机）来选择一个连接。这意味着每次发起请求时，可能会随机选择一个可用的节点进行通信。 然而，在这个缓存系统中，缓存数据是根据一致性哈希算法来决定应该分布在哪个特定的节点上的。也就是说，对于一个特定的 key，通过一致性哈希算法可以确定它唯一对应的缓存节点。如果使用官方的 etcd resolver 进行随机选择节点，就可能会导致请求被发送到错误的节点，从而无法获取到正确的缓存数据。 手动维护 etcd 节点列表的必要性 为了确保请求能够被正确地发送到根据一致性哈希算法计算出的特定节点上，需要手动维护 etcd 上组对应的 IP 地址列表。具体来说，可以在服务启动时从 etcd 中获取所有可用的节点信息，并将这些节点信息注册到一致性哈希环中。当需要获取某个 key 的缓存时，通过一致性哈希算法计算出该 key 对应的节点地址，然后直接向该节点发送请求。