CN106790289A - 一种基于Nginx服务器的动态负载处理方法及系统 - Google Patents

一种基于Nginx服务器的动态负载处理方法及系统 Download PDF

Info

Publication number
CN106790289A
CN106790289A CN201710130846.0A CN201710130846A CN106790289A CN 106790289 A CN106790289 A CN 106790289A CN 201710130846 A CN201710130846 A CN 201710130846A CN 106790289 A CN106790289 A CN 106790289A
Authority
CN
China
Prior art keywords
end server
mark
server
status
health status
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.)
Pending
Application number
CN201710130846.0A
Other languages
English (en)
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.)
Beijing Sohu New Media Information Technology Co Ltd
Original Assignee
Beijing Sohu New Media Information 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 Beijing Sohu New Media Information Technology Co Ltd filed Critical Beijing Sohu New Media Information Technology Co Ltd
Priority to CN201710130846.0A priority Critical patent/CN106790289A/zh
Publication of CN106790289A publication Critical patent/CN106790289A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1025—Dynamic adaptation of the criteria on which the server selection is based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种基于Nginx服务器的动态负载处理方法，包括：定时向后端服务器发送心跳包，基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；当判断后端服务器处于非健康状态时，生成第一标记标记后端服务器，当判断后端服务器处于健康状态时，生成第二标记标记后端服务。本发明能够有效的对负载进行动态管理。本发明还公开了一种基于Nginx服务器的动态负载处理系统。

Description

