Prize overtaking control method and device

Abstract

The invention provides a prize overdelivery control method and device. The method comprises the following steps: acquiring a plurality of lottery drawing requests; calculating the plurality of lottery drawing requests by adopting a preset lottery drawing algorithm to obtain a lottery drawing result corresponding to each lottery drawing request; determining the lottery drawing results indicating winning as winning results, and sorting the winning results; inquiring whether the number of remaining awards is 0 or not in a database for each winning result in the sequence in sequence; if yes, sending a non-winning notice to the user corresponding to the corresponding winning result and the subsequent winning result in the sequence; if not, a winning notice is sent to the user corresponding to the corresponding winning result, and 1 is subtracted from the remaining award number in the database, so that the next winning result of the corresponding winning result in the sequence is inquired based on the remaining award number obtained after 1 is subtracted. The multiple lottery drawing requests are calculated at the same time, and the lottery drawing processing efficiency can be improved. The winning results are sequentially queried in the remaining prize number of the database, and the problem of prize overtaking is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a method and device for controlling over-issuance of prizes, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] After the lottery system receives a user's lottery request, it uses a preset lottery algorithm to calculate the lottery request to obtain a lottery result. If the lottery result indicates winning, the lottery system checks whether the remaining number of prizes in the database is 0, and if it is not 0, subtracts 1 from the remaining number of prizes in the database and sends a winning notice to the user at the same time. If the lottery result indicates not winning, or the lottery result indicates winning but the remaining number of prizes in the database is 0, a non-winning notice is sent to the user.

[0003] In the case of a large number of concurrent lottery requests, the lottery system calculates multiple lottery requests simultaneously, and multiple lottery results in the calculated lottery results may indicate winning. Multiple winning results are queried in the database at the same time. If the remaining number of prizes is not 0, all users corresponding to the multiple winning results can obtain prizes. However, if the number of winning results is greater than the remaining number of prizes in the database, it will lead to over-issuance of prizes to users. To avoid over-issuance of prizes by the lottery system, a read-write lock is usually added at the interface of the lottery system. After the lottery system receives a large number of concurrent lottery requests, the read-write lock controls the large number of lottery requests to be executed in order. That is, the read-write lock controls the lottery system to completely process one lottery request and then process the next lottery request.

[0004] However, the lottery system processes lottery requests one by one, which will increase the processing time of multiple lottery requests, thereby reducing the lottery efficiency. Moreover, the lottery system is generally deployed on multiple servers, and the read-write lock can only be installed in each server. Multiple lottery requests received by different servers at the same time will still form concurrent lottery requests, and there may still be a problem of over-issuance of prizes. It can be seen that there is a need to provide a technical solution that can both improve the lottery efficiency and avoid over-issuance of prizes. Summary of the Invention

[0005] The purpose of the embodiments of this application is to provide a method and device for controlling over-issuance of prizes, an electronic device, a computer-readable storage medium, and a computer program product, which can improve the lottery efficiency while avoiding over-issuance of prizes.

[0006] To solve the above technical problems, the embodiments of this application provide the following technical solutions:

[0007] The first aspect of the present application provides a method for controlling over-issuance of prizes, and the method includes: obtaining a plurality of lottery requests; calculating the plurality of lottery requests by using a preset lottery algorithm to obtain a lottery result corresponding to each lottery request; determining the lottery results indicating winning as winning results and sorting the winning results; sequentially querying in the database whether the remaining number of prizes for each winning result in the sorting is 0; if so, sending a non-winning notice to the user corresponding to the corresponding winning result and the winning results subsequent thereto in the sorting; if not, sending a winning notice to the user corresponding to the corresponding winning result and subtracting 1 from the remaining number of prizes in the database, so that the next winning result in the sorting corresponding to the corresponding winning result queries based on the remaining number of prizes after subtracting 1.

[0008] Compared with the prior art, the method for controlling over-issuance of prizes provided by the first aspect of the present application calculates the lottery results of a plurality of lottery requests simultaneously, then sorts the winning results in the lottery results, and sequentially queries in the remaining number of prizes in the database according to the sorting. Calculating a plurality of lottery requests simultaneously can improve the efficiency of lottery processing. Querying the winning results sequentially in the remaining number of prizes in the database can avoid querying in the remaining number of prizes in the database at the same time even in the face of lottery requests from multiple servers, and further avoid the remaining number of prizes being queried by multiple winning results at the same time when there is only 1 remaining prize, ensuring that the expected number of prizes is consistent with the actual number of winning notifications sent to users and solving the problem of over-issuance of prizes.

[0009] In some modified implementation manners of the first aspect of the present application, before calculating the plurality of lottery requests by using a preset lottery algorithm, the method further includes: deleting the lottery requests that meet the preset filtering conditions in the plurality of lottery requests to obtain the plurality of lottery requests after deletion; calculating the plurality of lottery requests by using a preset lottery algorithm, including: calculating the plurality of lottery requests after deletion by using a preset lottery algorithm.

[0010] Before processing the plurality of lottery requests, first delete some lottery requests that do not meet the lottery conditions. In this way, the processing volume of the lottery system for lottery requests can be reduced, some server connection resources can be released, the performance impact brought by database access can be reduced, and finally the lottery efficiency can be improved.

[0011] In some modified implementation manners of the first aspect of the present application, deleting the lottery requests that meet the preset filtering conditions in the plurality of lottery requests includes at least one of the following four items: deleting the lottery requests with duplicate Internet Protocol (IP) addresses within a preset time in the plurality of lottery requests; deleting the lottery requests exceeding a preset quantity within a unit time in the plurality of lottery requests; deleting the lottery requests with unpassed signature verification in the plurality of lottery requests; deleting the lottery requests with completely duplicate lottery parameters in the plurality of lottery requests.

[0012] Duplicate IP addresses, excessive requests, signatures not passing verification, and duplicate lottery draw parameters can comprehensively and accurately characterize abnormal lottery draw behaviors. Therefore, deleting lottery draw requests with duplicate IP addresses, excessive requests, signatures not passing verification, and duplicate lottery draw parameters among multiple lottery draw requests can achieve fast and comprehensive filtering of lottery draw requests.

[0013] In some modified implementation manners of the first aspect of the present application, deleting lottery draw requests with signatures not passing verification among multiple lottery draw requests includes: extracting the sign signature in each lottery draw request; matching the extracted sign signature with the sign signature in the cache. Among them, when the user corresponding to the lottery draw request passes verification in the lottery draw system, the lottery draw system returns the sign signature to the user, stores the returned sign signature in the cache, and deletes the sign signature that matches successfully in the cache in the case of successful matching; if the matching fails, the corresponding lottery draw request is deleted.

[0014] When filtering requests based on the signatures in the requests, by matching with the sign signatures in the cache, there is no need to generate additional signatures in the requests, and the existing sign signatures are used. This can not only verify the signatures in the requests but also avoid generating brand-new signatures, improving the signature generation efficiency. Moreover, after the signature matching is successful, deleting the sign signatures that match successfully in the cache can ensure that one interface verification corresponds to one lottery draw behavior, effectively avoiding duplicate lottery draw behaviors.

