Request processing method, apparatus, device, and readable storage medium

Abstract

The application discloses a request processing method and device, equipment and a readable storage medium, and relates to the technical field of computers. The method comprises the following steps: receiving a first request, determining user access information corresponding to the first request; determining at least two first distribution weights based on the user access information, wherein the first distribution weights represent the weights of distributing the first request to data centers corresponding to the first distribution weights; determining the risk entropy of a first user based on historical behavior data of the first user; adjusting each first distribution weight in the at least two first distribution weights through the risk entropy to obtain at least two second distribution weights after adjustment; and determining a target data center corresponding to the first request based on the at least two second distribution weights.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a request processing method, apparatus, device, and readable storage medium. Background Technology

[0002] With the rapid development of the Internet, multiple data centers can be used to process the ever-increasing amount of requested data in order to cope with the growing demand.

[0003] However, during the processing of request data in related technologies, it is impossible to reasonably allocate the request data to the corresponding data center. When there is a large amount of request data, unreasonable allocation of request data can easily lead to data congestion and ineffective utilization of data center resources. Summary of the Invention

[0004] This application provides a request processing method, apparatus, device, and readable storage medium to solve the problem of unreasonable allocation of request data.

[0005] Firstly, a request processing method is provided, including: Receive the first request and determine the user access information corresponding to the first request; Based on the user access information, at least two first allocation weights are determined, whereby the first allocation weight represents the weight for allocating the first request to the data center corresponding to the first allocation weight. The risk entropy of the first user is determined based on the first user's historical behavior data; The risk entropy is used to adjust each of the at least two first allocation weights to obtain at least two adjusted second allocation weights; Based on the at least two second allocation weights, the target data center corresponding to the first request is determined.

[0006] Optionally, determining at least two first allocation weights based on the user access information includes: Based on the user access information, determine the weight of each data center in at least two data centers in at least one request allocation dimension; The first allocation weight corresponding to each data center is determined based on the weight of each data center in at least one request allocation dimension.

[0007] Optionally, the at least one request allocation dimension includes at least one of the following: whether the data center corresponding to the user access information is available, whether the data center corresponding to the user access information has undergone a health check, the geographic attribute information corresponding to the user access information, the communication information corresponding to the user access information, the IP information corresponding to the user access information, the access channel information corresponding to the user access information, and the access terminal information corresponding to the user access information.

[0008] Optionally, determining the risk entropy of the first user based on the first user's historical behavior data includes: Based on the historical behavior data, the following parameters are determined for the first user: average daily number of requests, peak hour request percentage, IP matching degree, terminal matching degree, number of cross-terminal jumps, number of sensitive operation combinations, number of logins from different locations, and percentage of nighttime operations. The request operation frequency is determined based on the average daily number of requests and the percentage of requests during peak hours; Based on the IP matching degree and the terminal matching degree, the consistency of the request operation is determined; The complexity of the request operation is determined based on the number of cross-terminal jumps, the number of sensitive operation combinations, the number of logins from different locations, and the proportion of nighttime operations. The risk entropy is obtained based on the request operation frequency, the request operation consistency, and the request operation complexity.

[0009] Optionally, obtaining the risk entropy based on the request operation frequency, the request operation consistency, and the request operation complexity includes: The risk entropy is determined using the first formula; The first formula is: ; in, Characterizes the frequency of the request operation, the consistency of the request operation, and the complexity of the request operation. Let be the risk entropy.

[0010] Optionally, adjusting each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights includes: The second allocation weight is determined by the second formula; The second formula is: ; Among them, the For the second allocation weight, the Assign weights to the first one. The risk entropy, K represents the risk impact coefficient corresponding to the data center, and K is a preset value.

[0011] Secondly, a request processing apparatus is provided, comprising: The receiving module is used to receive a first request and determine the user access information corresponding to the first request. The first determining module is used to determine at least two first allocation weights based on the user access information, wherein the first allocation weight represents the weight of allocating the first request to the data center corresponding to the first allocation weight; The second determining module is used to determine the risk entropy of the first user based on the first user's historical behavior data; An adjustment module is used to adjust each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights. The third determining module is used to determine the target data center corresponding to the first request based on the at least two second allocation weights.

[0012] Thirdly, an electronic device is provided, comprising: a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the request processing method as described in the first aspect.

[0013] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the request processing method as described in the first aspect.

[0014] Fifthly, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the request processing method as described in the first aspect.

