[GitHub] [incubator-brpc] GardianT edited a comment on issue #649: 支持热点情况下的一致性hash？

[GitBox <gi...@apache.org>]

GardianT edited a comment on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-476999369
 
 
   （流量本身的）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命中率足够，不会颠簸。
   
   

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@brpc.apache.org
For additional commands, e-mail: dev-help@brpc.apache.org