CN114745562A

CN114745562A - Service request processing method and device

Info

Publication number: CN114745562A
Application number: CN202210365512.2A
Authority: CN
Inventors: 周雅倩
Original assignee: Shenzhen Gosling Network Technology Co ltd
Current assignee: Shenzhen Gosling Network Technology Co ltd
Priority date: 2022-04-07
Filing date: 2022-04-07
Publication date: 2022-07-12

Abstract

The embodiment of the invention discloses a method and a device for processing a service request, electronic equipment and a computer readable storage medium. The method comprises the following steps: respectively calculating a query rate per second QPS corresponding to each service request; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. The invention solves the problem of rough direct broadcast accident prevention and processing mode in the related technology, and achieves the technical effect of effectively protecting the lower-layer service and public resources of the direct broadcast system and further avoiding the avalanche effect from influencing the function of the whole system.

Description

Service request processing method and device

Technical Field

The present invention relates to the field of live broadcast accident handling, and in particular, to a method and an apparatus for handling a service request, an electronic device, and a computer-readable storage medium.

Background

In the time of live broadcasting late peak, the system is often too concentrated and has too large concurrence due to too concentrated pressure, and the bottom-layer system or part of bypass dependent systems cannot bear avalanche effect, so that the concurrence number is accumulated to be +1 when receiving one request at the entrance gateway of the system by utilizing redis increase concurrence statistics, the concurrence number is accumulated to be-1 in the backend middleware after the request is processed, if the request is processed for more than 5S, the default failure is avoided to prevent the request from being jammed, then a fusing rule is set for the request route, the bearable concurrence of each route is large, when the counted concurrence number reaches the threshold set by the change request, the change request is not received, the interception return is directly carried out at the entrance gateway, the concurrence pressure of the system is reduced, and the processing of core functions is guaranteed.

As can be seen, the following disadvantages exist in the related art: 1: the statistical concurrency is global, and some service functions with higher original performance can be fused; 2: and (5) counting the excessive pressure of the redis single machine.

Aiming at the problem that the direct broadcast accident prevention and treatment mode is rough in the related technology, no effective solution is provided.

Disclosure of Invention

The embodiment of the invention provides a method and a device for processing a service request, electronic equipment and a computer readable storage medium, which are used for at least solving the technical problem that the prevention and processing mode of a live broadcast accident is rough in the related technology.

According to an aspect of the embodiments of the present invention, a method for processing a service request is provided, including: respectively calculating a query rate per second QPS corresponding to each service request; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token.

Optionally, the method further comprises: after the service request is processed, acquiring the service request processing capacity of the token bucket in real time, wherein the service request processing capacity comprises that the number of service requests processed by the token bucket per second is greater than a first preset threshold; supplementing the number of the token buckets by using a preset rule according to the service request processing capacity of the token buckets, wherein the preset rule comprises a millisecond-level supplement rule.

Optionally, a request threshold of each service request is obtained; and when the request number of the service requests is greater than the request threshold value, the service requests are independently controlled on a control panel.

Optionally, the method further comprises: at an ingress gateway of the system, the service requests are counted using a redis cluster.

Optionally, the method further comprises: judging whether the number of the remaining tokens in the token bucket is lower than a second preset threshold value; if the judgment result is yes, acquiring the priority of the service request; and processing the service request according to the priority of the service request.

According to another aspect of the embodiments of the present invention, there is also provided a device for processing a service request, including: the calculation module is used for calculating a query rate per second QPS corresponding to each service request respectively; a first setting module, configured to set, according to a QPS corresponding to each service request, the number of token buckets for each service request by using a token bucket algorithm, where the token buckets are used to control the service requests; the second setting module is used for setting the service request to acquire the token from the token bucket after receiving the service request; and the processing module is used for processing the service request under the condition that the service request acquires the token.

Optionally, the apparatus further comprises: the obtaining module is used for obtaining the service request processing capacity of the token bucket in real time after the service request is processed, wherein the service request processing capacity comprises that the number of service requests processed by the token bucket per second is larger than a first preset threshold; and the supplementing module is used for supplementing the number of the token buckets by using a preset rule according to the service request processing capacity of the token buckets, wherein the preset rule comprises a millisecond-level supplementing rule.

