Request processing method, device, computer equipment and storage medium

Abstract

The present application relates to a request processing method, device, computer equipment and storage medium. The method includes: determining the processing priority of each user access request according to each user access request; the user access request is used to request resource transfer processing; according to the processing priority of each user access request, each user access request is added to the cache queue corresponding to the processing priority of each user access request; according to the processing priority, the user access request in each cache queue is subjected to resource transfer processing. For user access requests in high concurrency scenarios, the present application first determines the processing priority of each user access request, and then caches each user access request into a cache queue of the corresponding priority according to the processing priority of each user access request, and then processes the user access requests in each cache queue according to the processing priority of the cache queue, which is equivalent to processing the user access requests in batches, thereby effectively alleviating the pressure on the server.

Description

Technical Field

[0001] The present application relates to the field of data service technology, and in particular to a request processing method, apparatus, computer equipment and storage medium. Background Art

[0002] With the development of Internet technology, various e-commerce activities are increasing day by day. For example, mobile banking activities. Specifically, users can participate in bank commemorative coin redemption, phone bill recharge, shopping coupons and other activities through mobile phones and other user terminals. However, in some flash sales activities, the increase in user access requests will cause excessive pressure on the server to process requests.

[0003] In the related technology, for the scenario of high concurrency requests caused by the increase in the above-mentioned user access requests, in order to handle a large number of access requests, the merchant will increase the server nodes for processing the requests, and process the access requests initiated by the user end through multiple server nodes deployed in a cluster.

[0004] However, processing access requests by adding servers for clustered deployment will increase the cost of processing high-concurrency requests. Summary of the invention

[0005] Based on this, it is necessary to provide a high-concurrency request processing method, device, computer equipment and storage medium that can improve the efficiency of high-concurrency request processing in response to the above technical problems.

[0006] In a first aspect, a request processing method is provided, the method comprising:

[0007] Determine the processing priority of each user access request according to each user access request; the user access request is used to request the execution of resource transfer processing;

[0008] According to the processing priority of each user access request, each user access request is added to the cache queue corresponding to the processing priority of each user access request;

[0009] According to the processing priority, resource transfer processing is performed on user access requests in each cache queue.

[0010] In one embodiment, before adding each user access request to a cache queue corresponding to the processing priority of each user access request according to the processing priority of each user access request, the method further includes:

[0011] Based on the user risk data of each user, cluster the risk data of each user to obtain multiple target data sets; the user risk data includes risk level and credit score;

[0012] Each cache queue is generated according to each target data set; one target data set corresponds to one cache queue.

[0013] In one embodiment, based on the user risk data of each user, each user risk data is clustered to obtain multiple target data sets, including:

[0014] The format of the user risk data of each user is converted to obtain the corresponding characteristic points of the user risk data in the two-dimensional coordinate system, where the abscissa of the two-dimensional coordinate system is the credit score and the ordinate is the risk level;

[0015] The preset clustering algorithm is used to cluster the feature points to obtain multiple target data sets.

[0016] In one embodiment, a preset clustering algorithm is used to cluster the feature points to obtain multiple target data sets, including:

[0017] According to the risk level or credit score, each feature point is divided into sets to obtain multiple initial data sets;

[0018] Cluster each feature point based on the distance between each target feature point and the centroid of each initial data set to determine the candidate data set to which each feature point belongs; the centroid is any feature point in each initial data set; the target feature point is the feature point included in the target area in the two-dimensional coordinate system;

[0019] If the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than a preset value, the candidate data set is determined as the target data set;

[0020] If the distance between each feature point in the candidate data set and the centroid of the candidate data set is greater than or equal to the preset value, then continue to re-cluster each feature point based on the distance between each target feature point and the centroid of each candidate data set to determine the new candidate data set to which each feature point belongs, until the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than the preset value.

[0021] In one embodiment, before clustering each feature point based on the distance between each target feature point and the centroid of each initial data set and determining the candidate data set to which each feature point belongs, the method includes:

[0022] Determine the clustering range based on the polygon formed by the centroids of each initial data set;

[0023] The target area is determined with the centroid of each initial data set as the center of the circle and the cluster range as the radius.

[0024] In one embodiment, determining the processing priority of each user access request according to each user access request includes:

[0025] Determine the user level of the user who initiated each user access request according to each user access request;

[0026] The processing priority of each user's access request is determined according to the user level of each user; the higher the user level, the higher the processing priority of the user's access request.

[0027] In one embodiment, resource transfer processing is performed on user access requests in each cache queue according to processing priority, including:

[0028] According to the user identifier pre-stored in the cache queue, the access request initiated by the user for the first time is filtered from the user access requests in each cache queue to obtain the target access request of each cache queue;

[0029] According to the processing priority, resource transfer processing is performed on the target access requests in each cache queue.

[0030] In one embodiment, resource transfer processing is performed on target access requests in each cache queue according to the processing priority, including:

[0031] The identification information of the user corresponding to the target access request in each cache queue is locked, and after the locking process, the target access request in each cache queue is processed according to the processing priority.

[0032] In one embodiment, the method further comprises:

[0033] If the target access request of each cache queue is processed successfully, the information of the resources required to be transferred for the target access request in each cache queue is updated.

[0034] In one embodiment, before determining the processing priority of each user access request according to each user access request, the method includes:

[0035] Receive each user access request sent by the client; each user access request is sent by the user by triggering an access button in the access page of the client.

[0036] In one embodiment, the display color of the access button before being triggered is different from the display color after being triggered, and the access button is in a trigger-disabled state after being triggered.

[0037] In one embodiment, each user access request is sent by triggering an access button when resource information in the access page is displayed in a preset state.

[0038] In one embodiment, the method further comprises:

[0039] If the preset interval time is reached, the newly received user access request is stored in a preset waiting queue; the waiting queue indicates that the newly received user access request is an invalid request.

[0040] In a second aspect, a request processing device is provided, the device comprising:

[0041] A processing level determination module is used to determine the processing priority of each user access request according to each user access request; the user access request is used to request the execution of resource transfer processing;

[0042] A request cache module, used to add each user access request to a cache queue corresponding to the processing priority of each user access request according to the processing priority of each user access request;

[0043] The request processing module is used to perform resource transfer processing on user access requests in each cache queue according to processing priority.

