CN111901249A - Service current limiting method, device, equipment and storage medium - Google Patents
Service current limiting method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN111901249A CN111901249A CN202010770404.4A CN202010770404A CN111901249A CN 111901249 A CN111901249 A CN 111901249A CN 202010770404 A CN202010770404 A CN 202010770404A CN 111901249 A CN111901249 A CN 111901249A
- Authority
- CN
- China
- Prior art keywords
- service
- routing
- service provider
- token
- service 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000004364 calculation method Methods 0.000 claims description 16
- 230000002159 abnormal effect Effects 0.000 claims description 9
- 238000005516 engineering process Methods 0.000 abstract description 7
- 230000005540 biological transmission Effects 0.000 abstract description 2
- 230000008569 process Effects 0.000 description 10
- 238000012545 processing Methods 0.000 description 10
- 238000004891 communication Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000001680 brushing effect Effects 0.000 description 5
- 241001522296 Erithacus rubecula Species 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 229920006395 saturated elastomer Polymers 0.000 description 2
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- 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/215—Flow control; Congestion control using token-bucket
-
- 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
-
- 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to the technical field of data transmission in financial science and technology, and discloses a method, a device, equipment and a storage medium for limiting the flow of a service, wherein the method comprises the following steps: receiving a service request sent by a client, and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy; and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table. Therefore, whether the service request can obtain the token at each service level is judged based on the distributed current limiting strategy, and the service request which obtains the token is routed to the service provider based on the routing matching table after the token is obtained, so that the flexibility of current limiting is improved, and the routing efficiency and accuracy are improved.
Description
Technical Field
The present invention relates to the field of data transmission technology in financial technology (Fintech), and in particular, to a method, an apparatus, a device, and a storage medium for limiting traffic.
Background
With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually changing to financial technology (Fintech), but higher requirements are also put forward on the technologies due to the requirements of the financial industry on safety and real-time performance.
At present, many services need to be connected to a downstream service provider, and for services whose total traffic volume reaches the million-level per day, in order to ensure that the server operates stably without being broken down, a client sending a service request needs to be subjected to current limiting and then forwards the service request to the downstream service provider. Currently, the current is limited by counting and forwarding the service request by weighted polling. However, in the manner of counting current limiting and weighted polling, in the actual processing process, the operation and maintenance personnel need to communicate the service processing amount of the downstream service provider with the butt-joint person of the downstream service provider, and then the current limiting is estimated according to the service processing amount, so that the subsequent routing process is completed.
Disclosure of Invention
The invention provides a business method, a business device, business equipment and a storage medium, aiming at increasing the flexibility of current limiting and improving the efficiency and the accuracy of routing.
In order to achieve the above object, the present invention provides a method for limiting traffic, including:
receiving a service request sent by a client, and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy;
and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table.
Optionally, the step of determining whether the service request can obtain the token at each service level based on the distributed current limiting policy includes:
newly adding an asynchronous thread for the service request, accessing the distributed token buckets corresponding to all service levels according to a preset sequence through the asynchronous thread, and calculating the redis access time of all the distributed token buckets according to the starting interval and the timestamp of the asynchronous thread;
comparing the redis access time of each distributed token bucket with a preset token acquisition time of each distributed token bucket;
if the redis access times corresponding to the distributed token buckets are all smaller than corresponding preset token obtaining time, judging that the service request can obtain tokens at each service level;
and if one preset token obtaining time which is greater than or equal to the corresponding preset token obtaining time exists in the redis access times, judging that the token can not be obtained by the service request at each service level.
Optionally, the step of accessing, by the asynchronous thread, the distributed token buckets corresponding to the respective service levels in a preset order further includes:
and acquiring a calling identifier and interface information of the service request, and determining a plurality of service levels of the service request according to the calling identifier and the interface information so that the asynchronous thread can access a plurality of distributed token buckets corresponding to the plurality of service levels in sequence.
Optionally, the step of routing the service request to the corresponding service provider according to a preset routing ratio table includes:
based on the calling identification and the interface information of the service request, searching a designated service provider corresponding to the calling identification and the interface information from the routing ratio table;
if the appointed service provider is found, routing the service request to the appointed service provider;
if the appointed service provider is not found, acquiring the ratio of each service provider corresponding to the interface information from a preset routing ratio table, and randomly routing the service request to one service provider based on the ratio.
Optionally, the method further comprises:
setting a routing matching table according to the specified configuration information and the operation configuration information, wherein the operation configuration information comprises the total service volume, the limiting times of each service provider and the matching of the access service request quantity of each service provider;
the step of routing the service request to the corresponding service provider according to the preset routing ratio table further comprises:
and if the abnormal service provider is detected, updating the routing ratio table based on the success rate of the normal service provider to obtain a new routing ratio table.
Optionally, the step of updating the routing ratio table based on the success rate of the normal service provider to obtain a new routing ratio table includes:
judging whether the current ratio meets the traffic demand or not based on the success rate of each normal service provider, the current ratio and the residual traffic;
and if the current ratio does not meet the service requirement, determining a new ratio of each normal service provider according to the residual service volume and the success rate of each normal service provider, and updating the routing ratio table based on the new ratio to obtain a new routing ratio table.
Optionally, the step of determining a new allocation ratio of each normal service provider according to the remaining traffic volume and the success rate of each normal service provider includes:
calculating the remaining service times of each normal service provider according to the remaining service volume and the predetermined success rate difference by using a preset remaining service time calculation formula, wherein the remaining service time calculation formula is as follows:
wherein i denotes the number of the normal service provider, niFor the remaining number of services, SrIs the success rate gap, Nn is the remaining traffic;
determining a new matching ratio of each normal service provider according to the residual traffic, the residual service times and a preset matching calculation formula; wherein the proportion calculation formula is as follows:
where pi represents the new allocation ratio for each facilitator.
In addition, to achieve the above object, the present invention also provides a traffic current limiting apparatus, including:
the distributed current limiting module is used for receiving a service request sent by a client and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy;
and the routing module is used for routing the service request to a corresponding service provider according to a preset routing ratio table if the service request can acquire the token at each service level.
In addition, to achieve the above object, the present invention further provides a service current limiting device, where the service current limiting device includes a processor, a memory, and a service current limiting program stored in the memory, and when the service current limiting program is executed by the processor, the service current limiting method as described above is implemented.
In addition, to achieve the above object, the present invention further provides a computer storage medium, where a traffic throttling program is stored, and the traffic throttling program implements the steps of the traffic throttling method when being executed by a processor.
Compared with the prior art, the invention provides a service current limiting method, a device, equipment and a storage medium, which are used for receiving a service request sent by a client and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy; and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table. Therefore, whether the service request can obtain the token at each service level is judged based on the distributed current limiting strategy, and the service request which obtains the token is routed to the service provider based on the routing matching table after the token is obtained, so that the flexibility of current limiting is improved, and the routing efficiency and accuracy are improved.
Drawings
Fig. 1 is a schematic hardware structure diagram of a traffic current limiting device according to various embodiments of the present invention;
fig. 2 is a schematic flow chart of a first embodiment of the traffic throttling method of the present invention;
fig. 3 is a schematic diagram of a service throttling framework designed by the service throttling method of the present invention;
fig. 4 is a flowchart illustrating a second embodiment of the traffic throttling method according to the present invention;
fig. 5 is a flow chart illustrating a third embodiment of the traffic throttling method of the present invention;
fig. 6 is a functional block diagram of a traffic limiting device according to a first embodiment of the present invention.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
The service current limiting device mainly related to the embodiment of the invention is a network connection device capable of realizing network connection, and the service current limiting device can be a server, a cloud platform and the like.
Referring to fig. 1, fig. 1 is a schematic diagram of a hardware structure of a traffic current limiting device according to embodiments of the present invention. In this embodiment of the present invention, the traffic limiting device may include a processor 1001 (e.g., a Central processing unit, CPU), a communication bus 1002, an input port 1003, an output port 1004, and a memory 1005. The communication bus 1002 is used for realizing connection communication among the components; the input port 1003 is used for data input; the output port 1004 is used for data output, the memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as a magnetic disk memory, and the memory 1005 may optionally be a storage device independent of the processor 1001. Those skilled in the art will appreciate that the hardware configuration depicted in FIG. 1 is not intended to be limiting of the present invention, and may include more or less components than those shown, or some components in combination, or a different arrangement of components.
With continued reference to fig. 1, the memory 1005 of fig. 1, which is a readable storage medium, may include an operating system, a network communication module, an application program module, and a traffic throttling program. In fig. 1, the network communication module is mainly used for connecting to a server and performing data communication with the server; the processor 1001 may call the traffic throttling program stored in the memory 1005 and execute the traffic throttling method provided by the embodiment of the present invention.
The embodiment of the invention provides a service current limiting method.
Referring to fig. 2, fig. 2 is a flowchart illustrating a traffic throttling method according to a first embodiment of the present invention.
In this embodiment, the service current limiting method is applied to a service current limiting device, and the method includes:
step S101, receiving a service request sent by a client, and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy;
and step S102, if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table.
In this embodiment, a service current limiting framework for operating the service current limiting method is set up in advance. Specifically, as shown in fig. 3, fig. 3 is a schematic diagram of a service current limiting framework designed by the service current limiting method of the present invention; referring to fig. 3, the framework includes a client interface, a load balancing module, a distributed throttling module, a routing module, and a facilitator interface. The client interface is used for establishing communication connection with a client and receiving a service request sent by the client. The load balancing module is used for distributing the service requests sent by the clients to the servers of the distributed current limiting module so that the servers can process the service requests. It will be appreciated that the server may be a front-end system of the distributed current limiting module. The distributed current limiting module is used for the distributed token bucket to carry out multi-level current limiting on the service request. And the routing module is used for routing the service request which obtains the token to the corresponding service provider. redis dictionary server, which is an open source log-type and key-value-type data storage system written in C language, supporting network, based on memory and endurable, and providing application program interface of multiple languages.
Specifically, the service request includes service types such as a face refreshing request, a payment request, a login request, a download request, and a forwarding request. The service request mainly refers to a large number of service requests sent by one or more clients within a time period, or refers to service requests sent by a large number of clients within a time period.
It can be understood that if a large number of service requests are directly accessed to the server, the processing capacity of the server may be exceeded, which may result in the server being broken down, and thus, the normal service flow may be affected. In order to control the accessed service request within the acceptable range, the service request accesses a distributed token bucket, if the service request can obtain the token from the distributed token bucket, the processing capacity of the server is not exceeded.
In this embodiment, each service level of the service request is set according to a specific service. For example, if the service request is a face-brushing request, a plurality of service levels such as a face-brushing service level, a total service level, and a total client level may be set. If the service request is a micro credit card payment request, a plurality of service levels such as a micro payment level, a credit card payment level, a settlement level, a general service level and a general client level can be set. And each service level is respectively provided with a corresponding distributed token bucket, and if all service levels of the service request can obtain tokens from the distributed token buckets, the token does not exceed the processing range of the server, so that the server cannot be punctured.
Further, if the service request can obtain tokens at each service level, the service request is routed to a corresponding service provider according to a preset routing ratio table. In this embodiment, the routing matching table is set according to actual needs, and the routing matching table includes total traffic of each service, including the number of times of restriction of each service provider, and the matching of the number of requests for accessing services by each service provider. Wherein the ratio is set according to the processing capacity of each service provider. For example, for a face-brushing request, the total traffic in the corresponding routing ratio table is the total number of requests that can be handled for the face-brushing request. If the service providers A, B and C are included, the limit times of each service provider can be expressed as L according to the time situationA,LB,LCThe corresponding ratio may be 3:3: 4.
Otherwise, if the service request cannot acquire the token in one or more service levels, the service request is rejected.
According to the scheme, the service request sent by the client is received, and whether the token can be obtained in each distributed token bucket corresponding to each service level of the service request is judged based on the distributed current limiting strategy; and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table. Therefore, whether the service request can obtain the token at each service level is judged based on the distributed current limiting strategy, and the service request which obtains the token is routed to the service provider based on the routing matching table after the token is obtained, so that the flexibility of current limiting is improved, and the routing efficiency and accuracy are improved.
As shown in fig. 4, a second embodiment of the present invention provides a method for limiting traffic flow, where based on the first embodiment shown in fig. 2, the step of determining, based on a distributed current limiting policy, whether a token can be obtained in each distributed token bucket corresponding to each service level of the service request includes:
step S201: newly adding an asynchronous thread for the service request, accessing the distributed token buckets corresponding to all service levels according to a preset sequence through the asynchronous thread, and calculating the redis access time of all the distributed token buckets according to the starting interval and the timestamp of the asynchronous thread;
step S202: comparing the redis access time of each distributed token bucket with a preset token acquisition time of each distributed token bucket;
step S203: if the redis access times corresponding to the distributed token buckets are all smaller than corresponding preset token obtaining time, judging that the service request can obtain tokens at each service level;
step S204: and if one preset token obtaining time which is greater than or equal to the corresponding preset token obtaining time exists in the redis access times, judging that the token can not be obtained by the service request at each service level.
In this embodiment, the token bucket is a distributed token bucket, and multi-level distributed current limiting is implemented by the distributed token bucket.
In order to process a large number of service requests concurrently, after receiving a service request, an asynchronous thread is newly added to the service request, and then the token buckets of all levels are accessed through the asynchronous thread. If a plurality of asynchronous threads simultaneously read and write data of the distributed token bucket, dirty reading and magic reading may be caused. Therefore, in order to prevent dirty reading and unreal reading in a high-concurrency scene, after an asynchronous thread is newly added, the thread is locked, and after a token result is obtained, the lock is released. The token result includes a get token and an unseen token. In this embodiment, a redis distributed lock may be used. Upon obtaining a token result for the service request corresponding to the asynchronous thread, the redis distributed lock is released.
Further, the step S201: the step of accessing the distributed token buckets corresponding to the service levels in the preset order through the asynchronous threads further comprises:
and acquiring a calling identifier and interface information of the service request, and determining a plurality of service levels of the service request according to the calling identifier and the interface information so that the asynchronous thread can access a plurality of distributed token buckets corresponding to the plurality of service levels in sequence.
In this embodiment, the plurality of service levels may include a first service level, a second service level, and a third service level, so that the asynchronous thread sequentially accesses a first distributed token bucket, a second distributed token bucket, and a third distributed token bucket corresponding to the first service level, the second service level, and the third service level. It will be appreciated that more or fewer traffic levels and their corresponding distributed token buckets may be provided in other embodiments. Wherein the calling identifier is a code allocated to each client. The interface information is a method name or URL (Uniform Resource Locator) of each service interface. Therefore, the service type of the service request can be known according to the interface information. In this embodiment, the number of service levels is three, the service type of the service request is set as a first service level, all service types are set as a second service level, and each accessible request type is set as a third service level. For example, the service type corresponding to the first service level may be one of a face brushing service, a payment service, a login service, a download service, and a forwarding service, and specifically, the first service level is determined by the service type to which the service request belongs. The second service level comprises all service types, i.e. the second level comprises all service requests. The third service level comprises all requests, such as connection requests, access requests, service requests, etc., that can be received by the client interface of the service throttling system. The maximum number of accessible requests of each level of each service type is then set empirically, e.g. for a flush service request the maximum number of connectable requests of the first service level may be set to N1, the maximum number of connectable requests of all services of the second service level may be set to N2, and the maximum number of connectable requests of the third service level may be set to N3. In this embodiment, the capacity of the distributed token bucket is determined based on the maximum number of requests. After the maximum request number is set, the maximum request number of each hierarchy is used as the token number of the redis token bucket of the corresponding hierarchy.
The principle of the token bucket algorithm is that a system generates tokens at a constant rate, then puts the tokens into a token bucket, and when the number of tokens in the token bucket reaches the number of tokens and then puts the tokens into the token bucket, redundant tokens are discarded. When a service request needs to be processed, a token needs to be taken out from the token bucket, and if no token exists in the token bucket at the moment, the service request cannot be processed, so that the service request needs to be rejected, or the service request which does not acquire the token is added into a waiting queue. The present embodiment sets a distributed token bucket based on redis.
Typically the asynchronous thread accesses the distributed token bucket no less than 5ms once. The response time of each distributed token bucket can reach 200tps (transition per second, average response time per service request) when high concurrency occurs, so that the timestamp needs to be saved.
When the asynchronous thread corresponding to the service request is started, the redis access time of the asynchronous thread accessing the distributed token bucket needs to be recorded. Specifically, the preset asynchronous thread starting interval is represented as Tstart, wherein Tstart is generally more than 0ms and less than 50 ms; the timestamp is denoted as Ttimestamp, which is expressed in ms. The embodiment determines the sum of the timestamp and the preset asynchronous thread starting interval as the redis access time. And expressing the redis access time as Tredis, and then Tredis is Ttimestamp + Tstart.
Further, the redis access time is compared with a preset token acquisition time. If the preset token obtaining time is represented as Token, the specified time is represented as Tgiven, and the token generating time interval is represented as Tproduct, the Ttoken is Tgiven + Tproduct.
In this embodiment, if the redis access times Tredis of the multiple distributed token buckets are all smaller than the corresponding preset token obtaining time Ttoken, it is indicated that the distributed token buckets of each level of the asynchronous thread can obtain tokens. On the contrary, if the redis access time Tredis of the asynchronous thread accessing one or more distributed token buckets is greater than or equal to the corresponding preset token obtaining time Ttoken, it is determined that the service request cannot obtain tokens at each service level. And if the token cannot be acquired, the hierarchy which cannot be accessed to the service request exists, so that the service request is rejected, or the service request is transferred to a waiting queue.
In this embodiment, the asynchronous thread accesses the plurality of distributed token buckets corresponding to the plurality of service levels in sequence according to a preset order. For example, if the first distributed token bucket does not acquire tokens, it is determined that the service request cannot acquire tokens at each service level; or if the token is not acquired in the second distributed token bucket, it is determined that the service request cannot acquire the token at each service level. Therefore, distributed token buckets of all levels are sequentially accessed, if a token cannot be obtained in a certain distributed token bucket, the next distributed token bucket is not continuously accessed, and the token obtaining time can be saved. For example, if the first traffic level is flush, the second traffic level is service, and the third traffic level is all interfaces. If the token is not acquired in the face brushing distributed token bucket corresponding to the face brushing, indicating that the face brushing service is saturated and a new face brushing service cannot be accessed; for another example, if no token is obtained in the service token bucket corresponding to the service, it indicates that the service traffic is saturated, and accessing a new traffic request may overload the server. Therefore, in order to ensure that the servers of all the levels can stably operate, if the redis access time Tredis of the asynchronous thread accessing one or more distributed token buckets is greater than or equal to the corresponding preset token obtaining time Ttoken, it is determined that the service request cannot obtain tokens at all the service levels.
In this embodiment, by using the above scheme, an asynchronous thread is newly added to the service request, redis access time is calculated according to a start interval and a timestamp of the asynchronous thread, and a plurality of distributed token buckets corresponding to each service level are accessed by the asynchronous thread according to a preset sequence; comparing the redis access time with a preset token acquisition time; and if the redis access time corresponding to the distributed token buckets is smaller than the corresponding preset token acquisition time, judging that the service request can acquire the token at each service level. Therefore, the distributed token bucket realizes the current limiting of the service requests sent by the client at each level, prevents the server from being broken down, and realizes the distributed current limiting at multiple levels.
As shown in fig. 5, a third embodiment of the present invention provides a method for limiting traffic flow, based on the first and second embodiments shown in fig. 2 and fig. 4, where the step of routing the service request to a corresponding service provider according to a preset routing ratio table includes:
step S301: based on the calling identification and the interface information of the service request, searching a designated service provider corresponding to the calling identification and the interface information from the routing matching table;
step S3011: if the appointed service provider is found, routing the service request to the appointed service provider;
step S3012: if the appointed service provider is not found, acquiring the ratio of each service provider corresponding to the interface information from a preset routing ratio table, and randomly routing the service request to one service provider based on the ratio.
The call identifier is a code assigned to each client. The interface information is a method name or URL (Uniform Resource Locator) of each service interface.
Further, a routing matching table is set according to the specified configuration information and the operation configuration information, wherein the operation configuration information comprises the total service volume, the limit times of each service provider and the matching of the access service request quantity of each service provider.
The routing matching table is set according to actual needs, and the routing matching table comprises the total service quantity of each service, the limiting times of each service provider and the matching of the quantity of service access requests of each service provider. Wherein the ratio is set according to the processing capacity of each service provider. For example, for a face-brushing request, the total traffic in the corresponding routing ratio table is the total number of requests that can be handled for the face-brushing request. If the service providers A, B and C are included, the limit times of each service provider can be expressed as L according to the time situationA,LB,LCThe corresponding ratio may be 3:3: 4. Further, the routing ratio table further comprises one or more specified service providers of the clients. For example, a specific facilitator a is set for client X1 in the routing ratio table as needed.
Because the service request may correspond to a plurality of service providers, in the actual operation process of the service, there may be a situation where one or more service providers are abnormal, and the abnormal service provider needs to perform maintenance, the access to the service request needs to be suspended, and in this situation, the routing ratio table needs to be updated based on the success rate of the normal service provider to obtain a new routing ratio table. Specifically, the abnormal server may be determined by: and reading the service record table of each service provider according to a preset time interval, and if one or more abnormal codes exist in the service record table, judging that the corresponding server is an abnormal server.
And when the abnormal service provider is detected, updating the routing ratio table based on the success rate of the normal service provider to obtain a new routing ratio table.
Specifically, whether the current ratio meets the traffic demand is judged based on the success rate, the current ratio and the remaining traffic of each normal service provider;
and counting the currently processed completed traffic, and determining the difference between the total traffic and the completed traffic as the residual traffic. Since each server may fail to process the service request, in order to perform routing more flexibly and accurately, the present embodiment determines the task amount that can be processed by each server based on the success rate of each server.
Specifically, the quotient of the successful task volume and the processed task volume is determined as the success rate of the corresponding service provider based on the processed task volume and the successful task volume of each service provider, respectively. Nover represents the processed task amount, Ns represents the successful task amount, Si represents the success rate of the service provider, wherein i represents the number of each service provider, and Si is Ns/Nover. Therefore, the predicted task amount required to be processed by each service provider is the success rate multiplied by the current matching multiplied by the remaining traffic, the remaining traffic is represented by Nn, the current matching is represented by Py, the predicted task amount is represented by Ne, and Ne is Nn × Py × Si.
After the predicted task amount is obtained, comparing the predicted task amount with a service amount limit value in the routing matching table, and if the predicted task amount of a service provider is less than or equal to the service amount limit value, indicating that the current matching meets service requirements; and if the predicted task volume of the service provider is larger than the service volume limit value, the current ratio does not meet the service requirement.
And if the current ratio does not meet the service requirement, determining a new ratio of each normal service provider according to the residual service volume and the success rate of each normal service provider, and updating the routing ratio table based on the new ratio.
In this embodiment, the step of determining the new allocation ratio of each normal service provider according to the remaining traffic and the success rate of each normal service provider includes:
utilizing preset remaining servicesThe number calculation formula is used for calculating the remaining service number of each normal service provider according to the remaining service volume and the predetermined success rate difference, wherein the remaining service number niThe calculation formula is as follows:
wherein i denotes the number of the normal service provider, niFor the remaining service times, Sr is the success rate gap, and Nn is the remaining traffic; the success rate gap in this embodiment is the total power minus the success rate of other service providers. For example, the success rate gap for the facilitator M is the total power minus the values of the other normal facilitators, except the facilitator M. And the total power is determined by the success rate and the remaining traffic of each normal service provider. Represents the total power by So, then
Where Nx represents the other normal service providers.
Therefore, the remaining service times of each normal service provider can be calculated.
Determining a new matching ratio of each normal service provider according to the residual traffic, the residual service times and a preset matching calculation formula; wherein the proportion calculation formula is as follows:
where pi represents the new allocation ratio for each facilitator.
And after the new matching is obtained, updating the routing matching table based on the new matching, and obtaining a new routing matching table so as to route the service request to a corresponding service provider based on the new routing matching table.
Further, the present embodiment routes the service request to a service provider according to a weighted round robin algorithm based on the ratio. The weighted round robin algorithm may randomly assign a facilitator based on the ratio. The specific routing process may be: polling all service providers, selecting a target service provider (usually, the service provider with the maximum ratio is selected for the first time), routing the service request to the target service provider, and reducing the ratio of the target service provider by 1; continuing to access the next service request, and continuing to select the target service provider (the same service provider as the last service provider can be selected, or a different service provider can be selected), until the ratio of the target service provider is 0, the service provider can not be selected. And polling is carried out continuously, and service providers can be randomly distributed for all the service requests based on the ratio.
In this embodiment, through the above scheme, the call identifier and the interface information of the service request are obtained, and the specified service provider corresponding to the call identifier and the interface information is searched from the routing proportioning table; if the appointed service provider is found, routing the service request to the appointed service provider; if the appointed service provider is not found, acquiring the ratio of each service provider corresponding to the interface information from a preset routing ratio table, and randomly routing the service request to one service provider based on the ratio. Therefore, the routing matching table is flexibly updated according to the success rate and the service processing capacity of each service provider, and the updated routing matching table routes the service request, so that the routing efficiency and accuracy are improved.
In addition, the embodiment also provides a service current limiting device. Referring to fig. 6, fig. 6 is a functional module diagram of a traffic current limiting device according to a first embodiment of the present invention.
In this embodiment, the service current limiting device is a virtual device, and is stored in the memory 1005 of the service current limiting device shown in fig. 1, so as to implement all functions of a service current limiting program: the system comprises a client, a token bucket and a server, wherein the token bucket is used for receiving a service request sent by the client and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy; and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table.
Specifically, referring to fig. 6, the traffic limiting apparatus includes:
the distributed current limiting module 10 is configured to receive a service request sent by a client, and determine whether the service request can obtain a token in each distributed token bucket corresponding to each service level based on a distributed current limiting policy;
and the routing module 20 is configured to route the service request to a corresponding service provider according to a preset routing ratio table if the service request can obtain the token at each service level.
Further, the distributed current limiting module is further configured to:
newly adding an asynchronous thread for the service request, accessing the distributed token buckets corresponding to all service levels according to a preset sequence through the asynchronous thread, and calculating the redis access time of all the distributed token buckets according to the starting interval and the timestamp of the asynchronous thread;
comparing the redis access time of each distributed token bucket with a preset token acquisition time of each distributed token bucket;
if the redis access times corresponding to the distributed token buckets are all smaller than corresponding preset token obtaining time, judging that the service request can obtain tokens at each service level;
and if one preset token obtaining time which is greater than or equal to the corresponding preset token obtaining time exists in the redis access times, judging that the token can not be obtained by the service request at each service level.
Further, the distributed current limiting module is further configured to:
and acquiring a calling identifier and interface information of the service request, and determining a plurality of service levels of the service request according to the calling identifier and the interface information so that the asynchronous thread can access a plurality of distributed token buckets corresponding to the plurality of service levels in sequence.
Further, the routing module is further configured to:
based on the calling identification and the interface information of the service request, searching a designated service provider corresponding to the calling identification and the interface information from the routing matching table;
if the appointed service provider is found, routing the service request to the appointed service provider;
if the appointed service provider is not found, acquiring the ratio of each service provider corresponding to the interface information from a preset routing ratio table, and randomly routing the service request to one service provider based on the ratio.
Further, the routing module is further configured to:
setting a routing matching table according to the specified configuration information and the operation configuration information, wherein the operation configuration information comprises the total service volume, the limiting times of each service provider and the matching of the access service request quantity of each service provider;
and if the abnormal service provider is detected, updating the routing ratio table based on the success rate of the normal service provider to obtain a new routing ratio table.
Further, the routing module is further configured to:
judging whether the current ratio meets the traffic demand or not based on the success rate of each normal service provider, the current ratio and the residual traffic;
and if the current ratio does not meet the service requirement, determining a new ratio of each normal service provider according to the residual service volume and the success rate of each normal service provider, and updating the routing ratio table based on the new ratio to obtain a new routing ratio table.
Further, the routing module is further configured to:
calculating the remaining service times of each normal service provider according to a predetermined success rate difference of the remaining service volume by using a preset remaining service time calculation formula, wherein the remaining service time calculation formula is as follows:
wherein i denotes the number of the normal service provider, niFor the remaining number of services, SrIs the success rate gap, Nn is the remaining traffic;
determining a new matching ratio of each normal service provider according to the residual traffic, the residual service times and a preset matching calculation formula; wherein the proportion calculation formula is as follows:
where pi represents the new allocation ratio for each facilitator.
In addition, an embodiment of the present invention further provides a computer storage medium, where a service current limiting program is stored on the computer storage medium, and when the service current limiting program is executed by a processor, the steps of the service current limiting method are implemented, which are not described herein again.
Compared with the prior art, the invention provides a service current limiting method, a device, equipment and a storage medium, wherein the method comprises the following steps: receiving a service request sent by a client, and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy; and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table. Therefore, whether the service request can obtain the token at each service level is judged based on the distributed current limiting strategy, and the service request which obtains the token is routed to the service provider based on the routing matching table after the token is obtained, so that the flexibility of current limiting is improved, and the routing efficiency and accuracy are improved.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) as described above and includes instructions for causing a terminal device to execute the method according to the embodiments of the present invention.
The above description is only for the preferred embodiment of the present invention and is not intended to limit the scope of the present invention, and all equivalent structures or flow transformations made by the present specification and drawings, or applied directly or indirectly to other related arts, are included in the scope of the present invention.
Claims (10)
1. A method of traffic throttling, the method comprising:
receiving a service request sent by a client, and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy;
and if the service request can obtain the token at each service level, routing the service request to a corresponding service provider according to a preset routing ratio table.
2. The method of claim 1, wherein the step of determining whether the token can be obtained from each distributed token bucket corresponding to each service level of the service request based on a distributed throttling policy comprises:
newly adding an asynchronous thread for the service request, accessing the distributed token buckets corresponding to all service levels according to a preset sequence through the asynchronous thread, and calculating remote dictionary service redis access time of all the distributed token buckets according to the starting interval and the time stamp of the asynchronous thread;
comparing the redis access time of each distributed token bucket with a preset token acquisition time of each distributed token bucket;
if the redis access times corresponding to the distributed token buckets are all smaller than corresponding preset token obtaining time, judging that the service request can obtain tokens at each service level;
and if one preset token obtaining time which is greater than or equal to the corresponding preset token obtaining time exists in the redis access times, judging that the token can not be obtained by the service request at each service level.
3. The method of claim 2, wherein the step of accessing distributed token buckets corresponding to respective traffic levels in a predetermined order by the asynchronous thread is preceded by the step of:
and acquiring a calling identifier and interface information of the service request, and determining a plurality of service levels of the service request according to the calling identifier and the interface information so that the asynchronous thread can access a plurality of distributed token buckets corresponding to the plurality of service levels in sequence.
4. The method of claim 1, wherein the step of routing the service request to the corresponding service provider according to a preset routing ratio table comprises:
based on the calling identification and the interface information of the service request, searching a designated service provider corresponding to the calling identification and the interface information from the routing matching table;
if the appointed service provider is found, routing the service request to the appointed service provider;
if the appointed service provider is not found, acquiring the ratio of each service provider corresponding to the interface information from a preset routing ratio table, and randomly routing the service request to one service provider based on the ratio.
5. The method according to any one of claims 1-4, further comprising:
setting a routing matching table according to the specified configuration information and the operation configuration information, wherein the operation configuration information comprises the total service volume, the limiting times of each service provider and the matching of the access service request quantity of each service provider;
the step of routing the service request to the corresponding service provider according to the preset routing ratio table further comprises:
and if the abnormal service provider is detected, updating the routing ratio table based on the success rate of the normal service provider to obtain a new routing ratio table.
6. The method of claim 5, wherein the step of updating the routing ratio table based on the success rate of the normal service provider to obtain a new routing ratio table comprises:
judging whether the current ratio meets the traffic demand or not based on the success rate of each normal service provider, the current ratio and the residual traffic;
and if the current ratio does not meet the service requirement, determining a new ratio of each normal service provider according to the residual service volume and the success rate of each normal service provider, and updating the routing ratio table based on the new ratio to obtain a new routing ratio table.
7. The method of claim 6, wherein the step of determining the new allocation ratio of each normal service provider according to the remaining traffic volume and the success rate of each normal service provider comprises:
calculating the remaining service times of each normal service provider according to the remaining service volume and the predetermined success rate difference by using a preset remaining service time calculation formula, wherein the remaining service time calculation formula is as follows:
wherein i denotes the number of the normal service provider, niFor the remaining number of services, SrIs the success rate gap, Nn is the remaining traffic;
determining a new matching ratio of each normal service provider according to the residual traffic, the residual service times and a preset matching calculation formula; wherein the proportion calculation formula is as follows:
where pi represents the new allocation ratio for each facilitator.
8. A traffic limiting apparatus, characterized in that the traffic limiting apparatus comprises:
the distributed current limiting module is used for receiving a service request sent by a client and judging whether the service request can obtain tokens in each distributed token bucket corresponding to each service level based on a distributed current limiting strategy;
and the routing module is used for routing the service request to a corresponding service provider according to a preset routing ratio table if the service request can acquire the token at each service level.
9. Traffic throttling device, characterized in that it comprises a processor, a memory and a traffic throttling program stored in said memory, said traffic throttling program, when executed by said processor, implementing the steps of the traffic throttling method according to any one of claims 1 to 7.
10. A computer storage medium having stored thereon a traffic throttling program, the traffic throttling program when executed by a processor implementing the steps of the traffic throttling method according to any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010770404.4A CN111901249B (en) | 2020-07-31 | 2020-07-31 | Service flow limiting method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010770404.4A CN111901249B (en) | 2020-07-31 | 2020-07-31 | Service flow limiting method, device, equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111901249A true CN111901249A (en) | 2020-11-06 |
| CN111901249B CN111901249B (en) | 2024-03-22 |
Family
ID=73183273
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010770404.4A Active CN111901249B (en) | 2020-07-31 | 2020-07-31 | Service flow limiting method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111901249B (en) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113098792A (en) * | 2021-02-07 | 2021-07-09 | 北京思特奇信息技术股份有限公司 | Interface data communication method and system based on token binding |
| CN113238875A (en) * | 2021-04-26 | 2021-08-10 | 西安点告网络科技有限公司 | Queue-based request frequency control system and control method |
| CN113342498A (en) * | 2021-06-28 | 2021-09-03 | 平安信托有限责任公司 | Concurrent request processing method, device, server and storage medium |
| CN113783727A (en) * | 2021-09-07 | 2021-12-10 | 山石网科通信技术股份有限公司 | Method and device for adjusting bandwidth of distributed equipment, storage medium and processor |
| CN113810306A (en) * | 2021-09-07 | 2021-12-17 | 山石网科通信技术股份有限公司 | Bandwidth allocation method and device, storage medium and processor |
| CN114138357A (en) * | 2021-10-29 | 2022-03-04 | 北京达佳互联信息技术有限公司 | Request processing method and device, electronic equipment, storage medium and product |
| CN114285799A (en) * | 2021-12-22 | 2022-04-05 | 深圳市优必选科技股份有限公司 | Method, device, terminal and storage medium for processing service |
| CN115037693A (en) * | 2022-05-17 | 2022-09-09 | 瀚云科技有限公司 | Distributed current limiting method and distributed current limiting device based on token bucket |
| CN115277851A (en) * | 2022-06-22 | 2022-11-01 | 聚好看科技股份有限公司 | Service request processing method and system |
| CN115396377A (en) * | 2022-07-29 | 2022-11-25 | 天翼云科技有限公司 | Method, device and equipment for optimizing service quality of object storage and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009051533A1 (en) * | 2007-10-19 | 2009-04-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for scheduling data packets in a communication network system |
| CN102195819A (en) * | 2011-05-30 | 2011-09-21 | 中兴通讯股份有限公司 | Network equipment and service traffic supervision method thereof |
| CN107276827A (en) * | 2017-07-25 | 2017-10-20 | 郑州云海信息技术有限公司 | Qos implementation method and device in a kind of distributed memory system |
-
2020
- 2020-07-31 CN CN202010770404.4A patent/CN111901249B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009051533A1 (en) * | 2007-10-19 | 2009-04-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for scheduling data packets in a communication network system |
| CN102195819A (en) * | 2011-05-30 | 2011-09-21 | 中兴通讯股份有限公司 | Network equipment and service traffic supervision method thereof |
| CN107276827A (en) * | 2017-07-25 | 2017-10-20 | 郑州云海信息技术有限公司 | Qos implementation method and device in a kind of distributed memory system |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113098792A (en) * | 2021-02-07 | 2021-07-09 | 北京思特奇信息技术股份有限公司 | Interface data communication method and system based on token binding |
| CN113098792B (en) * | 2021-02-07 | 2022-11-18 | 北京思特奇信息技术股份有限公司 | Interface data communication method and system based on token binding |
| CN113238875A (en) * | 2021-04-26 | 2021-08-10 | 西安点告网络科技有限公司 | Queue-based request frequency control system and control method |
| CN113342498A (en) * | 2021-06-28 | 2021-09-03 | 平安信托有限责任公司 | Concurrent request processing method, device, server and storage medium |
| CN113783727A (en) * | 2021-09-07 | 2021-12-10 | 山石网科通信技术股份有限公司 | Method and device for adjusting bandwidth of distributed equipment, storage medium and processor |
| CN113810306A (en) * | 2021-09-07 | 2021-12-17 | 山石网科通信技术股份有限公司 | Bandwidth allocation method and device, storage medium and processor |
| CN113783727B (en) * | 2021-09-07 | 2024-04-26 | 山石网科通信技术股份有限公司 | Method and device for adjusting bandwidth of distributed equipment, storage medium and processor |
| CN114138357A (en) * | 2021-10-29 | 2022-03-04 | 北京达佳互联信息技术有限公司 | Request processing method and device, electronic equipment, storage medium and product |
| CN114285799B (en) * | 2021-12-22 | 2024-01-19 | 深圳市优必选科技股份有限公司 | Method, device, terminal and storage medium for processing service |
| CN114285799A (en) * | 2021-12-22 | 2022-04-05 | 深圳市优必选科技股份有限公司 | Method, device, terminal and storage medium for processing service |
| CN115037693A (en) * | 2022-05-17 | 2022-09-09 | 瀚云科技有限公司 | Distributed current limiting method and distributed current limiting device based on token bucket |
| CN115037693B (en) * | 2022-05-17 | 2023-05-26 | 瀚云科技有限公司 | Distributed current limiting method and distributed current limiting device based on token bucket |
| CN115277851A (en) * | 2022-06-22 | 2022-11-01 | 聚好看科技股份有限公司 | Service request processing method and system |
| CN115277851B (en) * | 2022-06-22 | 2023-06-06 | 聚好看科技股份有限公司 | Service request processing method and system |
| CN115396377B (en) * | 2022-07-29 | 2024-03-12 | 天翼云科技有限公司 | Method, device, equipment and storage medium for optimizing service quality of object storage |
| CN115396377A (en) * | 2022-07-29 | 2022-11-25 | 天翼云科技有限公司 | Method, device and equipment for optimizing service quality of object storage and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111901249B (en) | 2024-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111901249B (en) | Service flow limiting method, device, equipment and storage medium | |
| CN108776934B (en) | Distributed data calculation method and device, computer equipment and readable storage medium | |
| CN108848037A (en) | Service request processing method, device, computer equipment and storage medium | |
| CN107451853B (en) | Method, device and system for real-time red packet distribution and storage medium | |
| US20200104177A1 (en) | Resource allocation system, management device, method, and program | |
| CN110321225B (en) | Load balancing method, metadata server and computer readable storage medium | |
| CN110839069B (en) | Node data deployment method, node data deployment system and medium | |
| US20110035499A1 (en) | Discontinuous access management method using waiting ticket for resource allocation control, waiting ticket management method, and resource allocation control method | |
| CN115421922A (en) | Current limiting method, device, equipment, medium and product of distributed system | |
| CN111260475A (en) | Data processing method, block chain node point equipment and storage medium | |
| CN108632085B (en) | Gray level user management method, device, platform and storage medium | |
| CN108520401B (en) | User list management method, device, platform and storage medium | |
| CN114070847B (en) | Method, device, equipment and storage medium for limiting current of server | |
| CN110245014B (en) | Data processing method and device | |
| CN112102063B (en) | Data request method, device, equipment, platform and computer storage medium | |
| CN112860421B (en) | Method, apparatus and computer program product for job processing | |
| CN111694835B (en) | Number section access method, system, equipment and storage medium of logistics electronic bill | |
| CN116886626A (en) | Service data flow limiting method and device, computer equipment and storage medium | |
| CN114780228B (en) | Hybrid cloud resource creation method and system | |
| CN116319810A (en) | Flow control method, device, equipment, medium and product of distributed system | |
| CN115277588B (en) | Fusing current limiting system based on middle platform system | |
| CN108683608B (en) | Method and device for distributing flow | |
| CN114157482A (en) | Service access control method, device, control equipment and storage medium | |
| CN110795237B (en) | Resource processing method, device, electronic equipment and medium | |
| CN114374657A (en) | Data processing method and device |
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 |