Optionally, the apparatus further comprises: the device further comprises: and the counting module is used for counting the service request by using the redis cluster at an entrance gateway of the system.

Optionally, the apparatus is further configured to obtain a request threshold of each service request; and when the request number of the service requests is greater than the request threshold, adjusting the request threshold on a control panel.

The device is further configured to determine whether the number of remaining tokens in the token bucket is below a second preset threshold; if the judgment result is yes, acquiring the priority of the service request; and processing the service request according to the priority of the service request.

An embodiment of the present invention provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of any of the methods described above.

Embodiments of the present invention provide a computer-readable storage medium, on which instructions are stored, and when executed by a processor, implement the steps of any one of the above methods.

In the embodiment of the invention, the query rate per second QPS corresponding to each service request is respectively calculated; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the invention replaces the original counting mode with the token bucket to realize, finely controls the processing performance of each service request, further solves the problem that the live broadcast accident prevention and processing mode in the related technology is rough, and achieves the technical effect of effectively protecting the lower-layer service and public resources of the live broadcast system and further avoiding the avalanche effect from influencing the function of the whole system.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

fig. 1 is a schematic flowchart of a method for processing a service request according to an embodiment of the present invention;

fig. 2 is a schematic diagram (one) of a service request processing apparatus according to an embodiment of the present invention;

fig. 3 is a schematic diagram (two) of a service request processing apparatus according to an embodiment of the present invention;

fig. 4 is a schematic diagram (three) of a service request processing apparatus according to an embodiment of the present invention.

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, shall fall within the protection scope of the present invention.

It should be noted that the terms "first", "second", and the like in the description and claims of the present invention and the drawings are used for distinguishing different objects, and are not used for limiting a specific order.

An embodiment of the present invention provides a method for processing a service request, and fig. 1 is a flowchart illustrating the method for processing the service request according to the embodiment of the present invention.

Optionally, application scenarios of the embodiment of the present invention include, but are not limited to:

in a first scenario, a user queries details of goods through a live broadcast platform and purchases the goods, and due to the fact that the number of purchasers is large, the system is often too concentrated in pressure and too large in concurrency, and under the condition that a bottom system or a part of bypass dependent systems cannot bear the situation, blocking occurs, the method provided by the embodiment of the invention can be used for respectively calculating the query rate per second QPS corresponding to each service request; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the present invention replaces the original counting manner with the token bucket, and finely controls the processing performance of each service request.

In a second scenario, a large number of users access a small program at the same time, because the number of access persons is large, the system is often too concentrated and too large in concurrency due to pressure, and under the condition that the underlying system or part of bypass dependent systems cannot bear the situation, the system is stuck, so that the query rate per second QPS corresponding to each service request can be respectively calculated by using the method provided by the embodiment of the invention; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the present invention replaces the original counting manner with the token bucket, and finely controls the processing performance of each service request.

As shown in fig. 1, a method for processing a service request provided in an embodiment of the present application includes the following steps:

s102, respectively calculating a query rate per second QPS corresponding to each service request;

QPS is a measure of how much traffic a particular query server processes within a specified time. On the internet, the query rate per second is often used to measure the performance of the machine of the domain name system server, corresponding to fetches/sec, i.e. the number of response requests per second, i.e. the maximum throughput capacity, and its calculation relationship is QPS ═ concurrency/average response time.

S104, respectively setting the quantity of token buckets for each service request by using a token bucket algorithm according to the QPS corresponding to each service request, wherein the token buckets are used for controlling the service requests;