一种基于Nginx服务器的动态负载处理方法及系统
技术领域
本发明涉及负载处理技术领域，尤其涉及一种基于Nginx服务器的动态负载处理方法及系统。
背景技术
Nginx是一种高性能的HTTP(HyperText Transfer Protocol，超文本传输协议)和反向代理服务器，是业界常用的负载均衡软件。目前，Nginx默认的负载均衡策略是采用加权轮询的方式给后端服务器分发请求。经研究发现，现有的的负载均衡策略不能有效的对负载进行管理，存在一定的局限性。因此，如何有效的基于Nginx服务器对负载进行动态管理是一项亟待解决的问题。
发明内容
本发明提供了一种基于Nginx服务器的动态负载处理方法，能够有效的对负载进行动态管理。
本发明提供了一种基于Nginx服务器的动态负载处理方法，包括：
定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
基于所述后端服务器根据所述心跳包返回的结果判断所述后端服务器的健康状态；
当判断所述后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征所述后端服务器处于非健康状态的标记；
当判断所述后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征所述后端服务器处于健康状态的标记。
优选地，所述返回结果包含所述后端服务器的状态码；
相应的，基于所述后端服务器根据所述心跳包返回的结果判断所述后端服务器的健康状态包括：
判断所述状态码是否满足预设条件；
当所述状态码不满足预设条件时，判断所述后端服务器处于非健康状态；
当所述状态码满足所述预设条件时，判断所述后端服务器处于健康状态。
优选地，所述方法还包括：
基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
基于业务需求将所述后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
基于业务需求添加或删减后端服务器。
优选地，所述方法还包括：
基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器。
优选地，所述方法还包括：
获取主服务器集群中的后端服务器的每秒查询率；
判断所述主服务器集群中的后端服务器的每秒查询率是否超过预设阈值；
当所述主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将部分请求分发至备用后端服务器集群中的后端服务器，直至所述主服务器集群中的后端服务器的每秒查询率小于等于所述预设阈值。
一种基于Nginx服务器的动态负载处理系统，包括：
第一发送模块，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
第一判断模块，用于基于所述后端服务器根据所述心跳包返回的结果判断所述后端服务器的健康状态；
标记模块，用于当判断所述后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征所述后端服务器处于非健康状态的标记；当判断所述后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征所述后端服务器处于健康状态的标记。
优选地，所述返回结果包含所述后端服务器的状态码；
相应的，所述第一判断模块具体用于：
判断所述状态码是否满足预设条件；
当所述状态码不满足预设条件时，判断所述后端服务器处于非健康状态；
当所述状态码满足所述预设条件时，判断所述后端服务器处于健康状态。
优选地，所述系统还包括：
表述性状态转移架构应用程序接口，用于实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
修改模块，用于基于业务需求将所述后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
增删模块，用于基于业务需求添加或删减后端服务器。
优选地，所述系统还包括：
第二发送模块，用于基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
转发模块，用于当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器。
优选地，所述系统还包括：
获取模块，用于获取主服务器集群中的后端服务器的每秒查询率；
第二判断模块，用于判断所述主服务器集群中的后端服务器的每秒查询率是否超过预设阈值；
分发模块，用于当所述主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将部分请求分发至备用后端服务器集群中的后端服务器，直至所述主服务器集群中的后端服务器的每秒查询率小于等于所述预设阈值。
由上述方案可知，本发明提供的一种基于Nginx服务器的动态负载处理方法，当需要对负载进行管理时，通过定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求，基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；当判断后端服务器处于非健康状态时，生成第一标记标记后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记后端服务，所述第二标记为表征后端服务器处于健康状态的标记。实现对后端服务器的主动健康检查，相对于现有技术能够更加有效的对负载进行动态管理。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例1的方法流程图；
图2为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例2的方法流程图；
图3为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例3的方法流程图；
图4为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例4的方法流程图；
图5为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例5的方法流程图；
图6为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例1的结构示意图；
图7为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例2的结构示意图；
图8为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例3的结构示意图；
图9为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例4的结构示意图；
图10为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例5的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
为了更加特定地强调实施的独立性，本说明书涉及许多模块或单元。举例而言，模块或单元可由硬件电路实现，该硬件电路包括特制VLSI电路或门阵列，比如逻辑芯片、晶体管，或其它组件。模块或单元也可在可编程的硬设备中实现，比如场效可编程门阵列、可编程阵列逻辑、可编程逻辑设备等等。
模块或单元也可在藉由各种形式的处理器所执行的软件中实现。比如说，一可执行码模块可包括一个或多个实体的或逻辑的计算机指令区块，该区块可能形成为，比如说，对象、程序或函数。然而，鉴别模块或单元的可执行部分不需要物理上放置在一起，但可由存于不同位置的不同指令所组成，当逻辑上组合在一起时，形成模块或单元且达到该模块或单元所要求的目的。
实际上，可执行码模块或单元可以是一单一指令或多个指令，甚至可以分布在位于不同的程序中的数个不同的码区段，并且横跨数个存储设备。同样地，操作数据可被辨识及显示于此模块或单元中，并且可以以任何合适的形式实施且在任何合适的数据结构形式内组织。操作数据可以集合成单一数据集，或可分布在具有不同的存储设备的不同的位置，且至少部分地只以电子信号方式存在于一系统或网络。
本说明书所提及的“实施例”或类似用语表示与实施例有关的特性、结构或特征，包括在本发明的至少一实施例中。因此，本说明书所出现的用语“在一实施例中”、“在实施例中”以及类似用语可能但不必然都指向相同实施例。
再者，本发明所述特性、结构或特征可以以任何方式结合在一个或多个实施例中。以下说明将提供许多特定的细节，比如编程序、软件模块、用户选择、网络交易、数据库查询、数据库结构、硬件模块、硬件电路、硬件芯片等例子，以提供对本发明实施例的了解。然而相关领域的普通技术人员将看出本发明，即使没有利用其中一个或多个特定细节，或利用其它方法、组件、材料等亦可实施。另一方面，为避免混淆本发明，公知的结构、材料或操作并没有详细描述。
如图1所示，为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例1的方法流程图，该方法包括：
S101、定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
S102、基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
S103、当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
S104、当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记。
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
综上所述，在上述实施例中，当需要对负载进行管理时，通过定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求，基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；当判断后端服务器处于非健康状态时，生成第一标记标记后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记后端服务，所述第二标记为表征后端服务器处于健康状态的标记。实现对后端服务器的主动健康检查，相对于现有技术能够更加有效的对负载进行动态管理。
如图2所示，为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例2的方法流程图，该方法包括：
S201、定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
S202、基于后端服务器根据心跳包返回的状态码，判断状态码是否满足预设条件；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，例如，判断后端服务器返回的状态码是否满足预设条件，当判断返回的状态码满足预设条件时，表明后端服务器处于健康状态，当判断返回的状态码不满足预设条件时，表明后端服务器处于非健康状态。
S203、当状态码不满足预设条件时，生成第一标记标记所述后端服务器，所述第一标记为表征所述后端服务器处于非健康状态的标记；
当判断后端服务器处于非健康状态时，即当状态码不满足预设条件时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
S204、当状态码满足预设条件时，生成第二标记标记所述后端服务，所述第二标记为表征所述后端服务器处于健康状态的标记。
当判断后端服务器处于健康状态时，即当状态码满足预设条件时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
综上所述，在上述实施例中，当需要对负载进行管理时，通过定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求，基于后端服务器根据心跳包返回的状态码判断后端服务器的健康状态；当判断后端服务器处于非健康状态时，生成第一标记标记后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记后端服务，所述第二标记为表征后端服务器处于健康状态的标记。实现对后端服务器的主动健康检查，相对于现有技术能够更加有效的对负载进行动态管理。
如图3所示，为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例3的方法流程图，该方法包括：
S301、定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
S302、基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
S303、当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
S304、当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记；
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
S305、基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
同时，基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，如，通过RESTful API实时获取后端服务器的状态信息，通过GET/detail获取所有后端服务器的信息，以及通过GET/status获取所有后端服务器的健康状态信息，即通过GET/status获取所有后端服务器的第一标记或第二标记。
S306、基于业务需求将后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
当根据业务需求需要动态调整后端服务器的状态时，可以将后端服务器的第一标记修改为第二标记，或将后端服务器的第二标记修改为第一标记，有效的避免了手动修改配置文件，并且避免了Nginx服务器重启导致性能损耗的缺点。
S307、基于业务需求添加或删减后端服务器。
同时，能够根据具体的业务需求对后端服务器进行添加或删除。
综上所述，在上述实施例中，在对后端服务器进行主动健康检测的同时，进一步实现了对后端服务器的动态管理，避免了手动修改Nginx服务器的配置文件以及重启Nginx服务器。
如图4所示，为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例4的方法流程图，该方法包括：
S401、定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
S402、基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
S403、当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
S404、当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记；
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
S405、基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
同时，基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，如，通过RESTful API实时获取后端服务器的状态信息，通过GET/detail获取所有后端服务器的信息，以及通过GET/status获取所有后端服务器的健康状态信息，即通过GET/status获取所有后端服务器的第一标记或第二标记。
S406、基于业务需求将后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
当根据业务需求需要动态调整后端服务器的状态时，可以将后端服务器的第一标记修改为第二标记，或将后端服务器的第二标记修改为第一标记，有效的避免了手动修改配置文件，并且避免了Nginx服务器重启导致性能损耗的缺点。
S407、基于业务需求添加或删减后端服务器；
同时，能够根据具体的业务需求对后端服务器进行添加或删除。
S408、基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能。
S409、当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器。
由于后端服务器中的某个服务器宕机，根据Nginx服务器提供的轮询算法，会导致后端服务器的缓存失效。本发明通过Nginx服务器将请求安装一定的负载均衡算法转发给主服务器集群中的后端服务器，在转发请求前会检测主服务器集群中的后端服务器的状态，若是第二标记up才转发，若所有转发的后端服务器处于第二标记down，则将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器进行处理，这样就保证主服务器集群中的其中一个服务器宕机只会影响部分的请求，将影响的范围降到了最低。
综上所述，在上述实施例中，在对后端服务器进行主动健康检测的同时，进一步实现了对后端服务器的动态管理，避免了手动修改Nginx服务器的配置文件以及重启Nginx服务器，同时，进一步实现了根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能，同时，进一步保证了在主服务器集群中的其中一个服务器宕机时，只会影响部分的请求，将影响的范围降到了最低。
如图5所示，为本发明公开的一种基于Nginx服务器的动态负载处理方法实施例5的方法流程图，该方法包括：
S501、定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
S502、基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
S503、当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
S504、当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记；
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
S505、基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
同时，基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，如，通过RESTful API实时获取后端服务器的状态信息，通过GET/detail获取所有后端服务器的信息，以及通过GET/status获取所有后端服务器的健康状态信息，即通过GET/status获取所有后端服务器的第一标记或第二标记。
S506、基于业务需求将后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
当根据业务需求需要动态调整后端服务器的状态时，可以将后端服务器的第一标记修改为第二标记，或将后端服务器的第二标记修改为第一标记，有效的避免了手动修改配置文件，并且避免了Nginx服务器重启导致性能损耗的缺点。
S507、基于业务需求添加或删减后端服务器；
同时，能够根据具体的业务需求对后端服务器进行添加或删除。
S508、基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能。
S509、当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器；
由于后端服务器中的某个服务器宕机，根据Nginx服务器提供的轮询算法，会导致后端服务器的缓存失效。本发明通过Nginx服务器将请求安装一定的负载均衡算法转发给主服务器集群中的后端服务器，在转发请求前会检测主服务器集群中的后端服务器的状态，若是第二标记up才转发，若所有转发的后端服务器处于第二标记down，则将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器进行处理，这样就保证主服务器集群中的其中一个服务器宕机只会影响部分的请求，将影响的范围降到了最低。
S510、获取主服务器集群中的后端服务器的每秒查询率；
S511、判断主服务器集群中的后端服务器的每秒查询率是否超过预设阈值；
S512、当主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将部分请求分发至备用后端服务器集群中的后端服务器，直至主服务器集群中的后端服务器的每秒查询率小于等于所述预设阈值。
当主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将超出的请求qps_exceed＝qps_now-qps_threshold，转发到备用后端服务器集群中的n个服务器中。具体的：
判断qps_now是否超过qps_threshold，若超过则解不等式X*qps_threshold＞＝qps_now，求解出的X，X表示需要多少服务器来承担qps_now请求，其中需要备用后端服务器集群中的服务器的数量为X-1，若X大于backup_server_n+1，则将X置为backup_server_n+1，否则，根据请求中指定的key进行哈希运算得到server_n，其中哈希表的长度为M。判断server_n是否在序列[1,2...Y-1]中，其中若是则将请求按照负载均衡策略转发到备用后端服务器集群中的X-1个服务器中，否则将请求转发给本该转发给主服务器集群中的服务器处理。
综上所述，在上述实施例中，在对后端服务器进行主动健康检测的同时，进一步实现了对后端服务器的动态管理，避免了手动修改Nginx服务器的配置文件以及重启Nginx服务器，同时，进一步实现了根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能，同时，进一步保证了在主服务器集群中的其中一个服务器宕机时，只会影响部分的请求，将影响的范围降到了最低，同时，能够实现后端服务器的动态扩容。
如图6所示，为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例1的结构示意图，该系统包括：
第一发送模块601，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
第一判断模块602，用于基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
标记模块603，用于当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记。
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
综上所述，在上述实施例中，当需要对负载进行管理时，通过定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求，基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；当判断后端服务器处于非健康状态时，生成第一标记标记后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记后端服务，所述第二标记为表征后端服务器处于健康状态的标记。实现对后端服务器的主动健康检查，相对于现有技术能够更加有效的对负载进行动态管理。
如图7所示，为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例2的结构示意图，该系统包括：
第一发送模块701，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
第一判断模块702，用于基于后端服务器根据心跳包返回的状态码，判断状态码是否满足预设条件；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，例如，判断后端服务器返回的状态码是否满足预设条件，当判断返回的状态码满足预设条件时，表明后端服务器处于健康状态，当判断返回的状态码不满足预设条件时，表明后端服务器处于非健康状态。
标记模块703，用于当状态码不满足预设条件时，生成第一标记标记所述后端服务器，所述第一标记为表征所述后端服务器处于非健康状态的标记；当状态码满足预设条件时，生成第二标记标记所述后端服务，所述第二标记为表征所述后端服务器处于健康状态的标记。
当判断后端服务器处于非健康状态时，即当状态码不满足预设条件时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
当判断后端服务器处于健康状态时，即当状态码满足预设条件时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
综上所述，在上述实施例中，当需要对负载进行管理时，通过定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求，基于后端服务器根据心跳包返回的状态码判断后端服务器的健康状态；当判断后端服务器处于非健康状态时，生成第一标记标记后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记后端服务，所述第二标记为表征后端服务器处于健康状态的标记。实现对后端服务器的主动健康检查，相对于现有技术能够更加有效的对负载进行动态管理。
如图8所示，为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例3的结构示意图，该系统包括：
第一发送模块801，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
第一判断模块802，用于基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
标记模块803，用于当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
表述性状态转移架构应用程序接口804，用于实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
同时，基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，如，通过RESTful API实时获取后端服务器的状态信息，通过GET/detail获取所有后端服务器的信息，以及通过GET/status获取所有后端服务器的健康状态信息，即通过GET/status获取所有后端服务器的第一标记或第二标记。
修改模块805，用于基于业务需求将后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
当根据业务需求需要动态调整后端服务器的状态时，可以将后端服务器的第一标记修改为第二标记，或将后端服务器的第二标记修改为第一标记，有效的避免了手动修改配置文件，并且避免了Nginx服务器重启导致性能损耗的缺点。
增删模块806，用于基于业务需求添加或删减后端服务器。
同时，能够根据具体的业务需求对后端服务器进行添加或删除。
综上所述，在上述实施例中，在对后端服务器进行主动健康检测的同时，进一步实现了对后端服务器的动态管理，避免了手动修改Nginx服务器的配置文件以及重启Nginx服务器。
如图9所示，为本发明公开的一种基于Nginx服务器的动态负载处理系统实施例4的结构示意图，该系统包括：
第一发送模块901，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
第一判断模块902，用于基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
标记模块903，用于当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
表述性状态转移架构应用程序接口904，用于接口实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
同时，基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，如，通过RESTful API实时获取后端服务器的状态信息，通过GET/detail获取所有后端服务器的信息，以及通过GET/status获取所有后端服务器的健康状态信息，即通过GET/status获取所有后端服务器的第一标记或第二标记。
修改模块905，用于基于业务需求将后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
当根据业务需求需要动态调整后端服务器的状态时，可以将后端服务器的第一标记修改为第二标记，或将后端服务器的第二标记修改为第一标记，有效的避免了手动修改配置文件，并且避免了Nginx服务器重启导致性能损耗的缺点。
增删模块906，用于基于业务需求添加或删减后端服务器；
同时，能够根据具体的业务需求对后端服务器进行添加或删除。
第二发送模块907，用于基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能。
转发模块908，用于当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器。
由于后端服务器中的某个服务器宕机，根据Nginx服务器提供的轮询算法，会导致后端服务器的缓存失效。本发明通过Nginx服务器将请求安装一定的负载均衡算法转发给主服务器集群中的后端服务器，在转发请求前会检测主服务器集群中的后端服务器的状态，若是第二标记up才转发，若所有转发的后端服务器处于第二标记down，则将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器进行处理，这样就保证主服务器集群中的其中一个服务器宕机只会影响部分的请求，将影响的范围降到了最低。
综上所述，在上述实施例中，在对后端服务器进行主动健康检测的同时，进一步实现了对后端服务器的动态管理，避免了手动修改Nginx服务器的配置文件以及重启Nginx服务器，同时，进一步实现了根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能，同时，进一步保证了在主服务器集群中的其中一个服务器宕机时，只会影响部分的请求，将影响的范围降到了最低。
如图10所示，为本发明公开的一种基于Nginx服务器的动态负载处理方系统实施例5的结构示意图，该系统包括：
第一发送模块1001，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
当需要基于Nginx服务器对负载进行动态管理时，首先在Nginx服务器中启动一个任务，定时的向后端的服务器发送心跳包请求，即发送一个超文本传输协议请求给后端服务器，后端服务器即真正处理请求的服务器。后端服务器接收到Nginx服务器发送的心跳包请求后返回处理结果，所述返回的结果可以为状态码、返回内容等。
第一判断模块1002，用于基于后端服务器根据心跳包返回的结果判断后端服务器的健康状态；
Nginx服务器基于后端服务器返回的结果，对后端服务器的健康状态进行判断，即判断返回的结果是否满足预设条件，当判断返回的结果满足预设条件时，表明后端服务器处于健康状态，当判断返回的结果不满足预设条件时，表明后端服务器处于非健康状态。
标记模块1003，用于当判断后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征后端服务器处于非健康状态的标记；当判断后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征后端服务器处于健康状态的标记；
当判断后端服务器处于非健康状态时，生成第一标记对后端服务器进行标记，所述的第一标记为表征后端服务器处于非健康状态的标记，例如，第一标记可以为down。
当判断后端服务器处于健康状态时，生成第二标记对后端服务器进行标记，所述第二标记为表征后端服务器处于健康状态的标记，例如，第二标记可以为up。
表述性状态转移架构应用程序接口1004，用于实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
同时，基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，如，通过RESTful API实时获取后端服务器的状态信息，通过GET/detail获取所有后端服务器的信息，以及通过GET/status获取所有后端服务器的健康状态信息，即通过GET/status获取所有后端服务器的第一标记或第二标记。
修改模块1005，用于基于业务需求将后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
当根据业务需求需要动态调整后端服务器的状态时，可以将后端服务器的第一标记修改为第二标记，或将后端服务器的第二标记修改为第一标记，有效的避免了手动修改配置文件，并且避免了Nginx服务器重启导致性能损耗的缺点。
增删模块1006，用于基于业务需求添加或删减后端服务器；
同时，能够根据具体的业务需求对后端服务器进行添加或删除。
第二发送模块1007，用于基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能。
转发模块1008，用于当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器；
由于后端服务器中的某个服务器宕机，根据Nginx服务器提供的轮询算法，会导致后端服务器的缓存失效。本发明通过Nginx服务器将请求安装一定的负载均衡算法转发给主服务器集群中的后端服务器，在转发请求前会检测主服务器集群中的后端服务器的状态，若是第二标记up才转发，若所有转发的后端服务器处于第二标记down，则将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器进行处理，这样就保证主服务器集群中的其中一个服务器宕机只会影响部分的请求，将影响的范围降到了最低。
获取模块1009，用于获取主服务器集群中的后端服务器的每秒查询率；
第二判断模块1010，用于判断主服务器集群中的后端服务器的每秒查询率是否超过预设阈值；
分发模块1011，用于当主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将部分请求分发至备用后端服务器集群中的后端服务器，直至主服务器集群中的后端服务器的每秒查询率小于等于所述预设阈值。
当主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将超出的请求qps_exceed＝qps_now-qps_threshold，转发到备用后端服务器集群中的n个服务器中。具体的：
判断qps_now是否超过qps_threshold，若超过则解不等式X*qps_threshold＞＝qps_now，求解出的X，X表示需要多少服务器来承担qps_now请求，其中需要备用后端服务器集群中的服务器的数量为X-1，若X大于backup_server_n+1，则将X置为backup_server_n+1，否则，根据请求中指定的key进行哈希运算得到server_n，其中哈希表的长度为M。判断server_n是否在序列[1,2...Y-1]中，其中若是则将请求按照负载均衡策略转发到备用后端服务器集群中的X-1个服务器中，否则将请求转发给本该转发给主服务器集群中的服务器处理。
综上所述，在上述实施例中，在对后端服务器进行主动健康检测的同时，进一步实现了对后端服务器的动态管理，避免了手动修改Nginx服务器的配置文件以及重启Nginx服务器，同时，进一步实现了根据用户的唯一标识进行分流，保证同一个用户的请求能够落在同一个后端服务器上处理，这样保证了推荐系统的缓存能够继续为用户使用，提高了服务性能，同时，进一步保证了在主服务器集群中的其中一个服务器宕机时，只会影响部分的请求，将影响的范围降到了最低，同时，能够实现后端服务器的动态扩容。
本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本发明实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种基于Nginx服务器的动态负载处理方法，其特征在于，包括：
定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
基于所述后端服务器根据所述心跳包返回的结果判断所述后端服务器的健康状态；
当判断所述后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征所述后端服务器处于非健康状态的标记；
当判断所述后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征所述后端服务器处于健康状态的标记。
2.根据权利要求1所述的方法，其特征在于，所述返回结果包含所述后端服务器的状态码；
相应的，基于所述后端服务器根据所述心跳包返回的结果判断所述后端服务器的健康状态包括：
判断所述状态码是否满足预设条件；
当所述状态码不满足预设条件时，判断所述后端服务器处于非健康状态；
当所述状态码满足所述预设条件时，判断所述后端服务器处于健康状态。
3.根据权利要求2所述的方法，其特征在于，还包括：
基于表述性状态转移架构应用程序接口实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
基于业务需求将所述后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
基于业务需求添加或删减后端服务器。
4.根据权利要求3所述的方法，其特征在于，还包括：
基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器。
5.根据权利要求4所述的方法，其特征在于，还包括：
获取主服务器集群中的后端服务器的每秒查询率；
判断所述主服务器集群中的后端服务器的每秒查询率是否超过预设阈值；
当所述主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将部分请求分发至备用后端服务器集群中的后端服务器，直至所述主服务器集群中的后端服务器的每秒查询率小于等于所述预设阈值。
6.一种基于Nginx服务器的动态负载处理系统，其特征在于，包括：
第一发送模块，用于定时向后端服务器发送心跳包，所述心跳包为超文本传输协议请求；
第一判断模块，用于基于所述后端服务器根据所述心跳包返回的结果判断所述后端服务器的健康状态；
标记模块，用于当判断所述后端服务器处于非健康状态时，生成第一标记标记所述后端服务器，所述第一标记为表征所述后端服务器处于非健康状态的标记；当判断所述后端服务器处于健康状态时，生成第二标记标记所述后端服务，所述第二标记为表征所述后端服务器处于健康状态的标记。
7.根据权利要求6所述的系统，其特征在于，所述返回结果包含所述后端服务器的状态码；
相应的，所述第一判断模块具体用于：
判断所述状态码是否满足预设条件；
当所述状态码不满足预设条件时，判断所述后端服务器处于非健康状态；
当所述状态码满足所述预设条件时，判断所述后端服务器处于健康状态。
8.根据权利要求7所述的系统，其特征在于，还包括：
表述性状态转移架构应用程序接口，用于实时获取所述后端服务器的状态信息，所述状态信息包括表征所述后端服务器健康状态的第一标记或第二标记；
修改模块，用于基于业务需求将所述后端服务器的第一标记修改为第二标记，或将所述后端服务器的第二标记修改为第一标记；
增删模块，用于基于业务需求添加或删减后端服务器。
9.根据权利要求8所述的系统，其特征在于，还包括：
第二发送模块，用于基于用户的唯一标识，将同一个用户的请求分发至同一个后端服务器进行处理；
转发模块，用于当待转发的主服务器集群中的后端服务器的健康状态标记为第一标记时，将安装一定的负载均衡算法的请求转发至备用后端服务器集群中的后端服务器。
10.根据权利要求9所述的系统，其特征在于，还包括：
获取模块，用于获取主服务器集群中的后端服务器的每秒查询率；
第二判断模块，用于判断所述主服务器集群中的后端服务器的每秒查询率是否超过预设阈值；
分发模块，用于当所述主服务器集群中的后端服务器的每秒查询率超过预设阈值时，将部分请求分发至备用后端服务器集群中的后端服务器，直至所述主服务器集群中的后端服务器的每秒查询率小于等于所述预设阈值。
CN201710130846.0A 2017-03-07 2017-03-07 一种基于Nginx服务器的动态负载处理方法及系统 Pending CN106790289A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710130846.0A CN106790289A (zh) 2017-03-07 2017-03-07 一种基于Nginx服务器的动态负载处理方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710130846.0A CN106790289A (zh) 2017-03-07 2017-03-07 一种基于Nginx服务器的动态负载处理方法及系统