[0015] In some modified implementation manners of the first aspect of the present application, sorting the winning results includes: storing the winning results in a queue, where the queue is located in the lottery draw system; sorting the winning results in the queue.

[0016] For multiple winning results, they are sorted in the queue of the lottery draw system. Compared with the lottery draw system sending multiple lottery draw requests to the middleware for sorting and sequentially obtaining lottery draw requests from the middleware for processing, the lottery draw system manages multiple winning results through the queue, which can avoid the influence of the network on the transmission of winning results and improve the lottery draw efficiency.

[0017] In some modified implementation manners of the first aspect of the present application, the database includes a winning identifier; determining the lottery draw results indicating winning as winning results includes: sending each lottery draw result to the database so that the database matches each lottery draw result with the winning identifier; obtaining the winning results that match the winning identifier in each lottery draw result feedback by the database and their return times; sorting the winning results in the queue includes: sorting the winning results in the queue according to the return times.

[0018] Sort multiple winning results based on the return time of the database. The return time obtained through the behavior of the database itself can more fairly and simply represent the order among multiple winning results. Therefore, it can improve the fairness and efficiency of sorting multiple winning results, and then, when the number of remaining awards is insufficient, it can fairly and efficiently achieve prize distribution.

[0019] In some modified implementation manners of the first aspect of the present application, before obtaining multiple lottery requests, the method further includes: turning off the deadlock detection function in the database.

[0020] Turning off the deadlock detection function in the database can prevent the database from automatically shutting down or restarting when a deadlock problem occurs, ensure the continuous operation of the database, effectively avoid a sharp drop in the database processing performance in the case of a deadlock, and guarantee that a large number of concurrent lottery requests can be continuously and stably processed.

[0021] In some modified implementation manners of the first aspect of the present application, the database further includes the remaining number of awards for other lottery items except the lottery item corresponding to the lottery request; sequentially query in the database whether the remaining number of awards for each winning result in the sorting is 0, including: locking the remaining number of awards for the lottery item corresponding to the lottery request in the database; querying in the database whether the locked remaining number of awards is 0 based on the current winning result in the sorting.

[0022] For the remaining number of awards for different lottery items in the database, the query can be performed simultaneously. That is, when querying a certain winning result of a certain lottery item in the database, only the remaining number of awards for that lottery item needs to be locked. In this way, different lottery items can be carried out simultaneously, improving the overall lottery efficiency.

[0023] In some modified implementation manners of the first aspect of the present application, after sequentially querying in the database whether the remaining number of awards for each winning result in the sorting is 0, the method further includes: if not, generating and storing a prize awarding order corresponding to the corresponding winning result, and releasing the resources of the server where the corresponding lottery request is located, waiting to process the prize awarding order when the resource utilization rate of the server is less than a preset threshold.

[0024] For the prize awarding order, it can be stored first. After a large number of concurrent lottery requests are processed, the prize awarding order is processed. Making the lottery and prize awarding asynchronous can provide more resources for the processing of lottery requests during the lottery, improving the lottery processing efficiency.

[0025] The second aspect of the present application provides a prize over-issuance control device, which includes: an acquisition module for acquiring a plurality of lottery requests; a calculation module for calculating the plurality of lottery requests using a preset lottery algorithm to obtain a lottery result corresponding to each lottery request; a sorting module for determining the lottery results indicating winning as winning results and sorting the winning results; a query module for sequentially querying in the database whether the remaining number of prizes for each winning result in the sorting is 0; if so, entering the first notification module, and if not, entering the second notification module; the first notification module for sending a non-winning notification to the users corresponding to the corresponding winning results and the subsequent winning results in the sorting; the second notification module for sending a winning notification to the user corresponding to the corresponding winning result, and subtracting 1 from the remaining number of prizes in the database, so that the next winning result in the corresponding winning result in the sorting queries based on the remaining number of prizes after subtraction.

[0026] The third aspect of the present application provides an electronic device, which includes a processor, a memory, and a bus. The processor and the memory communicate with each other through the bus. The processor is used to call program instructions in the memory to execute the method in the first aspect.

[0027] The fourth aspect of the present application provides a computer-readable storage medium, which includes a stored program. When the program runs, it controls the device where the computer-readable storage medium is located to execute the method in the first aspect.

[0028] The fifth aspect of the present application provides a computer program product, which includes a computer program or instruction. When the computer program or instruction is executed by the device where it is located, it implements the method in the first aspect.

[0029] The prize over-issuance control device provided in the second aspect of the present application, the electronic device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect have the same or similar beneficial effects as the prize over-issuance control method provided in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] By referring to the drawings and reading the detailed description below, the above and other objects, features, and advantages of the exemplary embodiments of the present application will become easy to understand. In the drawings, several embodiments of the present application are shown in an exemplary rather than restrictive manner, and the same or corresponding reference numerals represent the same or corresponding parts, where:

[0031] Figure 1 is a schematic structural diagram of a lottery system in an embodiment of the present application;

[0032] Figure 2 is a flowchart of the prize over-issuance control method in an embodiment of the present application Figure 1 ;

[0033] Figure 3 Schematic flow chart of the method for controlling over-issuance of prizes in the embodiments of the present application Figure 2 ;

[0034] Figure 4 Schematic structure of the device for controlling over-issuance of prizes in the embodiments of the present application Figure 1 ;

[0035] Figure 5 Schematic structure of the device for controlling over-issuance of prizes in the embodiments of the present application Figure 2 ;

[0036] Figure 6 Schematic diagram of the structure of the electronic device in the embodiments of the present application. Detailed implementation manners

[0037] Hereinafter, the exemplary embodiments of the present application will be described in more detail with reference to the accompanying drawings. Although the exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that the present application can be more thoroughly understood and the scope of the present application can be fully conveyed to those skilled in the art.

[0038] It should be noted that, unless otherwise specified, the technical terms or scientific terms used in the present application should have the ordinary meanings understood by those skilled in the art to which the present application belongs.

[0039] In a lottery system, in the face of a large number of concurrent lottery requests, if multiple lottery requests are processed simultaneously, when the remaining number of prizes in the database is not sufficient to support the number of winning results corresponding to multiple lottery requests, the problem of over-issuance of prizes will occur. If a read-write lock is installed at the interface of the lottery system, in the case where the lottery system is deployed on multiple servers, the lottery system still needs to face the lottery requests of multiple servers, and the problem of over-issuance of prizes will still occur.

[0040] In view of this, the embodiments of the present application provide a method for controlling over-issuance of prizes, a device for controlling over-issuance of prizes, an electronic device, a computer-readable storage medium, and a computer program product. Whether it is a lottery request from one server or multiple servers, after the lottery system receives multiple lottery requests, when calculating the lottery results based on the lottery requests, it can be carried out simultaneously, which can improve the processing efficiency of lottery requests. When querying the remaining number of prizes in the database based on the winning results in the lottery results, it is necessary to query sequentially based on each winning result, which can avoid over-issuance of prizes caused by simultaneous queries. Finally, it can not only improve the lottery efficiency but also avoid over-issuance of prizes.

[0041] First, the application scenario of the method for controlling over-issuance of prizes provided in the embodiments of the present application will be described.

