debug确认了大致原因：consistent hash策略实现时，虚拟节点因子是160，我们生产环境的某个服务有80多个节点，每个节点的权重是10左右，总的虚拟节点大致为8010160=128000个，在consistent_hash初始化时，会使用qsort排序，耗时200多ms；另外，dyups机制的第一个worker处理时，还有sandbox机制，耗时会增加一倍，这样总耗时就接近500ms了，导致worker来不及处理循环内的其它很多事件，像是短暂夯住了一样。
关于这个问题，我个人理解是，在dyups动态更新的场景中，consistent hash的初始化逻辑不太合适导致的，如果每次都要重新初始化hash环，那就要控制虚拟节点的上限，否则就只在第一次初始化hash环，后面增删节点时避免重新初始化。
不知道作者关于这块的设计是如何考虑的？是否有更好的优化或者规避方法？