[0044] In a third aspect, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of any one of the request processing methods in the first aspect are implemented.

[0045] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps of any one of the request processing methods in the first aspect are implemented.

[0046] The above-mentioned request processing method, device, computer equipment and storage medium determine the processing priority of each user access request according to each user access request; the user access request is used to request the execution of resource transfer processing; according to the processing priority of each user access request, each user access request is added to the cache queue corresponding to the processing priority of each user access request; according to the processing priority, the user access requests in each cache queue are subjected to resource transfer processing. That is, for user access requests in high-concurrency scenarios, the present application first determines the processing priority of each user access request, and then caches each user access request into a cache queue with a corresponding priority according to the processing priority of each user access request, and then processes the user access requests in each cache queue according to the processing priority of the cache queue, which is equivalent to processing high-concurrency user access requests in batches, thereby effectively alleviating server pressure. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 An application environment diagram of a request processing method in an embodiment;

[0048] Figure 2 A flowchart of a request processing method in one embodiment;

[0049] Figure 3 is a flow chart of a user classification method in one embodiment;

[0050] Figure 4 is a schematic diagram of a clustering process of user risk data in one embodiment;

[0051] Figure 5 is a flow chart of a feature point screening method in one embodiment;

[0052] Figure 6 A flowchart of a request processing method in another embodiment;

[0053] Figure 7 A flowchart of a request processing method in another embodiment;

[0054] Figure 8 A flowchart of a request processing method in another embodiment;

[0055] Fig. 9 is a structural block diagram of a request processing device in one embodiment;

[0056] Fig.10 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0058] With the development of Internet technology, businesses have begun to launch client applications related to their own businesses (such as websites or mobile apps) to conduct online business. Specifically, businesses usually deploy corresponding online businesses on their own client applications, and users can handle personal business by triggering various access buttons and filling in information on the access page of each business. In addition, in order to attract customers, businesses will also provide flash sales services on client applications during holidays or anniversaries, display various snap-up products, attract users' attention at low prices, and then expand their own user groups.

[0059] Flash sales refer to the situation where the number of users rushing to buy a product is far greater than the inventory of the product, and the product will be sold out in a very short time. For example, banks will launch some commemorative coin redemption activities on their client applications. Assuming that the activity starts at 10 am, the user access volume before 10 am is relatively flat. At 10 am, the bank's backend server will receive a large number of user access requests to participate in this commemorative coin redemption activity.

[0060] Based on the above-mentioned flash sale business, its business characteristics are limited time, limited quantity, limited price, and short duration. Among them, limited time means that the flash sale business will be carried out within a specified time, limited quantity means that the inventory of the flash sale products in the flash sale business is limited, and limited price means that the price of the flash sale products will be much lower than the initial price. Limited time, limited quantity and limited price can exist separately or in combination. Short duration means that in the flash sale business, there are many people buying each flash sale product, and the flash sale products will be sold out quickly.

[0061] In addition, from the perspective of processing user access requests in client applications, the technical characteristics of the flash sale business are very high instantaneous concurrency, more reads and less writes, and simple processes. That is, a large number of users will rush to buy the flash sale products under the flash sale business at the same time, resulting in a very high instantaneous concurrent peak of user access requests, a huge number of visits to the client application system, and a small number of actual purchases of the flash sale products, that is, the number of inventory query visits is greater than the number of purchases of the products; and in the flash sale business, the inventory of the flash sale products will continue to decrease, and the inventory of the flash sale products needs to be adjusted according to the user's purchase amount to ensure the accuracy of the inventory data and avoid overselling.

[0062] Therefore, in response to the scenario where the above-mentioned flash sale business leads to high-concurrency user access requests, the present application proposes a request processing method, apparatus, computer equipment and storage medium, which can improve the efficiency of high-concurrency request processing to alleviate server pressure.

[0063] See also Figure 1 The request processing method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown in FIG. 1 , a user initiates a user access request for each business resource from the business display interface of the merchant application client 110 to request online processing of user business. After receiving each user access request, the merchant application server 120 performs resource transfer processing on each user access request and updates resource information according to the processing result.

[0064] The client 110 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, portable wearable devices, etc. As an example, the server 120 may be a backend server of an e-commerce company, or may be implemented as an independent server or a server cluster consisting of multiple servers.

[0065] In a possible implementation, if the client 110 application is a website, the server 120 may be a proxy server (Nginx). The proxy server is another server between the client and the Web server. The client's browser does not directly go to the Web server to obtain the web page, but sends a request to the proxy server. The signal will first be sent to the proxy server, and the proxy server will retrieve the information required by the browser and transmit it to the client's browser.

[0066] By setting up a proxy server, load balancing can be achieved. That is, the proxy server distributes the received user access requests to different servers, and multiple servers handle a large number of user access requests, which can balance the user access request processing volume of each server.

[0067] In another possible implementation, if the client 110 application is a mobile phone APP, the above-mentioned server 120 can also be the background server of the application. The background server may include a site layer, a service layer and a database layer. In response to the high-concurrency user access requests generated in the flash sale business scenario, the concurrency generated by each layer is different, and different layers perform different actions, so that the server can process high-concurrency user access requests in the above-mentioned flash sale scenario.

[0068] However, in the flash sale business, a large number of user access requests will increase the processing pressure of the server. When the processing resources of the server cannot meet the processing volume of user access requests, it will cause important users' requests to not be responded to, the application system to crash, etc. Based on this, the present application proposes a request processing method, device, computer equipment and storage medium.

[0069] In one embodiment, Figure 2 As shown, a request processing method is provided, which is applied to Figure 1 The server 120 in the example is used as an example to illustrate, and the following steps are included:

[0070] Step 210: Determine the processing priority of each user access request according to each user access request; the user access request is used to request to execute resource transfer processing.

[0071] The user access request carries a user ID and a resource ID of the accessed resource. The user ID can indicate the unique identity of the initiator of the user access request, and the resource ID indicates which resource in the client-deployed resources each user access request is initiated against.

[0072] As an example, the processing priorities of user access requests are divided into high priority, secondary priority and rejection. User access requests initiated by different users may have different processing priorities.

[0073] The resources accessed by the user may be various online services displayed by the merchant on its terminal application, and the user sends a user access request to the server for a certain resource.