[0015] In this embodiment, the electronic device receives a request, determines the user access information corresponding to the request, determines the first allocation weight for each data center based on the user access information, determines the user's risk entropy based on the user's historical behavior data, adjusts the first allocation weight for each data center using the risk entropy to obtain a second allocation weight for each data center, determines a suitable data center based on the second allocation weight, and then allocates the request to that data center. It is understood that in this process, the electronic device can accurately determine the second allocation weight for each data center using the first allocation weight and risk entropy, and can rationally allocate requests to suitable data centers using the second allocation weight, avoiding data congestion and ineffective utilization of data center resources. Attached Figure Description

[0016] Figure 1 Assign a system architecture diagram for a request related to the technology; Figure 2 A request allocation system architecture diagram provided for embodiments of this application; Figure 3 A flowchart illustrating a request allocation method provided for an embodiment of this application; Figure 4 A schematic diagram of a request allocation device provided for an embodiment of this application; Figure 5 This is a schematic diagram of an electronic device structure provided for an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specified order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. However, the following description describes New Radio (NR) systems for illustrative purposes, and NR terminology is used in most of the following description. These technologies can also be applied to applications beyond NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0020] Before introducing the embodiments of this application, the technical background of this application will be explained.

[0021] like Figure 1 As shown, a Content Delivery Network (CDN) or a globally responsible load balancer can receive requests and process them to distribute them to appropriate data centers.

[0022] CDN is an intelligent virtual network built on the existing network infrastructure. It relies on edge servers deployed in various locations and uses the load balancing, content distribution, and scheduling functions of the central platform to enable devices to obtain the content they need from the nearest location, thereby reducing network congestion and improving device access response speed and hit rate.

[0023] A globally responsible load balancing system can perform local load balancing for user servers. It uses a powerful and effective load balancing algorithm to intelligently distribute the load among servers with different performance levels based on the actual response time. This ensures that servers with average performance do not become load bottlenecks, while also ensuring that the resources of high-performance servers are fully utilized.

[0024] The requested data can be generated by a computer, an application, a tablet, or a mini-program.

[0025] Data centers can be dedicated server rooms or Internet Data Centers (IDCs). A data center can consist of multiple servers and can provide IDC services such as disaster recovery, server hosting, rack space, and bandwidth leasing. For example, multiple servers can form a service cluster, which can then be used to create an Application Programming Interface (API) gateway cluster, and finally, one or more API gateway clusters can form a data center.

[0026] exist Figure 1 In the corresponding request distribution architecture, CDN and global load balancing systems are not suitable for certain fine-grained management requirements and cannot reasonably distribute request data to the corresponding data centers. For example, when there is a large amount of request data, unreasonable distribution of request data is likely to occur.

[0027] To address the issue of unreasonable data allocation in requests, such as Figure 2 As shown, this application provides a request processing method deployed on an electronic device. The electronic device can be pre-configured with weight values ​​for each data center across various request allocation dimensions, and can maintain basic information about the data centers.

[0028] Maintaining basic data center information may include: data center location, center overview, distribution addresses, etc., as shown in the table below: Table 1:

[0029] You can also configure individual request allocation dimensions to determine the weight of each data center in each dimension, and it also supports the expansion of new request allocation dimensions. Request allocation dimensions can be shown in the table below: Table 2:

[0030] The following example, using Table 3, illustrates the weights of each data center in each request allocation dimension. Data centers can include dedicated server room 1 data center and IDC.

[0031] Table 3: After configuring the weights of each data center on each request allocation dimension, the electronic device that deploys the request processing method can receive the request, determine the user access information corresponding to the request, determine the weight on at least one request allocation dimension based on the user access information, determine the appropriate data center based on the weight on at least one request allocation dimension, and then allocate the request to the corresponding data center.

[0032] The specific process is as follows: Figure 3 As shown, the specific steps of the request processing method in this application are as follows: Step 301: Receive the first request and determine the user access information corresponding to the first request.

[0033] In some embodiments, user access information may include: geographic attribute information, mobile phone number information, IP information (or IP range), access terminal information, access channel information, etc.

[0034] Step 302: Based on the user access information, determine at least two first allocation weights, whereby the first allocation weight represents the weight of allocating the first request to the data center corresponding to the first allocation weight.

