CN114205361B - 一种负载均衡方法以及服务器 - Google Patents

一种负载均衡方法以及服务器 Download PDF

Info

Publication number
CN114205361B
CN114205361B CN202111496270.2A CN202111496270A CN114205361B CN 114205361 B CN114205361 B CN 114205361B CN 202111496270 A CN202111496270 A CN 202111496270A CN 114205361 B CN114205361 B CN 114205361B
Authority
CN
China
Prior art keywords
service node
service
weight
node
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111496270.2A
Other languages
English (en)
Other versions
CN114205361A (zh
Inventor
王清华
郭伟
矫恒浩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Juhaokan Technology Co Ltd
Original Assignee
Juhaokan Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Juhaokan Technology Co Ltd filed Critical Juhaokan Technology Co Ltd
Priority to CN202111496270.2A priority Critical patent/CN114205361B/zh
Publication of CN114205361A publication Critical patent/CN114205361A/zh
Application granted granted Critical
Publication of CN114205361B publication Critical patent/CN114205361B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请示出一种负载均衡方法以及服务器。解决了服务节点被分配的请求量超负荷,导致服务不稳定的问题。其中,负载均衡方法包括:接收服务请求;确定与各服务节点对应的权重;其中,各服务节点包括第一服务节点和第二服务节点;第一服务节点为本地缓存的缓存量为低于第一阈值的节点;第二服务节点为本地缓存的缓存量高于第二阈值的节点;第一阈值不大于第二阈值,第一服务节点对应的权重为第一权重,第二服务节点对应的权重为第二权重;第一权重小于第二权重;根据权重,将分发服务请求至各服务节点,用以使服务节点根据分发的服务请求获取数据并存储在其本地缓存中,其中,第一服务节点获取到服务请求的概率低于第二服务节点。

Description

一种负载均衡方法以及服务器
技术领域
本申请涉及信息通信领域,尤其涉及一种负载均衡方法以及服务器。
背景技术
负载均衡是一种将负载进行分发的技术,负载均衡的主要目的是将外部发来的大量请求,根据一定的算法,均匀地分散到各个服务节点当中,这样,相对于一个服务节点完成全部请求,多个服务节点同时工作能够缩短响应时间并提高吞吐率。
目前,现有负载均衡方案支持按权重向节点分发请求,采用的是固定的权重分配模式。采用这种方式,服务节点很容易分到超过其负载能力的请求量,导致服务不稳定。
发明内容
本申请提供一种负载均衡方法以及服务器,解决了服务节点被分配的请求量超负荷,导致服务不稳定的问题。
第一方面,本申请提供一种负载均衡方法,方法包括:接收服务请求;确定与各服务节点对应的权重;其中,各服务节点包括第一服务节点和第二服务节点;第一服务节点为本地缓存的缓存量为低于第一阈值的节点;第二服务节点为本地缓存的缓存量高于第二阈值的节点;第一阈值不大于第二阈值,第一服务节点对应的权重为第一权重,第二服务节点对应的权重为第二权重;第一权重小于第二权重;根据权重,分发服务请求至各服务节点,用以使服务节点根据分发的服务请求获取数据并存储在其本地缓存中,其中,第一服务节点获取到服务请求的概率低于第二服务节点。
这样,通过监控服务节点对应的本地存储的缓存量,根据不同的缓存量确定服务节点的权重。使得缓存量少的服务节点对应的权重小于缓存量大的服务节点的权重。解决了刚启动的服务节点承接超负荷请求量的问题。
在一些实施例中,分发至第一服务节点的服务请求为第一服务请求;在将服务请求分发服务请求至各服务节点后,方法还包括:接收第一服务节点返回的监控指标,监控指标为第一服务节点完成第一服务请求后其本地缓存的缓存状态;在监控指标表征第一服务节点的本地缓存的缓存量增加时,增大第一权重,用以在下一次分发服务请求时按照增大后的权重分发服务请求至第一服务节点。
在一些实施例中,接收第一服务节点返回的监控指标,包括:第一服务节点发送根据第一服务请求生成的查询请求至本地缓存和/或第三方系统,查询请求用以查询第一服务请求对应的数据;第一服务节点接收第三方系统返回的第一数据;第一数据为第三方系统响应于查询请求得到的数据;第一服务节点将第一数据存储在第一服务节点对应的本地缓存中;以及随数据添加监控指标;监控指标包括缓存量;第一服务节点上传监控指标至负载均衡系统。
在一些实施例中,确定与各服务节点对应的权重,包括:权重W的公式为:W=W0×F;其中,W0表示初始权重;F表示影响因子,为0-1之间的数字,若监控指标M小于第一阈值M1,则影响因子F的值为初始影响值F0;若监控指标M大于等于第一阈值M1且小于等于第二阈值M2,则影响因子F的公式为:若监控指标M大于第二阈值M2,则影响因子F的值为1。
在一些实施例中,第一权重W1的公式为:W1=W0×F0
在一些实施例中,第一服务节点包括故障恢复的服务节点或新建节点。
在一些实施例中,方法还包括:接收第二服务节点返回的监控指标,监控指标为第二服务节点完成第二服务请求后本地缓存的缓存状态;根据监控指标,更新第二权重,用以在下一次分发服务请求时按照更新后的第二权重分发服务请求至第二服务节点。
在一些实施例中,当监控指标与影响因子为负相关时,最终影响因子Ff的公式为:
Ff=1-F+F0
在一些实施例中,当监控指标与影响因子为负相关时,最终影响因子Ff的公式为:
Ff=1-(M2-M)+F0
第二方面,本申请提供一种服务器,服务器被配置为:接收服务请求;服务器包括:负载均衡模块、至少一个服务节点以及本地存储;其中,服务节点包括第一服务节点;负载均衡模块被配置为:接收服务请求;确定与各服务节点对应的权重;根据权重,分发服务请求至各服务节点;其中,第一服务节点获取到服务请求的概率低于第二服务节点;分发至第一服务节点的服务请求为第一服务请求;服务节点被配置为:根据分发的服务请求获取数据并存储在其本地缓存中;第一服务节点为本地缓存的缓存量为低于第一阈值的节点,第一服务节点对应的权重为第一权重,第一服务节点被配置为:根据第一服务请求,向本地缓存或第三方系统查询数据;第二服务节点为本地缓存的缓存量高于第二阈值的节点,第二服务节点对应的权重为第二权重,第二服务节点被配置为:根据第一服务请求,向本地缓存查询数据;其中,第一阈值不大于第二阈值;第二权重大于第一权重。
由以上实施例可知,本申请提供的设备中负载均衡模块通过监听服务状态,根据服务状态确认监控指标,根据监控指标确认影响因子,进而更新权重,本申请基于服务节点状态逐渐接入流量,提高服务稳定性。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1示出了根据一些实施例的一种负载均衡方法的场景图;
图2示出了根据一些实施例的一种负载均衡方法的交互示意图。
具体实施方式
为使本申请的目的和实施方式更加清楚,下面将结合本申请示例性实施例中的附图,对本申请示例性实施方式进行清楚、完整地描述,显然,描述的示例性实施例仅是本申请一部分实施例,而不是全部的实施例。
需要说明的是,本申请中对于术语的简要说明,仅是为了方便理解接下来描述的实施方式,而不是意图限定本申请的实施方式。除非另有说明,这些术语应当按照其普通和通常的含义理解。
本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体,而不必然意味着限定特定的顺序或先后次序,除非另外注明。应该理解这样使用的用语在适当情况下可以互换。
术语“包括”和“具有”以及他们的任何变形,意图在于覆盖但不排他的包含,例如,包含了一系列组件的产品或设备不必限于清楚地列出的所有组件,而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。
术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合,能够执行与该元件相关的功能。
负载均衡(load balance),将服务请求分摊到多个操作单元上进行执行,多个操作单元例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求。网站负载建立在现有网络结构之上,它提供了一种廉价、有效、透明的方法,来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡有两方面的含义:首先,大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间;其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到大幅度提高。
本申请所示的负载均衡方法,是一种软件负载均衡解决方案。通过在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,基于特定环境设置权重,具有配置简单、使用灵活以及成本低廉的优点,可以满足负载均衡需求。本地负载均衡不需要花费高额成本购置高性能服务器,只需利用现有设备资源,就可有效避免服务器单点故障造成数据流量的损失,通常用来解决数据流量过大、网络负荷过重的问题。同时它拥有形式多样的均衡策略把数据流量合理均衡的分配到各台服务器。如果需要在现在服务器上升级扩充,不需改变现有网络结构、停止现有服务,仅需要在服务群中简单地添加一负载均衡模块。
在视频应用中,通常一台服务器无法解决所有业务,需要考虑系统的负载均衡。在实际应用场景中,主要考虑两种典型的应用,一是拥有大量接入摄像头的应用,客户端多,但设备更多,而且这种情况下设备还需要在没有客户端的情况下实现视频上传实现云存储,如在移动车载领域,视频监控领域。第二种应用是设备并不多,但拥有大量的客户端,这种应用更加常见,如直播,教育等行业。无论这两种应用的那种,当量变大以后都需要考虑多视频服务器架构,并实现负载均衡。本申请通过软负载实现均衡策略。
图1示出了根据一些实施例的一种负载均衡方法的场景图。如图1所示,本申请适用于所有对外提供服务接口的设备。设备包括负载均衡模块、至少一个服务节点以及本地存储;设备接收外部的服务请求,为了提升服务性能,一般会部署多个服务节点,在某一实现方式中,服务节点可以包括第一服务节点和第二服务节点;在另一实现方式中,服务节点可以包括第一服务节点、第二服务节点以及第三服务节点。服务节点的个数可以根据设备的硬件资源和使用环境设置。负载均衡模块根据所述负载均衡方案中的权重,将所述服务请求分发至服务节点,用以分摊负载压力;在某一具体的实施例中,负载均衡模块将服务请求分发至第一服务节点和所述第二服务节点,其中,分发至所述第一服务节点的服务请求记作第一服务请求;分发至所述第二服务节点的服务请求记作第二服务请求。各服务节点设置有对应的本地缓存。在一种具体的实现方式中,服务节点接收服务请求后,会先向其本地缓存发起查询,若本地缓存没有服务请求对应的数据,则向数据库或者下游服务查询数据。
在一种情境中,服务节点对应的本地存储的缓存量是随承接服务请求次数的增多而逐步建立的。当某个服务节点刚开始启动的时候,还没有接收服务请求,本地存储的缓存还没有建立起来,这时,本地缓存可能是空的,因而当服务节点被分配服务请求时,本地缓存没有服务请求对应的数据,服务节点需要向数据库或者第三方系统获取数据。这样,该服务节点在等待数据传回的过程中,响应时间和吞吐量都比从本地存储获取数据的服务节点差。因而,对于刚启动的服务节点和已经承多次服务请求的服务节点,在分配服务请求时,应差异化处理。刚启动的服务节点应该少分一些,已经承多次服务请求的服务节点应该多分一下。避免刚启动的服务节点因为承接的请求量超负荷导致响应变慢、请求堆积、占用节点内存导致服务不稳定、进而导致请求超时以及影响整体的服务性能的问题。
为解决上述问题,本申请提供一种负载均衡方法,通过监控服务节点对应的本地存储的缓存量,根据不同的缓存量确定服务节点的权重。这样,使得缓存量少的服务节点对应的权重小于缓存量大的服务节点的权重。解决了刚启动的服务节点承接超负荷请求量的问题。
如图2所示,在一些实施例中,本申请提供的负载均衡方法包括:负载均衡模块接收服务请求;负载均衡模块确定与各服务节点对应的权重;其中,各服务节点包括第一服务节点和第二服务节点;第一服务节点为本地缓存的缓存量为低于第一阈值的节点;第二服务节点为本地缓存的缓存量高于第二阈值的节点;第一阈值不大于第二阈值,第一服务节点对应的权重为第一权重,第二服务节点对应的权重为第二权重;第一权重小于第二权重以使第一服务节点获取到所述服务请求的概率低于第二服务节点;根据权重,分发服务请求至各服务节点,用以使服务节点根据分发的服务请求获取数据并存储在其本地缓存中,其中,第一服务节点获取到服务请求的概率低于第二服务节点。可以理解的是,第一阈值可以表征为:当本地缓存未达到该阈值时,认为服务节点刚启动;第二阈值可以表征为:当本地缓存达到该阈值时,认为服务节点已彻底完成预热,可正常提供服务。
在一些实施例中,根据权重分发服务请求至各服务节点,包括根据各服务节点对应的权重,将服务请求分发至各服务节点,第一服务节点获取到所述服务请求的概率低于第二服务节点。
示例性的,第一阈值为1000,第二阈值为10000。第一服务节点为刚启动的新增加点,此时,第一服务节点的缓存量为0,即本地缓存为空,缓存量小于第一阈值1000,第一服务节点对应的第一权重为0.1;第二服务节点缓存量为11000,缓存量大于第二阈值10000,其对应的第二权重为0.9。需要说明的是,负载均衡方案中各服务节点对应的权重,其初始值可以根据硬件环境或环境不同,给定初始值。例如,可以在服务节点本地缓存为空的条件下,进行压测,进而确定初始权重。可以理解的是,权重值和各个服务节点具有一一对应的关系。权重的大小只是个参考值,不同系统可能定义不一样,可以用如上述实施例所示用大于0小于1的小数;也可以用大于1的数值,例如将初始权重定为10,或将初始权重定为90。因此在使用中也会存在一些区别。在使用大于0小于1的小数的小数时,可以使所有节点的权重之和为1,此时,各节点获得请求的概率为对应的权重数值和1的比值(即为对应的权重数值。在所有节点的权重之和不为1或各自数值大于1时,各节点获得请求的概率为对应的权重数值和各权重之和的比值。根据确定好的权重去分发请求可以参照相关技术。
在一些实施例中,当权重被定义为整数时,根据权重将服务请求分发服务请求至各服务节点的步骤还包括:根据第一权重占各服务节点权重之和的比值、第二权重占各服务节点权重之和的比值将服务请求分为第一服务请求和第二服务请求,将第一服务请求发送至第一服务节点,将第二服务请求发送至第二服务节点。可以理解的是,当有n个服务节点时,每个服务节点对应的权重(记作第n权重Wn)占n个服务节点的权重之和(记作∑W)的比值作为分发服务请求的直接依据。
示例性的,第一阈值为1000,第二阈值为10000。第一服务节点为刚启动的新增加点,此时,第一服务节点的缓存量为0,即本地缓存为空,缓存量小于第一阈值1000,第一服务节点对应的第一权重为10;第二服务节点缓存量为11000,其对应的第二权重为90,则第一服务节点获取服务请求占比为0.1,即10/(10+90);第二服务节点获取服务请求占比为0.9,即90/(10+90)。
进一步,本申请通过监控刚启动的服务节点在完成一次服务请求时其对应的本地存储的缓存量,逐步提升服务节点的权重。这样,使得缓存量少的服务节点对应的权重少于缓存量大的服务节点,同时,缓存量少的服务节点随着其本地缓存量的增加其对应的权重也增加。解决了刚启动的服务节点承接超负荷请求量的问题。
在一些实施例中,分发至第一服务节点的服务请求为第一服务请求;在分发服务请求至各服务节点后,方法还包括:接收第一服务节点返回的监控指标,监控指标为第一服务节点完成第一服务请求后其本地缓存的缓存状态;在监控指标表征第一服务节点的本地缓存的缓存量增加时,增大第一权重,用以在下一次分发服务请求时按照增大后的权重分发服务请求至第一服务节点。
示例性的,第一阈值为1000,第二阈值为10000。第一服务节点为刚启动的新增加点,此时,第一服务节点的缓存量为0,即本地缓存为空,缓存量小于第一阈值1000,第一服务节点对应的第一权重为0.1;第二服务节点缓存量为11000,缓存量大于第二阈值10000,其对应的第二权重为0.9。在分配服务请求a时,刚启动的第一服务节点对应的第一权重为0.1;第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由0增长至300,则监控指标为300,负载均衡模块根据“监控指标为300”,增大第一服务节点对应的权重,此时第一权重由0.1增加至0.2;在分配服务请求b时,第一服务节点对应的第一权重为0.2,
在一些实施例中,当权重被定义为整数时,第一阈值为1000。在分配服务请求a时,刚启动的第一服务节点对应的第一权重为10;第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由0增长至300,则监控指标为300,负载均衡模块根据“监控指标为300”,增大第一服务节点对应的权重,此时第一权重由10增加至20;在分配服务请求b时,第一服务节点对应的第一权重为20,若第二服务节点对应的第二权重仍为90,则第一服务节点获取的第一服务请求占服务请求b的比值为0.182,即20/(20+90);第二服务节点获取服务请求占比为0.818,即90/(20+90);若第二服务节点对应的第二权重为100,则第一服务节点获取的第一服务请求占服务请求b的比值为0.167,即20/(20+100);第二服务节点获取服务请求占比为0.833,即100/(20+100)。
在一些实施例中,接收第一服务节点返回的监控指标,包括:第一服务节点发送根据第一服务请求生成的查询请求至本地缓存和/或第三方系统,查询请求用以查询第一服务请求对应的数据;第一服务节点接收第三方系统返回的第一数据;第一数据为第三方系统响应于查询请求得到的数据;第一服务节点将第一数据存储在第一服务节点对应的本地缓存中;以及随数据添加监控指标;监控指标包括缓存量;第一服务节点上传监控指标至负载均衡系统。
进一步,本申请提供一种确定与各服务节点对应的权重的方法,在根据本地存储的缓存量逐步提升服务节点的权重的基础上,引入影响因子。影响因子随着监控指标的变化而变化,使得调整后的权重更符合服务节点对应的工作状态。这样不仅仅是当服务节点的缓存量小于第一阈值时,当服务节点的缓存量大于等于第一阈值且小于等于第二阈值时,也通过逐渐增大的方式,进一步解决还未完成预热的服务节点承接超负荷请求量的问题。
在一些实施例中,确定与各服务节点对应的权重,包括:权重W的公式为:W=W0×F;其中,W0表示初始权重;F表示影响因子,为0-1之间的数字,若监控指标M小于第一阈值M1,则影响因子F的值为初始影响值F0;若监控指标M大于等于第一阈值M1且小于等于第二阈值M2,则影响因子F的公式为:若监控指标M大于第二阈值M2,则影响因子F的值为1。其中,设置初始影响值F0、第一阈值M1以及第二阈值M2,影响因子随着监控指标的变化而进行上述公式的变化,其目的是减小服务预热对节点的冲击,使节点平稳高效预热。通过压测或真实环境测试,可调整初始影响值F0取值,并确定第一阈值M1以及第二阈值M2
示例性的,为了保证服务性能,当正常节点(本地缓存的缓存量高于第二阈值的服务节点)不超过20%的请求到达数据库和下游服务时,则说明无本地缓存的节点至少可承受20%的流量,则将factor初始值定为0.2。
在一种实现方式中,第一阈值为1000,第二阈值为10000。在分配服务请求a时,第一服务节点的初始权重W0为0.5,初始影响值F0为0.2;刚启动的第一服务节点对应的第一权重W1的公式为:W1=W0×F0,即为0.1(0.5×0.2);第二服务节点对应的第二权重为0.9。第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由0增长至300,则监控指标为300,负载均衡模块根据“监控指标为300”,300<1000,则增大第一权重,此时的初始权重为“0.5+0.1=0.6”,初始影响值F0为0.2,第一权重增大为0.6×0.2=0.12;在分配服务请求b时,第一服务节点对应的第一权重为0.12,第二服务节点对应的第二权重为0.88。第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由300增长至3000,则监控指标为3000,负载均衡模块根据“监控指标为3000”,1000<3000<10000,则代入公式:F=0.378,此时的初始权重为“0.6+0.12=0.72”,第一权重增大为0.72×0.378=0.27216。以此类推,在本地缓存的缓存量增高至第二阈值过程中,第一服务节点的权重逐渐增大,直到完成预热。
在另一种实现方式中,当权重被定义为整数时,第一阈值为1000,第二阈值为10000。在分配服务请求a时,第一服务节点的初始权重W0为50,初始影响值F0为0.2;刚启动的第一服务节点对应的第一权重W1的公式为:W1=W0×F0,即为10(50×0.2);第二服务节点对应的第二权重为90,则第一服务节点获取服务请求占比为0.1,即10/(10+90);第二服务节点获取服务请求占比为0.9,即90/(10+90)。第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由0增长至300,则监控指标为300,负载均衡模块根据“监控指标为300”,300<1000,则增大第一权重,此时的初始权重为“50+10=60”,初始影响值F0为0.2,第一权重增大为60×0.2=12;在分配服务请求b时,第一服务节点对应的第一权重为12,若第二服务节点对应的第二权重仍为90,则第一服务节点获取的第一服务请求占服务请求b的比值为12/(12+90)=0.118;第二服务节点获取占比为90/(12+90)=0.882。第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由300增长至3000,则监控指标为3000,负载均衡模块根据“监控指标为3000”,1000<3000<10000,则代入公式:F=0.378,此时的初始权重为“60+12=72”,第一权重增大为72×0.378=27.216。以此类推,在本地缓存的缓存量增高至第二阈值过程中,第一服务节点的权重逐渐增大,直到完成预热。在分配服务请求b时,第一服务节点对应的第一权重为12,若第二服务节点对应的第二权重为100,则第一服务节点获取的第一服务请求占服务请求b的比值为12/(12+100)=0.107;第二服务节点获取占比为90/(12+90)=0.893。第一服务节点根据第一服务请求向数据库或者第三方系统请求数据后,将数据保存在其本地缓存中,此时,第一服务节点的本地缓存的缓存量增加,由300增长至3000,则监控指标为3000,负载均衡模块根据“监控指标为3000”,1000<3000<10000,则代入公式:/>F=0.378,此时的初始权重为“60+12=72”,第一权重增大为72×0.378=27.216。以此类推,在本地缓存的缓存量增高至第二阈值过程中,第一服务节点的权重逐渐增大,直到完成预热。
在一些实施例中,第一服务节点包括故障恢复的服务节点或新建节点。当节点因为某些原因,如网络故障、GC等导致本地缓存过期失效时,影响因子取值可能重新变小,进入预热状态。
在一些实施例中,当监控指标与影响因子为负相关时,最终影响因子Ff的公式为:
Ff=1-F+F0
在一些实施例中,当监控指标与影响因子为负相关时,最终影响因子Ff的公式为:
Ff=1-(M2-M)+F0
在上述实施例中,监控指标可以由所述第一服务节点添加返回缓存量大小到所述第一服务请求的响应头中,例如HTTP请求可在HTTP响应头中返回缓存大小。
由以上实施例可知,本申请通过定期监听服务状态,根据服务状态确认监控指标,根据监控指标确认影响因子,进而更新权重,本申请基于刚启动的服务节点状态逐渐接入流量,提高服务稳定性。
在一些实施例中,方法还包括:接收第二服务节点返回的监控指标,监控指标为第二服务节点完成第二服务请求后本地缓存的缓存状态;根据监控指标,更新第二权重,用以在下一次分发服务请求时按照更新后的第二权重分发服务请求至第二服务节点。更新第二权重可以参见上述更新第一权重的方法,再次不作赘述。
第二方面,本申请提供一种服务器,服务器被配置为:接收服务请求;服务器包括:负载均衡模块、至少一个服务节点以及本地存储;其中,服务节点包括第一服务节点;负载均衡模块被配置为:接收服务请求;确定与各服务节点对应的权重;根据权重,分发服务请求至各服务节点;其中,第一服务节点获取到服务请求的概率低于第二服务节点;分发至第一服务节点的服务请求为第一服务请求;服务节点被配置为:根据分发的服务请求获取数据并存储在其本地缓存中;第一服务节点为本地缓存的缓存量为低于第一阈值的节点,第一服务节点对应的权重为第一权重,第一服务节点被配置为:根据第一服务请求,向本地缓存或第三方系统查询数据;第二服务节点为本地缓存的缓存量高于第二阈值的节点,第二服务节点对应的权重为第二权重,第二服务节点被配置为:根据第一服务请求,向本地缓存查询数据;其中,第一阈值不大于第二阈值;第二权重大于第一权重。
本申请提供一种服务器,通过监控服务节点对应的本地存储的缓存量,根据不同的缓存量确定服务节点的权重。这样,使得缓存量少的服务节点对应的权重小于缓存量大的服务节点的权重。解决了刚启动的服务节点承接超负荷请求量的问题。
在一些情境中,第一服务节点通过上述负载均衡方法,权重逐渐增大,直到完成预热。此时第一服务节点和第二服务节点都处于正常工作状态。但是,由于不同服务节点对应的本地缓存中缓存数据的差异性,以及不同服务节点对应的服务请求的差异性,若按照固定的权重,不能很好地适应各服务节点的工作状态。
针对上述问题,本申请提供另一种负载均衡方法,进一步解决当服务器中有多个正常工作的服务节点时根据监控指标合理改变权重的问题。负载均衡方法包括:接收服务请求;根据负载均衡方案中的权重,将服务请求分发至服务节点;其中,服务节点包括第一服务节点;分发至第一服务节点的服务请求记作第一服务请求;接收第一服务节点返回与第一服务请求对应的数据时添加的监控指标;其中,监控指标包括数据的缓存加载状态;根据监控指标,更新权重,用以在下一次分发服务请求时按照更新后的权重分发服务请求。
示例性的,如图1所示,服务器包括三个服务节点,分别为第一服务节点、第二服务节点以及第三服务节点,此时若负载均衡模块根据所述负载均衡方案中的权重分配新的服务请求,各个服务节点的初始权重可以相同,也可以不同。其中第一服务节点的初始权重为0.33,第二服务节点的初始权重为0.33,第三服务节点的初始权重为0.34。负载均衡模块按照前述权重对服务请求进行分散,得到第一服务请求、第二服务请求以及第三服务请求。其中,第一服务请求和第二服务请求对应的负载相同,第三服务请求对应的负载最大。将第一服务请求发送至第一服务节点,将第二服务请求发送至第二服务节点,将第三服务请求发送至第三服务节点。第一服务节点根据第一服务请求首先向本地缓存请求数据,若本地缓存没有第一服务请求对应的数据,则第一服务节点根据第一服务请求向数据库或第三方系统查询第一服务请求对应的数据。第二服务节点以及第三服务节点在本地缓存中查询到了第二服务请求以及第三服务请求对应的数据,则直接获取数据,并返回数据至负载均衡模块。
可以理解的是,本地缓存可以只包括第一服务请求对应的一部分数据,第一服务请求对应的另一部分数据则需要想数据库或第三方系统查询。
在某一情景中,由于本地存储中没有第一服务请求对应的数据,第一服务节点不能从本地存储获取数据,只能数据库或者第三方系统获取数据;本地存储中有第二服务请求对应的数据,第二服务节点可以从本地存储直接获取数据。在第一服务节点等待等待数据传回的过程中,第二服务节点正常工作,第一服务节点的响应时间和吞吐量比第二服务节点差。此时若负载均衡模块根据所述负载均衡方案中的权重分配新的服务请求,由于第一服务节点并未完成上一次的数据回传任务,此时再按照原始权重被分配新的请求量,会造成第一服务节点超负荷,影响第一服务节点的服务性能,甚至导致第一服务节点被压垮。
示例性的,第一服务节点和第二服务节点的初始权重均为0.33,第一服务请求和第二服务请求对应的负载量相同,但是由于第一服务节点向数据库或第三方系统查询并获取第一服务请求对应的数据,而第二服务节点直接向本地缓存请求数据,因而在同样负载量的情况下,第一服务节点的响应时间和吞吐量比第二服务节点差。此时,若按照初始权重数据分配新的服务请求,根据第一服务节点当前工作状态,明显不能再承受权重数据0.33对应的请求量。同时,相比第二服务节点仍然承受权重数据0.33对应的请求量,当前时刻的第一服务节点超出第二服务节点的负荷,这样分配显然是不合理的。同理,第三服务节点的初始权重是0.34,第三服务节点直接向本地缓存请求数据,若按照初始权重数据分配新的服务请求,会造成第一服务节点超负荷,影响第一服务节点的服务性能,甚至导致第一服务节点被压垮。即使第二服务节点和第三服务节点理论上能够完成部分服务请求,仍然会造成任务失败,造成损失。所以,第一服务节点对应的新的权重数据应该小于0.33,而第二服务节点对应的新的权重数据和第三服务节点对应的新的权重数据应视情况变化。具体来说,如果增加了新的服务节点,例如第四服务节点,第二服务节点和第三服务节点分别对应的权重数据可以减少。
可以理解的是,权重的大小只是个参考值,不同系统可能定义不一样,可以用如上述实施例所示用小数,也可以用整数,例如将初始权重定为100。
为解决上述问题,本申请提供一种更新权重数据的方法。图2示出了根据一些实施例的一种负载均衡方法的交互示意图。如图2所示,在一些实施例中,本申请中负载均衡模块通过接收所述第一服务节点返回与所述第一服务请求对应的数据时添加的监控指标;其中,所述监控指标包括所述数据的缓存加载状态;根据所述监控指标,更新所述权重,用以在下一次分发服务请求时按照更新后的权重分配。这样,负载均衡模块可以根据监控指标重新安排各个节点对应的权重。
示例性的,第一服务节点向数据库或第三方系统查询并获取第一服务请求对应的数据时,数据库或第三方系统返回数据至第一服务节点时,同时返回数据的缓存加载状态,第一服务节点根据缓存加载状态添加监控指标,并将监控指标和数据同时返回至负载均衡模块。其中,第一服务节点从数据库或第三方系统加载的越少,就是从本地缓存加载越多时,负载均衡模块根据监控指标计算的新权重越大。
在一种实现方式中,缓存加载状态由所述第一服务节点添加返回缓存大小到所述第一服务请求的响应头中,例如HTTP请求可在HTTP响应头中返回缓存大小。
在一种情景中,同时存在多个服务节点,各个服务节点的工作状态也不同。因而,每个服务节点都需要在返回数据的时候添加监控指标,负载均衡模块根据各个服务节点反馈的监控指标综合计算后,给每个服务节点分配新的权重。在一些实施例中,监控指标还可以通过定期监听服务状态得到,监听服务状态的监听维度可以是接口响应时间、缓存加载状态以及接口调用失败率等。这样,监控指标可以同时包括多个指标,即接口响应时间对应第一监控指标,缓存加载状态对应第二监控指标,接口调用失败率对应第三监控指标。负载均衡模块根据第一监控指标、第二监控指标以及第三监控指标,计算得到权重。
在某一具体的实现方式中,监控指标还可以是接口的内存使用情况。
为了进一步计算监控指标,本申请引入影响因子,同时根据硬件环境和实际工作需求,预先设置初始影响因子,记作预调影响值。通过上述监控指标单独或者结合起来生成最终的影响因子。监控指标与影响因子可以是正相关或负相关的:缓存加载状态中本地缓存加载越多,则影响因子越大,缓存加载状态对应的第二监控指标与影响因子正相关;接口响应时间越大,则影响因子越小,接口响应时间对应的第一监控指标与影响因子负相关。当监听服务状态的监听维度是接口响应时间、缓存加载状态以及接口调用失败率等多个维度时,每个监听维度对应生成一个影响因子,这样,多个影响影子共同作用于权重计算,得到的负载均衡效果最好。
在某一具体的实现方式中,权重的计算公式为:权重等于初始权重乘以影响因子;影响因袭的确认方法如下:监控指标有一个阈值范围,包括阈值下限和阈值上限,阈值下限记作第三阈值,阈值上限记作第四阈值。其中,影响因子为0-1之间的数字,若所述监控指标小于或等于第三阈值,则影响因子为预调影响值;若所述监控指标大于第三阈值且小于第四阈值,则影响因子的公式为:影响因子=预调影响值+[(监控指标-第三阈值)/(第四阈值-第三阈值)]×(1-预调影响值);若所述监控指标大于或等于第四阈值,则影响因子为1。
示例性的,以缓存加载条数作为监控指标,初始权重定为100,第三阈值为1000,第四阈值为10000,预调影响值为0.1。当缓存加载条数不到1000时,影响因子固定为0.1;当缓存加载条数超过10000时,影响因子固定为1;当缓存加载条数介于1000和10000之间时,假设为5000,影响因子=0.1+[(5000-1000)/(10000-1000)]×(1-0.1)=0.5。
在某一具体的实现方式中,当监控指标与影响因子为负相关时,最终影响因子=1-影响因子+预调影响值。
在某一具体的实现方式中,当监控指标与影响因子为负相关时,最终影响因子=1-(第四阈值-监控指标)+预调影响值。
由以上实施例可知,本申请提供的设备中负载均衡模块通过定期监听服务状态,根据服务状态确认监控指标,根据监控指标确认影响因子,进而更新权重,本申请基于节点状态逐渐接入流量,提高服务稳定性。
在一些情境中,当分发一个新的服务请求时,设备会增减参与分发请求的服务节点的个数。例如,故障恢复的服务节点以及新增的服务节点作为新的服务节点启动,并加入负载均衡分配。
在一些实施中,作为新的服务节点启动并加入负载均衡分配的节点,其权重为初始权重。可以理解的是,当再次分配服务请求时,新的服务节点启动时对应的权重按照前述实施例计算,在此不作赘述。
由以上实施例可知,本申请提供的设备中负载均衡模块通过定期监听服务状态。
在一些实施例中,第一阈值还可以等于第二阈值。此时,在节点的缓存数量达到阈值时,即可按照第二权重进行请求的分配。
第二方面,本申请提供一种服务器,服务器被配置为:接收服务请求;服务器包括:负载均衡模块、至少一个服务节点以及本地存储;其中,服务节点包括第一服务节点;负载均衡模块被配置为:根据负载均衡方案的权重,将服务请求分发至服务节点;其中,分发至第一服务节点的服务请求记作第一服务请求;第一服务节点被配置为:根据第一服务请求,向本地缓存或第三方系统查询数据;其中,数据与第一服务请求对应;负载均衡模块进一步被配置为:接收第一服务节点返回与第一服务请求对应的数据时添加的监控指标;其中,监控指标包括数据的缓存加载状态;根据监控指标,更新权重,用以在下一次分发服务请求时按照更新后的权重分发服务请求。
示例性的,服务调用方发送调用服务的请求指令,负载均衡模块响应于请求指令,根据所述负载均衡方案中的权重,将所述服务请求分发至服务节点,用以分摊负载压力;当服务节点被分配服务请求时,本地缓存没有服务请求对应的数据,服务节点需要向数据库或者第三方系统获取数据。第一服务节点向数据库或第三方系统查询并获取第一服务请求对应的数据时,数据库或第三方系统返回数据至第一服务节点时,同时返回数据的缓存加载状态,第一服务节点根据缓存加载状态添加监控指标,并将监控指标和数据同时返回至负载均衡模块。负载均衡模块可以根据监控指标重新安排各个节点对应的权重。同时,负载均衡模块将调用服务对应的数据返回至服务调用方。
本申请实施例还提供一种芯片,与存储器相连或者包括存储器,用于读取并执行所述存储器中存储的软件程序,本申请实施例提供的方法。
本申请实施例还提供一种计算机程序产品,计算机程序产品包括一个或多个计算机程序指令。在计算机加载和执行计算机程序指令时,全部或部分地产生按照本申请上述各个实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。当其在计算机上运行时,使得计算机执行本申请实施例提供的方法。
在本实施例还提供一种计算机可读存储介质,该计算机可读存储介质计算机存储介质可存储有计算机程序指令,当程序指令被执行时,可实现本申请上述各实施例的图像处理方法的全部步骤。计算机可读存储介质包括磁盘、光盘、只读存储记忆体ROM或随机存储记忆体RAM等。
在上述实施例中,可以全部或部分通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现,本实施例不予限制。
本领域技术任何还可以了解到本申请列出的各种说明性逻辑块(illustrativelogical block)和步骤(step)可以通过电子硬件、电脑软件,或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用,可以使用各种方法实现的功能,但这种实现不应被理解为超出本申请保护的范围。
本申请中所描述的各种说明性的逻辑单元和电路可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列(FPGA)或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
本申请中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地,存储媒介可以与处理器连接,以使得处理器可以从存储媒介中读取信息,并可以向存储媒介存写信息。可选地,存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中,ASIC可以设置于UE中。可选地,处理器和存储媒介也可以设置于UE中的不同的部件中。
应理解,在本申请的各种实施例中,各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请的实施过程构成任何限定。
另外,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本领域的技术人员可以清楚地了解到本申请实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分的方法。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其,对于网络设备/节点或装置设备而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例中的说明即可。
以上的本申请实施方式并不构成对本申请保护范围的限定。

Claims (9)

1.一种负载均衡方法,其特征在于,包括:
接收服务请求;
根据公式W=W0×F确定与各服务节点对应的权重;其中,所述各服务节点包括第一服务节点和第二服务节点;所述第一服务节点为本地缓存的缓存量为低于第一阈值的节点;所述第二服务节点为本地缓存的缓存量高于第二阈值的节点;所述第一阈值不大于所述第二阈值,所述第一服务节点对应的权重为第一权重,所述第二服务节点对应的权重为第二权重;所述第一权重小于所述第二权重;W表示所述权重,W0表示初始权重;F表示影响因子,为0-1之间的数字,若监控指标M)小于第一阈值M1,则影响因子F的值为初始影响值F0;若所述监控指标M大于等于第一阈值M1)且小于等于第二阈值M2,则影响因子F的公式为:若所述监控指标M大于第二阈值M2,则影响因子F的值为1;所述监控指标为所述第一服务节点完成第一服务请求后其本地缓存的缓存状态;
根据所述权重,分发所述服务请求至所述各服务节点,用以使所述服务节点根据分发的服务请求获取数据并存储在其本地缓存中,其中,所述第一服务节点获取到所述服务请求的概率低于所述第二服务节点。
2.根据权利要求1所述的负载均衡方法,其特征在于,分发至所述第一服务节点的服务请求为第一服务请求;在所述分发所述服务请求至所述各服务节点后,所述方法还包括:
接收所述第一服务节点返回的监控指标;
在所述监控指标表征所述第一服务节点的本地缓存的缓存量增加时,增大所述第一权重,用以在下一次分发服务请求时按照增大后的权重分发服务请求至所述第一服务节点。
3.根据权利要求2所述的负载均衡方法,其特征在于,所述接收所述第一服务节点返回的监控指标,包括:
所述第一服务节点发送根据所述第一服务请求生成的查询请求至本地缓存和/或第三方系统,所述查询请求用以查询所述第一服务请求对应的数据;
所述第一服务节点接收所述第三方系统返回的第一数据;所述第一数据为所述第三方系统响应于所述查询请求得到的数据;
所述第一服务节点将所述第一数据存储在所述第一服务节点对应的本地缓存中;以及随所述数据添加监控指标;所述监控指标包括缓存量;
所述第一服务节点上传所述监控指标至负载均衡系统。
4.根据权利要求1所述的负载均衡方法,其特征在于,所述第一权重W1的公式为:
W1=W0×F0
5.根据权利要求1所述的负载均衡方法,其特征在于,所述第一服务节点包括故障恢复的服务节点或新建节点。
6.根据权利要求1所述的负载均衡方法,其特征在于,还包括:
接收所述第二服务节点返回的监控指标,所述监控指标为所述第二服务节点完成第二服务请求后本地缓存的缓存状态;
根据所述监控指标,更新所述第二权重,用以在下一次分发服务请求时按照所述更新后的第二权重分发服务请求至所述第二服务节点。
7.根据权利要求1所述的负载均衡方法,其特征在于,还包括:当监控指标与影响因子为负相关时,最终影响因子Ff的公式为:
Ff=1-F+F0
8.根据权利要求1所述的负载均衡方法,其特征在于,还包括:当监控指标与影响因子为负相关时,最终影响因子Ff的公式为:
Ff=1-(M2-M)+F0
9.一种服务器,其特征在于,所述服务器被配置为:接收服务请求;
所述服务器包括:负载均衡模块、至少一个服务节点以及本地存储;其中,所述服务节点包括第一服务节点和第二服务节点;
所述负载均衡模块被配置为:接收服务请求;根据公式W=W0×F确定与各服务节点对应的权重;根据所述权重,分发所述服务请求至所述各服务节点;其中,所述第一服务节点获取到所述服务请求的概率低于所述第二服务节点;分发至所述第一服务节点的服务请求为第一服务请求;W表示所述权重,W0表示初始权重;F表示影响因子,为0-1之间的数字,若监控指标M小于第一阈值M1,则影响因子F的值为初始影响值F0;若所述监控指标M大于等于第一阈值M1且小于等于第二阈值M2,则影响因子F的公式为:若所述监控指标M大于第二阈值M2,则影响因子F的值为1;所述监控指标为所述第一服务节点完成第一服务请求后其本地缓存的缓存状态;
所述服务节点被配置为:根据分发的服务请求获取数据并存储在其本地缓存中;
所述第一服务节点为本地缓存的缓存量为低于第一阈值的节点,所述第一服务节点对应的权重为第一权重,所述第一服务节点被配置为:根据所述第一服务请求,向本地缓存或第三方系统查询数据;
所述第二服务节点为本地缓存的缓存量高于第二阈值的节点,所述第二服务节点对应的权重为第二权重,所述第二服务节点被配置为:根据所述第一服务请求,向本地缓存查询数据;其中,所述第一阈值不大于所述第二阈值;所述第二权重大于所述第一权重。
CN202111496270.2A 2021-12-08 2021-12-08 一种负载均衡方法以及服务器 Active CN114205361B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111496270.2A CN114205361B (zh) 2021-12-08 2021-12-08 一种负载均衡方法以及服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111496270.2A CN114205361B (zh) 2021-12-08 2021-12-08 一种负载均衡方法以及服务器

