NoSQL中负载均衡系统如何解决热点问题，提高可用性？

发布时间：2025-11-05 09:49:53 来源：创站工坊 作者：应用开发

一、负载背景

表格存储(原名OTS)是均衡决热一款阿里自研的NoSQL多租户分布式数据库，本文主要会分享在表格存储中，系统负载均衡系统如何解决热点问题。何解

1、点问表格存储架构

下图是题提表格存储系统最基本的一个架构图：

实际上，表格存储还有很多其他的用性模块，这里我们主要看下和本文内容相关的负载部分，并且也是均衡决热最核心的一部分。

从下往上看，系统表格存储是何解基于飞天内核的产品，飞天内核主要提供了分布式共享存储、点问分布式锁服务、题提通信组件等基础功能。用性

然后上面是负载表格存储的引擎部分，主要由worker和master组成，一个集群中有少量的master和大量的worker，master负责管理worker的状态，并将partition调度到各个worker上提供对外的服务器租用服务。

再上层是前端组件，提供统一的http服务，并把这些请求转发到worker上。

2、负载均衡相关的背景

在表格存储系统中，我们会对用户数据按分片键进行切分，切分之后的一个分片，我们叫做partition，它是表格存储系统里面，调度的基本单元，所有调度都是基于partition的。

partition可以做如下操作：

上述的所有对partition的操作，包括move、split、merge、group，都是秒级别的。

3、热点问题

在NoSQL多租户系统中经常遇到的热点问题，主要分为以下两类：

1)用户访问热点

用户访问热点又分为合理的突发式访问热点，以及不合理的突发式访问热点：

2)机器热点

机器的热点问题指的是，该机器的cpu，网络流量由于某些原因突然变高，该机器资源成为瓶颈，导致的热点。

通常，热点问题很难处理，主要有如下原因：

在表格存储系统中，对上述几个难点，我们都有对应的手段来解决。针对信息不全，定位难的问题，我们系统中有详细的partition级别统计信息，并且秒级别的partition move、split、merge、group功能也能很好地处理问题。

我们开发了一套负载均衡系统，它能收集信息、分析信息、解决问题，做到热点问题快速自动化解决，不需要人工参与。

二、负载均衡系统

接下来我们来看看表格存储中的负载均衡系统是如何自动化解决问题的。首先介绍负载均衡系统的架构，然后分模块来详细阐述各个模块的功能。

1、负载均衡架构

下图是负载均衡系统的架构图：

它主要包括LBAgent和LBMaster两个角色，其中LBAgent和worker进程部署在同一台机器上，它负责收集这台机器上的所有信息指标，包括worker进程和其他相关的进程。收集之后，在内存中维护近期的数据，同时把数据异步地写到外部存储系统中，在图中我们叫做MetricStore。

然后往上一层的模块是OpsServer，它是很薄的一层封装，主要提供了所有命令的http服务。

再往上是LBMaster。LBMaster中的collector模块通过OpsServer实时收集LBAgent的数据，并把近期的数据维护在内存中，这个模块我们叫做MetricsTable，它主要提供各种数据聚合和top排序的功能。

在线分析模块(OnlineAnalyzer)会实时分析MetricsTable中的近期数据，来检测是否有热点等异常的问题。如果有，则对这些信息进行进一步分析，来产生相应的解决action，并把这些action交给执行模块(Executor)。执行模块通过OpsServer把相应的action发送给worker或者master，由worker或者master执行action，最终解决热点问题。

同时，LBMaster还有一个离线分析模块(OfflineAnalyzer)，这个模块主要从外部存储系统MetricStore中读取信息，并对这些信息进行分析，以检测系统中是否有潜在问题，如果有，则对这些问题产生相对应的action，同样通过OpsServer交给worker或者master来执行，最终解决潜在的问题，做到防患于未然。

无论是在线分析模块还是离线分析模块，分析出的结果和action都会写入到一个外部存储系统中，这里叫做ResultDataStore，主要为了人工或者系统对这些action做进一步的分析。

LBMaster还提供一个白屏化的管控平台，这个管控平台能够实时查询LBMaster中的各种数据，同时也可以通过它来发送人工运维命令。

2、信息收集模块

信息收集模块有两个重点：

在表格存储系统中，任何一个模块处理请求时，都会顺便收集该模块的相关信息，这些信息会随着请求一起流动。如下图：

在图中，经过rpc模块，就会收集rpc模块中的统计信息;经过m1、m2模块时，也会一起收集m1、m2模块的信息;最终在返回用户前，异步地把信息推送到一个后台计算模块，这个模块会在后台用很少量的资源来汇总这些信息，并定期把信息推送给LBAgent。

由于这个后台计算模块，不在主路径上执行，是异步执行的，并且只占用少量的资源，可能只有一个核的cpu，所以对主路径的性能影响极小。

通过这种方式，我们既保证了能收集到各个模块的信息，同时尽可能地减少了对主路径性能的影响。

3、LBAgent模块

LBAgent模块主要有三个功能：

如图所示：

LBAgent端的接收信息模块不仅会收到worker进程的信息，还会收到系统中其他相关进程的信息。收到信息之后，LBAgent在内存中维护近期收集的信息，同时异步地将信息持久化到外部存储系统(MetricStore)中，以保存更长时间。LBMaster通过接口周期性地获取LBAgent内存中维护的信息。

4、LBMaster模块

LBMater模块是负载均衡系统最核心的模块。它的主要功能是：

我们结合下图来看：

collector负责收集信息，MetricsTable负责多维度信息的top查询，OnlineAnalyzer和OfflineAnalyzer模块分别分析在线实时信息和离线信息，ActionExecutor模块负责执行分析模块产出的action。

