jamesge edited a comment on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-477004736
@GardianT
你说的这种情况不是一致性哈希能解决的。用到一致性哈希的场景的前提之一就是server加载什么数据由client决定，但这里server加载什么是由自己决定的，类型场景还有机器学习model
serving。这种场景中一个记录什么数据在哪里的高可用模块是无法绕开的，经常叫Meta Ser
jamesge commented on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-477004736
@GardianT
你说的这种情况不是一致性哈希能解决的。用到一致性哈希的场景的前提之一就是server加载什么数据由client决定，但这里机器加载什么是由机器自己决定的，类型场景还有机器学习model
serving。这种场景中一个记录什么数据在哪里的高可用模块是无法绕开的，经常叫Meta Server或Place
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是
GardianT commented 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
jamesge edited a comment on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-476993500
@tiankonguse
说的对。如果对值的一致性要求放低，其实承载流量的server也可以在内存中缓存最热的N个Key。如果要在server间共享对热Key的缓存，可以对热Key加上后缀做进一步的散列。
--
jamesge commented on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-476993500
@tiankonguse
说的对。如果对值的一致性要求放低，其实承载流量的server也可以在内存中缓存最热的N个Key。如果要在server间贡献热Key的缓存，可以对热Key加上后缀做进一步的散列。
--
tiankonguse edited a comment on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-476962335
1. 增大虚拟节点的个数， 可以降低热点集中在一个节点的概率
2. 如果某一个单Key是热点，那不管如何增加虚拟节点数，单key的热点都不可能被均摊
此时有两个方法
1. 多个一致性hash环（可能会造成资源浪费）
2. 只有一个一致性hash环，但是环后面的节
tiankonguse edited a comment on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-476962335
1. 增大虚拟节点的个数， 可以降低热点集中在一个节点的概率
2. 如果某一个单Key是热点，那不管如何增加虚拟节点数，单key的热点都不可能被均摊
此时有两个方法
1. 多个一致性hash环
2. 只有一个一致性hash环，但是环后面的节点不是对应一个实例，而
tiankonguse commented on issue #649: 支持热点情况下的一致性hash？
URL: https://github.com/apache/incubator-brpc/issues/649#issuecomment-476962335
1. 增大虚拟节点的个数， 可以降低热点集中在一个节点的概率
2. 如果某一个单Key是热点，那不断如何增加虚拟节点数，单key的热点都不可能被均摊
此时有两个方法
1. 多个一致性hash环
2. 只有一个一致性hash环，但是环后面的节点不是对应一个实例，而是多个实例
jamesge commented on a change in pull request #694: Health check by rpc call
URL: https://github.com/apache/incubator-brpc/pull/694#discussion_r269019674
##
File path: src/brpc/socket.cpp
##
@@ -92,6 +96,15 @@ DEFINE_int32(connect_timeout_as_unreachable, 3,
"t
jamesge commented on a change in pull request #694: Health check by rpc call
URL: https://github.com/apache/incubator-brpc/pull/694#discussion_r269020754
##
File path: src/brpc/socket.cpp
##
@@ -92,6 +96,15 @@ DEFINE_int32(connect_timeout_as_unreachable, 3,
"t
zyearn commented on a change in pull request #694: Health check by rpc call
URL: https://github.com/apache/incubator-brpc/pull/694#discussion_r268964773
##
File path: docs/cn/client.md
##
@@ -242,7 +242,7 @@ locality-aware，优先选择延时低的下游，直到其延时高于其他机
| -
12 matches
Mail list logo
