tiankonguse edited a comment on issue #649: 支持热点情况下的一致性hash？ URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-477448587 > （流量本身的）key为url，后端存储按照这个url全局有序。流量的（写入）存储过程中牵扯若干的词典，词典可能以domain，或者site为单位。所以server如果以这样的url为range做sharding条件，可以比较有效的提升词典cache的命中率。比如一个server a，处理的range是 [a.test.com, b.test.com) ，那server只需要cache住一条词典（test.com）就足够了。但是这样的话，test.com下如果有流量爆发的场景，明显server a就负载极高，需要一些负载均衡措施。 > > 如果我们使用了一致性hash，由于使用了hash等，[a.test.com, b.test.com) 可能就扩散到很多很多个（甚至所有的）server都有可能处理到。那这样的话，很多很多个server都需要cache test.com这条词典。同理，由于hash打破了这种domain，site的规律，所有的server都需要cache多条词典；而cache不可能无限增长。所以这样就有可能出现cache颠簸的问题（cache频繁的更新） > > 感觉这种场景下，产生了cache颠簸的主要原因应该是hash函数；而没有hash函数，又不知道如何将热点打散到全局。所以这种场景的负载均衡有什么好办法解决么？ > > 不要太care这个是否sharding。我们这里sharding是因为主要希望cache命中率足够。主要是希望有这样的一个负载均衡方案，可以： > > 1. 热点下的负载均衡 > 2. cache命中率足够，不会颠簸。 这个例子其实有几个关键的地方没有说清楚。 1. 你是使用域名(a.b.vom) 还是 url(a.b.com/xx/xx/xx) 作为一致性HASH的KEY的？ 2. 如果是使用域名的话，那KEY量其实很少的，使用一致性HASH没意义了吧，你应该使用URL来当做KEY。 3. 如果URL当做KEY依旧存在热点，那说明是固定的一个或几个页面非常热，这个时候，按照上面我提到的方法就可以解决：一致性HASH下是路由节点，每个路由节点下根据实际的访问量扩容即可。 当然也可以手动降低这个路由节点的权重（虚拟节点个数），从而将其他无关的流量导走（概率问题，不一定有效）。 至于你说的监控热点，自动化调整权重什么的，只是上面的手动操作改成自动操作，依旧是概率问题，不一定解决问题。 扩容才是根本的解决方法。 PS：恰好这几天我也在思考这个问题，写的有一篇文章，可以一起讨论下： https://mp.weixin.qq.com/s/yyqEwfEgEWYwWoalFLcuSw
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