when data is transmitted in a network, in order to prevent congestion of the network, it is necessary to limit traffic flowing out of the network and to send the traffic out at a relatively uniform speed. The token bucket algorithm accomplishes this function by controlling the amount of data sent onto the network and allowing the transmission of bursts of data. The token bucket algorithm is one of the most commonly used algorithms in network Traffic Shaping (Traffic Shaping) and Rate Limiting (Rate Limiting). Typically, token bucket algorithms are used to control the amount of data sent onto the network and to allow the transmission of bursts of data. A fixed token bucket size may generate tokens at a constant rate on its own. If tokens are not consumed or are consumed less than the rate of generation, tokens are continually incremented until the bucket is filled and tokens that are later generated overflow the bucket, and finally the maximum number of tokens that can be held in the bucket never exceeds the size of the bucket. Packets passed to the token bucket need to consume tokens. Different size packets consume different numbers of tokens. The control mechanism of token bucket indicates when traffic can be sent based on whether there are tokens in the token bucket. Each token in the token bucket represents a byte. If the token bucket has a token, allowing the traffic to be sent; and if no token exists in the token bucket, the traffic is not allowed to be sent. Thus, if the burst threshold is reasonably configured and there are enough tokens in the token bucket, traffic can be sent at the peak rate. The basic process of the token bucket algorithm is as follows: if the user configured average sending rate is r, a token is added into the bucket every 1/r second; assume that the bucket can hold a maximum of b tokens. If the token bucket is full when the token arrives, then the token is discarded; when an n-byte packet arrives, n tokens are removed from the token bucket and the packet is sent to the network; if there are fewer than n tokens in the token bucket, then no tokens are deleted and the packet is considered to be outside the traffic limit; the algorithm allows bursts of a longest b bytes, but from long-running results the rate of the packets is limited to a constant r. Packets outside the traffic limit can be handled in different ways: they can be discarded; they may be queued for retransmission when a sufficient number of tokens have accumulated in the token bucket; they can continue to transmit but need to be specially marked and these specially marked packets are discarded when the network is overloaded.

S106, after receiving the service request, setting the service request to acquire a token from the token bucket;

and S108, processing the service request under the condition that the service request acquires the token.

Optionally, in this embodiment, the processing the service request includes but is not limited to: and forwarding the service request and rejecting the service request.

Respectively calculating a query rate per second QPS corresponding to each service request through the steps S102 to S108; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the invention omits the original counting mode and uses the token bucket instead to realize, finely controls the processing performance of each service request, further solves the problem that the live broadcast accident prevention and processing mode in the related technology is rough, and achieves the technical effect of effectively protecting the lower-layer service and public resources of the live broadcast system and further avoiding the avalanche effect from influencing the functions of the whole system.

In an optional embodiment, the method further comprises:

s11, after processing the service request, acquiring the service request processing capacity of the token bucket in real time, wherein the service request processing capacity includes that the number of service requests processed by the token bucket per second is greater than a first preset threshold;

and S12, supplementing the quantity of the token bucket by using a preset rule according to the service request processing capacity of the token bucket, wherein the preset rule comprises a supplement rule in millisecond level.

For example, the token bucket may be supplemented on the order of milliseconds by the number of requests that can be processed per second, which also ensures that a function is not always unmanaged, and possibly the next second can be processed.

Optionally, the method further comprises:

s21, obtaining the request threshold value of each service request;

s22, when the number of requests of the service request is larger than the request threshold, the service request is controlled on the control panel.

For example, assuming that the request threshold of the service request 1 is 5000, the request threshold of the service request 2 is 10000, when the number of requests of the service request 1 is 6000 and the number of requests of the service request 2 is 7000, since the number of requests 6000 of the service request 1 is greater than the request threshold of the service request 1 by 5000 and the number of requests 7000 of the service request 2 is less than the request threshold of the service request 2 by 10000, the service request 1 only needs to be controlled on the control panel, and the service request 2 maintains the original control mode.

For another example, assuming that the request threshold of the service request 1 is 5000, the request threshold of the service request 2 is 10000, and when the number of requests of the service request 1 is 6000 and the number of requests of the service request 2 is 12000, since the number of requests 6000 of the service request 1 is greater than the request threshold of the service request 1 is 5000 and the number of requests 12000 of the service request 2 is greater than the request threshold of the service request 2 is 10000, the service request 1 and the service request 2 need to be controlled on the control panel.

For another example, assuming that the request threshold of the service request 1 is 5000, the request threshold of the service request 2 is 10000, and when the number of requests of the service request 1 is 4000 and the number of requests of the service request 2 is 7000, since 4000 requests of the service request 1 are smaller than 5000 requests of the service request 1 and 7000 requests of the service request 2 are smaller than 10000 requests of the service request 2, the service request 1 and the service request 2 maintain the original control mode.