在action执行完成之后，ActionEvaluation模块会比较action执行前后的信息变化来判断这个action的效果，通过这种方式来反馈该action是否真正解决了问题。

此外，LBMaster还有一个配置相关的模块，各个模块都有灵活的配置，配置存储在外部存储系统中，配置模块会读取这些信息，然后同步给所有模块。所有模块的配置都支持实时地动态更新。

总结下，LBMaster的有如下特点：

接下来，我们从在线和离线两方面来看下负载均衡处理问题的情况。

5、在线分析路径

首先看在线分析路径。在线分析主要是分析短期信息，发现问题，最终解决问题，它主要有如下特点：

我们从架构图来看在线分析路径，可以发现：

在表格存储系统中有很多在分析的策略，下面举两个例子：

例1：热点问题导致读写队列满报错

例2：机器资源满导致的问题

负载均衡系统分析信息发现worker1的资源被打满，然后开始分析原因，发现是partition2导致的，进一步分析发现partition2的访问模式有问题。

比如说是单partitionkey的访问，或者顺序写访问，这种访问模式，split不能解决问题，所以负载均衡系统发出隔离partition2的action，action执行后，partition2被单独隔离到一台机器上服务。

此时，partition2不影响其他任何用户，并且也独享整体机器的资源，系统给它提供了强服务能力。

6、离线分析路径

与在线分析路径恰好相反的是，离线分析主要是分析长期信息，发现潜在的问题，并最终消除这些潜在问题，做到防患于未然。和在线路径相比，它的特点是：

从架构图来看，离线分析路径的数据来源于外部存储系统，并且由于分析的数据量很大，它会先借助外部分析系统做初步的分析，然后把分析结果写入到一张结果表中。

LBMaster的离线分析模块，对结果表中的信息做进一步的分析，然后发现问题，产生action。借助外部分析系统，大大减少了LBMaster的资源消耗，也大大增加了分析的能力。

接下来简单介绍两个离线分析策略的例子：

首先是auto merge，在NoSQL系统中，有部分的partition刚开始访问量很大，所以被切分成很多partition，随后这些partition的访问量可能会很低，甚至几乎没有，那么我们就可以将这些partition进行merge，来节约系统资源。

但是，不能通过短期统计数据判断一个partition访问量低就对它做merge，因为有些partition的访问模式是周期性的，所以要通过长期统计数据来判断一个partition能否做merge。

另外一个例子是，我们可以通过对长期数据的分析来预测某些用户的访问峰值，提前做好资源的调整。

7、效果展示

接下来，展示一些负载均衡系统上线后的效果。选取的都是有明显热点的业务，所以效果都非常明显。

如下图所示，负载均衡系统上线后，读操作的错误率和延时明显降低，吞吐量明显提高：

如下图所示，负载均衡系统上线后，写操作的错误率明显降低，并且在发现热点的时候，即错误率突然升高时，能立刻处理掉：

三、总结

从我自己做负载均衡系统的实践中总结了几点经验：

每个模块的信息统计是根本

如果没有信息统计，或者信息统计不全，都会导致问题定位不出来或是定位错误，整个负载均衡系统都无从谈起。并且这部分的工作量绝对不小，不是很简单就能做到信息全，并且也几乎不影响性能的。

把人工处理自动化是高效的策略

很多人刚开始都会觉得负载均衡要用到非常多的机器学习算法，这个可能是对的。

但是对于前期来说，我们把人工处理方式来进行自动化处理，可能就能解决90%以上的线上问题，并不需要高大上的机器学习算法。在经过这个阶段之后，一些难点问题，或者预测性的策略方面，再去考虑机器学习的东西。

策略配置丰富，控制灵活

每个策略都要有一些阈值或者条件，这些条件都不能写死在系统中，都要由配置的方式来传入，因为线上的情况差异非常大，只有这样才能有机会针对不同的业务、不同的场景进行配置定制。

系统快速迭代，支持差异化配置

负载均衡系统是一个要求快速迭代的系统，比如今天发现线上一类问题，就需要尽快写出策略上线，来解决线上的问题。

再者，由于每个业务的特点不同，访问模式的差异非常大，对可用性的要求也会有很大区别。

所以这里就需要非常灵活的配置，对于不同的业务，也许是同一个策略都会需要不同的配置才能达对这个业务而言的理想效果。

Q & A

Q1：请问表的统计信息都统计些什么?既然有工作者队列，为什么还需要担心处理热点问题?

A1：在系统中，有部分队列不是独享的，可能是整个进程所有partition都共享的，如果一个partition出现了热点访问，占用了所有的资源，可能会导致这台机器上所有partition的访问都受到影响。

Q2：那么不采用hash环的分布式策略，比起明确分区键值有什么坏处?为什么要选用后者?

A2：hash分片主要的问题是，一旦确定之后动态调整比较困难，基于分片键的方式，能比较容易做到动态调整，比如split。而hash分片，如果刚开始分片有问题，后续再调整就比较困难。

Q3：我们这边用的是RabbitMQ，没有想过要另找一套的思路。当时自己创建这个的时候有没有参考别的解决方案?然后如何抉择的?

A3：你这里的队列服务可能和我说的不太一样。如果你们是基于队列服务做得系统，那么队列服务相关的负载均衡你们基本上就无能为力，要看队列服务这个产品来做，如果你们自己的系统本身也有热点问题，那么本次分享应该对你有所帮助。

直播回放

https://m.qlchat.com/topic/details?topicId=2000003638109687

陈新进 阿里云技术专家

参与阿里云自研NoSQL存储系统（表格存储）六年以上研发；

主要负责产品的master模块和负载均衡系统，在系统稳定性和可用性方面有一定的积累。

相关文章