[0042] Figure 1 This is a schematic structural diagram of the lottery system in the embodiments of the present application. Refer to Figure 1 As shown, the lottery system 11 is deployed in multiple servers 12.

[0043] Different users send lottery requests to the lottery system 11 at the same time, and these lottery requests are assigned to different servers 12 for processing. After receiving a lottery request, the server 12 first calculates the lottery request using a preset lottery algorithm to obtain a lottery result. In the case where the lottery result indicates winning, the server 12 directly sends a non-winning notice to the user. In the case where the lottery result indicates winning, the server 12 queries in the database 13 whether the remaining number of awards is 0.

[0044] In the initial state, the database 13 stores the total number of awards for this lottery. Each time a user wins, the number of awards is decreased by 1 to obtain the remaining number of awards.

[0045] When the server 12 queries in the database 13 based on multiple winning results, it needs to query and process based on the next winning result after one winning result is queried and processed.

[0046] For a certain winning result, if the server 12 queries that the remaining number of awards in the database 13 is 0, it means there are no remaining prizes. The server 12 can send a non-winning notice to the corresponding user and decrease the remaining number of awards in the database 13 by 1. If it queries that the remaining number of awards in the database 13 is not 0, it means there are still remaining prizes. The server 12 can send a winning notice to the corresponding user and decrease the remaining number of awards in the database 13 by 1.

[0047] In this way, when the server 12 calculates the lottery result of the lottery request using the preset lottery algorithm, a large number of concurrent lottery requests can be processed simultaneously, improving the lottery efficiency. Moreover, when the server 12 queries the remaining number of awards in the database based on multiple winning results, multiple winning results need to be processed sequentially, avoiding that most winning results simultaneously query a small number of remaining awards, thereby avoiding over-issuing of prizes.

[0048] It should be noted here that the relevant data and relevant processing methods involved in the embodiments of the present application have obtained relevant authorization in advance and are legal and compliant.

[0049] Next, a detailed description will be given to the method for controlling over-issuing of prizes provided in the embodiments of the present application.

[0050] Figure 2 This is a flowchart of the method for controlling over-issuing of prizes in the embodiments of the present application Figure 1 Refer to Figure 2 As shown, the method may include:

[0051] S21: Obtain multiple lottery draw requests.

[0052] When a user needs to participate in the lottery draw of the lottery system, the user operates in the client of the lottery system. The client of the lottery system will generate a lottery draw request and send the lottery draw request to the server of the lottery system. In this way, the server of the lottery system can obtain the lottery draw requests of the users.

[0053] In practical applications, the lottery system can be any application software that provides lottery draw services. There is no limitation on the specific application software here.

[0054] In the lottery draw request, in addition to including information for requesting a lottery draw, it can also include the identification of the user, the identification of the client, etc. There is no limitation on the specific content included in the lottery draw request here.

[0055] S22: Use a preset lottery draw algorithm to calculate multiple lottery draw requests to obtain the lottery draw result corresponding to each lottery draw request.

[0056] After the server receives multiple lottery draw requests, it starts to process these multiple lottery draw requests simultaneously to improve the lottery draw efficiency.

[0057] Specifically in the process of handling, first use a preset lottery draw algorithm to calculate each lottery draw request to obtain the lottery draw result corresponding to each lottery draw request.

[0058] The preset lottery draw algorithm here can refer to an algorithm that calculates based on the parameters in the lottery draw request to obtain a result indicating whether winning the lottery, or it can also refer to an algorithm that calculates based on preset rules to obtain a result indicating whether winning the lottery. There is no limitation on the specific content of the preset lottery draw algorithm here.

[0059] After the lottery draw request is calculated based on the preset lottery draw algorithm, the obtained lottery draw result is one of winning the lottery and not winning the lottery. Whether the lottery draw result specifically represents winning the lottery or not needs to be determined according to the predefined winning identification. When the lottery draw result is the same as the winning identification, it is determined that the lottery draw result is winning the lottery, and at this time the lottery draw result is the winning result. When the lottery draw result is different from the winning identification, it is determined that the lottery draw result is not winning the lottery, and at this time a non-winning notice can be sent to the user who did not win the lottery.

[0060] S23: Determine the lottery draw result indicating winning as the winning result and sort the winning results.

[0061] Among the lottery results corresponding to multiple requests, some of the lottery results may be winning, that is, multiple winning results are obtained. When querying the remaining number of awards in the database based on these winning results, it is necessary to perform one winning result after another to ensure that the remaining number of awards queried each time is accurate, and to avoid that when multiple winning results query the remaining number of awards at the same time, the users corresponding to the small number of winning results should win the prize, but in fact, the users corresponding to multiple winning results all win the prize, thus avoiding over-issuance of prizes.

[0062] In the sorting of multiple winning results, the multiple winning results can be sorted randomly, or sorted according to the time of generation of the multiple winning results from early to late, or sorted according to whether the lottery result wins the prize queried in the database and the time of the database's feedback on whether the corresponding lottery result wins the prize. The specific sorting method for multiple winning results is not limited here.

[0063] S24: Query whether the remaining number of awards in the database is 0 for each winning result in the sorting in turn. If so, execute S25; if not, execute S26.

[0064] Just because the lottery result corresponding to the lottery request indicates winning does not necessarily mean that the user has won the prize. It is also necessary to check the remaining number of awards in the database. Only when there are still remaining awards can the winning result be determined, that is, the user corresponding to the lottery request corresponding to the lottery result indicating winning wins the prize.

[0065] When querying the remaining number of awards in the database, each winning result in the sorting is performed in turn. That is, query whether the remaining number of awards in the database is 0 for the first winning result in the sorting. If so, it means that all the awards provided in this lottery have been distributed, and the subsequent winning results cannot be determined to be winning either. If the subsequent winning results are determined to be winning, it will lead to the number of distributed winning results exceeding the total number of awards, resulting in over-issuance of prizes in the future. If not, it means that all the awards provided in this lottery have not been fully distributed. At this time, the winning result can be finally determined to be winning. At the same time, the remaining number of awards in the database needs to be reduced by 1. Then, query whether the remaining number of awards in the database is 0 for the second winning result in the sorting. The query processing method in the database for the first winning result is the same until the query for the last winning result in the sorting is completed.

[0066] In practical applications, in addition to directly querying the remaining number of awards in the database, it is also possible to determine whether there are any remaining awards in the database by looking at the result of subtracting 1 from the remaining number of awards in the database. Specifically, an operation of subtracting 1 from the remaining number of awards is performed in the database based on a winning result. If the remaining number of awards in the database is greater than 0, this operation can succeed. If this operation succeeds, it is determined that the remaining number of awards in the database is not 0. If the remaining number of awards in the database is 0, this operation will not succeed because the remaining quantity must be greater than 0, but it is 0 at this time and cannot be further subtracted by 1. If this operation fails, it is determined that the remaining number of awards in the database is 0.