The above-mentioned S21-22 can be used for emergency processing means, and when the sudden change of a certain service pressure bearing is not predicted, a certain service request can be controlled on the control panel independently to prevent the occurrence of avalanche phenomenon.

Optionally, the method further includes:

and S31, counting the service requests by using a redis cluster at an entrance gateway of the system.

The main principle of single machine redis that +1 is accumulated every time a request concurrency number is received, the request concurrency number is-1 in a post middleware after the request is processed, and the request is prevented from being blocked if the request exceeds 5S and the default failure is not finished; and then, setting a fusing rule for the request route, wherein the bearable concurrency of each route is large, and when the counted concurrency number reaches a threshold set by the request change, the request change request is not received and is directly intercepted and returned at the entrance gateway, so that the concurrency pressure of the system is reduced, and the processing of the core function is guaranteed.

The Redis cluster adopts a decentralized thought, a central node is absent, for a client, the whole cluster can be regarded as a whole and can be connected with any node for operation, just like a single Redis instance, no proxy middleware is needed, and when a key operated by the client is not distributed to the node, the Redis can return a steering instruction to point to the correct node. Redis also has built-in high availability mechanism, supports N master nodes, and every master node all can carry a plurality of slave nodes, and when master node hangs down, the cluster can promote its certain slave node as new master node.

In the redis cluster, all redis nodes are interconnected with each other, and binary protocols are used inside the nodes to optimize transmission speed and bandwidth. When a node hangs up, more than half of the nodes in the cluster are considered to be failed when the detection of the node is failed. Unlike tomcat clusters which require the use of a reverse proxy server, any node in a redis cluster can be directly connected to a Java client. Data distribution on a redis cluster is realized by adopting HASH SLOTs (HASH SLOT), 16384 HASH SLOTs are built in the redis cluster, when data needs to be stored, redis firstly calculates keys by using a CRC16 algorithm, and the calculated result is subjected to remainder of 16384, so that each key corresponds to one HASH SLOT with the value of 0-16383, and the redis stores the data to the corresponding redis node according to the remainder, and a developer can adjust the distribution range of the HASH SLOTs on each redis instance according to the performance of each redis instance.

The method mainly comprises a master-slave mode, a Sentinel mode and a Cluster mode. Wherein, regarding the master-slave mode: and actively sending a SYNC command to the master after the slave is started. After receiving the SYNC command, the master saves the snapshot in the background (RDB persistence) and caches the command for saving the snapshot, and then sends the saved snapshot file and the cached command to the slave. And after receiving the snapshot file and the command, the slave loads the snapshot file and the cached execution command. After the copying initialization, the command received by the master each time is synchronously sent to the slave, so that the consistency of the master data and the slave data is ensured.

For the Sentinel mode: each sentinel sends a ping command to its known master, slave and other sentinel instances at a frequency of once per second. If an instance is more than the value specified by the own-after-mileseconds option from the time the last ping was validly replied, then the instance is marked by sentinel as a subjective down. If a master is marked as subjectively down, all sentinels monitoring this master are to confirm that the master did enter the subjectively down state at a frequency of once per second. When a sufficient number of sentinels (greater than or equal to the value specified by the configuration file) confirm that the master does indeed enter the subjective offline state within the specified range, the master will be marked as objective offline. In general, each sentinel will send an INFO command to all master, slave, it knows at a frequency of once every 10 seconds. When a master is marked by sentinel as objective offline, the frequency of sending INFO commands from sentinel to all slave of the offline master changes from once every 10 seconds to once every 1 second. If a sufficient number of sentinel uniform masters have been brought down, the objective offline state of the master is removed, and if the master returns to valid recovery again to the PING command of sentinel, the subjective offline state of the master is removed. When using the sentinel mode, the client does not directly connect with the redis, but connects ip and port of sentinel, and sentinel provides a specific redis implementation capable of providing services.