[0074] For example, there are various online services on the client application of the bank (for example, mobile banking), such as flash sales, funds, financial management, account books, transfers, phone recharges, life payment, limited-time special offers, etc. Users can initiate user access requests for the above services through the client application to request to handle personal business or participate in related activities. When users participate in flash sales, limited-time special offers and other activities, the user access request initiated by the user is used to request to purchase the corresponding flash sale products.

[0075] In a possible implementation, the implementation process of the above step 210 may be: the user sends a user access request to the server by touching an access button of a certain service in the display page of the client. In order to relieve the pressure on the server, the user access requests are processed in batches. After receiving the user access requests initiated by each user, the server first determines the processing priority of each user access request, so as to process each user access request according to different processing priorities.

[0076] Step 220: According to the processing priority of each user access request, each user access request is added to a cache queue corresponding to the processing priority of each user access request.

[0077] It is understandable that the processing priorities of user access requests in the same cache queue are the same, and the processing priorities of user access requests in different cache queues are different.

[0078] In a possible implementation, the implementation process of the above step 220 can be: according to the processing priority of each user access request and the correspondence between the processing priority and the cache queue priority, determine the cache queue corresponding to each user access request, so as to divide the user access requests into each cache queue.

[0079] As an example, corresponding to the processing priority of each user access request, the cache queue is divided into a high priority queue, a sub-priority queue and a rejection queue. High-priority user access requests are added to the high-priority queue, sub-priority user access requests are added to the sub-priority queue, and rejected user access requests are added to the rejection queue.

[0080] Step 230: Perform resource transfer processing on the user access requests in each cache queue according to the processing priority.

[0081] Among them, the resource transfer processing is to update the information of the resources corresponding to each user access request. The resource can be any business deployed in the client application. The resource transfer processing is to update the business information of the corresponding business. The business information may include the inventory quantity of the product corresponding to the business, the business display interface and the product description in the interface, etc. This application does not impose any restrictions here.

[0082] In a possible implementation, since different cache queues have different priorities, the processing order of different cache queues is different. In actual processing, the server processes the user access requests in the high priority queue first, then processes the user access requests in the second priority queue, and directly rejects the user access requests in the rejection queue without processing.

[0083] As an example, for the commemorative coin redemption activity on the bank's client application, 100 users initiated user access requests after the activity started. After the server classified and processed each user access request, 30 user access requests were cached in the high priority queue, 40 user access requests were cached in the secondary priority queue, and 30 user access requests were cached in the rejection queue. When processing, the 30 user access requests in the high priority queue are processed in sequence first. After the user access requests in the high priority queue are processed, the 40 user access requests in the secondary priority queue are processed. The user access requests in the rejection queue are not processed and are directly rejected.

[0084] It can be understood that when processing user access requests in each of the cache queues, the newly received user access requests can be divided into the corresponding cache queues using the above-mentioned data processing method after the user access requests in each cache queue are processed. It is also possible to divide the newly received user access requests into each cache queue during the processing process. This application does not impose any restrictions on this.

[0085] In this embodiment, the processing priority of each user access request is determined according to each user access request; the user access request is used to request the execution of resource transfer processing; according to the processing priority of each user access request, each user access request is added to the cache queue corresponding to the processing priority of each user access request; according to the processing priority, the user access requests in each cache queue are subjected to resource transfer processing. That is, for user access requests in high-concurrency scenarios, this application first determines the processing priority of each user access request, and then caches each user access request into a cache queue with a corresponding priority according to the processing priority of each user access request, and then processes the user access requests in each cache queue according to the processing priority of the cache queue, which is equivalent to processing high-concurrency user access requests in batches, thereby effectively alleviating server pressure.

[0086] Based on the above embodiment, for registered users and access users in the bank's client application, when receiving user access requests, the server can also start the risk control system deployed at the site layer and call the risk control interface to intercept malicious users from the access interfaces of each business, such as the wool-pulling wool-pulling party, attackers with attack tendencies, etc. Secondly, the risk control system deployed at the site layer can also determine the user risk data of each user through a pre-trained risk control model, and determine different levels of cache queues by clustering the risk data of each user. That is, before adding each user's access request to the cache queue of the corresponding processing priority, the server determines the cache queue for caching each user's access request based on the user risk data of each user.

[0087] In one embodiment, Figure 3 As shown, the present application provides a user classification method, comprising the following steps:

[0088] Step 310: clustering the user risk data of each user to obtain multiple target data sets; the user risk data includes risk level and credit score.

[0089] Among them, the risk level is determined based on the user's risk level in this bank and the user's risk level in other banks, and the credit score is the user's credit score in this bank.

[0090] In actual implementation, the user risk data of each user can be determined in advance through the risk control model, and the risk data of each user can be clustered to achieve the purpose of user classification.

[0091] As an example, the risk level of user A is level 2 and the credit score is 700 points, then the user risk data of user A can be expressed as (level 2, 700 points).

[0092] In addition, clustering of risk level data of each user can be achieved through some clustering algorithms, such as: K-means clustering, mean shift clustering, density-based clustering method (DBSCAN), maximum expectation (EM) clustering using Gaussian mixture model (GMM), agglomerative hierarchical clustering, graph community detection (Graph Community Detection, GCD), etc., and this application does not impose any restrictions on this.

[0093] Step 320: Generate each cache queue according to each target data set; one target data set corresponds to one cache queue.

[0094] In a possible implementation, the priority of each target data set is determined according to the user risk data included in each target data set, and a cache queue of corresponding priority is generated according to the priority of the target data set. Different cache queues have different processing priorities, and each cache queue is used to store user access requests received by the server.

[0095] Assuming that there are three target data sets, whose priorities are divided into high, medium and low, the cache queue is divided into a high priority queue, a secondary priority queue and a rejection queue.

[0096] As an example, the process of generating a cache queue of corresponding priority according to the priority of the target data set is as follows: from each target data set, determine the mean of the risk level in each user risk data. Determine the priority of each target data set according to the mean of the risk level corresponding to each target data set. The priority of the target data set with the smallest mean is high, the priority of the target data set with the largest mean is low, and the priority of the remaining target data set is medium. In this way, a high priority queue is generated according to the high-level target data set; a rejection queue is generated according to the low-level target data set; and a secondary priority queue is generated according to the remaining target data set.