[0067] Taking the execution of the update method of the mysql database as an example, all lottery requests execute the statement "update prize table set remaining quantity = remaining quantity - 1 where winning id = id and remaining quantity > 0". The winning lottery requests will be forced to queue up and execute in order when they reach this point in the database. Only when the remaining quantity > 0 will the operation of subtracting 1 from the remaining quantity be completed. Obtain the execution result of each winning lottery request, and thus determine whether the award corresponding to the winning lottery request has been successfully issued based on the execution result. If the execution of the winning lottery request is successful, it means that the user corresponding to the winning lottery request has won the prize; otherwise, it means that the user corresponding to the winning lottery request has not won the prize.

[0068] S25: Send a non-winning notice to the user corresponding to the corresponding winning result and the winning results that come after it in the sorting.

[0069] For a certain winning result in the sorting, if the remaining number of awards queried in the database is 0, it means that there are no remaining prizes available. At this time, it is determined that this winning result and all the winning results after it in the sorting have not won the prize, and a non-winning notice is sent to the users corresponding to these winning results.

[0070] S26: Send a winning notice to the user corresponding to the corresponding winning result, and subtract 1 from the remaining number of awards in the database so that the next winning result in the sorting can query based on the remaining number of awards after the subtraction.

[0071] For a certain winning result in the sorting, if the remaining number of awards queried in the database is not 0, it means that there are still remaining prizes available at present. At this time, it is determined that this winning result has finally won the prize, and a winning notice is sent to the user corresponding to this winning result. At the same time, since it has been previously determined to provide a prize to this user, the remaining number of awards in the database needs to be subtracted by 1, and the next winning result needs to be queried based on the remaining number of awards after the update (i.e., the previous subtraction by 1).

[0072] The following uses a specific example to illustrate the prize over-issuance control method provided by the embodiments of the present application.

[0073] Assume that the lottery system is deployed in Server 1 and Server 2. It is expected to distribute 10 prizes in this lottery, that is, the remaining number of prizes in the database is initially set to 10, and a total of 200 users participate in the lottery successively.

[0074] At the first time, users 1 - 10 send lottery requests to the lottery system. Server 1 receives the lottery requests from users 1 - 5, and Server 2 receives the lottery requests from users 6 - 10. Server 1 and Server 2 use the preset lottery algorithm to calculate the received lottery requests simultaneously, and obtain the lottery results 0, 0, 0, 0, 0, 0, 0, 0, 1, 1 respectively. Among them, 1 means winning the lottery, and 0 means not winning. At this time, it can be determined that users 1, 2, 3, 4, 5, 6, 7, 8 do not win, and non-winning notices are sent to these users. Users 9 and 10 win. In this order, based on user 9, the remaining number of prizes in the database is 10, not 0. At this time, it can be determined that user 9 wins, and a winning notice is sent to user 9. At the same time, the remaining number of prizes is decreased by 1, and the current remaining number of prizes is 9. Then, based on user 10, the remaining number of prizes in the database is 9, not 0. At this time, it can be determined that user 10 wins, and a winning notice is sent to user 10. At the same time, the remaining number of prizes is decreased by 1, and the current remaining number of prizes is 8.

[0075] At the second time, users 11 - 80 send lottery requests to the lottery system. Server 1 receives the lottery requests from users 11 - 30, and Server 2 receives the lottery requests from users 31 - 80. Server 1 and Server 2 use the preset lottery algorithm to calculate the received lottery requests simultaneously. The lottery results of users 11 - 17 are 1, and the lottery results of users 18 - 80 are 0. At this time, it can be determined that users 18 - 80 do not win, and non-winning notices are sent to these users. Users 11 - 17 win. In this order, based on user 11, the remaining number of prizes in the database is 8, not 0. At this time, it can be determined that user 11 wins, and a winning notice is sent to user 11. At the same time, the remaining number of prizes is decreased by 1, and the current remaining number of prizes is 7. Then, based on user 12, check whether the remaining number of prizes in the database is 0. The specific processing method hereafter is the same as that of user 11, and will not be elaborated here. After sending the winning notice to user 17, the remaining number of prizes in the database is 1.

[0076] At the third time, users 81 - 100 send lottery draw requests to the lottery system. Server 1 receives the lottery draw requests from users 81 - 90, and Server 2 receives the lottery draw requests from users 91 - 100. Server 1 and Server 2 calculate the lottery draw requests they receive simultaneously using a preset lottery algorithm. The lottery draw results for users 81 - 95 are 0, and the lottery draw results for users 95 - 100 are 1. At this time, it can be determined that users 81 - 95 do not win the lottery, and non-winning notices are sent to these users. Users 95 - 100 win the lottery. In this order, based on user 95, checking the remaining number of prizes in the database is 1, not 0. At this time, it can be determined that user 95 wins the lottery, a winning notice is sent to user 95, and at the same time, the remaining number of prizes is decreased by 1. The current remaining number of prizes is 0. Then, based on user 96, checking the remaining number of prizes in the database is 0. At this time, it can be determined that there are no remaining prizes, and it is determined that user 96 does not win the lottery, and a non-winning notice is sent to user 96. Since the remaining number of prizes in the database is already 0, users 97 - 100 thereafter can be directly determined not to win the lottery without further query. For the users corresponding to the winning results after the winning result corresponding to the first determination of the remaining number of prizes in the database being 0 in the sorting, that is, users 97 - 100, non-winning notices can be directly sent to these users.

[0077] For the lottery draw requests received after the remaining number of prizes in the database is first determined to be 0, that is, at the third time, the lottery draw requests sent by users 101 - 200 to the lottery system, non-winning notices can also be directly sent to these users, thereby improving the lottery efficiency.

[0078] As can be seen from the above, the method for controlling over-issuance of prizes provided by the embodiments of the present application calculates the lottery draw results of multiple lottery draw requests simultaneously, then sorts the winning results in the lottery draw results, and queries them in the remaining number of prizes in the database in sequence according to the sorting. Calculating multiple lottery draw requests simultaneously can improve the efficiency of lottery draw processing. Querying the winning results in the remaining number of prizes in the database in sequence can avoid querying the remaining number of prizes in the database at the same time even in the face of lottery draw requests from multiple servers, and further avoid the remaining number of prizes being simultaneously queried by multiple winning results when there is only 1 remaining prize, ensuring that the expected number of prizes is consistent with the actual number of winning users notified, and solving the problem of over-issuance of prizes.

[0079] Further, as a refinement and extension of the Figure 2 shown method, the embodiments of the present application also provide a method for controlling over-issuance of prizes.

[0080] Figure 3 For the flow diagram of the method for controlling over-issuance of prizes in the embodiments of the present application Figure 2 , see Figure 3 shown, this method may include:

[0081] S31: Turn off the deadlock detection function in the database.

[0082] The database here refers to the database used by the lottery system to query the remaining number of prizes during the lottery process. In practical applications, this database can be a database for storing structured data. The specific type of the database is not limited here.

[0083] Deadlock generally refers to a blocking phenomenon caused by two or more processes competing for resources or communicating with each other during execution, resulting in these processes being unable to continue execution unless there is external intervention. In a database, due to the concurrent execution of processes such as queries, a deadlock detection function is generally configured to ensure the smooth operation of each process. When the database detects a deadlock, it restarts to make the processes that had the deadlock run again, thereby ensuring the smooth operation of each process in the database. The processes here can refer to the processes called by the lottery system when querying in the database, or the processes called by other systems using the database except the lottery system.