[0035] In some embodiments, determining at least two first allocation weights based on the user access information includes: Based on the user access information, determine the weight of each data center in at least two data centers in at least one request allocation dimension; The first allocation weight corresponding to each data center is determined based on the weight of each data center in at least one request allocation dimension.

[0036] In this embodiment, the electronic device can obtain user access information and, based on the weight allocation of each data center in each request allocation dimension recorded in Table 3 above, determine the weight of each data center in each request allocation dimension and calculate the allocation weight corresponding to each data center.

[0037] The formula for calculating the weight allocation can be: .

[0038] Where Dx1 represents the weight of the data center in terms of its availability, Dx2 represents the weight of the data center in terms of its inspection results, Dx3 represents the default weight of the data center, and so on, with Dxn representing the weights for other dimensions. Dy1 represents the weight of the data center in terms of its geographic location, Dy2 represents the weight of the data center in terms of its mobile phone number, Dy3 represents the weight of the data center in terms of its IP address range, Dy4 represents the weight of the data center in terms of its access terminal, Dy5 represents the weight of the data center in terms of its access channel, and so on, with Dyn representing the weights for other dimensions. W(Dm) represents the assigned weight for the data center.

[0039] Optionally, the at least one request allocation dimension includes at least one of the following: whether the data center corresponding to the user access information is available, whether the data center corresponding to the user access information has undergone a health check, the geographic attribute information corresponding to the user access information, the communication information corresponding to the user access information, the IP information corresponding to the user access information, the access channel information corresponding to the user access information, and the access terminal information corresponding to the user access information.

[0040] Table 4 provides examples of various scenarios to illustrate the process of determining the weights of each dimension of the data center.

[0041] Table 4: Then, for each scenario, the allocation weight of the data center in each scenario is calculated.

[0042] Scenario 1: First, calculate the allocation weight for dedicated data center 1. For dedicated data center 1, Dx1 is 1, Dx2 is 1, Dx3 is 0, Dx4 is 0, Dx5 is 1, and Dy1 is 1. Since health checks are not enabled for dedicated data center 1, the value of Dy2 is empty. Furthermore, a suitable data center can be identified, so there's no need to use the default weight corresponding to Dy3 for calculation. Substituting Dx1-Dx5 and Dy1 into the formula, the allocation weight for dedicated data center 1 is 3. Similarly, for IDC, Dx1 is 0, Dx2 is 0, Dx3 is 0, Dx4 is 1, Dx5 is 0, Dy1 is 1, and Dy2 is 1. A suitable data center can be identified, so there's no need to use the default weight corresponding to Dy3 for calculation. Substituting Dx1-Dx5, Dy1, and Dy2 into the formula, the allocation weight for IDC is 1.

[0043] Scenario 2: Similarly, for dedicated data center 1, Dx1 is 0, Dx2 is 1, Dx3 is 0, Dx4 is 0, Dx5 is 0, and Dy1 is 1, so the allocation weight for dedicated data center 1 is 1. For IDC, Dx1 is 0, Dx2 is 0, Dx3 is 0, Dx4 is 1, Dx5 is 0, Dy1 is 1, and Dy2 is 1, so the allocation weight for IDC is 1.

[0044] Scenario 3: Due to the lack of geographic attribute information, mobile phone number information, IP range information, access terminal information, and access channel information, the default weight corresponding to Dy3 must be used for calculation. That is, Dy3 for dedicated data center 1 is 0.3, and Dy3 for IDC is 0.7. Since both data centers are available, Dy1 for both dedicated data center 1 and IDC is 1, and the weight corresponding to the health check results of dedicated data center 1 and IDC is also 1. That is, Dy2 for both dedicated data center 1 and IDC is 1. Therefore, the assigned weight for IDC is 0.7, and the assigned weight for dedicated data center 1 is 0.3.

[0045] Scenario 4: Since dedicated data center 1 is unavailable, IDC is directly selected as the available data center.

[0046] Step 303: Determine the risk entropy of the first user based on the first user's historical behavior data.

[0047] In some embodiments, determining the risk entropy of the first user based on the first user's historical behavior data includes: Based on the historical behavior data, the following parameters are determined for the first user: average daily number of requests, peak hour request percentage, IP matching degree, terminal matching degree, number of cross-terminal jumps, number of sensitive operation combinations, number of logins from different locations, and percentage of nighttime operations. The request operation frequency is determined based on the average daily number of requests and the percentage of requests during peak hours; Based on the IP matching degree and the terminal matching degree, the consistency of the request operation is determined; The complexity of the request operation is determined based on the number of cross-terminal jumps, the number of sensitive operation combinations, the number of logins from different locations, and the proportion of nighttime operations. The risk entropy is obtained based on the request operation frequency, the request operation consistency, and the request operation complexity.