[0097] Similarly, the priority of each target data set can also be determined according to the average of the credit points, and a cache queue of the corresponding priority can be generated according to the priority of the target data set. For details, please refer to the above example, which will not be repeated here.

[0098] In this embodiment, the user risk data of each user is determined by the risk control model deployed at the site layer, and a cache queue is generated for the target data set after clustering the risk data of each user. Since different cache queues have different priorities, after receiving the user access request, the server can divide the user access request into different cache queues, and the server will process them in batches.

[0099] In one embodiment, the clustering process of each user's risk data is explained by taking the K-Means algorithm as an example.

[0100] like Figure 4 As shown, according to the user risk data of each user, the implementation process of clustering the user risk data to obtain multiple target data sets (the above step 310) includes the following steps:

[0101] Step 410: Convert the format of each user's risk data to obtain the feature points corresponding to each user's risk data in a two-dimensional coordinate system, where the horizontal axis of the two-dimensional coordinate system is the credit score and the vertical axis is the risk level.

[0102] The format conversion is to represent each user data in the form of coordinate points in a two-dimensional coordinate system.

[0103] As an example, if the user risk data is (level 2, 700 points), the feature point corresponding to the user risk data in the two-dimensional coordinate system is (2, 700).

[0104] Step 420: clustering each feature point using a preset clustering algorithm to obtain multiple target data sets.

[0105] In this embodiment, the preset clustering algorithm is the K-Means algorithm.

[0106] In a possible implementation, the process of clustering feature points using the K-Means algorithm in step 420 includes the following steps:

[0107] Step 422: Divide each feature point into sets according to the risk level or credit score to obtain multiple initial data sets.

[0108] In a possible implementation, the implementation process of the above step 422 is: determine the horizontal coordinate of each feature point in the two-dimensional coordinate system, and divide each feature point into sets according to the horizontal coordinate and credit score range of each feature point to obtain multiple initial data sets.

[0109] As an example, assuming that the predetermined lower limit of the credit score is 0 and the upper limit is 1000 points, the user risk data with a horizontal axis value in the range of 200 to the left is divided into an initial data set; the user risk data with a horizontal axis value in the range of 200-600 is divided into an initial data set; the user risk data with a horizontal axis value in the range of 600 to the right is divided into an initial data set.

[0110] In another possible implementation, the implementation process of the above step 422 is: determine the vertical coordinate of each feature point in the two-dimensional coordinate system, and then divide each feature point into sets according to the vertical coordinate and risk level of each feature point to obtain multiple initial data sets.

[0111] As an example, assuming that the predetermined risk level is 10, the feature points with ordinate values ​​below 3 (i.e., the risk level is 3) are divided into an initial data set; the user risk data with ordinate values ​​in the range of 4-7 are divided into an initial data set; and the user risk data with ordinate values ​​above 7 are divided into an initial data set.

[0112] Step 424: Cluster each feature point based on the distance between each target feature point and the centroid of each initial data set to determine the candidate data set to which each feature point belongs; the centroid is any feature point in each initial data set; the target feature point is the feature point included in the target area in the two-dimensional coordinate system.

[0113] The target area is determined according to the range of each feature point, that is, the target area can be any area including the feature points in the two-dimensional coordinate system, and each target area includes multiple feature points.

[0114] It should be noted that by presetting the target area, irrelevant points can be removed from the two-dimensional coordinate system, narrowing the clustering range, while reducing the amount of data processing and ensuring the validity of the data to be clustered.

[0115] In a possible implementation, the implementation process of the above step 424 can be: for each initial data set, randomly select a point from each initial data set as the centroid, calculate the distance between the other feature points except the centroid and the centroid of each initial data set, and the centroid with the shortest distance to the feature point is the candidate data set to which the feature point belongs; repeat this step, take each feature point in the initial data set as the centroid in turn, and calculate the distance between the other feature points except the centroid and the centroid of each initial data set.

[0116] If the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than the preset value, the following step 426 is performed. If the distance between each feature point in the candidate data set and the centroid of the candidate data set is greater than or equal to the preset value, the following step 428 is performed.

[0117] The distance between each target feature point and the centroid of each initial data set can be represented by Euclidean distance or cosine similarity.

[0118] Both Euclidean distance and cosine similarity evaluate the difference between feature points. Specifically, the Euclidean distance measurement will be affected by the different unit scales of the indicator, and generally needs to be standardized first. The larger the Euclidean distance between two feature points, the greater the difference between the two feature points. The similarity measurement of the cosine angle of the spatial vector will not be affected by the indicator scale. If the cosine value of the spatial vector of the two feature points falls in the interval [-1, 1], the larger the cosine value, the smaller the difference between the two feature points.

[0119] Step 426: If the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than a preset value, the candidate data set is determined as the target data set.

[0120] Among them, if the distance between each feature point in the candidate data set and the centroid of the candidate data set is expressed by Euclidean distance, the preset value can be any positive number, such as: 5, 10, 15, etc.; if the distance between each feature point in the candidate data set and the centroid of the candidate data set is expressed by the cosine value of the space vector, the preset value can be any number in the interval [-1, 1], such as: -0.5, 0.5, 1, etc.

[0121] Step 428: If the distance between each feature point in the candidate data set and the centroid of the candidate data set is greater than or equal to the preset value, continue to re-cluster each feature point based on the distance between each target feature point and the centroid of each candidate data set, and determine the new candidate data set to which each feature point belongs, until the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than the preset value.

[0122] In this embodiment, the risk data of each user is clustered by the K-Means algorithm to obtain multiple target data sets. The user risk data in different target data sets correspond to different users. Clustering the user risk data is equivalent to classifying the users. In this way, user access requests initiated by different users can be added to different cache queues and processed by the server in batches.

[0123] In one embodiment, based on the above clustering process, in order to eliminate irrelevant data and avoid the situation where the clustering process cannot be completed due to individual abnormal data, the present application pre-processes each feature point before clustering the feature points to improve the accuracy of the feature points and ensure the clustering effect.

[0124] like Figure 5 As shown, the present application provides a feature point screening method, which includes the following steps:

[0125] Step 510: Determine the clustering range based on the polygons formed by the centroids of each initial data set.

[0126] Among them, the initial data set is 3 or more data sets, and the polygons formed by the centroids of each initial data set can be triangles, quadrilaterals, pentagons, etc., and this application does not impose any restrictions on this.

[0127] As an example, if the polygon is a triangle, the clustering range is the perpendicular bisector of the triangle formed by the centroids of the three initial data sets; if the polygon is a quadrilateral, the clustering range is any diagonal of the quadrilateral formed by the centroids of the four initial data sets, or the clustering range is the radius of the inscribed circle of the quadrilateral.

[0128] Step 520: Determine the target area with the centroid of each initial data set as the center of the circle and the cluster range as the radius.

[0129] It should be noted that, in order to reduce the amount of data processing, the present application further screens the feature points in the initial data set by way of step 520 to determine the feature points for subsequent clustering. After determining the target area, the feature points outside each target area are deleted from the two-dimensional coordinate system, and the above step 424 is performed on the remaining feature points to obtain multiple target data sets by clustering.

[0130] In this embodiment, each feature point is preprocessed, and the target area is determined with the centroid as the center of the circle and the cluster range as the radius. Feature points outside the target area, that is, feature points with low correlation, are deleted; the feature points in the target area are clustered to obtain the target data set. In this way, by further screening the feature points in the initial data set, effective feature points can be determined. While reducing the feature points to be processed and the amount of calculation, the clustering effect is improved.

[0131] Based on the above Figure 3-Figure 5 In the corresponding embodiment, the user risk data can reflect the user level. The user risk data of the registered users of the merchant application is clustered in advance to obtain multiple target data sets. The user risk data in the same target data set are similar, and the user level is similar. In this way, different services can be provided to different users according to the user level of each user. The present application determines the processing order of user access requests according to the user level.

[0132] Based on the user level of each user, in one embodiment, Figure 6 As shown, the implementation process of determining the processing priority of each user access request (the above step 210) according to each user access request includes the following steps:

[0133] Step 610: According to each user access request, determine the user level of the user who initiated each user access request.

[0134] The user access request carries a user identifier, which is used to indicate the unique identity of the initiator of the user access request.

[0135] In a possible implementation, the registration information of registered users is pre-stored in the server, and the registration information includes a user identification (Identity document, ID), bank card information, login password, transaction password, etc. After the server receives a user access request initiated by a user, it determines the identity of the user who initiates each user access request based on the user identification carried in the user access request and the pre-stored registration information.

[0136] Further, based on the above embodiment, according to the initiating user of each user access request, the user risk data of the user is obtained, and the target data set to which the user risk data belongs is determined; based on the correspondence between the target data set and the user level, the user level of the user who initiates each user access request is determined.

[0137] In addition, after determining the correspondence between the target data set and the user level, the user level of the user corresponding to each risk data in the target data set is further determined, and the user level is pre-added to the user's registration information. In this way, after receiving a user access request initiated by a user, the server can determine the user level of the user who initiated each user access request based on the user identifier carried in the user access request and the pre-stored registration information.

[0138] It should be noted that the user level may also be determined by other methods, not limited to the above methods.

[0139] Step 620: Determine the processing priority of each user's access request according to the user level of each user; the higher the user level, the higher the processing priority of the user's access request.

[0140] As an example, user levels are pre-divided into three levels: high level, medium level and low level, and processing priorities are divided into: high priority, secondary priority and rejection priority.

[0141] For merchants, in order to maintain existing important customers, the processing priority of user access requests initiated by senior users is set to high priority to ensure the access needs of important customers for business. Secondly, in order to ensure that the access requests of important customers are responded to, the processing priority of user access requests initiated by intermediate users is set to secondary priority. While cultivating important customers, the access volume of business is guaranteed to attract more users. In addition, for user access requests initiated by users with relatively low credit or even blacklisted users, the processing priority of user access requests initiated by such low-level users is set to rejection priority and no processing is performed.

[0142] Based on this, after obtaining each access request, the server determines the processing priority of each user access request according to the user level of the user initiating the user access request, so as to process the user access requests initiated by different users according to the processing priority.

[0143] In this embodiment, after receiving the user access request, the server determines the processing priority of each user access request according to the user level of each user. In this way, while ensuring that the user access request of the high-level user is responded to in a timely manner, the user access request initiated by the low-level user is rejected, so as to reduce the data processing pressure of the server and improve the effectiveness of access.

[0144] Based on the above embodiment, each user access request is added to a different cache queue according to the processing priority of each user access request. That is, different cache queues include different user access requests, the processing priority of user access requests in the same cache queue is the same, and the processing priority of user access requests in different cache queues is different.

[0145] In one embodiment, Figure 7 As shown, the implementation process of the server performing resource transfer processing (the above step 230) on the user access requests in each cache queue according to the processing priority includes the following steps:

[0146] Step 710: According to the user identifier pre-stored in the cache queue, the access request initiated by the user for the first time is screened from the user access requests in each cache queue to obtain the target access request of each cache queue.

[0147] It should be noted that, that is, after the user access request comes in, the same user may use different accounts to participate in the flash sale. That is, if a user has multiple accounts, if all accounts of each user initiate user access requests for the same flash sale product, a large number of invalid requests will appear, and when the server queries the inventory of the flash sale product from the database, it will also cause the database pressure to increase.

[0148] Therefore, in the process of business design, in order to avoid the situation where the same user uses multiple accounts to conduct flash sales, this application introduces a remote dictionary service (Remote Dictionary Server, Redis).

[0149] All customer accounts of each registered user are stored in Redis for caching. For the same user, when a user access request initiated by a customer account of the user is added to the cache queue, if user access requests initiated by other accounts are also added to the cache queue, all customer accounts cached in Redis are used to search for user access requests initiated twice or even multiple times, and they are rejected, with a prompt message displayed on the access page, such as: "Your other accounts have already received it, please do not receive it again."

[0150] Therefore, for user access in the cache queue, for user access requests initiated by the same user for the same resource (the resource in this application refers to any business in the merchant application, including the snap-up products in the flash sale business), only the first user access request initiated at the time node is retained and used as the target access request, and other duplicate user access requests are deleted from the cache queue to reduce the access pressure on the database.