[0084] Before officially conducting the lottery, it can be first detected whether the deadlock detection function in the database is turned off. If it is turned off, the next step can be entered. If it is not turned off, the deadlock detection function needs to be turned off. In this way, the database will not perform deadlock detection, and thus will not restart the database when a deadlock problem is found, enabling the database to continue running, and further ensuring that the lottery system can continuously query in the database, improving the lottery efficiency.

[0085] For the query process of the lottery system that has a deadlock problem in the database, it can be processed manually. That is, if the winning result corresponding to a certain lottery request has no response for a long time when querying in the database and the user has not received the notice of whether they have won the lottery for a long time, the user can feedback the situation to the lottery system at this time. After seeing the feedback situation, the back-end staff of the lottery system can re-run the query of the winning result corresponding to the lottery request in the database through back-end operations, so as to manually make the deadlocked lottery query process continue and ensure the normal operation of the lottery.

[0086] When specifically detecting whether the deadlock function is turned off, it can be checked manually whether the deadlock function detection option of the database is enabled. If it is enabled, this option can be turned off manually. If it is not enabled, it is determined that the deadlock detection function is turned off, and the next step can be continued. It is also possible to directly send a deadlock detection function turn-off instruction to the database. If the database deadlock detection function is enabled, the deadlock detection function will be turned off based on this instruction. If the database deadlock detection function is not enabled, no processing will be performed based on this instruction, and the next step, that is, officially starting to process the lottery request, can be continued.

[0087] S32: Obtain multiple lottery requests.

[0088] The specific implementation of step S32 here is the same as that of step S21 in the foregoing embodiment. For relevant descriptions, reference can be made to the foregoing embodiment and will not be elaborated herein.

[0089] S33: Delete the lottery requests that meet the preset filtering conditions among multiple lottery requests to obtain the multiple lottery requests after deletion.

[0090] Among multiple lottery requests, there are generally some unreasonable lottery requests, such as: lottery requests for scalpers' order brushing, users' repeated operations, etc. By first deleting these unreasonable lottery requests among multiple lottery requests, the pressure on the lottery system to process lottery requests can be reduced, more resources can be released to process normal lottery requests, and the lottery efficiency can be improved.

[0091] The preset filtering conditions for deleting lottery requests can be determined according to the actual situation. For example: to delete lottery requests for scalpers' order brushing, the preset filtering condition can be repeated IP addresses. To ensure the stable operation of the lottery system, the preset filtering condition can be lottery requests exceeding the preset quantity within a unit time. To ensure the safe operation of the lottery system, the preset filtering condition can be lottery requests that fail the security verification. To avoid repeated operations by the same user, the preset filtering condition can be repeated lottery parameters in the lottery requests. The specific content of the preset filtering conditions is not limited herein.

[0092] Specifically, the above step S33 may include:

[0093] Step A1: Delete the lottery requests with repeated IP addresses within a preset time among multiple lottery requests.

[0094] For scalpers' order brushing, the scalpers initiate lottery requests to the server of the lottery system. Unlike ordinary users who initiate lottery requests through the client of the lottery system, that is, the front-end initiates lottery requests to the server, but through batch direct calls to the interface of the lottery system. And the IP addresses used for batch interface calls are the same. Therefore, by judging whether the IP addresses corresponding to multiple lottery requests are the same, it can be determined that multiple lottery requests with the same IP address are sent by the same scalper, and the lottery requests with repeated IP addresses are deleted.

[0095] In some cases, it is not completely prohibited for lottery requests with repeated IP addresses from participating in the lottery. It is only necessary to ensure that there will not be a large number of order-brushing lottery requests within a certain period of time. Therefore, it is only necessary to ensure that lottery requests with repeated IP addresses are not processed within a certain period of time. That is, delete the lottery requests with repeated IP addresses within a preset time among multiple lottery requests.

[0096] The preset time here can be set according to actual needs and is not limited herein.

[0097] Step A2: Delete the lottery draw requests that exceed the preset quantity within a unit time among multiple lottery draw requests.

[0098] The quantity of lottery draw requests processed by the lottery draw system at the same time is limited. If it exceeds this quantity, it will overload the lottery draw system, reduce the processing efficiency, and even cause the lottery draw system to crash. Therefore, after the quantity of lottery draw requests received by the lottery draw system within a unit time reaches the preset quantity, when lottery draw requests are received again within the unit time, the received lottery draw requests will be deleted.

[0099] The lottery draw requests deleted at this time may be normal lottery draw requests of users. To ensure that users can participate in the lottery draw normally, the lottery draw requests that exceed the preset quantity can be stored in a preset location first, and the corresponding user can be notified that the system is busy and needs to wait. In the next unit time, the lottery draw system first obtains and processes these lottery draw requests from the preset location, and then processes the newly received lottery draw requests. If the quantity of lottery draw requests in the next unit time exceeds the limit, they will continue to be temporarily stored in the preset location for the next unit time.

[0100] The specific data of the unit time can be set according to the actual situation and is not limited here.

[0101] Step A3: Delete the lottery draw requests with signatures that fail to pass verification among multiple lottery draw requests.

[0102] In some cases, there may be some illegal users who forge lottery draw requests to obtain prizes. Generally, the signatures in lottery draw requests cannot be forged. Therefore, the signature in the lottery draw request can be verified to determine whether the lottery draw request is generated normally.

[0103] The signature used in the lottery draw request can be pre-agreed between the lottery draw system and the user. Different users correspond to different signatures, and the lottery draw system stores each user and their corresponding signatures. After the lottery draw system obtains the lottery draw request, it can match the signature in the lottery draw request with the signature of the corresponding user stored in advance. If the match is successful, it is determined that the signature is correct, and thus it is determined that the lottery draw request is sent by a normal user. If the match fails, it is determined that the signature is incorrect, and thus it is determined that the lottery draw request is sent by an illegal user. The lottery draw request is deleted, and the administrator is reminded to take precautions in advance.

[0104] In the lottery draw request, an existing signature can also be directly used. For example: sign signature. When a user accesses the lottery draw system, an access request will be sent to the lottery draw system. After the lottery draw system verifies and passes based on the access request, it will generate a sign signature, feedback the sign signature to the user, and store the sign signature in the cache. When the user participates in the lottery draw, the user carries the previously obtained sign signature when sending a lottery draw request to the lottery draw system. The lottery draw system can determine whether the lottery draw request is verified by matching the sign signature in the lottery draw request with the sign signature in the cache. At this time, the sign signature does not need to be newly generated between the lottery draw system and the user based on the lottery draw activity, but is the signature obtained by the user when accessing the lottery draw system previously. This avoids the generation of a new signature, improves the lottery draw efficiency, and reduces the occupation of system storage space.

[0105] In practical applications, the sign signature can be formed by encrypting the agreed data using an agreed encryption algorithm. No specific limitations are imposed on the agreed data and the agreed algorithm here. The predetermined algorithm can be the MD5 Message Digest Algorithm (Message Digest Algorithm MD5).

[0106] Specifically, the above step A3 may include:

[0107] Step A31: Extract the sign signature in each lottery draw request.