Regarding Cluster mode: cluster can be said to be a combination of sentinel and master-slave mode, and master-slave and master reselection functions can be realized through the cluster, so if two copies and three fragments are configured, six redis instances are needed. Because the data of the redis is distributed to different machines of the cluster according to a certain rule, when the data volume is overlarge, a machine can be added for capacity expansion.

Optionally, in this embodiment, the number of redis included in the redis cluster may be determined according to the service pressure. When the redis cluster is used for statistics, the service requests can be evenly distributed, and the service requests can also be distributed according to a certain proportion.

For example, at an ingress gateway of the system, statistics is performed by using 10 rediss, and when the 10 rediss is used for statistics, the service request may be divided into 10 shares, and statistics is performed by the corresponding redis respectively.

For another example, 2 redis are used for statistics at an ingress gateway of the system, and during the statistics of the 2 redis, 80% of the service requests are distributed to the redis1 for statistics, and 20% of the service requests are distributed to the redis2 for statistics.

Through the above step S31, the single machine redis is changed into the clustered redis, and the processing capacity of the entire redis pressure boosting system is dispersed.

In an optional embodiment, the method further comprises:

s41, judging whether the number of the remaining tokens in the token bucket is lower than a second preset threshold value;

s42, if the judgment result is yes, acquiring the priority of the service request;

s43, processing the service request according to the priority of the service request.

Optionally, the value of the second preset threshold may be determined according to the speed at which the system processes the service request, when the speed requirement for processing the service request is high, the value of the second preset threshold is set to be larger, and when the speed requirement for processing the service request is low, the value of the second preset threshold is set to be smaller.

For example, assuming that the number of remaining tokens in the token bucket is 1000, and the second preset threshold is 1500, in this case, the priority of the service request needs to be obtained, assuming that the priority of the service request is high priority, the service request is preferentially processed, and it is ensured that the service request with high priority is processed in time, assuming that the priority of the service request is low priority, the service request is not processed, and it is ensured that the service request with high priority is processed in time.

Through the above-mentioned S41-S43, all functions can be made available to the greatest extent, and the core function can be guaranteed to be available in the worst case.

The present embodiment will be described below by taking live broadcast as an example.

When the late peak is broadcast live, the query number (query Per Second, abbreviated as QPS) capable of being processed Per Second is measured aiming at each service request, and the initialized and processable request number is set for each service request by using a token bucket algorithm, so that the request control can be carried out according to certain service processing performance independently; according to the result of the pressure measurement performance of each service request, setting the initial number of token buckets for each service request when the service is started, wherein each service request needs to go to the token bucket to obtain a token, the service request can be received and forwarded only after the token is obtained, and meanwhile, the token bucket can be supplemented according to the millisecond level by the number of the service requests which can be processed in each second, so that the mode can also ensure that a certain function cannot be processed all the time, and the next second can be processed possibly; meanwhile, the threshold rule setting of each service request can be dynamically adjusted on the control panel, and can be used for emergency processing means.

By the example, in order to protect the lower-layer service and the public resource from the avalanche effect to influence the functions of the system, all the functions are made available to the greatest extent on the principle, and the core functions can be guaranteed to be available in the worst case. Namely, the original counting mode is replaced by a token bucket, the processing performance of each request is finely controlled, a single machine is replaced by the redis of a cluster, and the overall processing capacity of the system is improved by dispersing the redis pressure.

An embodiment of the present invention further provides a device for processing a service request, and fig. 2 is a schematic diagram of the device for processing a service request provided in the embodiment of the present invention.

In a first scenario, a user queries and purchases goods details through a live broadcast platform, and due to the fact that the number of purchasers is large, the system is often too concentrated in pressure and too large in concurrency, and under the condition that a bottom system or a part of bypass dependence systems cannot bear the situation, the system is stuck, and then the query rate per second QPS corresponding to each service request can be respectively calculated by using the method provided by the embodiment of the invention; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the present invention replaces the original counting manner with the token bucket, and finely controls the processing performance of each service request.

In a second scenario, a large number of users access a small program at the same time, and due to a large number of access people, the system is often too centralized and too complicated due to pressure, and under the condition that the underlying system or a part of bypass dependent systems cannot bear the situation, the system is stuck, so that the method provided by the embodiment of the invention can be used for respectively calculating the query rate per second QPS corresponding to each service request; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the present invention replaces the original counting manner with the token bucket, and finely controls the processing performance of each service request.