[0151] Step 720: Perform resource transfer processing on the target access requests in each cache queue according to the processing priority.

[0152] Among them, resource transfer processing is to update the business information of the target business corresponding to each user's access request. In the flash sale activity, resource transfer processing includes returning the processing result to the client (for example, successful purchase or failure to purchase), and updating the inventory of the purchased product to ensure the accuracy of the inventory and avoid overselling.

[0153] In a possible implementation, the implementation process of the above step 720 may be: locking the identification information of the user corresponding to the target access request in each cache queue, and after locking, processing the target access request in each cache queue according to the processing priority.

[0154] As an example, a Key-Value (key feature pair) database that uses Redis to store and operate data can achieve high concurrent processing of data and ensure the correctness of data, avoiding overselling, etc. The above identification information can be the user's Key value, which can be the registered user's certificate type and corresponding certificate number.

[0155] In the specific implementation, the unique identification key of the customer (such as certificate type + certificate number) is locked and locked through Redis Setnx. When locking, an expiration time needs to be set for the lock. When the data is updated and the user exits unexpectedly for some reason or the delayed task expires, the lock will be deleted and released, and will not exist forever, to ensure the unique access operation of the user.

[0156] Secondly, regarding the possible overselling problem, since Redis commands such as Get and Set are not atomic operations, in high concurrency situations, the remaining quantity deduction of the snapped-up products may be inconsistent with the actual quantity, resulting in "overselling and out-of-stock" phenomenon.

[0157] To avoid overselling problems, the atomicity of inventory deduction operations must be ensured. This application introduces the Lua script. Redis executes the entire Lua script as an atom to ensure the atomicity of the operation. In high-concurrency situations, no transactions are required and the Lua script only needs to send a request to Redis once, reducing network transmission and ensuring high performance and data correctness of high-concurrency requests.

[0158] In addition, after the locking process, the server processes the target access requests in each cache queue according to the processing priority. If the target access requests in each cache queue are processed successfully, the information of the resources required to be transferred for the target access requests in each cache queue is updated.

[0159] It should be noted that in order to reduce the number and frequency of server database queries, the inventory of the snap-up products is saved in Redis. After processing the user access request, the inventory is first updated in the Redis storage, and then the updated inventory in Redis is used to update the inventory of the snap-up products in the database.

[0160] Specifically, the server responds to the user's target access request by updating the business information of the flash sale business targeted by the target access request, or updates the inventory of the flash sale product.

[0161] In addition, because in the flash sale business, the products snapped up by users are concentrated on a few products, so these categories of products are displayed on the homepage of the application. However, for the inventory of the snapped-up products, only the available or unavailable is displayed in the access interface, and the specific remaining quantity of the product is not displayed. Therefore, when querying, there is no need to find the specific remaining quantity from the database, which can reduce the pressure on the backend server.

[0162] Based on any of the above embodiments, the server processes the user access requests in each cache queue in turn according to the processing priority. Since the number of user access requests added to each cache queue is limited, the user access requests that subsequently flow into the server are added to the waiting queue, and when the server has idle processing resources, the subsequent newly flowing user access requests are added to each cache queue.

[0163] Specifically, while adding the user access request to the cache queue, the present application prevents the subsequent newly received user access request from entering the cache queue in order to reduce the pressure on the server.

[0164] Therefore, in a possible implementation, if the preset interval time is reached, the newly received user access request is stored in a preset waiting queue.

[0165] The waiting queue indicates that the newly received user access request is an invalid request. The server only processes the user access requests in the cache queue and temporarily does not process the invalid requests in the waiting queue.

[0166] It should be noted that invalid requests in the waiting queue are not requests that need to be rejected, but requests that need to be processed. For user access requests in the waiting queue, a prompt message of "try again later" can be returned to the user first. Because there may be customers who have purchased the product but have not paid within the specified time, resulting in a return to the warehouse, returning the prompt message of "try again later" can remind users who visit later to purchase the product again after a period of time.

[0167] In addition, when the server is processing user access requests in the cache queue, if the server has idle processing resources and the remaining inventory of the rush-buy product is not 0, the invalid requests in the waiting queue will be added to the cache queue. If the remaining inventory of the rush-buy product is 0, all invalid requests in the waiting queue will be rejected, and the rush-buy product inventory will be displayed as 0 in the access interface, indicating that the rush-buy product is sold out.

[0168] Based on the above request processing method, while screening and classifying the user access requests pouring into the server to reduce the server pressure, the present application also limits the number of user access requests initiated on the client side to prevent users from repeatedly initiating user access requests based on a certain snap-up product in the flash sale business.

[0169] In one embodiment, before determining the processing priority of each user access request based on each user access request (the above-mentioned step 210), the request processing method provided by the present application includes: receiving each user access request sent by the client; each user access request is sent by the user by triggering an access button in the access page of the client.

[0170] It is understandable that multiple services are deployed in the application interface, and the user can initiate a request to handle the service through a button in the access interface of each service.

[0171] As an example, in the access interface of the flash sale service, the user can initiate a user access request by touching the access button of any flash sale product. The user access request is used to purchase the product when the remaining inventory of the flash sale product is not 0.

[0172] It should be noted that, in order to prevent the user from repeatedly touching the access button, the display color of the access button before being triggered is different from the display color after being triggered, and the access button is in a trigger-disabled state after being triggered.

[0173] That is, before the server responds to the initiated user access request, the request cannot be sent repeatedly. In other words, before each user access request receives prompt information such as successful processing, rejection, waiting, etc., the color of the button in the access interface is in a touch-invalid state, and the user will not send the user access request to the server repeatedly even if the user touches it repeatedly.

[0174] Furthermore, when the stock of the rush-buy product is sufficient, the user can initiate a user access request to rush-buy the product. When the stock of the rush-buy product is 0, the rush-buy product is sold out and the user cannot initiate a user access request for the product.

[0175] Based on this, in a possible implementation, the user access request of the present application is sent by triggering an access button when the resource information in the access page is displayed as a preset state.

[0176] The resource information may be product information of any rush-buy product in the flash sale business, and the preset state is the detailed display information of the product, which is used to introduce the product in detail to facilitate user understanding.