[0108] The sign signature can be stored at a fixed position in the lottery draw request according to a prior agreement. For example: at the end of the request, after the IP address, etc. In this way, the lottery draw system can directly obtain the sign signature from the fixed position of the lottery draw request, improving the acquisition efficiency of the sign signature.

[0109] Step A32: Match the extracted sign signature with the sign signature in the cache. If the match fails, execute step A33; if the match is successful, execute step X.

[0110] Among them, when the user corresponding to the lottery draw request is verified and passed in the lottery draw system, the lottery draw system returns the sign signature to the user and stores the returned sign signature in the cache. Here, the verification can refer to login verification or verification when operating a certain service in the operating system. No specific limitations are imposed on the specific type referred to by the verification here.

[0111] Step A33: Delete the corresponding lottery draw request.

[0112] The sign signature in the lottery draw request does not match the sign signature in the cache, indicating that the sign signature in the lottery draw request is forged. At this time, it is determined that the lottery draw request is not normally generated either, and the lottery draw request is deleted to prevent the lottery draw system from processing lottery draw requests forged by illegal users and ensure the safe and normal operation of the lottery draw system.

[0113] Step X: Delete the successfully matched sign signature in the cache.

[0114] The sign signature in the lottery draw request matches the sign signature in the cache, indicating that the lottery draw request is generated by a normal operation of a user who has passed verification before. There is no need to delete the request, but the successfully matched sign signature needs to be deleted to ensure that a lottery draw request with the same sign signature can only be processed once and prevent abuse after the sign signature is leaked, so as to ensure the safe and normal operation of the lottery draw system.

[0115] Step A4: Delete the lottery draw requests with completely duplicate lottery draw parameters among multiple lottery draw requests.

[0116] Sometimes, the same user may operate repeatedly many times in a short period of time. To avoid repeated processing of lottery draw requests sent repeatedly by the same user in a short period of time and ensure the fairness of the lottery draw, it is necessary to delete the lottery draw requests with completely duplicate lottery draw parameters among multiple lottery draw requests.

[0117] The lottery draw parameters here can refer to all parameters involved in the lottery draw request, such as: username, IP address, timestamp, etc.

[0118] It should be noted here that after deleting the lottery draw request in the above steps A1, A3, and A4, an error message can be sent to the user corresponding to the deleted lottery draw request. After deleting the lottery draw request in the above step A2, an error message can be sent to the user corresponding to the deleted lottery draw request, or a waiting message can be sent to the user corresponding to the deleted lottery draw request, which can be determined according to the specific processing situation of the deleted lottery draw request.

[0119] It should also be noted here that the above steps A1 - A4 can delete lottery draw requests among multiple received lottery draw requests synchronously or asynchronously. In asynchronous execution, steps A1, A3, and A4 can be executed first, and step A2 can be executed later to minimize the storage volume of lottery draw requests that are not processed temporarily and reduce the occupation of storage resources of the lottery draw system.

[0120] S34: Use a preset lottery draw algorithm to calculate the deleted multiple lottery draw requests to obtain the lottery draw result corresponding to each lottery draw request.

[0121] The specific implementation of step S34 here is the same as that of step S22 in the foregoing embodiment. For relevant descriptions, refer to the foregoing embodiment and will not be elaborated here.

[0122] S35: Determine the lottery result indicating a win as the winning result and store the winning result in the queue.

[0123] If the lottery result indicates no win, then send a notice of no win to the user corresponding to the lottery result.

[0124] If the lottery result indicates a win, then determine the lottery result as the winning result and continue to execute the subsequent steps.

[0125] The queue here is a queue created in the lottery system.

[0126] Compared with the original method of storing lottery requests in middleware outside the lottery system for sorting in the middleware, where lottery requests need to be transmitted over the network and are greatly affected by the network environment, which may cause a delay in the return of lottery requests to the lottery system and thus reduce the lottery efficiency. At this time, on the basis of simultaneously processing multiple lottery requests without the need for middleware sorting, the winning results in the lottery results corresponding to each lottery request are sorted in the queue of the lottery system, without the lottery system having to send or return the winning results over the network, and the number of winning results stored in the queue is less than the number of lottery requests, which can improve the lottery efficiency while also reducing the occupation of storage resources in the lottery system.

[0127] S36: Sort the winning results in the queue.

[0128] In addition to random sorting and specified sorting, the sorting among the winning results in the queue can also be performed according to the return time of the database.

[0129] Generally, in addition to storing the remaining number of prizes, the database also stores a winning flag correspondingly. Because after calculating the lottery result based on the lottery request, different lottery results represent a win or no win, and the winning flag representing a win in the lottery result is stored in the database.

[0130] The above step S35 may include:

[0131] Step B1: Send each lottery result to the database so that the database matches each lottery result with the winning flag.

[0132] Step B2: Obtain the winning result in each lottery result that matches the winning flag and its return time feedback by the database.

[0133] The server sends the lottery results calculated based on the lottery requests to the database. After the database receives the lottery results corresponding to multiple lottery requests, it simultaneously matches each lottery result with the winning identifiers stored therein. A lottery result that matches the winning identifier indicates a win. A lottery result that fails to match the winning identifier indicates no win.

[0134] The time when each lottery result obtains the matching result after being matched in the database may vary. When the database feeds back the winning results to the server, it also feeds back the time when the winning results are obtained, that is, the return time of the database. The winning results can be sorted in the queue based on the order of the return times of the winning results, so as to improve the fairness of the lottery. Moreover, the return time on which the sorting depends is data that the database itself will generate, and it is only carried along when the winning results are fed back. The acquisition of the sorting basis is relatively simple, and it can also improve the sorting efficiency, thereby improving the lottery efficiency.

[0135] The above step S36 may include:

[0136] Step B3: Sort the winning results in the queue according to the return time.

[0137] The earlier the return time is, the earlier the corresponding winning result is determined, and the more forward the position of the corresponding winning result in the sorting is. For example: the return time of winning result 1 is 2025.01.09 - 12:00:00, the return time of winning result 2 is 2025.01.09 - 12:00:01, and the return time of winning result 3 is 2025.01.09 - 12:00:02. The sorting of each winning result in the queue is winning result 1, winning result 2, and winning result 3.

[0138] S37: Lock the remaining number of awards for the lottery item corresponding to the lottery request in the database.

[0139] S38: Query in the database based on the current winning result in the sorting whether the locked remaining number of awards is 0. If so, execute S39; if not, execute S310.

[0140] In the database, generally, it does not only contain the remaining number of awards for one lottery item, but may contain the remaining number of awards corresponding to multiple lottery items respectively. For example: the database includes the remaining number of awards for the lottery item of clothing coupons and the remaining number of awards for the lottery item of home appliance full reduction coupons. Here, different lottery items can refer to different lottery items in the same lottery system, or lottery items in different lottery systems.

[0141] When the database queries the remaining number of awards for a certain winning result, the remaining number of awards for the lottery project to which the winning result belongs is locked. That is, other winning results belonging to the same lottery project as this winning result cannot query and modify the remaining number of awards in this lottery project at this time.