Publications (2)

Publication Number Publication Date
CN114205361A CN114205361A (zh) 2022-03-18
CN114205361B true CN114205361B (zh) 2023-10-27

Family

ID=80651493

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111496270.2A Active CN114205361B (zh) 2021-12-08 2021-12-08 一种负载均衡方法以及服务器

Country Status (1)

Country Link
CN (1) CN114205361B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114979271A (zh) * 2022-05-11 2022-08-30 浪潮云信息技术股份公司 一种基于边缘云计算的cdn缓存分层调度方法
CN115344031B (zh) * 2022-10-19 2023-02-17 北京理工大学深圳汽车研究院(电动车辆国家工程实验室深圳研究院) 一种汽车区架构系统和汽车
CN115686840A (zh) * 2022-10-24 2023-02-03 阿里巴巴(中国)有限公司 请求处理方法以及系统

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101984632A (zh) * 2010-11-15 2011-03-09 中兴通讯股份有限公司 一种分布式缓存系统中负荷分配方法、装置及服务器
WO2017095718A1 (en) * 2015-12-04 2017-06-08 Microsoft Technology Licensing, Llc State-aware load balancing
CN108667882A (zh) * 2017-04-01 2018-10-16 北京京东尚科信息技术有限公司 基于动态权重调整的负载均衡方法、装置和电子设备
CN108762924A (zh) * 2018-05-28 2018-11-06 郑州云海信息技术有限公司 一种负载均衡的方法、装置和计算机可读存储介质
CN108965381A (zh) * 2018-05-31 2018-12-07 康键信息技术(深圳)有限公司 基于Nginx的负载均衡实现方法、装置、计算机设备和介质
CN109831524A (zh) * 2019-03-11 2019-05-31 平安科技(深圳)有限公司 一种负载均衡处理方法及装置
CN110798517A (zh) * 2019-10-22 2020-02-14 雅马哈发动机(厦门)信息系统有限公司 去中心化集群负载均衡方法、系统、移动终端及存储介质
CN112217894A (zh) * 2020-10-12 2021-01-12 浙江大学 一种基于动态权重的负载均衡系统
US11025710B1 (en) * 2020-10-26 2021-06-01 Verizon Digital Media Services Inc. Systems and methods for dynamic load balancing based on server utilization and content popularity
CN112929408A (zh) * 2021-01-19 2021-06-08 郑州阿帕斯数云信息科技有限公司 动态负载均衡方法及装置
CN113141317A (zh) * 2021-03-05 2021-07-20 西安电子科技大学 流媒体服务器负载均衡方法、系统、计算机设备、终端
CN113742066A (zh) * 2021-08-09 2021-12-03 联通沃悦读科技文化有限公司 一种用于服务器集群的负载均衡系统和方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9871855B2 (en) * 2014-09-19 2018-01-16 Facebook, Inc. Balancing load across cache servers in a distributed data store
US10951691B2 (en) * 2019-03-05 2021-03-16 Cisco Technology, Inc. Load balancing in a distributed system

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101984632A (zh) * 2010-11-15 2011-03-09 中兴通讯股份有限公司 一种分布式缓存系统中负荷分配方法、装置及服务器
WO2017095718A1 (en) * 2015-12-04 2017-06-08 Microsoft Technology Licensing, Llc State-aware load balancing
CN108667882A (zh) * 2017-04-01 2018-10-16 北京京东尚科信息技术有限公司 基于动态权重调整的负载均衡方法、装置和电子设备
CN108762924A (zh) * 2018-05-28 2018-11-06 郑州云海信息技术有限公司 一种负载均衡的方法、装置和计算机可读存储介质
CN108965381A (zh) * 2018-05-31 2018-12-07 康键信息技术(深圳)有限公司 基于Nginx的负载均衡实现方法、装置、计算机设备和介质
CN109831524A (zh) * 2019-03-11 2019-05-31 平安科技(深圳)有限公司 一种负载均衡处理方法及装置
CN110798517A (zh) * 2019-10-22 2020-02-14 雅马哈发动机(厦门)信息系统有限公司 去中心化集群负载均衡方法、系统、移动终端及存储介质
CN112217894A (zh) * 2020-10-12 2021-01-12 浙江大学 一种基于动态权重的负载均衡系统
US11025710B1 (en) * 2020-10-26 2021-06-01 Verizon Digital Media Services Inc. Systems and methods for dynamic load balancing based on server utilization and content popularity
CN112929408A (zh) * 2021-01-19 2021-06-08 郑州阿帕斯数云信息科技有限公司 动态负载均衡方法及装置
CN113141317A (zh) * 2021-03-05 2021-07-20 西安电子科技大学 流媒体服务器负载均衡方法、系统、计算机设备、终端
CN113742066A (zh) * 2021-08-09 2021-12-03 联通沃悦读科技文化有限公司 一种用于服务器集群的负载均衡系统和方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
一种基于集群的动态负载均衡算法研究;吴俊鹏; 刘晓东;《电子设计工程》;第第29卷卷(第第15期期);75-78页 *