Publications (1)

Publication Number Publication Date
CN106790289A true CN106790289A (zh) 2017-05-31

Family

ID=58962842

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710130846.0A Pending CN106790289A (zh) 2017-03-07 2017-03-07 一种基于Nginx服务器的动态负载处理方法及系统

Country Status (1)

Country Link
CN (1) CN106790289A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107682442A (zh) * 2017-10-18 2018-02-09 中国银联股份有限公司 一种Web连接方法及装置
CN107888453A (zh) * 2017-11-27 2018-04-06 苏州乐麟无线信息科技有限公司 一种基于Nginx下的多服务器状态监控方法及系统
CN109558246A (zh) * 2018-12-04 2019-04-02 北京字节跳动网络技术有限公司 一种负载均衡方法、装置、电子设备及存储介质
CN109981459A (zh) * 2019-02-28 2019-07-05 联想(北京)有限公司 一种信息发送方法、客户端和计算机可读存储介质
CN111124765A (zh) * 2019-12-06 2020-05-08 中盈优创资讯科技有限公司 一种基于节点标签的大数据集群任务调度方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103491123A (zh) * 2012-06-14 2014-01-01 中国移动通信集团贵州有限公司 一种基于域名访问的负载均衡方法、系统及负载均衡器
CN104579765A (zh) * 2014-12-27 2015-04-29 北京奇虎科技有限公司 一种集群系统的容灾方法和装置
CN104753706A (zh) * 2013-12-27 2015-07-01 中国移动通信集团公司 一种分布式集群配置管理方法及装置
CN105978939A (zh) * 2016-04-25 2016-09-28 乐视控股（北京）有限公司 一种数据下载方法及设备
US20160294933A1 (en) * 2015-04-03 2016-10-06 Nicira, Inc. Method, apparatus, and system for implementing a content switch

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103491123A (zh) * 2012-06-14 2014-01-01 中国移动通信集团贵州有限公司 一种基于域名访问的负载均衡方法、系统及负载均衡器
CN104753706A (zh) * 2013-12-27 2015-07-01 中国移动通信集团公司 一种分布式集群配置管理方法及装置
CN104579765A (zh) * 2014-12-27 2015-04-29 北京奇虎科技有限公司 一种集群系统的容灾方法和装置
US20160294933A1 (en) * 2015-04-03 2016-10-06 Nicira, Inc. Method, apparatus, and system for implementing a content switch
CN105978939A (zh) * 2016-04-25 2016-09-28 乐视控股（北京）有限公司 一种数据下载方法及设备

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107682442A (zh) * 2017-10-18 2018-02-09 中国银联股份有限公司 一种Web连接方法及装置
CN107682442B (zh) * 2017-10-18 2020-12-18 中国银联股份有限公司 一种Web连接方法及装置
CN107888453A (zh) * 2017-11-27 2018-04-06 苏州乐麟无线信息科技有限公司 一种基于Nginx下的多服务器状态监控方法及系统
CN107888453B (zh) * 2017-11-27 2020-10-09 苏州乐麟无线信息科技有限公司 一种基于Nginx下的多服务器状态监控方法及系统
CN109558246A (zh) * 2018-12-04 2019-04-02 北京字节跳动网络技术有限公司 一种负载均衡方法、装置、电子设备及存储介质
CN109981459A (zh) * 2019-02-28 2019-07-05 联想(北京)有限公司 一种信息发送方法、客户端和计算机可读存储介质
CN111124765A (zh) * 2019-12-06 2020-05-08 中盈优创资讯科技有限公司 一种基于节点标签的大数据集群任务调度方法及系统