[0142] When specifically locking, for the mysql database, the database row lock of the update method of the mysql database can be used to only lock the data of the current operation row, without affecting the read and write operations of other data rows in the table.

[0143] For example, assume that the remaining number of awards for lottery project a is stored as 10 in the database, and the remaining number of awards for lottery project b is 5. And the lottery system generates winning result a1 and winning result a2 corresponding to lottery project a, and generates winning result b1 corresponding to lottery project b based on multiple lottery requests. For winning result a1, it can be queried in the remaining number of awards for lottery project a in the database, >0, to determine that the user corresponding to winning result a1 wins the lottery, and the remaining number of awards is reduced from 10 to 9. At the same time, for winning result b1, it can be queried in the remaining number of awards for lottery project b in the database, >0, to determine that the user corresponding to winning result b1 wins the lottery, and the remaining number of awards is reduced from 5 to 4. Next, for winning result a2, it can be queried in the remaining number of awards for lottery project a in the database, >0, to determine that the user corresponding to winning result a2 wins the lottery, and the remaining number of awards is reduced from 9 to 8.

[0144] S39: Send a non-winning notice to the users corresponding to the corresponding winning result and the subsequent winning results in the sorting.

[0145] For a certain lottery project, when a certain winning result in the queue of this lottery project queries 0 in the remaining number of awards for this lottery project in the database, it means that there are no more prizes available for this lottery project. At this time, directly send a non-winning notice to the users corresponding to this winning result and the subsequent winning results in the same queue.

[0146] S310: Send a winning notice to the user corresponding to the corresponding winning result, and subtract 1 from the remaining number of awards in the database, so that the next winning result in the corresponding sorting can query based on the remaining number of awards after subtraction 1, and generate and store the award-issuing order corresponding to the corresponding winning result, and release the resources of the server where the corresponding lottery request is located, and wait to process the award-issuing order when the resource utilization rate of the server is less than the preset threshold.

[0147] For a certain lottery project, when a winning result in the queue of the lottery project is found to be non-zero in the remaining number of prizes for the lottery project in the database, it indicates that there are still prizes available for the lottery project. At this time, a winning notice is sent to the user corresponding to the winning result. At the same time, the remaining number of prizes for the lottery project in the database is decreased by 1, a prize-awarding order corresponding to the winning result is generated, and the resources currently occupied by the winning result in the server are released, that is, the thread corresponding to the winning result is released.

[0148] The prize-awarding order here can be an order containing user information and winning information. After determining and notifying the user of winning, the prize-awarding operation may not be executed immediately. Because the prize-awarding operation also consumes server resources. The prize-awarding operation can be executed when there are remaining resources on the server in addition to processing lottery requests, which can leave sufficient resources for lottery requests and improve the lottery efficiency.

[0149] When the resource utilization rate of the server is less than a preset threshold, the prize-awarding order is processed.

[0150] The preset threshold here can be set according to actual requirements. The preset threshold can be the resource utilization rate of the server when it no longer processes lottery requests, that is, after the lottery requests are processed. That is to say, after the server finishes processing lottery requests, the prize-awarding orders are processed uniformly. The preset threshold can also be a fixed value. The specific value of the preset threshold is not limited here.

[0151] So far, the prize over-issuance control method provided by the embodiments of the present application has been fully described.

[0152] Based on the same inventive concept, as an implementation of the above method, the embodiments of the present application also provide a prize over-issuance control device.

[0153] Figure 4 For the structural schematic of the prize over-issuance control device in the embodiments of the present application Figure 1 , see Figure 4 As shown, the device may include: an acquisition module 41, a calculation module 42, a sorting module 43, a query module 44, a first notification module 45, and a second notification module 46.

[0154] The acquisition module 41 is used to acquire multiple lottery requests.

[0155] The calculation module 42 is used to calculate multiple lottery requests by using a preset lottery algorithm to obtain a lottery result corresponding to each lottery request.

[0156] The sorting module 43 is used to determine the lottery results indicating winning as winning results and sort the winning results.

[0157] The query module 44 is configured to sequentially query in the database whether the remaining number of prizes for each winning result in the sorting is 0; if so, it enters the first notification module 5, and if not, it enters the second notification module 46.

[0158] The first notification module 45 is configured to send a non-winning notification to the users corresponding to the corresponding winning result and the subsequent winning results in the sorting.

[0159] The second notification module 46 is configured to send a winning notification to the user corresponding to the corresponding winning result, and subtract 1 from the remaining number of prizes in the database, so that the next winning result in the corresponding winning result in the sorting queries based on the remaining number of prizes after subtraction.

[0160] Further, as a refinement and extension of the Figure 4 shown device, the embodiment of the present application also provides a prize over-issuance control device.

[0161] Figure 5 For the structural schematic of the prize over-issuance control device in the embodiment of the present application Figure 2 refer to Figure 5 shown in the figure, the device may include: a function closing module 51, an acquisition module 52, a request filtering module 53, a calculation module 54, a sorting module 55, a query module 56, a first notification module 57, and a second notification module 58.

[0162] The function closing module 51 is configured to close the deadlock detection function in the database.

[0163] The acquisition module 52 is configured to acquire a plurality of lottery requests.

[0164] The request filtering module 53 is configured to delete the lottery requests that meet the preset filtering conditions among the plurality of lottery requests, and obtain the plurality of lottery requests after deletion.

[0165] The request filtering module 53 includes: a first deletion unit 531, a second deletion unit 532, a third deletion unit 533, and a fourth deletion unit 534.

[0166] The first deletion unit 531 is configured to delete the lottery requests with duplicate Internet Protocol (IP) addresses within a preset time among the plurality of lottery requests.

[0167] The second deletion unit 532 is configured to delete the lottery requests that exceed the preset quantity within a unit time among the plurality of lottery requests.

[0168] The third deletion unit 533 is configured to delete the lottery requests with signatures that fail to pass verification among the plurality of lottery requests.

[0169] The third deletion unit 533 is specifically used to extract the sign signature in each lottery request; match the extracted sign signature with the sign signature in the cache. When the user corresponding to the lottery request passes the verification in the lottery system, the lottery system returns the sign signature to the user, stores the returned sign signature in the cache, and deletes the successfully matched sign signature in the cache when the matching is successful; if the matching fails, the corresponding lottery request is deleted.

[0170] The fourth deletion unit 534 is used to delete the lottery requests with exactly the same lottery parameters among multiple lottery requests.

[0171] The calculation module 54 is used to calculate the deleted multiple lottery requests by using a preset lottery algorithm to obtain the lottery result corresponding to each lottery request.

[0172] The sorting module 55 includes: a storage unit 551 and a sorting unit 552.

[0173] The storage unit 551 is used to determine the lottery result indicating winning as the winning result and store the winning result in a queue, and the queue is located in the lottery system.

[0174] The sorting unit 552 is used to sort the winning results in the queue.

[0175] When the database includes the winning identifier, the storage unit 551 is specifically used to send each lottery result to the database so that the database matches each lottery result with the winning identifier; obtain the winning result and its return time that match the winning identifier in each lottery result fed back by the database.

[0176] The sorting unit 552 is specifically used to sort the winning results in the queue according to the return time.