[0177] In this embodiment, through the access button in each rush product access interface in the flash sale business, after the user sends a user access request to the server for the first time, the user is prohibited from repeatedly sending requests to reduce the effective amount of user access requests from the source and avoid too many invalid requests from flooding into the server.

[0178] Regarding the above Figure 2-7 Request processing method shown, see Figure 8 This application also provides another request processing method, which is applied to Figure 1 Taking the server 120 in the example as an example, the request processing method includes the following steps:

[0179] Step 810: clustering the user risk data of each user to obtain multiple target data sets; the user risk data includes risk level and credit score;

[0180] Step 820: Generate each cache queue according to each target data set; one target data set corresponds to one cache queue;

[0181] Step 830: receiving each user access request sent by the client; each user access request is sent by the user by triggering an access button in the access page of the client.

[0182] Step 840: Determine the user level of the user who initiated each user access request according to each user access request;

[0183] Step 850: Determine the processing priority of each user's access request according to the user level of each user; the higher the user level, the higher the processing priority of the user's access request;

[0184] Step 860: according to the processing priority of each user access request, add each user access request to a cache queue corresponding to the processing priority of each user access request;

[0185] Step 870: Filter the access request initiated by the user for the first time from the user access requests in each cache queue according to the user identifier pre-stored in the cache queue, and obtain the target access request of each cache queue;

[0186] Step 880: Lock the identification information of the user corresponding to the target access request in each cache queue, and after the locking process, process the target access request in each cache queue according to the processing priority;

[0187] Step 890: If the target access request of each cache queue is processed successfully, the information of the resources required to be transferred for the target access request in each cache queue is updated.

[0188] Above Figure 8 The specific implementation process and beneficial effects of the steps shown can be found in the above embodiments and will not be described in detail here.

[0189] It should be understood that although Figure 2-8 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2-8 At least part of the steps may include multiple steps or multiple stages. These steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the steps or stages in other steps.

[0190] In one embodiment, Fig. 9 As shown, a request processing device is provided, the device 900 includes: a processing level determination module 910, a request caching module 920 and a request processing module 930, wherein:

[0191] The processing level determination module 910 is used to determine the processing priority of each user access request according to each user access request; the user access request is used to request to perform resource transfer processing;

[0192] The request cache module 920 is used to add each user access request to a cache queue corresponding to the processing priority of each user access request according to the processing priority of each user access request;

[0193] The request processing module 930 is used to perform resource transfer processing on user access requests in each cache queue according to the processing priority.

[0194] In one embodiment, the apparatus 900 further includes:

[0195] A clustering module is used to cluster the risk data of each user according to the user risk data of each user to obtain multiple target data sets; the user risk data includes risk level and credit score;

[0196] The queue generation module is used to generate each cache queue according to each target data set; one target data set corresponds to one cache queue.

[0197] In one embodiment, the clustering module includes:

[0198] A format conversion unit, used to convert the format of each user's risk data to obtain the corresponding feature points of each user's risk data in a two-dimensional coordinate system, where the abscissa of the two-dimensional coordinate system is the credit score and the ordinate is the risk level;

[0199] The clustering unit is used to cluster the feature points using a preset clustering algorithm to obtain multiple target data sets.

[0200] In one embodiment, the clustering unit includes:

[0201] A set division subunit is used to divide each feature point into sets according to risk level or credit score to obtain multiple initial data sets;

[0202] The first determination subunit is used to cluster each feature point based on the distance between each target feature point and the centroid of each initial data set, and determine the candidate data set to which each feature point belongs; the centroid is any feature point in each initial data set; the target feature point is the feature point included in the target area in the two-dimensional coordinate system;

[0203] A second determination subunit is used to determine the candidate data set as the target data set if the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than a preset value;

[0204] The third determination subunit is used to continue to re-cluster each feature point based on the distance between each target feature point and the centroid of each candidate data set if the distance between each feature point in the candidate data set and the centroid of the candidate data set is greater than or equal to a preset value, and determine the new candidate data set to which each feature point belongs, until the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than the preset value.

[0205] In one embodiment, the apparatus 900 further includes:

[0206] A clustering range determination module is used to determine the clustering range according to the polygon formed by the centroids of each initial data set;

[0207] The clustering region determination module is used to determine the target region with the centroid of each initial data set as the center of the circle and the clustering range as the radius.

[0208] In one embodiment, the processing level determination module 910 includes:

[0209] A first determining unit, configured to determine, according to each user access request, a user level of a user initiating each user access request;

[0210] The second determining unit is used to determine the processing priority of each user's access request according to the user level of each user; the higher the user level, the higher the processing priority of the user's access request.

[0211] In one embodiment, the request processing module 930 includes:

[0212] A request screening unit, configured to screen the access request initiated by the user for the first time from the user access requests in each cache queue according to the user identifier pre-stored in the cache queue, and obtain the target access request of each cache queue;

[0213] The request processing unit is used to perform resource transfer processing on the target access requests in each cache queue according to the processing priority.

[0214] In one embodiment, the request processing unit is further configured to:

[0215] The identification information of the user corresponding to the target access request in each cache queue is locked, and after the locking process, the target access request in each cache queue is processed according to the processing priority.

[0216] In one embodiment, the apparatus 900 further includes:

[0217] The information updating module is used to update the information of the resources required to be transferred for the target access requests in each cache queue if the target access requests of each cache queue are processed successfully.

[0218] In one embodiment, the apparatus 900 further includes:

[0219] The receiving module is used to receive each user access request sent by the client; each user access request is sent by the user by triggering an access button in the access page of the client.

[0220] In one embodiment, the display color of the access button before being triggered is different from the display color after being triggered, and the access button is in a trigger-disabled state after being triggered.

[0221] In one embodiment, each user access request is sent by triggering an access button when resource information in the access page is displayed in a preset state.

[0222] In one embodiment, the apparatus 900 further includes:

[0223] The storage module is used to store the newly received user access request in a preset waiting queue if the preset interval time is reached; the waiting queue indicates that the newly received user access request is an invalid request.

[0224] For the specific definition of the request processing device, please refer to the definition of the request processing method above, which will not be repeated here. Each module in the above request processing device can be implemented in whole or in part by software, hardware and a combination thereof. The above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0225] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.10 As shown. The computer device includes a processor, a memory and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store user registration information, as well as data such as the inventory of each snap-up product in the flash sale business. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a request processing method is implemented.