Similar Documents

Publication Publication Date Title
CN106790289A (zh) 一种基于Nginx服务器的动态负载处理方法及系统
JP5664098B2 (ja) 複合イベント分散装置、複合イベント分散方法および複合イベント分散プログラム
US20180121322A1 (en) Methods and Systems for Testing Versions of Applications
US9965515B2 (en) Method and device for cache management
CN107239701B (zh) 识别恶意网站的方法及装置
CN108009261A (zh) 一种数据同步方法、装置及电子设备
US9703705B2 (en) Performing efficient cache invalidation
WO2016028416A1 (en) Dynamic peg orders in an electronic trading system
CN111708637A (zh) 一种数据处理方法、装置及计算机可读介质
WO2020055413A1 (en) Blockchain for audit
US20150333985A1 (en) Identifying an analysis reporting message in network traffic
CN108052824A (zh) 一种风险防控方法、装置及电子设备
CN104239353B (zh) 一种web分类控制和日志审计的方法
CN104219230A (zh) 识别恶意网站的方法及装置
US10055313B2 (en) Method and system for session disaster recovery
US20200349277A1 (en) Privacy preserving data collection and analysis
CN111813868B (zh) 数据同步方法及装置
CN104468399A (zh) 数据传输方法、装置和服务器
US10387407B2 (en) Preventing abuse in content sharing system
JP2017525072A (ja) 組み込み可能なクラウド分析
CN108664493B (zh) 统计url是否有效的方法、装置、电子设备和存储介质
CN110209347B (zh) 一种可追溯的数据存储方法
JP2015106330A (ja) 著作権侵害監視システム、監視サーバおよびプログラム
CN105335362B (zh) 实时数据的处理方法及系统、即时处理系统
US9172729B2 (en) Managing message distribution in a networked environment

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20170531