[0177] When the database also includes the remaining number of awards of other lottery items except the lottery item corresponding to the lottery request, the query module 56 includes: a locking unit 561 and a query unit 562.

[0178] The locking unit 561 is used to lock the remaining number of awards of the lottery item corresponding to the lottery request in the database.

[0179] The query unit 562 is used to query whether the locked remaining number of awards is 0 in the database based on the current winning result in the sorting. If so, it enters the first notification module 57, and if not, it enters the second notification module 58.

[0180] The first notification module 57 is used to send a non-winning notification to the users corresponding to the corresponding winning result and the subsequent winning results in the sorting.

[0181] The second notification module 58 is configured to send a winning notification to the user corresponding to the corresponding winning result, and decrement the remaining number of awards in the database by 1, so that the next winning result in the sorting queries based on the remaining number of awards after the decrement.

[0182] The second notification module 58 is further configured to generate and store a prize-awarding order corresponding to the corresponding winning result, and release the resources of the server where the corresponding lottery request is located, and wait to process the prize-awarding order when the resource utilization rate of the server is less than a preset threshold.

[0183] It should be noted here that the description of the above device embodiments is similar to the description of the above method embodiments and has similar beneficial effects to the method embodiments. For the technical details not disclosed in the device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0184] Based on the same inventive concept, an embodiment of the present application further provides an electronic device.

[0185] Figure 6 As shown in the structural schematic diagram of the electronic device in the embodiment of the present application, see Figure 6 shown, the electronic device may include: a processor 61, a memory 62, and a bus 63. The processor 61 and the memory 62 communicate with each other through the bus 63. The processor 61 is configured to call program instructions in the memory 62 to execute the methods in the above one or more embodiments.

[0186] It should be noted here that the description of the above electronic device embodiments is similar to the description of the above method embodiments and has similar beneficial effects to the method embodiments. For the technical details not disclosed in the electronic device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0187] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium. The computer-readable storage medium may include: a stored program that controls the device where the storage medium is located to execute the methods in the above one or more embodiments when the program runs.

[0188] It should be noted here that the description of the above computer-readable storage medium embodiments is similar to the description of the above method embodiments and has similar beneficial effects to the method embodiments. For the technical details not disclosed in the computer-readable storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0189] Based on the same inventive concept, an embodiment of the present application further provides a computer program product. The computer program product includes a computer program or instructions that, when executed by the device where they are located, implement the methods in the above one or more embodiments.

[0190] It should be noted here that the description of the above embodiments of the computer program product is similar to the description of the above method embodiments and has beneficial effects similar to those of the method embodiments. For the technical details not disclosed in the embodiments of the computer program product of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0191] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, and all of them should be covered by the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claimed rights.

Claims

1. A method for controlling over-issuance of prizes, characterized in that: The method comprises: Get multiple lottery requests; Calculate the multiple lottery requests using a preset lottery algorithm to obtain a lottery result corresponding to each lottery request; Determine the lottery result indicating a winning prize as a winning result, and sort the winning results; Check the database for each winning result in the sorting to see if the number of remaining prizes is 0; If yes, a non-winning notification is sent to the corresponding winning result and the user corresponding to the subsequent winning result in the ranking; If not, a winning notification is sent to the user corresponding to the corresponding winning result, and the number of remaining prizes in the database is reduced by 1, so that the next winning result of the corresponding winning result in the sorting is queried based on the remaining number of prizes after reducing 1.

2. The method according to claim 1, characterized in that Before using a preset lottery algorithm to calculate the multiple lottery requests, the method further includes: Deleting the lottery requests that meet the preset filtering condition from the multiple lottery requests to obtain multiple lottery requests after deletion; The using a preset lottery algorithm to calculate the multiple lottery requests includes: The preset lottery algorithm is used to calculate the multiple lottery requests after deletion.

3. The method according to claim 2, characterized in that The deleting of the lottery requests that meet the preset filtering condition from the multiple lottery requests includes at least one of the following four items: Deleting the lottery draw requests with duplicate Internet Protocol IP addresses within a preset time from among the multiple lottery draw requests; Deleting the lottery requests that exceed a preset number within a unit time among the multiple lottery requests; Deleting the lottery requests whose signatures have not passed the verification among the multiple lottery requests; The lottery requests having completely repeated lottery parameters among the multiple lottery requests are deleted.

4. The method according to claim 3, characterized in that The deleting of the lottery requests whose signatures have not passed the verification among the multiple lottery requests comprises: Extract the sign signature from each lottery request; Match the extracted sign signature with the sign signature in the cache, wherein, when the user corresponding to the lottery request is verified in the lottery system, the lottery system returns the sign signature to the user, and stores the returned sign signature in the cache, and deletes the successfully matched sign signature in the cache if the match is successful; If the match fails, the corresponding lottery request will be deleted.

5. The method according to any one of claims 1 to 4, characterized in that The step of sorting the winning results comprises: The winning result is stored in a queue, and the queue is located in a lottery system; The winning results are sorted in the queue.

6. The method according to claim 5, characterized in that The database includes a prize-winning identifier; and determining the lottery result indicating a prize-winning result as a prize-winning result includes: Sending each lottery result to the database so that the database matches each lottery result with a winning identifier; Obtaining the winning result and return time of each lottery result fed back by the database that matches the winning identifier; The step of sorting the winning results in the queue includes: The winning results are sorted in the queue according to the return time.

7. The method according to any one of claims 1 to 4, characterized in that Before obtaining a plurality of lottery requests, the method further includes: Disable the deadlock detection function in the database.

8. The method according to any one of claims 1 to 4, characterized in that The database also includes the number of remaining prizes for other lottery items except the lottery item corresponding to the lottery request; the querying of the database for each winning result in the sorting to see whether the number of remaining prizes is 0 includes: Lock the remaining number of prizes for the lottery item corresponding to the lottery request in the database; Based on the current winning result in the sorting, the database is queried to see whether the number of remaining locked prizes is 0.

9. The method according to any one of claims 1 to 4, characterized in that After querying the database for each winning result in the sorting to see whether the number of remaining prizes is 0, the method further includes: If not, a prize distribution order corresponding to the corresponding winning result is generated and stored, and the resources of the server where the corresponding lottery request is located are released, so as to process the prize distribution order when the resource utilization rate of the server is less than a preset threshold.

10. A device for controlling the over-issuance of prizes, characterized in that: The device comprises: The acquisition module is used to obtain multiple lottery requests; A calculation module, used to calculate the multiple lottery requests using a preset lottery algorithm to obtain a lottery result corresponding to each lottery request; A sorting module, used to determine the lottery result indicating a winning as a winning result, and sort the winning results; A query module, used to query the database for each winning result in the ranking in turn to see whether the number of remaining prizes is 0; if so, enter the first notification module, if not, enter the second notification module; A first notification module, used to send a non-winning notification to the user corresponding to the corresponding winning result and the subsequent winning results in the ranking; The second notification module is used to send a winning notification to the user corresponding to the corresponding winning result, and reduce the number of remaining prizes in the database by 1, so that the next winning result of the corresponding winning result in the sorting can be queried based on the remaining number of prizes after reducing 1.

Images