[0226] Those skilled in the art will understand that Fig.10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0227] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0228] Determine the processing priority of each user access request according to each user access request; the user access request is used to request the execution of resource transfer processing;

[0229] According to the processing priority of each user access request, each user access request is added to the cache queue corresponding to the processing priority of each user access request;

[0230] According to the processing priority, resource transfer processing is performed on user access requests in each cache queue.

[0231] When the computer device provided in this embodiment implements the above steps, its implementation principle and technical effects are similar to those of the above method embodiments, which will not be repeated here.

[0232] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0233] Determine the processing priority of each user access request according to each user access request; the user access request is used to request the execution of resource transfer processing;

[0234] According to the processing priority of each user access request, each user access request is added to the cache queue corresponding to the processing priority of each user access request;

[0235] According to the processing priority, resource transfer processing is performed on user access requests in each cache queue.

[0236] When the computer device provided in this embodiment implements the above steps, its implementation principle and technical effects are similar to those of the above method embodiments, which will not be repeated here.

[0237] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0238] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0239] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A request processing method, characterized in that: The method comprises: Determining the processing priority of each user access request according to each user access request; the user access request is used to request to perform resource transfer processing; According to the processing priority of each of the user access requests, each of the user access requests is added to a cache queue corresponding to the processing priority of each of the user access requests; According to the processing priority, resource transfer processing is performed on the user access requests in each cache queue, and during the processing, newly received user access requests are divided into corresponding cache queues; Before adding each of the user access requests to a cache queue corresponding to the processing priority of each of the user access requests according to the processing priority of each of the user access requests, the method further includes: Clustering the user risk data of each user to obtain multiple target data sets according to the user risk data of each user; the user risk data includes risk level and credit score; The priority of each target data set is determined according to the user risk data included in each target data set, and a cache queue of corresponding priority is generated according to the priority of the target data set; one target data set corresponds to one cache queue.

2. The method according to claim 1, characterized in that According to the user risk data of each user, each user risk data is clustered to obtain multiple target data sets, including: Performing format conversion on the user risk data of each user to obtain feature points corresponding to each user risk data in a two-dimensional coordinate system, wherein the abscissa of the two-dimensional coordinate system is the credit score and the ordinate is the risk level; A preset clustering algorithm is used to cluster the feature points to obtain the multiple target data sets.

3. The method according to claim 2, characterized in that The preset clustering algorithm is used to cluster the feature points to obtain multiple target data sets, including: According to the risk level or the credit score, each of the characteristic points is divided into sets to obtain multiple initial data sets; Clustering each of the feature points based on the distance between each target feature point and the centroid of each of the initial data sets to determine the candidate data set to which each of the feature points belongs; the centroid is any feature point in each of the initial data sets; the target feature point is a feature point included in the target area in the two-dimensional coordinate system; If the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than a preset value, the candidate data set is determined as the target data set; If the distance between each feature point in the candidate data set and the centroid of the candidate data set is greater than or equal to the preset value, then continue to re-cluster each feature point based on the distance between each target feature point and the centroid of each candidate data set, and determine the new candidate data set to which each feature point belongs, until the distance between each feature point in the candidate data set and the centroid of the candidate data set is less than the preset value.

4. The method according to claim 3, characterized in that Before clustering each of the feature points based on the distance between each target feature point and the centroid of each of the initial data sets to determine the candidate data set to which each of the feature points belongs, the method includes: Determining a clustering range according to a polygon formed by the centroids of each of the initial data sets; The target area is determined with the centroid of each of the initial data sets as the center of the circle and the cluster range as the radius.

5. The method according to claim 1 or 2, characterized in that: Determining the processing priority of each user access request according to each user access request includes: Determining, based on each user access request, a user level of a user initiating each of the user access requests; The processing priority of each user access request is determined according to the user level of each user; the higher the user level, the higher the processing priority of the user access request.

6. The method according to any one of claims 1 to 4, characterized in that: The performing resource transfer processing on the user access requests in each cache queue according to the processing priority includes: According to the user identifiers pre-stored in the cache queues, the access requests initiated by the user for the first time are screened from the user access requests in each cache queue to obtain the target access requests of each cache queue; According to the processing priority, resource transfer processing is performed on the target access request in each cache queue.

7. The method according to claim 6, characterized in that The performing resource transfer processing on the target access request in each cache queue according to the processing priority includes: The identification information of the user corresponding to the target access request in each cache queue is locked, and after the locking process, the target access request in each cache queue is processed according to the processing priority.

8. The method according to claim 7, characterized in that The method further comprises: If the target access request of each cache queue is processed successfully, the information of the resources required to be transferred for the target access request in each cache queue is updated.

9. The method according to any one of claims 1 to 4, characterized in that: Before determining the processing priority of each user access request according to each user access request, the method includes: Receive each user access request sent by the client; each user access request is sent by the user by triggering an access button in the access page of the client.

10. The method according to claim 9, characterized in that The display color of the access button before being triggered is different from the display color after being triggered, and the access button is in a trigger-disabled state after being triggered.

11. The method according to claim 9, characterized in that Each of the user access requests is sent by triggering the access button when the resource information in the access page is displayed in a preset state.

12. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: If the preset interval time is reached, the newly received user access request is stored in a preset waiting queue; the waiting queue indicates that the newly received user access request is an invalid request.

13. A request processing device, characterized in that: The device comprises: A processing level determination module, used to determine the processing priority of each user access request according to each user access request; the user access request is used to request to perform resource transfer processing; A request cache module, used for adding each of the user access requests to a cache queue corresponding to the processing priority of each of the user access requests according to the processing priority of each of the user access requests; A request processing module, used to perform resource transfer processing on the user access requests in each of the cache queues according to the processing priority, and during the processing, divide the newly received user access requests into the corresponding cache queues; The device also includes: A clustering module is used to cluster the risk data of each user according to the user risk data of each user to obtain multiple target data sets; the user risk data includes risk level and credit score; The queue generation module is used to determine the priority of each target data set according to the user risk data included in each target data set, and generate a cache queue of corresponding priority according to the priority of the target data set; one target data set corresponds to one cache queue.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 12 are implemented.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images