1。后台表存储（原OTS）是阿里巴巴开发的NoSQL多租户分布式数据库。本文将主要分享负载均衡系统如何解决TableStorage中的热点问题。一、表存储架构下图是表存储系统最基本的架构图：其实表存储还有很多其他的模块。这里我们主要看与本文内容相关的部分，也是核心部分。从下往上看，TableStorage是一个基于飞天内核的产品，主要提供分布式共享存储、分布式锁服务、通信组件等基础功能。然后上面是TableStorage的engine部分，主要由worker和master组成。集群中有少量的master和大量的worker。master负责管理worker的状态，为每个worker调度分区，对外提供服务。上层是前端组件，提供统一的http服务，将这些请求转发给worker。2.负载均衡相关背景在表存储系统中，我们会根据shardkey对用户数据进行切分。切分之后我们称之为分区，它是表存储系统中调度的基本单位。所有调度都基于分区。分区可以做以下操作：移动：将分区从一台机器迁移到另一台机器上服务。split：将一个分区拆分为两个分区。合并：将两个分区合并为一个分区。组：组是隔离分区的主要手段。例如，它一般先将一批worker添加到指定的group中，然后再将instance、table或partition添加到group中。这些操作完成后，系统会将指定组的实例、表的所有分区、显示指定组的分区固定调度到该组的worker上，达到隔离的目的。简单来说，我给一些用户分配了指定的机器，这些机器就是专门为这些用户服务的。以上对分区的所有操作，包括移动、拆分、合并、分组，都在第二层。3.热点NoSQL多租户系统中经常遇到的热点主要分为以下两类：1）用户访问热点。用户访问热点分为合理突发访问热点和不合理突发访问热点。访问热点：合理的突发访问是指用户的表设计合理，但由于业务量突然增加，比如大促。访问热点不合理是指用户的表设计不合理，在此基础上，业务量增加造成的热点。2）机器热点机器热点问题是指由于某种原因导致机器的CPU和网络流量突然增加，导致机器的资源成为瓶颈的热点。通常，热点难以处理，主要有以下原因：难以定位：系统中的信息统计不够完整，导致热点难以定位，只能靠猜测。解决难：即使定位到问题，也可能难以解决。主要原因是系统中处理热点的手段不足。人工处理慢：即使能定位，也能解决，但处理时间过长，严重影响服务可用性。在表存储系统中，我们有相应的手段来解决上述困难。对于信息不全、定位难的问题，我们的系统有详细的分区级统计信息，二级分区移动、拆分、合并、分组功能也能很好的处理。我们开发了一个集信息收集、信息分析、问题解决为一体的负载均衡系统，可以快速自动解决热点问题，无需人工参与。2.负载均衡系统接下来我们看看TableStorage中的负载均衡系统是如何自动解决问题的。首先介绍负载均衡系统的架构，然后详细解释各个模块的功能。1.负载均衡架构下图是负载均衡系统的架构图：主要包括LBAgent和LBMaster这两个角色，其中LBAgent和worker进程部署在同一台机器上，它负责收集所有信息本机指标，包括worker进程和其他相关进程。收集后，在内存中维护最近的数据，将数据异步写入外部存储系统，图中称为MetricStore。然后上层模块是OpsServer，是一层很薄的封装，主要为所有命令提供http服务。再往上是LBMaster。LBMaster中的采集模块通过OpsServer实时采集LBAgent的数据，并在内存中维护最近的数据。这个模块叫做MetricsTable，主要提供各种数据聚合和top排序功能。在线分析模块（OnlineAnalyzer）会实时分析MetricsTable中的近期数据，检测是否存在热点等异常问题。如果有，则进一步分析这些信息，生成相应的解决方案，并将这些动作下发给执行模块（Executor）。执行模块通过OpsServer向worker或master发送相应的action，worker或master执行action最终解决热点问题。同时，LBMaster还有一个离线分析模块（OfflineAnalyzer），主要从外部存储系统MetricStore中读取信息，并对信息进行分析，检测系统是否存在潜在问题，如果存在则生成相应的action也通过OpsServer交给worker或者master去执行，最终解决潜在的问题，防患于未然。无论是在线分析模块还是离线分析模块，都会将分析出的结果和动作写入外部存储系统，这里称为ResultDataStore，主要是为了人工或系统对这些动作的进一步分析。LBMaster还提供了白屏管控平台，可以实时查询LBMaster中的各种数据，也可以通过它发送人工运维命令。2.信息采集模块信息采集模块有两个要点：信息尽可能完整。主路径的性能不得受到影响。在表存储系统中，任何一个模块在处理一个请求时，都会顺便收集该模块的相关信息，这些信息会随着请求而流动。如下图所示：图中，经过rpc模块后，会收集rpc模块中的统计信息；当经过m1和m2模块时，m1和m2模块的信息也会被一起收集；最后，信息在返回给用户之前会被异步推送到一个后台计算模块，该模块会在后台使用少量资源汇总信息，并定期将信息推送给LBAgent。因为这个后台计算模块不在主路径上执行，是异步执行的，只占用很少的资源，而且可能只有一个核的CPU，所以对主路径的性能影响很小小路。这样，我们既保证了每个模块的信息都能被采集到，又能将对主路径性能的影响降到最低。3.LBAgent模块LBAgent模块主要有三个功能：收集单机的所有信息。预先汇总此信息。异步保存所有信息。如图所示：LBAgent端的接收信息模块不仅接收worker进程的信息，还接收系统中其他相关进程的信息。LBAgent接收到信息后，将最近采集到的信息维护在内存中，并异步将信息持久化到外部存储系统（MetricStore）中，以保存更长时间。LBMaster通过接口周期性的获取LBAgent内存中维护的信息。4.LBMaster模块LBMaster模块是负载均衡系统的核心模块。它的主要功能是：收集集群的所有信息。多维度信息的置顶查询，包括但不限于错误率、时延、qps等信息。分析信息、生成操作并执行操作。自我反馈策略的有效性。我们看下图：collector负责收集信息，MetricsTable负责多维信息的顶层查询，OnlineAnalyzer和OfflineAnalyzer模块分别分析在线实时信息和离线信息，ActionExecutor模块负责用于执行分析模块生成的动作。动作执行完成后，ActionEvaluation模块会比较动作执行前后的信息变化，判断动作的效果，并通过这种方式反馈动作是否真正解决了问题。另外，LBMaster还有一个配置相关的模块，每个模块都有一个灵活的配置，配置存储在外部存储系统中，配置模块会读取信息，然后同步到所有模块。所有模块配置都支持实时动态更新。综上所述，LBMaster具有以下特点：冷热数据存储分离：热数据存储在内存中，保留最新小时级别的数据，冷数据存储在外部存储系统中，可以根据需要保存数月甚至数年。离线和在线模块分离：从架构图可以看出，离线模块和在线模块的路径不会互相影响。灵活配置动态加载：LBMaster支持灵活配置，无需升级即可动态加载。白屏操作和信息显示：LBMaster中的所有信息都支持白屏显示，也可以在白屏下向LBMaster发送运维命令，由LBMaster执行这些运维命令。高可用：由于LBMaster在整个负载均衡系统中起着核心作用，因此也需要高可用。接下来我们从线上和线下两个方面来看负载均衡处理的问题。5.在线分析路径首先看在线分析路径。在线分析主要是分析短期信息，发现问题，最终解决问题。具有以下特点：对数据实时性要求极高，分析频次高，发现问题秒级处理。数据量小，全部维护在内存表中。主路径不依赖于任何外部系统。从架构图看在线分析路径，可以发现：整个数据流路径，从worker到LBAgent再到LBMaster，从LBMaster到worker、master的控制流路径，只是分析结果会异步写入到外部存储系统，不涉及外部系统。并且分析结果写入外部存储系统失败不影响主路径的执行，属于异步操作。所有这些设计都是为了满足实时性的要求。表存储系统有很多策略在分析。下面举两个例子：例子一：热点问题导致读写队列满，报错。首先，负载均衡系统分析信息，发现worker1的队列已满，报错，达到单Partition服务瓶颈。进一步分析后发现可以做拆分来解决这个问题。于是，负载均衡系统发出splitpartition1的动作。worker和master执行完action后，partition1被分为partition11和partition12，被调度到两台机器上服务。这样热点问题就解决了。示例2：机器资源满导致的问题负载均衡系统分析信息发现worker1资源满了，然后开始分析原因，发现是partition2导致的。进一步分析发现partition2的访问方式有问题。比如单partitionkey访问，或者顺序写访问，在这种访问方式下，split解决不了问题，所以负载均衡系统发送action隔离partition2。动作执行后，partition2被隔离，单机服务。此时partition2不影响其他任何用户，也独享整机资源，系统为其提供强大的服务能力。6、离线分析路径与在线分析路径正好相反。离线分析主要是对长期信息进行分析，发现潜在问题，最终排除这些潜在问题，做到防患于未然。与线上路径相比，其特点是：对实时数据要求低，分析频率低，问题发现和处理在小时级。由于数据量大，信息保存在外部存储系统中。计算量大，可依赖外部分析系统进行分析。从架构图来看，离线分析路径的数据来自于外部存储系统，由于分析数据量大，会先借助外部分析系统进行初步分析，然后再编写分析结果存入结果表。LBMaster的离线分析模块进一步分析结果表中的信息，进而发现问题并生成动作。借助外部分析系统，LBMaster的资源消耗大大降低，分析能力也大大提升。下面简单介绍两个离线分析策略的例子：第一个是automerge。在NoSQL系统中，有些分区一开始的访问量很大，所以分成很多分区，然后这些分区的访问量可能会很低，甚至几乎没有，那么我们可以合并这些分区来节省系统资源。但是不能用短期的统计数据判断一个分区是否流量低再合并，因为有些分区的访问模式是周期性的，需要用长期的统计数据来判断一个分区是否可以合并合并。再比如，我们可以通过对长期数据的分析，预测部分用户的访问高峰，提前做出资源调整。7.效果展示下面展示负载均衡系统上线后的一些效果。所有选择的业务都有明显的热点，所以效果非常明显。如下图，负载均衡系统上线后，读操作的错误率和延迟明显降低，吞吐量明显提升：如下图，负载均衡系统上线后，写操作错误率显着当错误率突然上升时，可以立即处理：3.总结我从自己搭建负载均衡系统的实践中总结了一些经验：各个模块的信息统计是基础。如果没有信息统计，或者信息统计不完整，就会导致无法定位问题或者错误定位，整个负载均衡系统就无从谈起。而且这部分的工作量肯定不小，要做到信息完整不容易，几乎不影响性能。自动化手动处理是一种有效的策略。很多人认为负载均衡一开始需要大量的机器学习算法，这可能是真的。但是对于前期，如果我们把人工处理自动化，或许可以解决90%以上的在线问题，而不需要高级的机器学习算法。过了这个阶段，再考虑一些困难的问题，或者预测策略，再考虑机器学习。丰富的策略配置和灵活的控制每一个策略都必须有一些阈值或条件。这些条件不能硬编码在系统中，必须通过配置导入，因为线上的情况千差万别，只有这样才有机会针对不同的业务和场景定制配置。系统迭代快，支持差异化配置。负载均衡系统是一个需要快速迭代的系统。比如今天在网上发现了一个问题，就需要写一个攻略，第一时间上线，在线解决这个问题。再者，由于每个业务的特点不同，接入方式也大不相同，对易用性的要求也会大不相同。因此，这里需要一个非常灵活的配置。对于不同的业务，可能同一个策略需要不同的配置才能达到这个业务想要的效果。Q&AQ1：表的统计信息有哪些？既然有worker队列，为什么还要担心热点呢？A1：在系统中，有些队列是不排他的，可能是整个进程的所有分区都是共享的，如果一个分区热访问，占用了所有资源，可能会影响本机所有分区的访问。Q2：那么与指定分区键值相比，不使用哈希环分布式策略有什么缺点呢？为什么选择后者？A2：hashsharding的主要问题是一旦确定就很难动态调整，基于shardingkey的方法可以让动态调整更容易，比如split。至于哈希分片，如果一开始分片有问题，后面调整起来就比较困难。Q3：我们这里用的是RabbitMQ，一直没有想过再找一套思路。您在创建时是否参考了其他解决方案？你是如何选择的？A3：你们这里的排队服务可能和我说的不一样。如果你基于队列服务构建系统，那么你基本上无法对队列服务相关的负载均衡做任何事情。这取决于队列服务的产品。如果你自己的系统本身就存在热点问题，那么这篇分享应该对你有所帮助。直播回放https://m.qlchat.com/topic/details?topicId=2000003638109687陈新进阿里云技术专家，参与阿里云自研NoSQL存储系统（表存储）研发六年多;主要负责产品的主控模块和负载均衡，在系统稳定性和可用性方面有一定的积累。