As shown in fig. 2, a device for processing a service request provided in an embodiment of the present application includes:

a calculating module 22, configured to calculate a query rate per second QPS corresponding to each service request;

A first setting module 24, configured to set, according to a QPS corresponding to each service request, the number of token buckets for each service request by using a token bucket algorithm, where the token buckets are used to control the service request;

when data is transmitted in a network, in order to prevent congestion of the network, it is necessary to limit the flow rate flowing out of the network and to send the flow rate to the outside at a relatively uniform speed. The token bucket algorithm accomplishes this function by controlling the amount of data sent onto the network and allowing the transmission of bursts of data. The token bucket algorithm is one of the most commonly used algorithms in network Traffic Shaping (Traffic Shaping) and Rate Limiting (Rate Limiting). Typically, token bucket algorithms are used to control the amount of data sent onto the network and to allow the transmission of bursts of data. A fixed size token bucket may generate tokens at its own constant rate and constantly. If tokens are not consumed or are consumed less than the rate of generation, tokens are continually incremented until the bucket is filled and tokens that are later generated overflow the bucket, and finally the maximum number of tokens that can be held in the bucket never exceeds the size of the bucket. Packets passing to the token bucket need to consume tokens. Different size packets consume different numbers of tokens. The control mechanism of token bucket indicates when traffic can be sent based on whether there are tokens in the token bucket. Each token in the token bucket represents a byte. If the token exists in the token bucket, allowing the traffic to be sent; and if no token exists in the token bucket, the traffic is not allowed to be sent. Thus, if the burst threshold is reasonably configured and there are enough tokens in the token bucket, traffic can be sent at the peak rate. The basic process of the token bucket algorithm is as follows: if the average sending rate configured by the user is r, adding a token into the bucket every 1/r second; assume that the bucket can hold a maximum of b tokens. If the token bucket is full when the token arrives, then the token is discarded; when an n-byte packet arrives, n tokens are removed from the token bucket and the packet is sent to the network; if there are fewer than n tokens in the token bucket, then no tokens are deleted and the packet is considered to be outside the traffic limit; the algorithm allows bursts of a longest b bytes, but from long-running results the rate of the packets is limited to a constant r. Packets outside the traffic limit can be handled in different ways: they can be discarded; they may be queued for retransmission when a sufficient number of tokens have accumulated in the token bucket; they can continue to transmit but need to be specially marked and these specially marked packets are discarded when the network is overloaded.

A second setting module 26, configured to, after receiving the service request, set the service request to obtain a token from the token bucket;

and a processing module 28, configured to process the service request if the service request obtains the token.

Optionally, in this embodiment, the processing the service request includes but is not limited to: and forwarding the service request and refusing the service request.

Respectively calculating a query rate per second QPS corresponding to each service request by using the apparatus shown in fig. 2; according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests; after receiving a service request, setting the service request to acquire a token from the token bucket; and processing the service request under the condition that the service request acquires the token. That is to say, the embodiment of the invention omits the original counting mode and uses the token bucket instead to realize, finely controls the processing performance of each service request, further solves the problem that the live broadcast accident prevention and processing mode in the related technology is rough, and achieves the technical effect of effectively protecting the lower-layer service and public resources of the live broadcast system and further avoiding the avalanche effect from influencing the functions of the whole system.

Optionally, as shown in fig. 3, the apparatus further includes:

an obtaining module 32, configured to obtain, in real time, a service request processing capability of the token bucket after processing the service request, where the service request processing capability includes that the number of service requests processed by the token bucket per second is greater than a first preset threshold;

and a supplementing module 34, configured to supplement the number of the token buckets by using a preset rule according to the service request processing capacity of the token buckets, where the preset rule includes a supplementing rule on a millisecond level.

Optionally, as shown in fig. 4, the apparatus further includes:

and a statistics module 42, configured to perform statistics on the service request by using a redis cluster at an ingress gateway of the system.

