关于一致性哈希算法在游戏服务器端的思考

关于一致性哈希算法在游戏服务器端的思考

  1. 需求分析

    • 后端有很多逻辑node节点(not-section binded),节点启动后注册到注册中心
      • node本身有状态,有内存cache,有过期时间
    • 客户端登陆,需要从注册中心分配一个node
      • a. 客户端需要在一段时间内连接固定节点(长连接)。因为内存有状态,最好支持客户端断线一段时间再次连接还是之前的节点
      • b. 节点最好是相对负载均匀的
      • 考虑新增/减少节点(宕机),最好保证a/b两点
  2. 引入一致性hash算法

    • 算法主要参考:dubbo ConsistentHashSelector 并做部分修改

    • 算法测试

      • a. 初始运营服5个,每个服10w注册,即50w注册。后端一个node承载1w,后端初始50个node

        算法步骤

        1. 初始化50w个rid,rid格式 serverId_id,shuffle
        2. build hash ring,replicaNumber(虚拟节点) = 160
        3. 依次遍历shuffle后的rid list,从hash ring select
        4. 看node整体分布情况(最大、最小、平均、标准差)
        5. 不断调整虚拟节点数目

        统计结果展示

        [7743, 8777, 8847, 8932, 8985, 9100, 9185, 9229, 9274, 9308, 9330, 9478, 9625, 9638, 9660, 9697, 9699, 9728, 9748, 9791, 9794, 9847, 9904, 10021, 10053, 10055, 10063, 10073, 10257, 10258, 10263, 10291, 10356, 10374, 10376, 10486, 10519, 10521, 10581, 10620, 10628, 10678, 10719, 10783, 10790, 10837, 10859, 11001, 11120, 12099]
        replica:160 |max:12099|min:7743|mean:10000.0|std:750.9|median:10054.0

        [9142, 9393, 9518, 9525, 9549, 9578, 9626, 9659, 9667, 9690, 9765, 9777, 9811, 9831, 9848, 9850, 9886, 9889, 9909, 9933, 9940, 9958, 9998, 10002, 10007, 10029, 10030, 10050, 10052, 10129, 10152, 10158, 10182, 10184, 10202, 10212, 10213, 10215, 10247, 10265, 10273, 10279, 10297, 10321, 10322, 10342, 10358, 10420, 10456, 10861]

        replica:1280 |max:10861|min:9142|mean:10000.0|std:317.2|median:10018.0

        结论

        1. 在节点不动态变化的情况,算法可以保证同一个rid每次都select到同一个node
        2. 通过调整replicaNumber,可以让node负载相对均匀
        3. 因为rid样本是可确定的,所以可以这种方式不断调整hash ring的参数,来符合实际的负载情况,即是可预测的
          • 如果一个node负载是1w,那么目前会有node overloaded。实际可以考虑将node负载调整为9k
      • b. 从a的结果上看,看似很美好,比较好的满足我们的需求,but 我们还要考虑新增/减少节点的情况

        假设

        1. 让我们问问题先简化一下 因为我们本身是长连接,所以假设之前的50w个rid全部连接到已知的50个node

        2. 需求:准备开始开第6个服,在新增10个node,用来承载10w人,并重建hash ring

        测试输出

        // 这个是已经连接的50个node的数据分布情况,和a的结果一致,也验证了本身一致性hash算法的正确性

        [9142, 9393, 9518, 9525, 9549, 9578, 9626, 9659, 9667, 9690, 9765, 9777, 9811, 9831, 9848, 9850, 9886, 9889, 9909, 9933, 9940, 9958, 9998, 10002, 10007, 10029, 10030, 10050, 10052, 10129, 10152, 10158, 10182, 10184, 10202, 10212, 10213, 10215, 10247, 10265, 10273, 10279, 10297, 10321, 10322, 10342, 10358, 10420, 10456, 10861]

        replica:1280 |max:10861|min:9142|mean:10000.0|std:317.2|median:10018.0

        // 这个是新增10个node后的数据分布情况

        [1499, 1534, 1569, 1652, 1673, 1675, 1684, 1712, 1713, 1723, 10585, 10948, 11119, 11162, 11173, 11177, 11223, 11267, 11270, 11324, 11348, 11404, 11504, 11511, 11530, 11546, 11547, 11569, 11570, 11610, 11631, 11635, 11674, 11681, 11684, 11706, 11742, 11750, 11758, 11769, 11796, 11815, 11842, 11855, 11878, 11908, 11912, 11921, 11933, 11952, 11991, 11996, 12019, 12068, 12068, 12077, 12089, 12157, 12215, 12657]

        replica:1280 |max:12657|min:1499|mean:10000.0|std:3783.8|median:11620.5

        结论

        1. 我们在假设条件成立的情况下,我们期望新增的10w客户端全部负载到新的10个node上。但是从结果上看,其实是负载了整个的60个node上(这个其实也是相对均匀的)。这个和我们预期完全不相符
        2. 从一致性hash的算法实现上看,对于新增/减少节点来说,一定是会有一部分客户端重新分配节点,这个是由算法本身决定的
  3. 继续沿着一致性hash的思路走

    • 主要问题
      • a. 如何解决新增/减少节点,部分客户端select节点变化的问题?
      • b. 如何解决新增节点,整体的负载均匀问题(甚至分配过程中的相对均匀,即不会出现分配过程中某一个node先达到上限,而是整体均衡)?
    • 一些扩展思路
      • 对于a
        • 可以在客户端select到一个节点后,将客户端和节点的映射关系保存下来。客户端断线再连接还是同一个节点。当内存数据过期后,下次再连接,可以再次重新映射
        • 可以在每次客户端断线时,强制刷新一下对应的node内存数据到外部缓存。这样当客户端再次连接时,如果切到了其他的node也没有关系,只不过额外走一次加载流程。不过如果是频繁断线重连的情况下则需要额外注意
      • 对于b
        • 可以引入有限负载一致性哈希,即node有负载的概念。首选还是按照正常的一致性hash算法选择某一个node。不过区别是会判断此node是否overloaded,如果overloaded,则继续从hash ring寻找下一个node,直到未超过负载。引入该算法后,对于2b中的测试来说,新的10w人会被主要分流到新增的10个node上
          • 我目前实现的一个版本是可以设置一个node的负载上限比如9000
          • 不过引入负载后,就需要额外维护负载这个指标。比如客户端内存数据过期后,将客户端所属的node的负载-1
    • 思考
      • 如果我们按照一致性hash的思路实现需求,是可以做的,只不过有不少额外成本。那这样的必要性大吗?
      • 一致性hash最早的例子是用在如memcache,根据key hash到对应的node。而这个应用场合是缓存,即使key没有命中的话(增/减),那么对于应用层来是可以重新从数据库加载的。所以其实应用场合并一定特别适合
      • 对于我们的需求,我们手动实现一个基于负载的类似轮询算法,是不是更简单?
  4. 再换一个思路 假如我们把连接和数据分开呢?

    • 假如我们让客户端不是直接连接后端的node,而是一个网关呢?
    • 网关负责连接,node负责数据
    • 我们有一组网关,网关的数量是固定的(当然也可以在维护时间调整),先通过客户端rid做hash运算到对应的网关(为保证均匀,可以考虑一致性hash)
    • 然后再通过网关和后端node的映射关系得出客户端该路由到那个node上。这样node节点动态变化时,只需要修改路由表中网关和动态node之前的关系即可
    • TODO
      • Consistent Hashing + Distributed Hash Table (Orleans)
  5. ref

    • Improve consistent hashing load balancing with a new algorithm(patch for 3.0)
    • 蚂蚁金服服务注册中心如何实现 DataServer 平滑扩缩容
    • Dubbo 一致性Hash负载均衡实现剖析
    • Making The Case For Building Scalable Stateful Services In The Modern Era
    • {技术}某分布式应用实践一致性哈希的一些问题

你可能感兴趣的:(关于一致性哈希算法在游戏服务器端的思考)