CN114666207A - 一种客户端对服务端进行请求保护的方案及系统 - Google Patents
一种客户端对服务端进行请求保护的方案及系统 Download PDFInfo
- Publication number
- CN114666207A CN114666207A CN202210266917.0A CN202210266917A CN114666207A CN 114666207 A CN114666207 A CN 114666207A CN 202210266917 A CN202210266917 A CN 202210266917A CN 114666207 A CN114666207 A CN 114666207A
- Authority
- CN
- China
- Prior art keywords
- request
- client
- retry
- server
- fusing
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种客户端对服务端进行请求保护的方案,所述方案包括以下步骤:步骤S1、客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;步骤S2、判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;步骤S3、在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;步骤S4、重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常;本发明能够实现在服务端出现异常情况下,能够对服务端进行保护。
Description
技术领域
本发明涉及计算机技术领域,特别是一种客户端对服务端进行请求保护的方案及系统。
背景技术
随着业务的发展,流量的增长,服务端的高可用成为一个不小的挑战,除了服务端自身的性能提升,横向扩容的优化措施。客户端对服务端也有必要增加一些保护措施,假设服务端因为某些不可控的原因导致服务不可用,如果这时客户端仍然大量的进行请求,那么可能加剧服务端的崩溃,直接把服务打掛。
发明内容
为克服上述问题,本发明的目的是提供一种能够实现在服务端出现不可控异常或者流量超载的情况下,对服务端进行保护的方案。
本发明采用以下方案实现:一种客户端对服务端进行请求保护的方案,所述方案包括以下步骤:
步骤S1、客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;
步骤S2、判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;
步骤S3、在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;
步骤S4、重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常,从而实现了在服务端出现异常情况下,能够对服务端进行保护。
进一步的,所述步骤S1进一步具体为:客户端向服务端发起读取用户信息的接口请求,判断服务端返回数据是否成功,是,则向用户展示数据,并记录请求成功数+1;否,则判断当前是否处于熔断状态,是,则提示用户“服务繁忙,请稍后再试”;否,则对请求失败的接口,发起重试,重试3次失败,则提示用户“服务繁忙,请稍后再试”。
进一步的,所述步骤S2进一步具体为:静默数是指设定一个最大的无效请求数10,静默期是指在一个统计周期内,对资源的请求数小于设置的静默数,那么就不会开启熔断,判断熔断的公式=请求失败数/请求总数>70%,请求失败比例大于70%,则判断是否处于静默期,是,则不开启熔断,否,则开启熔断。
进一步的,所述步骤S3进一步具体为:在60s-70s后释放10%流量进行重试,失败则翻倍,120s-130s后进行重试,直到第8-9分钟重试还是失败则开启服务降级,对外提供有损服务。
进一步的,所述步骤S4进一步具体为:在熔断开启后,步骤S3重试成功,则客户端逐步释放请求客户端的流量,每次释放的流量翻倍,第一次10%,第二次20%,第三次40%,第四次80%,直到100%流量全部释放,客户端关闭熔断状态,恢复正常。
本发明还提供了一种客户端对服务端进行请求保护的系统,包括发起模块、判断模块、重试模块和释放模块,所述发起模块,即客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;所述判断模块,即判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;所述重试模块,即在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;所述释放模块,即重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常,从而实现了在服务端出现异常情况下,能够对服务端进行保护。
进一步的,所述发起模块进一步具体为:客户端向服务端发起读取用户信息的接口请求,判断服务端返回数据是否成功,是,则向用户展示数据,并记录请求成功数+1;否,则判断当前是否处于熔断状态,是,则提示用户“服务繁忙,请稍后再试”;否,则对请求失败的接口,发起重试,重试3次失败,则提示用户“服务繁忙,请稍后再试”。
进一步的,所述判断模块进一步具体为:静默数是指设定一个最大的无效请求数10,静默期是指在一个统计周期内,对资源的请求数小于设置的静默数,那么就不会开启熔断,判断熔断的公式=请求失败数/请求总数>70%,请求失败比例大于70%,则判断是否处于静默期,是,则不开启熔断,否,则开启熔断。
进一步的,所述重试模块进一步具体为:在60s-70s后释放10%流量进行重试,失败则翻倍,120s-130s后进行重试,直到第8-9分钟重试还是失败则开启服务降级,对外提供有损服务。
进一步的,所述释放模块进一步具体为:在熔断开启后,步骤S3重试成功,则客户端逐步释放请求客户端的流量,每次释放的流量翻倍,第一次10%,第二次20%,第三次40%,第四次80%,直到100%流量全部释放,客户端关闭熔断状态,恢复正常。
本发明的有益效果在于:本发明能够解决服务端出现不可控异常或者流量超载的情况下,对服务端进行保护,避免因大量无效的尝试,让服务端有恢复的喘息时间。
附图说明
图1是本发明的方法流程示意图。
图2是本发明的系统原理框图。
具体实施方式
下面结合附图对本发明做进一步说明。
请参阅图1所示,本发明的一种客户端对服务端进行请求保护的方案,所述方案包括以下步骤:
步骤S1、客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;
步骤S2、判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;
步骤S3、在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;
步骤S4、重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常,从而实现了在服务端出现异常情况下,能够对服务端进行保护。
下面通过一具体实施例对本发明作进一步说明:
步骤一、判断请求是否成功,失败则判断是否处于熔断状态,不是则发起重试
客户端向服务端发起读取用户信息的接口请求,如果服务端返回数据成功,则向用户展示数据,并记录请求成功数+1。如果服务端接口返回数据失败,则判断当前是否处于熔断状态,如果是则提示用户“服务繁忙,请稍后再试”。如果当前不处于熔断状态,则对请求失败的接口,发起重试,如果重试3次仍然失败,则提示用户“服务繁忙,请稍后再试”。并且记录请求失败数+3。
步骤二、判断失败数是否超过静默数,如果超过则判断是否开启熔断
静默数是指设定一个最大的无效请求数10,静默期是指在一个统计周期内,如果对资源的请求数小于设置的静默数,那么就不会开启熔断。假设在一个统计周期刚刚开始时候,第1个请求碰巧是个失败请求,这个时候的失败比例就会是100%,存在一定的巧合性,所以静默期提高了熔断器的精准性以及降低误判可能性。
判断熔断的公式=请求失败数/请求总数>70%,如果请求失败比例大于70%则判断是否处于静默期,如果不在静默期则开启熔断。
步骤三、1分钟后释放10%流量进行重试,失败则翻倍,2分钟后进行重试,直到第8分钟重试还是失败则开启服务降级,对外提供有损服务。
如果处于熔断状态,则开始计时,前1分钟客户端对服务端进行完全的保护,任何用户的访问均不再向服务端发起请求,直接提示用户“服务繁忙,请稍后再试”。1分钟后客户端再逐渐开始释放流量向服务端进行尝试,第1分钟后释放10%流量进行尝试,如果失败率大于50%则时间翻倍,1x2=2分钟后重试,2x2=4分钟后重试,4x2=8分钟后重试。如果在8分钟后的重试还失败,则服务进入降级状态。
步骤四、如果成功则逐步释放流量,每次翻倍流量,10%、20%、40%、80%,直到释放100%,关闭熔断状态,恢复正常。
用户打开app客户端,客户端向服务端读取用户信息,返回客户端后展示给用户,如果在熔断开启后,步骤三重试成功,则客户端逐步释放请求客户端的流量,每次释放的流量翻倍,第一次10%,第二次20%,第三次40%,第四次80%,直到100%流量全部释放,客户端关闭熔断状态,恢复正常。
请参阅图2所示,本发明还提供了一种客户端对服务端进行请求保护的系统,包括发起模块、判断模块、重试模块和释放模块,所述发起模块,即客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;所述判断模块,即判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;所述重试模块,即在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;所述释放模块,即重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常,从而实现了在服务端出现异常情况下,能够对服务端进行保护。
所述发起模块进一步具体为:客户端向服务端发起读取用户信息的接口请求,判断服务端返回数据是否成功,是,则向用户展示数据,并记录请求成功数+1;否,则判断当前是否处于熔断状态,是,则提示用户“服务繁忙,请稍后再试”;否,则对请求失败的接口,发起重试,重试3次失败,则提示用户“服务繁忙,请稍后再试”。
所述判断模块进一步具体为:静默数是指设定一个最大的无效请求数10,静默期是指在一个统计周期内,对资源的请求数小于设置的静默数,那么就不会开启熔断,判断熔断的公式=请求失败数/请求总数>70%,请求失败比例大于70%,则判断是否处于静默期,是,则不开启熔断,否,则开启熔断。
所述重试模块进一步具体为:在60s-70s后释放10%流量进行重试,失败则翻倍,120s-130s后进行重试,直到第8-9分钟重试还是失败则开启服务降级,对外提供有损服务。
所述释放模块进一步具体为:在熔断开启后,步骤S3重试成功,则客户端逐步释放请求客户端的流量,每次释放的流量翻倍,第一次10%,第二次20%,第三次40%,第四次80%,直到100%流量全部释放,客户端关闭熔断状态,恢复正常。
以上所述仅为本发明的较佳实施例,凡依本发明申请专利范围所做的均等变化与修饰,皆应属本发明的涵盖范围。
Claims (10)
1.一种客户端对服务端进行请求保护的方案,其特征在于,所述方案包括以下步骤:
步骤S1、客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;
步骤S2、判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;
步骤S3、在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;
步骤S4、重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常,从而实现了在服务端出现异常情况下,能够对服务端进行保护。
2.根据权利要求1所述的一种客户端对服务端进行请求保护的方案,其特征在于:所述步骤S1进一步具体为:客户端向服务端发起读取用户信息的接口请求,判断服务端返回数据是否成功,是,则向用户展示数据,并记录请求成功数+1;否,则判断当前是否处于熔断状态,是,则提示用户“服务繁忙,请稍后再试”;否,则对请求失败的接口,发起重试,重试3次失败,则提示用户“服务繁忙,请稍后再试”。
3.根据权利要求1所述的一种客户端对服务端进行请求保护的方案,其特征在于:所述步骤S2进一步具体为:静默数是指设定一个最大的无效请求数10,静默期是指在一个统计周期内,对资源的请求数小于设置的静默数,那么就不会开启熔断,判断熔断的公式=请求失败数/请求总数>70%,请求失败比例大于70%,则判断是否处于静默期,是,则不开启熔断,否,则开启熔断。
4.根据权利要求1所述的一种客户端对服务端进行请求保护的方案,其特征在于:所述步骤S3进一步具体为:在60s-70s后释放10%流量进行重试,失败则翻倍,120s-130s后进行重试,直到第8-9分钟重试还是失败则开启服务降级,对外提供有损服务。
5.根据权利要求1所述的一种客户端对服务端进行请求保护的方案,其特征在于:所述步骤S4进一步具体为:在熔断开启后,步骤S3重试成功,则客户端逐步释放请求客户端的流量,每次释放的流量翻倍,第一次10%,第二次20%,第三次40%,第四次80%,直到100%流量全部释放,客户端关闭熔断状态,恢复正常。
6.一种客户端对服务端进行请求保护的系统,其特征在于:包括发起模块、判断模块、重试模块和释放模块,所述发起模块,即客户端向服务端发起读取用户信息的接口请求,判断请求是否成功,是,则向用户展示数据,并记录,否,则判断是否处于熔断状态;所述判断模块,即判断请求失败数是否超过静默数,是,则判断是否开启熔断,否,则继续重试请求;所述重试模块,即在一定时间内释放固定流量进行接口请求重试,重试失败则翻倍固定流量,然后再次重试,直至多次重试后还是失败,开启服务降级;所述释放模块,即重试成功的话,开始逐步释放流量,每次释放的流量翻倍,直至释放流量达到百分之百,关闭熔断状态,恢复正常,从而实现了在服务端出现异常情况下,能够对服务端进行保护。
7.根据权利要求6所述的一种客户端对服务端进行请求保护的系统,其特征在于:所述发起模块进一步具体为:客户端向服务端发起读取用户信息的接口请求,判断服务端返回数据是否成功,是,则向用户展示数据,并记录请求成功数+1;否,则判断当前是否处于熔断状态,是,则提示用户“服务繁忙,请稍后再试”;否,则对请求失败的接口,发起重试,重试3次失败,则提示用户“服务繁忙,请稍后再试”。
8.根据权利要求6所述的一种客户端对服务端进行请求保护的系统,其特征在于:所述判断模块进一步具体为:静默数是指设定一个最大的无效请求数10,静默期是指在一个统计周期内,对资源的请求数小于设置的静默数,那么就不会开启熔断,判断熔断的公式=请求失败数/请求总数>70%,请求失败比例大于70%,则判断是否处于静默期,是,则不开启熔断,否,则开启熔断。
9.根据权利要求6所述的一种客户端对服务端进行请求保护的系统,其特征在于:所述重试模块进一步具体为:在60s-70s后释放10%流量进行重试,失败则翻倍,120s-130s后进行重试,直到第8-9分钟重试还是失败则开启服务降级,对外提供有损服务。
10.根据权利要求6所述的一种客户端对服务端进行请求保护的系统,其特征在于:所述释放模块进一步具体为:在熔断开启后,步骤S3重试成功,则客户端逐步释放请求客户端的流量,每次释放的流量翻倍,第一次10%,第二次20%,第三次40%,第四次80%,直到100%流量全部释放,客户端关闭熔断状态,恢复正常。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210266917.0A CN114666207B (zh) | 2022-03-17 | 2022-03-17 | 一种客户端对服务端进行请求保护的方案及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210266917.0A CN114666207B (zh) | 2022-03-17 | 2022-03-17 | 一种客户端对服务端进行请求保护的方案及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114666207A true CN114666207A (zh) | 2022-06-24 |
CN114666207B CN114666207B (zh) | 2023-06-06 |
Family
ID=82029104
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210266917.0A Active CN114666207B (zh) | 2022-03-17 | 2022-03-17 | 一种客户端对服务端进行请求保护的方案及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114666207B (zh) |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060230305A1 (en) * | 2005-04-07 | 2006-10-12 | Microsoft Corporation | Retry request overload protection |
CN108156091A (zh) * | 2016-12-02 | 2018-06-12 | 阿里巴巴集团控股有限公司 | 一种流量控制方法及系统 |
CN110247856A (zh) * | 2019-05-24 | 2019-09-17 | 平安科技(深圳)有限公司 | 服务器资源释放方法和装置 |
CN111385125A (zh) * | 2018-12-29 | 2020-07-07 | Tcl集团股份有限公司 | 一种服务器动态控制方法及服务器 |
CN112131036A (zh) * | 2020-10-09 | 2020-12-25 | 腾讯科技(深圳)有限公司 | 一种过载保护方法、装置、设备及计算机可读存储介质 |
CN112527597A (zh) * | 2020-12-08 | 2021-03-19 | 云智慧(北京)科技有限公司 | 一种DotNet数据采集探针的自我监控与熔断方法 |
CN113923163A (zh) * | 2021-10-20 | 2022-01-11 | 广东亿迅科技有限公司 | 一种基于长连接消息通道限流方法及系统 |
-
2022
- 2022-03-17 CN CN202210266917.0A patent/CN114666207B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060230305A1 (en) * | 2005-04-07 | 2006-10-12 | Microsoft Corporation | Retry request overload protection |
CN108156091A (zh) * | 2016-12-02 | 2018-06-12 | 阿里巴巴集团控股有限公司 | 一种流量控制方法及系统 |
CN111385125A (zh) * | 2018-12-29 | 2020-07-07 | Tcl集团股份有限公司 | 一种服务器动态控制方法及服务器 |
CN110247856A (zh) * | 2019-05-24 | 2019-09-17 | 平安科技(深圳)有限公司 | 服务器资源释放方法和装置 |
CN112131036A (zh) * | 2020-10-09 | 2020-12-25 | 腾讯科技(深圳)有限公司 | 一种过载保护方法、装置、设备及计算机可读存储介质 |
CN112527597A (zh) * | 2020-12-08 | 2021-03-19 | 云智慧(北京)科技有限公司 | 一种DotNet数据采集探针的自我监控与熔断方法 |
CN113923163A (zh) * | 2021-10-20 | 2022-01-11 | 广东亿迅科技有限公司 | 一种基于长连接消息通道限流方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN114666207B (zh) | 2023-06-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106533805B (zh) | 一种微服务请求处理方法、微服务控制器及微服务架构 | |
EP0683942B1 (en) | Restoration of a home location register in a mobile radio system | |
ES2244451T3 (es) | Procedimiento y sistema para la comprobacion de la autenticidad de un primer abonado de comunicaciones en una red de comunicaciones. | |
US20040235523A1 (en) | System for replicating data of a mobile station | |
CN111078453B (zh) | 微服务自动熔断和恢复方法、装置、计算机设备及存储介质 | |
EP2921974A1 (en) | Data restoration method and system | |
CN103957155A (zh) | 报文传输方法、装置及互联接口 | |
CN113986501A (zh) | 实时数据库api无中断调用方法、系统、存储介质及服务器 | |
US7528697B2 (en) | Edge server failover | |
CN114666207B (zh) | 一种客户端对服务端进行请求保护的方案及系统 | |
US7082308B1 (en) | HLR mated-pair auto cutover | |
US20110029621A1 (en) | Mail server system and congestion control method | |
CN112437155B (zh) | 服务数据的处理方法、装置以及服务端设备 | |
CN112988546A (zh) | 一种支付系统防止服务雪崩的熔断方案及系统 | |
CN113867915A (zh) | 任务调度方法、电子设备及存储介质 | |
JPH08328970A (ja) | 被管理機器のログ取得方式 | |
CN112698969A (zh) | 一种基于消息落库的mq消息可靠性投递解决方法 | |
US5343480A (en) | System for detecting loss of message | |
CN111190754A (zh) | 一种区块链事件通知方法及区块链系统 | |
AU781354B2 (en) | SNMP network management system and management method thereof | |
CN113596083B (zh) | 一种基于状态跟踪的高可用云通信通话恢复的方法及系统 | |
CN111885169B (zh) | 一种云硬盘服务高可用的实现方法、系统及装置 | |
CN111049938B (zh) | 消息通知方法、装置、电子设备及可读存储介质 | |
CN109361620B (zh) | 一种数据发送的方法、装置、设备及存储介质 | |
CN111858177A (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 |