The main principle of single machine redis that +1 is accumulated when one request concurrency number is received, the request concurrency number is-1 in a post middleware after the request is processed, and the request is defaulted to fail to prevent the request from being blocked if the request exceeds 5S and is not processed; and then, setting a fusing rule for the request route, wherein the bearable concurrency of each route is large, and when the counted concurrency number reaches a threshold set by the request change, the request change request is not received and is directly intercepted and returned at the entrance gateway, so that the concurrency pressure of the system is reduced, and the processing of the core function is guaranteed.

In a redis cluster, all redis nodes are interconnected with each other, and a binary protocol is used inside the nodes to optimize transmission speed and bandwidth. When a node hangs up, more than half of the nodes in the cluster are considered to be failed when the detection of the node is failed. Unlike tomcat clusters which require the use of a reverse proxy server, any node in a redis cluster can be directly connected to a Java client. Data distribution on the redis cluster is realized by adopting a HASH SLOT (HASH SLOT), 16384 HASH SLOTs are built in the redis cluster, when data needs to be stored, the redis firstly calculates keys by using a CRC16 algorithm, and the calculated result is subjected to remainder of 16384, so that each key corresponds to one HASH SLOT with the value between 0 and 16383, the redis stores the data on the corresponding redis node according to the remainder, and a developer can adjust the distribution range of the HASH SLOT on each redis instance according to the performance of each redis instance.

The method mainly comprises a master-slave mode, a Sentinel mode and a Cluster mode. Wherein, regarding the master-slave mode: and actively sending a SYNC command to the master after the slave is started. After receiving the SYNC command, the master saves the snapshot in the background (RDB persistence) and caches the command for saving the snapshot in this period of time, and then sends the saved snapshot file and the cached command to the slave. And after receiving the snapshot file and the command, the slave loads the snapshot file and the cached execution command. After the copying initialization, the command received by the master each time is synchronously sent to the slave, so that the consistency of the master data and the slave data is ensured.

For the Sentinel mode: each sentinel sends a ping command to its known master, slave and other sentinel instances at a frequency of once per second. If an instance is more than the value specified by the own-after-mileseconds option from the time the last ping was validly replied, then the instance is marked by sentinel as a subjective down. If a master is marked as subjectively down, all sentinels monitoring this master are to confirm that the master did enter the subjectively down state at a frequency of once per second. When a sufficient number of sentinels (greater than or equal to the value specified by the configuration file) confirm that the master does indeed enter the subjective offline state within the specified range, the master will be marked as objective offline. In general, each sentinel will send an INFO command to all the masters, slave, it knows, at a frequency of once every 10 seconds. When a master is marked by sentinel as objective offline, the frequency of sending INFO commands from sentinel to all slave of the offline master changes from once every 10 seconds to once every 1 second. If a sufficient number of sentinel uniform masters have been brought down, the objective offline state of the master is removed, and if the master returns to valid recovery again to the PING command of sentinel, the subjective offline state of the master is removed. When using the sentinel mode, the client does not directly connect with the redis, but connects ip and port of sentinel, and sentinel provides a specific redis implementation capable of providing services.

Regarding Cluster mode: cluster can be said to be a combination of sentinel and master-slave mode, and master-slave and master reselection functions can be realized through the cluster, so if two copies and three fragments are configured, six redis instances are needed. Because the data of the redis is distributed to different machines of the cluster according to a certain rule, when the data volume is overlarge, a new machine can be added for capacity expansion.

Optionally, in this embodiment, the number of redis included in the above redis cluster may be determined according to a service pressure. When the redis cluster is used for statistics, the service requests can be evenly distributed, and the service requests can also be distributed according to a certain proportion.

Through the device, the single-machine redis is changed into the clustered redis, and the overall processing capacity of the system is improved by dispersing the redis pressure.

Optionally, the apparatus is further configured to obtain a request threshold of each service request; and when the request number of the service requests is larger than the request threshold, adjusting the request threshold on the control panel.