Also Published As

Publication number Publication date
CN114205361A (zh) 2022-03-18

Similar Documents

Publication Publication Date Title
CN114205361B (zh) 一种负载均衡方法以及服务器
CN109218355B (zh) 负载均衡引擎,客户端,分布式计算系统以及负载均衡方法
CN101820384A (zh) 一种集群服务动态分配方法及装置
CN110519183B (zh) 一种节点限速的方法、装置、电子设备及存储介质
CN106817432B (zh) 云计算环境下虚拟资源弹性伸展的方法,系统和设备
CN110365748A (zh) 业务数据的处理方法和装置、存储介质及电子装置
CN108900626B (zh) 一种云环境下数据存储方法、装置及系统
CN109802986B (zh) 设备管理方法、系统、装置及服务器
US20220070099A1 (en) Method, electronic device and computer program product of load balancing
US10216593B2 (en) Distributed processing system for use in application migration
CN112799839A (zh) 请求处理方法、装置、计算机可读存储介质及电子设备
CN105450784B (zh) 向mq中的消息分配消费节点的装置及方法
CN112202829A (zh) 基于微服务的社交机器人调度系统和调度方法
CN110515728B (zh) 服务器调度方法、装置、电子设备及机器可读存储介质
CN113268329A (zh) 一种请求调度方法、装置及存储介质
CN114546493A (zh) 核共享方法及装置、处理核、电子设备、介质
CN116546029A (zh) 负载均衡方法、装置、存储介质及计算机设备
CN115794396A (zh) 资源分配的方法、系统和电子设备
CN112379978B (zh) 后端服务调用方法、装置、设备和存储介质
CN108600354B (zh) 系统响应时间波动抑制方法和系统
CN114296869A (zh) 一种基于tcp长连接的服务器节点服役方法及装置
CN115878309A (zh) 资源分配方法、装置、处理核、设备和计算机可读介质
CN113608870A (zh) 消息队列的负载均衡方法及装置、电子设备及存储介质
CN109445934B (zh) 查询请求的分配方法及系统
CN113190347A (zh) 一种边缘云系统及任务管理方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant