Content reward issuing method and device, storage medium and terminal

Abstract

The embodiment of the invention discloses a content reward issuing method and device, a storage medium and a terminal. In response to a prize issuing request for the target award, the prize issuing request is analyzed to obtain prize issuing configuration information corresponding to the target award, and the prize issuing configuration information is obtained through configuration in advance according to an award issuing demand; determining a target prize issuing strategy corresponding to the prize issuing request according to the prize issuing configuration information; and issuing the target award according to the target award issuing strategy, and obtaining award issuing result data corresponding to the target award. In the embodiment of the specification, various types of reward issuing strategies are comprehensively combed and pre-configured, when the reward issuing event is triggered, the system can automatically match and call the pre-configured corresponding reward issuing strategy, and then reward issuing is realized according to the reward issuing strategy. The reward issuing mode not only improves reusability of reward issuing logic, but also remarkably reduces development cost.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technology, and in particular, to a method, apparatus, storage medium, and terminal for content reward distribution. Background Art

[0002] Nowadays, the launch of various online activities has become an important means to attract user participation, improve platform activity, and user stickiness. These activities often cleverly incorporate various reward mechanisms to stimulate users' interest and participation. Currently, many traditional reward distribution schemes still adopt the independent development method, that is, for each activity or each type of reward, the development, testing, and deployment of the award function need to start from scratch, resulting in a large amount of time and resources consumed for each award. In addition, once problems occur during the award process, such as delays, missed awards, or duplicate awards, cumbersome retry and reconciliation work are required. This repetitive development process is not only inefficient but also poses potential risks in terms of stability and security. Summary of the Invention

[0003] The embodiments of this specification provide a method, apparatus, storage medium, and terminal for content reward distribution, which can solve the technical problem of low development efficiency of reward distribution gameplay in related technologies.

[0004] In a first aspect, the embodiments of this specification provide a method for content reward distribution, the method includes:

[0005] In response to an award request for a target reward, parse the award request to obtain the award configuration information corresponding to the target reward, and the award configuration information is pre-configured according to the award requirements of the reward;

[0006] Determine the target award strategy corresponding to the award request according to the award configuration information;

[0007] Distribute the target reward according to the target award strategy, and obtain the award result data corresponding to the target reward.

[0008] In a possible implementation manner, the award configuration information at least includes award type, award content configuration, award process, award channel, failure handling process, and associated data model.

[0009] In a possible implementation, when the above reward type is the batch award type, the above-mentioned target reward is distributed according to the above-mentioned target award strategy, and the award result data corresponding to the above-mentioned target reward is obtained, including: dividing all the pending award information in the above-mentioned award request into at least one pending award batch, and marking each pending award batch as the initialization state, where each pending award batch includes at least two pieces of pending award information; performing concurrent award distribution processing on each pending award batch through the batch award component, and marking each pending award batch as the award success state or the award failure state according to the award result; receiving the status data of each pending award batch returned by the above-mentioned batch award component.

[0010] In a possible implementation, the above-mentioned performing concurrent award distribution processing on each pending award batch through the batch award component includes: through the batch award component, according to the user identification corresponding to the pending award information in each pending award batch, sharding the pending award information corresponding to the user identification belonging to the same award service into the same user award batch, and invoking the corresponding award service for each user award batch.

[0011] In a possible implementation, when the above reward type is the single award type, the above-mentioned target reward is distributed according to the above-mentioned target award strategy, and the award result data corresponding to the above-mentioned target reward is obtained, including: querying whether there is a corresponding issued record for the above-mentioned target reward; if there is the above-mentioned issued record, obtaining the award result data corresponding to the above-mentioned target reward according to the above-mentioned issued record; if there is no the above-mentioned issued record, distributing the above-mentioned target reward according to the above-mentioned target award strategy, and obtaining the award result data corresponding to the above-mentioned target reward.

[0012] In a possible implementation, after the above-mentioned distributing the above-mentioned target reward according to the above-mentioned target award strategy, it further includes: when the above-mentioned target reward is successfully distributed, generating unique redemption data corresponding to each redeeming user according to the prize identification of the above-mentioned target reward, the user identification of the redeeming user, and the idempotency identification of the above-mentioned award request; storing each unique redemption data as the award result data corresponding to the above-mentioned target reward.

[0013] In a possible implementation, when the above failure handling process is an asynchronous retry process, after the above-mentioned distributing the above-mentioned target reward according to the above-mentioned target award strategy, it further includes: when the above-mentioned target reward fails to be awarded, triggering a retry award process for the above-mentioned target reward; when the number of retries exceeds the preset number and the above-mentioned target reward fails to be awarded, determining the award failure result corresponding to the above-mentioned target reward.

[0014] In a possible implementation, when the above failure handling process is a quick failure process, after the above target reward is issued according to the above target award policy, it further includes: when the issuance of the above target reward fails, determining the award failure result corresponding to the above target reward.

[0015] In a second aspect, an embodiment of this specification provides a content reward issuance device, and the device includes:

[0016] A request acquisition module, configured to, in response to a reward issuance request for a target reward, parse the above reward issuance request to obtain the award configuration information corresponding to the above target reward, and the above award configuration information is pre-configured according to the reward issuance requirements;

[0017] A policy parsing module, configured to determine the target award policy corresponding to the above reward issuance request according to the above award configuration information;

[0018] A reward issuance module, configured to issue the above target reward according to the above target award policy and obtain the award result data corresponding to the above target reward.

[0019] In a third aspect, an embodiment of this specification provides a computer program product including instructions, which, when the computer program product runs on a computer or a processor, causes the computer or the processor to execute the steps of the above method.

[0020] In a fourth aspect, an embodiment of this specification provides a computer storage medium, and the above computer storage medium stores multiple instructions, and the above instructions are suitable for being loaded and executed by a processor to execute the steps of the above method.

[0021] In a fifth aspect, an embodiment of this specification provides a terminal, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and the above computer program is suitable for being loaded and executed by the processor to execute the steps of the above method.

[0022] The beneficial effects brought by the technical solutions provided by some embodiments of this specification at least include:

[0023] An embodiment of this specification provides a method for distributing content rewards. In response to a reward distribution request for a target reward, the reward distribution request is parsed to obtain the reward distribution configuration information corresponding to the target reward, where the reward distribution configuration information is pre-configured according to the reward distribution requirements; the target reward distribution strategy corresponding to the reward distribution request is determined according to the reward distribution configuration information; the target reward is distributed according to the target reward distribution strategy, and the reward distribution result data corresponding to the target reward is obtained. In the embodiment of this specification, various types of reward distribution strategies are comprehensively sorted out and pre-configured. When a reward distribution event is triggered, the system can automatically match and call the pre-configured corresponding reward distribution strategy, and then implement the reward distribution according to the reward distribution strategy. Such a reward distribution method not only improves the reusability of the reward distribution logic, but also helps to improve the flexibility and maintainability of the reward system, and significantly reduces the development cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of this specification. For those skilled in the art, without creative efforts, other drawings can be obtained according to these drawings.

[0025] Figure 1 An exemplary system architecture diagram of a method for distributing content rewards provided by an embodiment of this specification;

[0026] Figure 2 A flowchart of a method for distributing content rewards provided by an embodiment of this specification;

[0027] Figure 3 An implementation diagram of content reward configuration and distribution provided by an embodiment of this specification;

[0028] Figure 4 A flowchart of a method for distributing content rewards provided by an embodiment of this specification;

[0029] Figure 5 A logic block diagram of a batch reward distribution process provided by an embodiment of this specification;

[0030] Figure 6 A logic block diagram of a single reward distribution process provided by an embodiment of this specification;

[0031] Figure 7 A logic block diagram of an asynchronous retry process provided by an embodiment of this specification;

[0032] Figure 8 A logic block diagram of a fast failure process provided by an embodiment of this specification;

[0033] Figure 9 It is a structural block diagram of a content reward distribution device provided by an embodiment of this specification;

[0034] Figure 10 It is a schematic structural diagram of a terminal provided by an embodiment of this specification. Specific implementation manners

[0035] To make the features and advantages of the embodiments of this specification more obvious and understandable, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope protected by the embodiments of this specification.

[0036] When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all the implementation manners consistent with the embodiments of this specification. On the contrary, they are only examples of devices and methods consistent with some aspects of the embodiments of this specification as detailed in the appended claims. And in the description of the embodiments of this specification, unless otherwise specified, " / " means "or". For example, A / B can represent A or B. The "and / or" in the text is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this specification, "a plurality of" means two or more than two.

[0037] Hereinafter, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features.

[0038] In the operation of Internet platforms, various online activities often use reward mechanisms to attract user participation and enhance user activity. However, in current technical practices, many traditional reward distribution schemes still adopt an independent development approach, that is, for each activity, the development, testing, and deployment of the award function need to start from scratch. This requires rewriting similar logic codes for each activity, which not only greatly increases the workload of the technical team but also leads to serious waste of resources. In addition to the waste of development resources, separate reconciliation mechanisms need to be established for the rewards of these activities, resulting in higher operating costs. Moreover, due to the fact that each development is completely new, bugs found and fixed in previous activities, such as delays, missed awards, or duplicate awards, may reappear in the new development, thus affecting the overall stability of the system. Therefore, the embodiments of this specification provide a content reward distribution method to solve the technical problem of low development efficiency of the above reward distribution methods.

[0039] Please refer to Figure 1 , Figure 1 which is an exemplary system architecture diagram of a content reward distribution method provided by the embodiments of this specification.

[0040] As Figure 1 shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 is used to provide a medium for the communication link between the terminal 101 and the server 103. The network 102 may include various types of wired communication links or wireless communication links. For example, wired communication links include optical fibers, twisted pairs, or coaxial cables, and wireless communication links include Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0041] The terminal 101 can interact with the server 103 through the network 102 to receive messages from the server 103 or send messages to the server 103. Alternatively, the terminal 101 can interact with the server 103 through the network 102 to receive messages or data sent by other users to the server 103. The terminal 101 can be hardware or software. When the terminal 101 is hardware, it can be various electronic devices, including but not limited to smartphones, tablets, laptop portable computers, and desktop computers, etc. When the terminal 101 is software, it can be installed in the above-listed electronic devices, which can be implemented as multiple software or software modules (for example, used to provide distributed services), or can be implemented as a single software or software module, and no specific limitation is made here.

[0042] In the embodiments of this specification, when a prize needs to be awarded, the terminal 101 first responds to the prize-awarding request for the target prize, parses the prize-awarding request to obtain the prize-awarding configuration information corresponding to the target prize, and the prize-awarding configuration information is pre-configured according to the awarding requirements of the prize. Then, the terminal 101 determines the target prize-awarding strategy corresponding to the prize-awarding request according to the prize-awarding configuration information. Based on the pulled target prize-awarding strategy, the terminal 101 can further award the target prize according to the target prize-awarding strategy and obtain the prize-awarding result data corresponding to the target prize.

[0043] The server 103 may be a business server that provides various services. It should be noted that the server 103 may be hardware or software. When the server 103 is hardware, it can be implemented as a distributed server cluster composed of multiple servers or as a single server. When the server 103 is software, it can be implemented as multiple software or software modules (such as those used to provide distributed services) or as a single software or software module, and specific limitations are not made here.

[0044] Alternatively, the system architecture may not include the server 103. In other words, the server 103 may be an optional device in the embodiments of this specification, that is, the method provided in the embodiments of this specification can be applied to a system structure that only includes the terminal 101, and specific limitations are not made in the embodiments of this specification.

[0045] It should be understood that Figure 1 the numbers of terminals, networks, and servers in

[0046] Please refer to Figure 2 Figure 2 which is a schematic flowchart of a method for awarding content prizes provided in the embodiments of this specification. The execution subject of the embodiments of this specification may be the terminal that executes the content prize awarding, or the processor in the terminal that executes the content prize awarding method, or the content prize awarding service in the terminal that executes the content prize awarding method. For the convenience of description, the following takes the execution subject as the processor in the terminal as an example to introduce the specific execution process of the content prize awarding method.

[0047] As Figure 2 shown, the content prize awarding method may at least include:

[0048] S202. Respond to the prize-awarding request for the target prize, parse the prize-awarding request to obtain the prize-awarding configuration information corresponding to the target prize, and the prize-awarding configuration information is pre-configured according to the awarding requirements of the prize.

[0049] ​Optionally, although the specific activity themes and forms vary when most rewards are issued, there are certain characteristics in the reward issuance logic. For example, the core logic of reward issuance usually includes the following steps: First, the triggering of the reward issuance request, which involves the parsing of activity rules and the tracking response of user behavior; after the issuance request is triggered, the verification of reward eligibility is often carried out, including but not limited to the execution of rules such as user identity verification, participation times limit, and reward collection conditions; if the conditions for issuing the reward are met, the reward can be issued, and this process is mainly related to the configuration of the reward itself; according to the issuance result, corresponding records, retries, and reconciliations are also required to ensure the accuracy and traceability of the reward issuance result. It can be found that the execution logic of these steps has a certain universality, which means that the issuance logic can still be reused even in different activity scenarios and different reward types, and only the specific parameters and rules related to the activity and reward need to be adjusted adaptively.

[0050] Then, in the embodiments of this specification, for the issuance requirements of each reward, the information of various rewards can be pre-configured. The award issuance configuration information may include but is not limited to that the award issuance configuration information at least includes reward type, reward content configuration, award issuance process, award issuance channel, failure handling process, and associated data model, so that when a reward needs to be issued, the corresponding award issuance strategy can be directly reused according to the reward configuration information, reducing the development volume of the reward system.

[0051] Specifically, when performing reward configuration, first, relevant data models need to be constructed, using dedicated databases, data tables, and data items to store various data information in the award issuance process. In the specific reward configuration, for each reward type, corresponding issuance logics can be designed, including but not limited to reward content configuration (such as gold coins, items, experience values, etc.), award issuance process (such as issuance form, quantity, etc.), award issuance channel (such as API interface, service channel, etc.), and failure handling process (such as retry or not retry, etc.). These logics can be encapsulated into independent modules for subsequent reuse and management. In a possible actual development, an award configuration class: AwardConfig can be used to manage the above configuration information, where the actual configurations of various rewards are stored through the configuration attribute of the reward. Each type of reward corresponds to an award configuration class. For example, when the type of the reward is Tour, its configuration is of the type TourAwardConfig. When used, the type of the configuration can be directly converted according to the reward type, thus facilitating the operation of the reward configuration.

[0052] In addition, considering the use of this information in actual scenarios, a unique transaction identifier and a transaction sub-identifier can be applied for before configuring the rewards to isolate transactions. For example, when configuring rewards for a live broadcast event A, the unique transaction identifier corresponding to the live broadcast event A can be obtained first, so as to isolate all the award data generated in the live broadcast event A from other event transactions. Only one predefined reward type is specified for each reward. The fields of different type configuration contents contain the agreements and requirements corresponding to this reward. Each reward also specifies an awarding strategy and a distribution channel that supports this reward type. Similarly, in a possible actual development, the awarding strategy corresponding to each reward type can be specified in the awarding strategy configuration class: AwardStrategy, and the distribution channel corresponding to each reward type can be specified in the distribution channel configuration class: AwardChannel. When configuring rewards, the corresponding awarding strategy and channel can be directly specified according to the reward type, and the pre-configured logic process can be called when triggering the award request. In this way, when a new reward type needs to be added or the existing reward strategy needs to be adjusted, there is no need to develop from scratch at the code level, and only the corresponding parameters need to be adjusted in the configuration file, which greatly improves the maintainability and scalability of the system.

[0053] Optionally, when actually issuing a target reward to a user, first in response to the triggered award request, the award configuration information corresponding to the target reward can be obtained by parsing the award request. From the award configuration information, all the subsequent processes that need to be executed can be determined. It should be noted that the forms of the above transactions for configuring rewards can be diverse, including but not limited to live broadcasts, time-limited activities, etc., and the forms of target rewards are also diverse, including but not limited to points, coupons, cash red envelopes, physical prizes, etc. The specific content and form of the target rewards are not limited in the embodiments of this specification.

[0054] S204. Determine the target awarding strategy corresponding to the award request according to the award configuration information.

[0055] S206. Issue the target reward according to the target awarding strategy and obtain the award result data corresponding to the target reward.

[0056] Optionally, after obtaining the award configuration information of the reward to be issued this time through the above award request, the target awarding strategy can be further determined. In the target awarding strategy, all the processes that need to be executed during awarding are included, so the target reward can be issued according to the target awarding strategy. For details, please refer to Figure 3 , Figure 3 which is a schematic diagram of the implementation of a content reward configuration and issuance provided by the embodiments of this specification. As Figure 3As shown in the figure, the embodiments of this specification reflect the reward configuration process through the logic block diagram in the "configuration domain" and the reward distribution process through the logic block diagram in the "user domain". In the "configuration domain", the configurator configures various information corresponding to the target reward through the reward system according to the demand information of this time, and stores the configuration information after the configuration is completed. In the "user domain", based on some operations of users, activity operators or internal configurators, etc., a reward distribution request for the target reward is triggered. By parsing the information in the reward distribution request, the reward distribution configuration information corresponding to the target reward can be obtained in the reward system. At this time, the target reward can be distributed according to the queried reward distribution configuration information.

[0057] Furthermore, when distributing the reward, the reward distribution result data corresponding to the target reward in the downstream can be received asynchronously and regularly or obtained actively, so as to record, handle exceptions and other subsequent processes according to the reward distribution result data. By pre-configuring and reusing various types of reward distribution strategies in this way, it helps to build a reusable and extensible general reward distribution platform, realize the modularization and standardization of the reward distribution logic, not only improves the flexibility and maintainability of the reward system, but also significantly reduces the development cost.

[0058] In the embodiments of this specification, a content reward distribution method is provided. In response to a reward distribution request for a target reward, the reward distribution request is parsed to obtain the reward distribution configuration information corresponding to the target reward, and the reward distribution configuration information is pre-configured according to the reward distribution requirements; according to the reward distribution configuration information, the target reward distribution strategy corresponding to the reward distribution request is determined; the target reward is distributed according to the target reward distribution strategy, and the reward distribution result data corresponding to the target reward is obtained. In the embodiments of this specification, various types of reward distribution strategies are comprehensively sorted out and pre-configured. When a reward distribution event is triggered, the system can automatically match and call the pre-configured corresponding reward distribution strategy, and then realize the reward distribution according to the reward distribution strategy. Such a reward distribution method not only improves the reusability of the reward distribution logic, but also is conducive to improving the flexibility and maintainability of the reward system, and significantly reduces the development cost.

[0059] Please refer to Figure 4 , Figure 4 which is a schematic flowchart of a content reward distribution method provided by the embodiments of this specification.

[0060] As Figure 4 shown, the content reward distribution method can at least include:

[0061] S402. In response to a reward distribution request for a target reward, the reward distribution request is parsed to obtain the reward distribution configuration information corresponding to the target reward, and the reward distribution configuration information is pre-configured according to the reward distribution requirements.

[0062] S404. Determine the target awarding strategy corresponding to the awarding request according to the awarding configuration information.

[0063] Regarding steps S402 - S404, please refer to the detailed description in steps S202 - S204, which will not be elaborated here.

[0064] S406. When the reward type is the batch awarding type, divide all the to - be - awarded reward information in the awarding request into at least one to - be - awarded batch, and mark each to - be - awarded batch as the initialization state. Each to - be - awarded batch includes at least two pieces of to - be - awarded reward information.

[0065] Optionally, common reward types can be at least divided into two types. One is the batch awarding type, generally triggered by internal staff and used to award rewards to multiple users. The other is the single - awarding type, generally triggered by internal staff or the user's own behavior. In batch awarding, due to the large number of awards to be issued, the concurrent awarding method can be adopted during processing.

[0066] Specifically, please refer to Figure 5 , Figure 5 which is the logic block diagram of a batch awarding process provided by the embodiments of this specification. As Figure 5 shown, when processing a large number of concurrent awarding requirements, the reward information can be stored concurrently first, and all the to - be - awarded reward information in the awarding request can be divided into multiple to - be - awarded batches. Each to - be - awarded batch includes at least two pieces of to - be - awarded reward information (in the embodiments of this specification, 500 pieces of to - be - awarded reward information per batch are taken as an example), and these to - be - awarded batches are marked as the initialization state to indicate the "to - be - awarded" state of these batches. It should be noted that the number of to - be - awarded batches divided and the number of to - be - awarded reward information obtained in a single batch can both be configured according to the actual scenario requirements, and the embodiments of this specification do not limit this.

[0067] S408. Perform concurrent awarding processing on each to - be - awarded batch through the batch awarding component, and mark each to - be - awarded batch as the awarding success state or the awarding failure state according to the awarding result; receive the status data of each to - be - awarded batch returned by the batch awarding component.

[0068] Furthermore, please continue to refer to Figure 5, when specifically processing these batches to be awarded, these batches to be awarded can be asynchronously sent to the batch awarding component through a message sending component (such as msgbroker), so that the batch awarding component performs concurrent awarding processing on each batch to be awarded. The batch awarding component modifies the "initialization state" of each batch to be awarded to the "awarding state" through the received message. If the state modification is successful, it means that the current batch to be awarded can be normally processed subsequently (that is, it normally enters the "awarding" state and waits for subsequent awarding); if the state modification fails, it means that some problems may have occurred in the current batch to be awarded, resulting in the inability to support subsequent normal awarding processing.

[0069] In a feasible implementation manner, for the case where the modification of the "awarding state" fails as described above, a retry can be attempted first. If it still fails after reaching the maximum number of retries, an alarm is issued for the relevant situation. Among them, the maximum number of retries can be 3 times, 5 times, 7 times, etc., and the embodiments of this specification do not limit this.

[0070] Furthermore, the batch awarding component continues to perform awarding processing on the batches to be awarded in the "awarding state". Considering that the awarding system uses different awarding services for different types of users, the batch awarding component will slice the pending award information corresponding to the user identifier (such as userId) in each batch to be awarded into the same user awarding batch (such as userId 1 batch, userId 2 batch... userId n batch) according to the user identifier, and call the corresponding awarding service for each user awarding batch. At this time, the batch awarding component will regularly and asynchronously attempt to change the "awarding state" of the batch to be awarded to the "awarding success state". If the modification is successful, it means that all the pending award information in this batch has been successfully issued; if it fails, it can be retried until it still fails after reaching the maximum number of retries, and then the "awarding state" of the batch to be awarded is changed to the "awarding failure state", so that the timing task for processing failed awards can retrieve the batches with awarding failures based on the "awarding failure state". For the upstream reward awarding end, it will receive the status data of each batch to be awarded returned by the batch awarding component to know the current awarding situation.

[0071] Or,

[0072] S410. When the reward type is a single-award type, query whether there is a corresponding issued record for the target reward.

[0073] Optionally, please refer to Figure 6 , Figure 6 which is a logic block diagram of a single-award process provided by the embodiments of this specification. As Figure 6As shown, when the reward type is a single-time reward type, the issued records of the target reward related to the current transaction are first queried. The issued records include the unique identification information for identifying the issued status of the target reward. Therefore, by querying the issued records, errors such as duplicate awarding and duplicate claiming can be avoided.

[0074] S412. If there are issued records, obtain the awarding result data corresponding to the target reward according to the issued records; if there are no issued records, issue the target reward according to the target awarding strategy.

[0075] Please continue to refer to Figure 6 , if the issued records corresponding to the target reward can be found, an error code will be triggered, and at this time, directly return the corresponding awarding result data; if there are no issued records, the target reward can continue to be issued according to the target awarding strategy, and the awarding result data is returned according to the awarding situation.

[0076] S414. When the target reward is successfully issued, generate the unique claiming data corresponding to each claiming user according to the prize identification of the target reward, the user identification of the claiming user, and the idempotency identification of the awarding request; store each unique claiming data as the awarding result data corresponding to the target reward.

[0077] Optionally, when the target reward is successfully issued, in order to prevent subsequent duplicate awarding and duplicate claiming, the unique claiming data corresponding to each claiming user will be generated according to the prize identification of the target reward, the user identification of the claiming user, and the idempotency identification of the awarding request when recording the awarding. Idempotent operations can make the impacts generated by any number of executions the same as those of a single execution, thus ensuring the uniqueness of the reward issuance. For the unique claiming data, it can be stored as the awarding result data corresponding to the target reward. The awarding result data can be actively returned by the downstream to the upstream or the upstream can actively request the downstream in the form of an awarding flow.

[0078] S416. When the failure handling process is an asynchronous retry process, when the target reward awarding fails, trigger the retry awarding process for the target reward; when the number of retries exceeds the preset number and the target reward awarding fails, determine the awarding failure result corresponding to the target reward.

[0079] Optionally, to increase the stability and fault tolerance of the awarding process, some failed awarding tasks can be retried in scenarios that support retries. As can be known from the above embodiments, both the awarding process and the retry process need to ensure the uniqueness of the issued award records, which means that only downstream scenarios that support idempotent operations can perform asynchronous retry operations. Then, in such retryable scenarios, the failure handling process of the reward will be configured as an asynchronous retry process.

[0080] Please refer toFigure 7 , Figure 7 is a logic block diagram of an asynchronous retry process provided by an embodiment of this specification. As Figure 7 shown, if the failure handling process is an asynchronous retry process, then when the target reward awarding fails, a retry awarding process is triggered for the target reward. Specifically, starting from the first awarding attempt, query the reward configuration and obtain the reward channel, and save the current initial user reward transaction. If it fails or is abnormal at this time, it means that the subsequent awarding process cannot be carried out, so just directly return the awarding failure information; if the initial transaction is successfully saved, then officially call the downstream interface to send the reward. If it fails at this time, continue to try to send a retry message to re-award (re-send service). If it is successful at this time, modify the corresponding awarding status (including the awarding transaction and the downstream awarding transaction ID); if the retry reaches the maximum number of times and still fails, record the current log information for subsequent compensation or other processing. If the retry is successful, modify the corresponding awarding status; in the case of successful awarding, if the awarding status modification is successful, directly return the user reward data. If the awarding status modification fails, it is also possible to try multiple retries until it still fails after the maximum number of retries; if the status modification still fails, it is also possible to record the current log information for subsequent compensation or other processing. In the whole process, if the upstream needs to obtain specific transaction or specific field data of the downstream, it can re-call the query transaction interface between the upstream and downstream to obtain the updated downstream transaction when the downstream asynchronously retries and updates the transaction.

[0081] The above-mentioned maximum number of retries can be configured according to actual scenario requirements, and the embodiments of this specification do not limit this.

[0082] It should be noted that if the current awarding type is a batch awarding type, the asynchronous retry method can also be in the form of batch processing. When batch processing these failed awarding tasks, multiple failed pending award information are obtained in each batch through an asynchronous timed task (10 are used as an example in the embodiments of this specification). According to their corresponding shard information, re-obtain the award request information, re-query the reward configuration, and further determine whether the current awarding downstream supports batch awarding. If the downstream supports batch awarding, directly call the downstream batch awarding service to perform the awarding service for this failed batch. But if the downstream does not support batch awarding, it is necessary to complete the pending award information in this failed batch one by one concurrently. Similarly, if the number of failures reaches the specified maximum number, the awarding task is considered to have failed. In another case, if the current awarding type is a single awarding type, the asynchronous retry method can be retried according to the original processing logic, which will not be elaborated here.

[0083] S418. When the failure handling process is a quick failure process, when the target reward awarding fails, determine the awarding failure result corresponding to the target reward.

[0084] Optionally, refer to Figure 8 , Figure 8 which is a logic block diagram of a fast failure process provided in an embodiment of this specification. As Figure 8 shown, if the downstream does not support idempotent operations, it means that the downstream cannot support asynchronous retry operations. In this case, the failure handling process of the reward is generally configured as a fast failure process, that is, when the target reward fails to be awarded, directly determine the award failure result corresponding to the target reward, without the need to retry. Other steps in the processing process are the same as those in the above asynchronous retry, so they will not be elaborated here.

[0085] In an embodiment of this specification, a method for distributing content rewards is provided. When the reward type is a batch award type, all the to-be-awarded reward information in the award request is divided into at least one to-be-awarded batch, and each to-be-awarded batch is marked as an initialization state. Each to-be-awarded batch includes at least two pieces of to-be-awarded reward information. The batch award component performs concurrent award processing on each to-be-awarded batch, and marks each to-be-awarded batch as an award success state or an award failure state according to the award result, efficiently and quickly processing a large number of concurrent award requirements. When the reward type is a single award type, query whether there is a corresponding awarded record for the target reward. If there is an awarded record, obtain the award result data corresponding to the target reward according to the awarded record. If there is no awarded record, distribute the target reward according to the target award strategy; when the target reward is successfully awarded, generate unique award data for each award-receiving user according to the prize identifier of the target reward, the user identifier of the award-receiving user, and the idempotent identifier of the award request; store each unique award data as the award result data corresponding to the target reward to prevent duplicate awarding and duplicate receiving of awards, thereby ensuring the uniqueness of the reward distribution. When the failure handling process is an asynchronous retry process, when the target reward fails to be awarded, trigger a retry award process for the target reward. When the number of retries exceeds the preset number and the target reward still fails to be awarded, determine the award failure result corresponding to the target reward; when the failure handling process is a fast failure process, when the target reward fails to be awarded, determine the award failure result corresponding to the target reward, thereby setting a retry mechanism in the downstream scenario that supports idempotent operations, increasing the fault tolerance and stability of the award process.

[0086] Please refer to Figure 9 , Figure 9 which is a structural block diagram of a content reward distribution device provided in an embodiment of this specification. As Figure 9 shown, the content reward distribution device 900 includes:

[0087] A request acquisition module 910, configured to parse the award request in response to an award request for a target reward to obtain the award configuration information corresponding to the target reward, where the award configuration information is pre-configured according to the award requirements of the reward;

[0088] A strategy analysis module 920, configured to determine a target awarding strategy corresponding to an awarding request according to the awarding configuration information;

[0089] An award distribution module 930, configured to distribute the target award according to the target awarding strategy and obtain award distribution result data corresponding to the target award.

[0090] Optionally, the awarding configuration information at least includes an award type, an award content configuration, an awarding process, an awarding channel, a failure handling process, and an associated data model.

[0091] Optionally, when the award type is a batch awarding type, the award distribution module 930 is further configured to divide all the awards-to-be-distributed information in the awarding request into at least one award-to-be-distributed batch, mark each award-to-be-distributed batch as an initialization state, and each award-to-be-distributed batch includes at least two awards-to-be-distributed information; perform concurrent awarding processing on each award-to-be-distributed batch through a batch awarding component, and mark each award-to-be-distributed batch as an awarding success state or an awarding failure state according to the awarding result; receive the state data of each award-to-be-distributed batch returned by the batch awarding component.

[0092] Optionally, the award distribution module 930 is further configured to, through the batch awarding component, slice the awards-to-be-distributed information corresponding to the user identifiers belonging to the same awarding service to the same user awarding batch according to the user identifiers corresponding to the awards-to-be-distributed information in each award-to-be-distributed batch, and call the corresponding awarding service for each user awarding batch.

[0093] Optionally, when the award type is a single awarding type, the award distribution module 930 is further configured to query whether there is a corresponding awarded record for the target award; if there is an awarded record, obtain the award distribution result data corresponding to the target award according to the awarded record; if there is no awarded record, distribute the target award according to the target awarding strategy and obtain the award distribution result data corresponding to the target award.

[0094] Optionally, the content award distribution device 900 further includes: an awarding success record module, configured to, when the target award is successfully distributed, generate unique award receiving data corresponding to each award receiving user according to the prize identifier of the target award, the user identifier of the award receiving user, and the idempotency identifier of the awarding request; store each unique award receiving data as the award distribution result data corresponding to the target award.

[0095] Optionally, when the failure handling process is an asynchronous retry process, the content award distribution device 900 further includes: an asynchronous retry processing module, configured to trigger a retry awarding process for the target award when the target award distribution fails; determine the award distribution failure result corresponding to the target award when the number of retry times exceeds a preset number and the target award distribution fails.

[0096] Optionally, when the failure handling process is a quick failure process, the content reward distribution device 800 further includes: a quick failure handling module, configured to determine the award failure result corresponding to the target award when the target award fails to be distributed.

[0097] In an embodiment of this specification, a content reward distribution device is provided. Among them, a request acquisition module is configured to, in response to an award request for a target award, parse the award request to obtain the award configuration information corresponding to the target award, where the award configuration information is pre-configured according to the award requirements of the reward; a policy parsing module is configured to determine the target award policy corresponding to the award request according to the award configuration information; and an award distribution module is configured to distribute the target award according to the target award policy and obtain the award result data corresponding to the target award. In the embodiment of this specification, various types of award distribution policies are comprehensively sorted out and pre-configured. When an award distribution event is triggered, the system can automatically match and call the pre-configured corresponding award distribution policy, and then implement the award according to the award distribution policy. Such an award distribution method not only improves the reusability of the award distribution logic, but also helps to improve the flexibility and maintainability of the award system, and significantly reduces the development cost.

[0098] An embodiment of this specification provides a computer program product containing instructions. When the computer program product runs on a computer or a processor, it causes the computer or the processor to execute the steps of the method in any one of the above embodiments.

[0099] An embodiment of this specification also provides a computer storage medium. The computer storage medium may store multiple instructions, and the instructions are suitable for being loaded and executed by a processor to execute the steps of the method in any one of the above embodiments.

[0100] Please refer to Figure 10 , Figure 10 which is a schematic structural diagram of a terminal provided by an embodiment of this specification. As Figure 10 shown, the terminal 1000 may include: at least one terminal processor 1001, at least one network interface 1004, a user interface 1003, a memory 1005, and at least one communication bus 1002.

[0101] Among them, the communication bus 1002 is used to implement connection communication between these components.

[0102] Among them, the user interface 1003 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 1003 may further include a standard wired interface and a wireless interface.

[0103] Among them, the network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0104] Among them, the terminal processor 1001 may include one or more processing cores. The terminal processor 1001 connects various parts within the entire terminal 1000 through various interfaces and lines. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 1005, and by invoking data stored in the memory 1005, it performs various functions of the terminal 1000 and processes data. Optionally, the terminal processor 1001 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The terminal processor 1001 may integrate one or a combination of several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the terminal processor 1001 and may be implemented separately by a single chip.

[0105] Among them, the memory 1005 may include random access memory (RAM) and may also include read-only memory (ROM). Optionally, the memory 1005 includes a non-transitory computer-readable storage medium. The memory 1005 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1005 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store the data involved in the above-mentioned various method embodiments. Optionally, the memory 1005 may also be at least one storage device located far from the aforementioned terminal processor 1001. As Figure 10 shown, the memory 1005, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a content reward distribution program.

[0106] In Figure 10In the terminal 1000 shown, the user interface 1003 is mainly used to provide an interface for the user to input and obtain the data input by the user; while the terminal processor 1001 can be used to call the content reward distribution program stored in the memory 1005 and specifically perform the following operations:

[0107] In response to a reward distribution request for a target reward, parse the reward distribution request to obtain the reward distribution configuration information corresponding to the target reward, and the reward distribution configuration information is pre-configured according to the reward distribution requirements;

[0108] Determine the target reward distribution strategy corresponding to the reward distribution request according to the reward distribution configuration information;

[0109] Distribute the target reward according to the target reward distribution strategy and obtain the reward distribution result data corresponding to the target reward.

[0110] In some embodiments, the reward distribution configuration information at least includes reward type, reward content configuration, reward distribution process, reward distribution channel, failure handling process, and associated data model.

[0111] In some embodiments, when the reward type is the batch reward type, when the terminal processor 1001 executes distributing the target reward according to the target reward distribution strategy and obtaining the reward distribution result data corresponding to the target reward, it specifically performs the following steps: divide all the reward information to be distributed in the reward distribution request into at least one batch of rewards to be distributed, and mark each batch of rewards to be distributed as the initialization state, and each batch of rewards to be distributed includes at least two pieces of reward information to be distributed; perform concurrent reward distribution processing on each batch of rewards to be distributed through the batch reward distribution component, and mark each batch of rewards to be distributed as the reward success state or the reward failure state according to the reward distribution result; receive the status data of each batch of rewards to be distributed returned by the batch reward distribution component.

[0112] In some embodiments, when the terminal processor 1001 executes performing concurrent reward distribution processing on each batch of rewards to be distributed through the batch reward distribution component, it specifically performs the following steps: through the batch reward distribution component, according to the user identification corresponding to the reward information to be distributed in each batch of rewards to be distributed, slice the reward information to be distributed corresponding to the user identifications belonging to the same reward service into the same user reward batch, and call the corresponding reward service for each user reward batch.

[0113] In some embodiments, when the reward type is the single - time reward type, when the terminal processor 1001 executes distributing the target reward according to the target reward distribution strategy and obtaining the reward distribution result data corresponding to the target reward, it specifically performs the following steps: query whether there is a corresponding issued record for the target reward; if there is an issued record, obtain the reward distribution result data corresponding to the target reward according to the issued record; if there is no issued record, distribute the target reward according to the target reward distribution strategy and obtain the reward distribution result data corresponding to the target reward.

[0114] In some embodiments, after the terminal processor 1001 distributes the target reward according to the target awarding policy, the following steps are further specifically executed: when the target reward is successfully distributed, unique redemption data corresponding to each redeeming user is generated according to the prize identifier of the target reward, the user identifier of the redeeming user, and the idempotency identifier of the awarding request; and the unique redemption data is stored as the awarding result data corresponding to the target reward.

[0115] In some embodiments, when the failure handling process is an asynchronous retry process, after the terminal processor 1001 distributes the target reward according to the target awarding policy, the following steps are further specifically executed: when the awarding of the target reward fails, a retry awarding process is triggered for the target reward; when the number of retries exceeds the preset number and the awarding of the target reward fails, the awarding failure result corresponding to the target reward is determined.

[0116] In some embodiments, when the failure handling process is a quick failure process, after the terminal processor 1001 distributes the target reward according to the target awarding policy, the following steps are further specifically executed: when the awarding of the target reward fails, the awarding failure result corresponding to the target reward is determined.

[0117] In several embodiments provided in this specification, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of devices or modules can be in electrical, mechanical or other forms.

[0118] The modules described as separate components may or may not be physically separated. The components displayed as modules may or may not be physical modules, that is, they may be located in one place, or may be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0119] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The above computer program product includes one or more computer instructions. When the above computer program instructions are loaded and executed on a computer, the processes or functions described above in accordance with the embodiments of this specification are generated in whole or in part. The above computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The above computer instructions can be stored in a computer-readable storage medium or transmitted through the above computer-readable storage medium. The above computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The above computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The above available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a Digital Versatile Disc (DVD)), or a semiconductor medium (such as a Solid State Disk (SSD)), etc.

[0120] It should be noted that for the foregoing method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the embodiments of this specification are not limited by the described action sequence, because according to the embodiments of this specification, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this specification.

[0121] In addition, it should also be noted that the information (including but not limited to user equipment information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions. For example, the user identification, reward distribution records, etc. involved in this specification are obtained under full authorization.

[0122] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0123] In the above embodiments, the descriptions of the various embodiments have their own emphases. For parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0124] The above is the description of a content reward distribution method, device, storage medium, and terminal provided by the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the embodiments of this specification.

Claims

1. A method for distributing content rewards, the method comprising: In response to a reward distribution request for a target reward, parsing the reward distribution request to obtain the reward distribution configuration information corresponding to the target reward, where the reward distribution configuration information is pre-configured according to the reward distribution requirements; Determining a target reward distribution strategy corresponding to the reward distribution request according to the reward distribution configuration information; Distributing the target reward according to the target reward distribution strategy and obtaining the reward distribution result data corresponding to the target reward.

2. The method according to claim 1, wherein the reward distribution configuration information at least includes a reward type, a reward content configuration, a reward distribution process, a reward distribution channel, a failure handling process, and an associated data model.

3. The method according to claim 2, when the reward type is a batch reward type, the distributing the target reward according to the target reward distribution strategy and obtaining the reward distribution result data corresponding to the target reward includes: Dividing all the to-be-distributed reward information in the reward distribution request into at least one to-be-distributed reward batch, and marking each to-be-distributed reward batch as an initialization state, where each to-be-distributed reward batch includes at least two pieces of to-be-distributed reward information; Performing concurrent reward distribution processing on each to-be-distributed reward batch through a batch reward distribution component, and marking each to-be-distributed reward batch as a reward distribution success state or a reward distribution failure state according to the reward distribution result; Receiving the status data of each to-be-distributed reward batch returned by the batch reward distribution component.

4. The method according to claim 3, wherein the performing concurrent reward distribution processing on each to-be-distributed reward batch through the batch reward distribution component includes: Through the batch reward distribution component, according to the user identifier corresponding to the to-be-distributed reward information in each to-be-distributed reward batch, sharding the to-be-distributed reward information corresponding to the user identifiers belonging to the same reward service into the same user reward batch, and invoking the corresponding reward service for each user reward batch.

5. The method according to claim 2, when the reward type is a single reward type, the distributing the target reward according to the target reward distribution strategy and obtaining the reward distribution result data corresponding to the target reward includes: Querying whether there is a corresponding issued record for the target reward; If there is the issued record, obtaining the reward distribution result data corresponding to the target reward according to the issued record; If there is no such issued record, distributing the target reward according to the target reward distribution strategy and obtaining the reward distribution result data corresponding to the target reward.

6. The method according to claim 2, after distributing the target reward according to the target reward distribution strategy, further comprising: When the target reward is successfully distributed, generating unique redemption data for each redeeming user according to the prize identifier of the target reward, the user identifier of the redeeming user, and the idempotency identifier of the reward distribution request; Storing each unique redemption data as the reward distribution result data corresponding to the target reward.

7. The method according to claim 2, when the failure handling process is an asynchronous retry process, after distributing the target reward according to the target reward distribution strategy, further comprising: When the target reward distribution fails, triggering a retry reward distribution process for the target reward; When the number of retry attempts exceeds a preset number and the awarding of the target reward fails, determine the awarding failure result corresponding to the target reward.

8. The method according to claim 1, when the failure handling process is a quick failure process, after awarding the target reward according to the target awarding strategy, further comprising: When the awarding of the target reward fails, determine the awarding failure result corresponding to the target reward.

9. A content reward awarding device, the device comprising: A request acquisition module, configured to, in response to an awarding request for a target reward, parse the awarding request to obtain the awarding configuration information corresponding to the target reward, where the awarding configuration information is pre-configured according to the awarding requirements of the reward; A strategy parsing module, configured to determine the target awarding strategy corresponding to the awarding request according to the awarding configuration information; A reward awarding module, configured to award the target reward according to the target awarding strategy and obtain the awarding result data corresponding to the target reward.

10. A computer program product containing instructions, when the computer program product runs on a computer or a processor, enabling the computer or the processor to execute the steps of the method according to any one of claims 1 to 8.

11. A computer storage medium, the computer storage medium stores multiple instructions, and the instructions are adapted to be loaded and executed by a processor to execute the steps of the method according to any one of claims 1 to 8.

12. A terminal, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 8.

Images