[0048] In this embodiment, the electronic device can acquire historical behavior data within a preset time period, and determine the average daily number of requests, the proportion of requests during peak hours, IP matching degree, terminal matching degree, number of cross-terminal jumps, number of sensitive operation combinations, number of logins from different locations, and the proportion of nighttime operations based on the historical behavior data.

[0049] Assuming a preset duration of 30 days, the following table 5 shows the methods for determining the average daily number of requests, peak hour request percentage, IP matching degree, terminal matching degree, cross-terminal redirection number, number of sensitive operation combinations, number of logins from different locations, and nighttime operation percentage:

[0050] The following table (Table 6) illustrates the process of obtaining the average daily number of requests, peak-hour request percentage, IP matching degree, terminal matching degree, cross-terminal redirection number, and number of sensitive operation combinations based on the actual collected data from September 28 to October 27, 2025.

[0051] Table 6:

[0052] Electronic devices then determine the request operation frequency based on the average daily number of requests and the proportion of requests during peak hours; determine the consistency of request operations based on IP matching degree and terminal matching degree; and determine the complexity of request operations based on the number of cross-terminal jumps, the number of sensitive operation combinations, the number of logins from different locations, and the proportion of nighttime operations.

[0053] In some embodiments, obtaining the risk entropy based on the request operation frequency, the request operation consistency, and the request operation complexity includes: The risk entropy is determined using the first formula; The first formula is: ; in, Characterizes the frequency of the request operation, the consistency of the request operation, and the complexity of the request operation. Let be the risk entropy.

[0054] In this embodiment, the electronic device can determine the risk entropy based on the frequency of request operations, the consistency of request operations, and the complexity of request operations. The higher the risk entropy, the more abnormal the user behavior (the higher the risk).

[0055] Step 304: Adjust each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights.

[0056] In some embodiments, adjusting each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights includes: The second allocation weight is determined by the second formula; The second formula is: ;

[0057] Among them, the For the second allocation weight, the Assign weights to the first one. The risk entropy, K represents the risk impact coefficient corresponding to the data center, and K is a preset value.

[0058] In this embodiment, The risk impact coefficient is dynamically set based on the type of business corresponding to the request. For example, if the request corresponds to a payment business, then... =0.8, query business, then it is =0.2. K is determined based on indicators such as the accuracy of the risk control model deployed in the data center and the coverage of the blacklist database. The value ranges from 0 to 1. The higher the value of k, the stronger the risk control capability of the data center.

[0059] Step 305: Based on the at least two second allocation weights, determine the target data center corresponding to the first request.

[0060] After determining the adjusted allocation weights of each data center, the electronic device selects the data center with the highest allocation weight value as the data center to process the request, that is, assigns the request to the data center with the highest allocation weight value.

[0061] As described in steps 301-305, the electronic device receives a request, determines the user access information corresponding to the request, determines the first allocation weight for each data center based on the user access information, determines the user's risk entropy based on the user's historical behavior data, adjusts the first allocation weight for each data center using the risk entropy to obtain the second allocation weight for each data center, determines a suitable data center based on the second allocation weight, and then allocates the request to that data center. It is understandable that in this process, the electronic device can accurately determine the second allocation weight for each data center using the first allocation weight and risk entropy, and can rationally allocate requests to suitable data centers using the second allocation weight, avoiding data congestion and ineffective utilization of data center resources.

[0062] Please refer to Figure 4 , Figure 4 This is a schematic diagram of a request processing device 400 according to an embodiment of this application. The request processing device 400 includes: The receiving module 401 is used to receive the first request and determine the user access information corresponding to the first request; The first determining module 402 is used to determine at least two first allocation weights based on the user access information, wherein the first allocation weight represents the weight of allocating the first request to the data center corresponding to the first allocation weight; The second determining module 403 is used to determine the risk entropy of the first user based on the historical behavior data of the first user. The adjustment module 404 is used to adjust each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights. The third determining module 405 is used to determine the target data center corresponding to the first request based on the at least two second allocation weights.

[0063] Optionally, the first determining module 402 may further include: The first determining unit is used to determine the weight of each data center in at least two data centers in at least one request allocation dimension based on the user access information. The second determining unit is used to determine the first allocation weight corresponding to each data center based on the weight of each data center in at least one request allocation dimension.

[0064] Optionally, the at least one request allocation dimension includes at least one of the following: whether the data center corresponding to the user access information is available, whether the data center corresponding to the user access information has undergone a health check, the geographic attribute information corresponding to the user access information, the communication information corresponding to the user access information, the IP information corresponding to the user access information, the access channel information corresponding to the user access information, and the access terminal information corresponding to the user access information.

[0065] Optionally, the second determining module 403 may further include: The third determining unit is used to determine, based on the historical behavior data, the first user's average daily request count, peak hour request percentage, IP matching degree, terminal matching degree, cross-terminal jump count, sensitive operation combination count, cross-location login count, and nighttime operation percentage. The fourth determining unit is used to determine the request operation frequency based on the average daily number of requests and the proportion of requests during peak hours; The fifth determining unit is used to determine the consistency of the request operation based on the IP matching degree and the terminal matching degree; The sixth determining unit is used to determine the complexity of the request operation based on the number of cross-terminal jumps, the number of sensitive operation combinations, the number of logins from different locations, and the proportion of nighttime operations. The seventh determining unit is used to obtain the risk entropy based on the request operation frequency, the request operation consistency, and the request operation complexity.

[0066] Optionally, the seventh determining unit may also include: The first determining subunit is used to determine the risk entropy using a first formula; The first formula is: ; in, Characterizes the frequency of the request operation, the consistency of the request operation, and the complexity of the request operation. Let be the risk entropy.

[0067] Optionally, adjustment module 404 may also include: The eighth determining unit is used to determine the second allocation weight through the second formula; The second formula is: ;

[0068] Among them, the For the second allocation weight, the Assign weights to the first one. The risk entropy, K represents the risk impact coefficient corresponding to the data center, and K is a preset value.

[0069] The request processing device 400 provided in this application embodiment can perform the above-described... Figure 3 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0070] This application also provides an electronic device. Since the principle by which this electronic device solves the problem is similar to the request processing method in the embodiments of this application, the implementation of this electronic device can be found elsewhere. Figure 3 The implementation of the method shown will not be repeated here. Figure 5 As shown, the electronic device of this application embodiment includes: a processor 510, configured to read a program from a memory 520 and execute the following processes: Receive the first request and determine the user access information corresponding to the first request; Based on the user access information, at least two first allocation weights are determined, whereby the first allocation weight represents the weight for allocating the first request to the data center corresponding to the first allocation weight. The risk entropy of the first user is determined based on the first user's historical behavior data; The risk entropy is used to adjust each of the at least two first allocation weights to obtain at least two adjusted second allocation weights; Based on the at least two second allocation weights, the target data center corresponding to the first request is determined.

[0071] Optionally, the processor 510 is also used to read the program from the memory 520 and perform the following steps: The determination of at least two first allocation weights based on the user access information includes: Based on the user access information, determine the weight of each data center in at least two data centers in at least one request allocation dimension; The first allocation weight corresponding to each data center is determined based on the weight of each data center in at least one request allocation dimension.

[0072] Optionally, the at least one request allocation dimension includes at least one of the following: whether the data center corresponding to the user access information is available, whether the data center corresponding to the user access information has undergone a health check, the geographic attribute information corresponding to the user access information, the communication information corresponding to the user access information, the IP information corresponding to the user access information, the access channel information corresponding to the user access information, and the access terminal information corresponding to the user access information.

[0073] Optionally, the processor 510 is also used to read the program from the memory 520 and perform the following steps: The determination of the risk entropy of the first user based on the first user's historical behavior data includes: Based on the historical behavior data, the following parameters are determined for the first user: average daily number of requests, peak hour request percentage, IP matching degree, terminal matching degree, number of cross-terminal jumps, number of sensitive operation combinations, number of logins from different locations, and percentage of nighttime operations. The request operation frequency is determined based on the average daily number of requests and the percentage of requests during peak hours; Based on the IP matching degree and the terminal matching degree, the consistency of the request operation is determined; The complexity of the request operation is determined based on the number of cross-terminal jumps, the number of sensitive operation combinations, the number of logins from different locations, and the proportion of nighttime operations. The risk entropy is obtained based on the request operation frequency, the request operation consistency, and the request operation complexity.