For example, assuming that the request threshold of the service request 1 is 5000, the request threshold of the service request 2 is 10000, and when the number of requests for generating the service request 1 is 6000 and the number of requests for generating the service request 2 is 7000, since the number of requests for generating the service request 1 is 6000 and is greater than the request threshold of the service request 1 by 5000 and the number of requests for generating the service request 2 is 7000 and is less than the request threshold of the service request 2 by 10000, it is only necessary to control the service request 1 on the control panel alone, and the service request 2 maintains the original control mode.

For another example, assuming that the request threshold of the service request 1 is 5000, and the request threshold of the service request 2 is 10000, when the number of requests of the service request 1 is 6000 and the number of requests of the service request 2 is 12000, since the number of requests 6000 of the service request 1 is greater than the request threshold of the service request 1 is 5000 and the number of requests 12000 of the service request 2 is greater than the request threshold of the service request 2 of 10000, the service request 1 and the service request 2 need to be controlled on the control panel.

The device can be used for emergency processing means, and can independently control a certain service request on the control panel under the condition that the sudden change of certain service pressure bearing is not predicted, so as to prevent the phenomenon of avalanche.

In an optional embodiment, the apparatus is further configured to determine whether the number of remaining tokens in the token bucket is lower than a second preset threshold; if the judgment result is yes, acquiring the priority of the service request; and processing the service request according to the priority of the service request.

By the device, all functions can be available to the maximum extent, and the core functions can be ensured to be available in the worst case.

An embodiment of the present invention further provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of any of the methods described above.

Embodiments of the present invention further provide a computer-readable storage medium, on which instructions are stored, and when executed by a processor, the instructions implement the steps of any one of the above methods.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention.

Claims

1. A method for processing service request is characterized by comprising the following steps:

respectively calculating a query rate per second QPS corresponding to each service request;

according to the QPS corresponding to each service request, respectively setting the number of token buckets for each service request by using a token bucket algorithm, wherein the token buckets are used for controlling the service requests;

after receiving a service request, setting the service request to acquire a token from the token bucket;

and processing the service request under the condition that the service request acquires the token.

2. The method of claim 1, wherein after processing the service request, the method further comprises:

acquiring the service request processing capacity of the token bucket in real time, wherein the service request processing capacity comprises that the number of service requests processed by the token bucket per second is greater than a first preset threshold;

supplementing the number of the token buckets by using a preset rule according to the service request processing capacity of the token buckets, wherein the preset rule comprises a millisecond-level supplement rule.

3. The method of claim 1, wherein the method further comprises:

acquiring a request threshold value of each service request;

and when the request number of the service requests is greater than the request threshold value, the service requests are independently controlled on a control panel.

4. The method of claim 1, wherein the method further comprises:

at an ingress gateway of the system, the service requests are counted using a redis cluster.

5. The method of claim 1, wherein the method further comprises:

judging whether the number of the remaining tokens in the token bucket is lower than a second preset threshold value;

if the judgment result is yes, acquiring the priority of the service request;

and processing the service request according to the priority of the service request.

6. An apparatus for processing service requests, comprising:

the calculation module is used for calculating a query rate per second QPS corresponding to each service request respectively;

a first setting module, configured to set, according to a QPS corresponding to each service request, the number of token buckets for each service request by using a token bucket algorithm, where the token buckets are used to control the service requests;

the second setting module is used for setting the service request to acquire the token from the token bucket after receiving the service request;

and the processing module is used for processing the service request under the condition that the service request acquires the token.

7. The apparatus for processing service request according to claim 6, wherein the apparatus further comprises:

the obtaining module is used for obtaining the service request processing capacity of the token bucket in real time after the service request is processed, wherein the service request processing capacity comprises that the number of service requests processed by the token bucket per second is larger than a first preset threshold;

and the supplementing module is used for supplementing the number of the token buckets by using a preset rule according to the service request processing capacity of the token buckets, wherein the preset rule comprises a millisecond-level supplementing rule.

8. The apparatus for processing service request according to claim 6, wherein the apparatus further comprises:

and the counting module is used for counting the service request by using the redis cluster at an entrance gateway of the system.

9. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to perform the steps of any of the methods of claims 1-5.

10. A computer readable storage medium having instructions stored thereon, wherein the instructions, when executed by a processor, implement the steps of any of the methods of claims 1-5.