[0074] Optionally, the processor 510 is also used to read the program from the memory 520 and perform the following steps: The risk entropy is obtained based on the request operation frequency, the request operation consistency, and the request operation complexity, including: The risk entropy is determined using the first formula; The first formula is: ; in, Characterizes the frequency of the request operation, the consistency of the request operation, and the complexity of the request operation. Let be the risk entropy.

[0075] Optionally, the processor 510 is also used to read the program from the memory 520 and perform the following steps: The step of adjusting each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights includes: The second allocation weight is determined by the second formula; The second formula is: ;

[0076] Among them, the For the second allocation weight, the Assign weights to the first one. The risk entropy, K represents the risk impact coefficient corresponding to the data center, and K is a preset value.

[0077] Among them, Figure 5 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 510 and memory represented by memory 520 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides the interface.

[0078] The electronic device provided in this application embodiment can perform the above-described functions. Figure 3 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0079] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the price request processing embodiment described above and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0080] This application also provides a computer program product, including computer instructions. When executed by a processor, these computer instructions implement the various processes of the above-described price request processing embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0081] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0082] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0083] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A request processing method, characterized in that, include: Receive the first request and determine the user access information corresponding to the first request; Based on the user access information, at least two first allocation weights are determined, whereby the first allocation weight represents the weight for allocating the first request to the data center corresponding to the first allocation weight. The risk entropy of the first user is determined based on the first user's historical behavior data; The risk entropy is used to adjust each of the at least two first allocation weights to obtain at least two adjusted second allocation weights; Based on the at least two second allocation weights, the target data center corresponding to the first request is determined.

2. The method according to claim 1, characterized in that, The determination of at least two first allocation weights based on the user access information includes: Based on the user access information, determine the weight of each data center in at least two data centers in at least one request allocation dimension; The first allocation weight corresponding to each data center is determined based on the weight of each data center in at least one request allocation dimension.

3. The method according to claim 2, characterized in that, The at least one request allocation dimension includes at least one of the following: whether the data center corresponding to the user access information is available, whether the data center corresponding to the user access information has undergone a health check, the geographic attribute information corresponding to the user access information, the communication information corresponding to the user access information, the IP information corresponding to the user access information, the access channel information corresponding to the user access information, and the access terminal information corresponding to the user access information.

4. The method according to claim 1, characterized in that, The determination of the risk entropy of the first user based on the first user's historical behavior data includes: Based on the historical behavior data, the following parameters are determined for the first user: average daily number of requests, peak hour request percentage, IP matching degree, terminal matching degree, number of cross-terminal jumps, number of sensitive operation combinations, number of logins from different locations, and percentage of nighttime operations. The request operation frequency is determined based on the average daily number of requests and the percentage of requests during peak hours; Based on the IP matching degree and the terminal matching degree, the consistency of the request operation is determined; The complexity of the request operation is determined based on the number of cross-terminal jumps, the number of sensitive operation combinations, the number of logins from different locations, and the proportion of nighttime operations. The risk entropy is obtained based on the request operation frequency, the request operation consistency, and the request operation complexity.

5. The method according to claim 4, characterized in that, The risk entropy is obtained based on the request operation frequency, the request operation consistency, and the request operation complexity, including: The risk entropy is determined using the first formula; The first formula is: ; in, Characterizes the frequency of the request operation, the consistency of the request operation, and the complexity of the request operation. Let be the risk entropy.

6. The method according to claim 1, characterized in that, The step of adjusting each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights includes: The second allocation weight is determined by the second formula; The second formula is: ; Among them, the For the second allocation weight, the Assign weights to the first one. The risk entropy, K represents the risk impact coefficient corresponding to the data center, and K is a preset value.

7. A request processing apparatus, characterized in that, include: The receiving module is used to receive a first request and determine the user access information corresponding to the first request. The first determining module is used to determine at least two first allocation weights based on the user access information, wherein the first allocation weight represents the weight of allocating the first request to the data center corresponding to the first allocation weight; The second determining module is used to determine the risk entropy of the first user based on the first user's historical behavior data; An adjustment module is used to adjust each of the at least two first allocation weights using the risk entropy to obtain at least two adjusted second allocation weights. The third determining module is used to determine the target data center corresponding to the first request based on the at least two second allocation weights.

8. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the request processing method as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the request processing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps in the request processing method as described in any one of claims 1 to 6.

Images