Data processing method and device, computer device, and storage medium

Abstract

The application belongs to the technical field of data processing, and relates to a data processing method and device, computer equipment and a storage medium, comprising the following steps: when a notification request of a user completing a target task is received, the task type and the completion timestamp of the target task are acquired; the cumulative number of times of the user completing the task type and the consecutive completion days of the user on the task type are queried; a target reward strategy is obtained by filtering a reward strategy list based on the completion timestamp; a reward rule of the target reward strategy is queried; the reward rule is matched based on the cumulative number of times and the consecutive completion days, and a to-be-issued reward list is generated based on a matching result; a reward record is created based on the to-be-issued reward list; the reward record is subjected to anti-duplication verification to screen a target reward record; and reward data in the target reward record is issued. The application can be applied to a business data issuing scene in the fields of financial technology and medical health, and can effectively improve the accuracy of reward data issuing.

Description

Technical Field

[0001] This application relates to the field of data processing technology and can be applied to fields such as financial technology and healthcare, and in particular to data processing methods, devices, computer equipment and storage media. Background Technology

[0002] In the financial insurance and healthcare sectors, reward systems are a core function for improving user activity and retention. However, existing reward data distribution schemes suffer from low accuracy in high-concurrency scenarios. Specifically, traditional methods typically directly call downstream services to distribute rewards after a user completes a task, which is prone to duplicate distributions in scenarios with multiple concurrent requests or request retries. For example, in the financial insurance sector's continuous check-in reward scenario, a user triggers a 5 yuan reward after checking in for the third consecutive day. If network fluctuations cause duplicate submissions, traditional solutions cannot recognize that the request has been processed, resulting in the reward being sent to the user's account twice. Similarly, in the healthcare sector's continuous medication check-in reward scenario, a patient triggers a 10 yuan medication coupon reward after checking in for the fifth consecutive day. If the system's retry mechanism automatically resends the coupon, it will also lead to duplicate distribution. This duplicate distribution problem not only causes economic losses for enterprises but also affects users' trust in the platform. Therefore, there is an urgent need to provide an intelligent reward data distribution method to ensure the accuracy of reward data distribution in high-concurrency scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a data processing method, apparatus, computer equipment, and storage medium to solve the technical problem of low accuracy in reward data distribution in existing reward data distribution schemes.

[0004] Firstly, a data processing method is provided, including: When a notification request is received from a user that the target task has been completed, the task type and completion timestamp of the target task are obtained; Based on a preset query path, the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type can be retrieved. Retrieve a list of reward strategies from a preset cache, and filter the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy; Retrieve the reward rules corresponding to the target reward strategy from the preset database; The reward rules are matched based on the cumulative number of times and the consecutive completion days, and a list of rewards to be distributed is generated based on the matching results. Create corresponding reward records based on the list of rewards to be distributed; The reward records are checked for duplicates, and the target reward records that pass the check are selected. Obtain the reward data from the target reward record and process the reward data for distribution.

[0005] Secondly, a data processing apparatus is provided, comprising: The acquisition module is used to acquire the task type and completion timestamp of the target task when it receives a notification request from the user that the target task has been completed. The first query module is used to query the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type based on a preset query path. The first processing module is used to obtain a list of reward strategies from a preset cache, and filter the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy. The second query module is used to query the reward rules corresponding to the target reward strategy from a preset database; The second processing module is used to perform rule matching on the reward rules based on the cumulative number of times and the consecutive completion days, and generate a list of rewards to be issued based on the obtained matching results; A creation module is used to create corresponding reward records based on the list of rewards to be distributed; The third processing module is used to perform anti-duplicate verification on the reward records and filter out the target reward records that pass the verification. The distribution module is used to obtain reward data from the target reward record and process the distribution of the reward data.

[0006] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described data processing method.

[0007] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described data processing method.

[0008] In the above-described data processing method, apparatus, computer equipment, and storage medium, when this application receives a notification request from a user to complete a target task, it first obtains the task type and completion timestamp of the target task; then, based on a preset query path, it queries the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type; next, it retrieves a reward strategy list from a preset cache, filters the reward strategy list based on the completion timestamp to obtain the corresponding target reward strategy; and queries a reward rule corresponding to the target reward strategy from a preset database; subsequently, it performs rule matching on the reward rule based on the cumulative number of times and the number of consecutive days of completion, and generates a list of rewards to be distributed based on the obtained matching results; and creates corresponding reward records based on the list of rewards to be distributed; further, it performs anti-duplicate verification on the reward records and filters out target reward records that pass the verification; finally, it obtains the reward data in the target reward record and processes the distribution of the reward data. Based on the above automated processing flow, this application provides an intelligent reward data processing method. It obtains the task type and completion timestamp of a user's completed target task, retrieves the user's cumulative number of attempts and consecutive completion days for that task type based on the query path, and filters the cached reward strategy list using the completion timestamp to obtain the target reward strategy. Then, it queries the corresponding reward rules and generates a list of rewards to be distributed based on rule matching using the cumulative number of attempts and consecutive completion days. On this basis, reward records are first created, and then anti-duplicate verification is performed to filter out the target reward records. Finally, the reward data in the target reward records is distributed. Thus, this application introduces an anti-duplicate verification step before reward distribution, filtering the created reward records layer by layer to ensure that only reward records that pass the verification enter the distribution process. This solves the problem of duplicate distribution caused by multiple concurrent requests or request retries in the background technology, effectively improving the accuracy of reward data distribution. Attached Figure Description

[0009] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart of an embodiment of the data processing method according to this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the data processing apparatus according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0011] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0012] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0013] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0014] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0015] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0016] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0017] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0018] It should be noted that the data processing method provided in the embodiments of this application is generally executed by a server / terminal device, and correspondingly, the data processing device is generally located in the server / terminal device.

[0019] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0020] Continue to refer to Figure 2 A flowchart illustrating an embodiment of the data processing method according to this application is shown. The order of steps in the flowchart can be changed, and some steps can be omitted, depending on different needs. The data processing method provided in this application embodiment can be applied to any scenario requiring data processing, and thus can be applied to products in these scenarios, such as data processing products in the financial insurance and healthcare fields. The data processing method includes the following steps: Step S201: When a notification request from a user to complete a target task is received, the task type and completion timestamp of the target task are obtained.

[0021] In this embodiment, the data processing method runs on an electronic device (e.g., Figure 1The server / terminal device shown can obtain the task type and completion timestamp of the target task through wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods. The executing entity of this application is specifically a data processing system, which can be simply referred to as the system. When a notification request from a user to complete a target task is received, the system will complete the corresponding task matching logic based on the implementation class of the TaskMatchStrategy interface and return a matching result object. The key fields contained in this matching result object are: user ID (userId), event type / task type (eventType, such as walking, running, medical consultation), task completion time (completeTime), matching status (matched, boolean value), and matched task template ID (taskTemplateId). The reward calculation process begins only when the matching status is true. The system then obtains the task type and completion timestamp of the target task to arrive at the aforementioned completion timestamp (denoted as T_now). If the matching status is false, the process terminates directly without generating any reward.

[0022] This application can be applied to reward data distribution scenarios in the financial insurance and healthcare sectors. For example, in the financial insurance sector, the aforementioned objective task could be a continuous check-in reward system (continuous type). The corresponding business scenario is: a user purchases a short-term health insurance policy, and after the policy takes effect, they need to check in for 7 consecutive days to receive a 5 yuan cash reward. On the 3rd day, the user completes the check-in, triggering the "3rd consecutive day" reward rule (reward: 5 yuan cash reward, trigger value: 3rd consecutive day). At this point, the system's accumulated check-in count is 3, and the consecutive days are 3.

[0023] Alternatively, in the financial insurance sector, the aforementioned objective could also be a task that rewards points for reaching a cumulative payment target (cumulative type). The corresponding business scenario is: a user has accumulated 6 premium payments on an insurance platform, triggering the "6th cumulative payment" reward rule (reward: 200 points, trigger value: 6th cumulative payment). In this case, the system accumulates 6 times, without considering the concept of consecutive days.

[0024] Furthermore, in the healthcare field, the aforementioned objective task could be a continuous medication check-in to receive coupons (continuous type). The corresponding business scenario is as follows: a patient needs to check in on time for medication for 7 consecutive days in a chronic disease management app. On the 5th day, the check-in is completed, triggering the "5th consecutive day" reward rule (reward: 10 yuan medication coupon, trigger value: 5th consecutive day). At this time, the number of consecutive days is 5.

[0025] Alternatively, in the healthcare field, the aforementioned objective could also be a cumulative task that awards points for reaching a certain number of online consultations. The corresponding business scenario is: a user completes their 10th text-based online consultation on an online consultation platform, triggering the "10th cumulative consultation" reward rule (reward: 50 points, trigger value: 10th cumulative consultation). At this point, the cumulative number of consultations is 10.

[0026] Step S202: Based on a preset query path, query the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type.

[0027] In this embodiment, the specific implementation process of querying the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type based on the preset query path will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0028] Step S203: Obtain a list of reward strategies from a preset cache, and filter the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy.

[0029] In this embodiment, the aforementioned preset cache is specifically a Redis cache. The data structure stored in Redis is: key "reward_strategy:online", value is a list, and each element in the list is a strategy object. The system retrieves all reward strategies marked "online" from the Redis cache at once and combines them to obtain a reward strategy list. Each reward strategy contains four core fields: strategyId, startTime, endTime, associated ruleId, and reward type (rewardType, cumulative or continuous). These reward strategies are configured by operations personnel in the management backend and cached in Redis, eliminating the need to read them from the database each time.

[0030] Then, based on the obtained completion timestamp (denoted as T_now) corresponding to the target task, the system iterates through each reward policy retrieved from the Redis cache. For each reward policy, it checks whether its effective time window satisfies: T_start ≤ T_now ≤ T_end. If satisfied, the policy is retained and proceeds to the next step; otherwise (i.e., the current time is earlier than the start time or later than the end time), the policy is discarded. This step ensures the real-time effectiveness of the reward rules. After operations modify the time window of a policy, the next arriving task will automatically use the new configuration without requiring a system restart. Therefore, the policies in the above reward policy list that have been filtered through streaming time windows are selected as the target reward policies.

[0031] Step S204: Query the reward rules corresponding to the target reward strategy from the preset database.

[0032] In this embodiment, the specific implementation process of querying the reward rules corresponding to the target reward strategy from the preset database will be described in more detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0033] Step S205: Perform rule matching on the reward rules based on the accumulated number of times and the consecutive completion days, and generate a list of rewards to be distributed based on the obtained matching results.

[0034] In this embodiment, the specific implementation process of matching the reward rules based on the accumulated number of times and the consecutive completion days, and generating a list of rewards to be issued based on the obtained matching results, will be described in more detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0035] Step S206: Create corresponding reward records based on the list of rewards to be distributed.

[0036] In this embodiment, after rule matching, the system writes all entries in the list of rewards to be distributed into the database one by one, creating reward records. Each reward record contains the following fields: User ID, Rule ID, Reward Content, Trigger Value (e.g., the 12th cumulative reward or the 4th consecutive day), Request ID (reqId, generated by the Snowflake algorithm for this task), Status (initialized to pending distribution), and Creation Time. No deduplication is performed in this step; all entries are stored in the database. Each record is currently in the pending distribution status, indicating that the reward has been recorded but has not yet been actually distributed to the user.

[0037] Furthermore, once the reward record is created, the system immediately updates the user's accumulated data: incrementing the user's cumulative completion count for that task type by 1 and updating the consecutive days to the latest calculated value. This accumulated data is written to the Redis cache according to the user ID plus the date. The expiration time of the Redis key is precisely calculated to the day boundary (e.g., 23:59:59 of the current day), ensuring that today's data will not be mistakenly deleted before midnight tomorrow, and will be automatically replaced by the data of the new day after crossing over. The purpose of this is to allow the system to quickly and directly read the cumulative count and consecutive days from Redis when the next task arrives, avoiding repeated database queries.

[0038] Step S207: Perform anti-duplicate verification on the reward records and filter out the target reward records that pass the verification.

[0039] In this embodiment, the specific implementation process of performing anti-duplicate verification on the reward records and filtering out the target reward records that pass the verification will be described in more detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0040] Step S208: Obtain the reward data from the target reward record and process the reward data for distribution.

[0041] In this embodiment, the specific implementation process of obtaining reward data from the target reward record and distributing the reward data will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0042] When this application receives a notification request from a user that a target task has been completed, it first obtains the task type and completion timestamp of the target task; then, based on a preset query path, it queries the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type; next, it retrieves a list of reward strategies from a preset cache, and filters the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy; and queries a preset database to retrieve the reward rule corresponding to the target reward strategy; subsequently, it performs rule matching on the reward rule based on the cumulative number of times and the number of consecutive days of completion, and generates a list of rewards to be distributed based on the matching results; and creates corresponding reward records based on the list of rewards to be distributed; further, it performs anti-duplicate verification on the reward records and filters out the target reward records that pass the verification; finally, it obtains the reward data in the target reward records and processes the distribution of the reward data. Based on the above automated processing flow, this application provides an intelligent reward data processing method. It obtains the task type and completion timestamp of a user's completed target task, retrieves the user's cumulative number of attempts and consecutive completion days for that task type based on the query path, and filters the cached reward strategy list using the completion timestamp to obtain the target reward strategy. Then, it queries the corresponding reward rules and generates a list of rewards to be distributed based on rule matching using the cumulative number of attempts and consecutive completion days. On this basis, reward records are first created, and then anti-duplicate verification is performed to filter out the target reward records. Finally, the reward data in the target reward records is distributed. Thus, this application introduces an anti-duplicate verification step before reward distribution, filtering the created reward records layer by layer to ensure that only reward records that pass the verification enter the distribution process. This solves the problem of duplicate distribution caused by multiple concurrent requests or request retries in the background technology, effectively improving the accuracy of reward data distribution.

[0043] In some alternative implementations, step S202 includes the following steps: Step S2021: Invoke a preset query path; wherein the query path includes a first query path and a second query path.

[0044] In this embodiment, when a notification request is received that a user has completed a target task, the system simultaneously initiates two independent query paths. The first path (i.e., the first query path) is the cumulative reward path, whose goal is to obtain the total number of times the user has completed the tasks corresponding to the above task type. The calculation formula is as follows: The second path is the continuous reward path (i.e., the second query path), whose goal is to obtain the number of days the user has continuously completed the tasks corresponding to the above task type. This path needs to query all task completion records of the user within a specified time range, extract the dates, remove duplicates, and then perform continuity calculations. The two paths are executed in parallel because they read completely different data dimensions: the cumulative path reads count-type data, and the continuous path reads date-series data, and they do not block each other.

[0045] Step S2022: Based on the first query path, query the cumulative number of times the user has completed the task type.

[0046] In this embodiment, the total number of times a user completes the task corresponding to the above task type (eventType) can be obtained through the first query path described above, so as to obtain the corresponding cumulative count. The corresponding calculation formula is: Cumulative count = Historical cumulative count + Current count (+1), where the historical cumulative count is read from Redis according to the dimension of "userId + eventType". If Redis does not find the data, it is queried from the database and written back to Redis.

[0047] Step S2023: Based on the second query path, query the number of consecutive days the user has completed the task in the task type.

[0048] In this embodiment, the process of querying the number of consecutive days the user has completed the task based on the second query path includes: 1) Query task completion records within a specified time range. Specifically, the system uses user ID and task type as query criteria to retrieve all completed tasks of that type for that user within a 90-day period preceding the current date from the database. The query results return the completion date field for each record. The 90-day time range is designed to cover the user's longest possible consecutive period, ensuring that earlier consecutive records are not missed due to a too short query range.

[0049] 2) Extract and deduplicate the completion date. Specifically, extract the completion date field from all records in the query results and then perform deduplication. Because a user may complete multiple tasks on the same day (e.g., walk 5 times in a day), but the calculation of consecutive days only cares about "whether a task was completed on a certain day", not "how many times it was completed", so it is necessary to deduplicate the dates to obtain a unique set of dates.

[0050] 3) Reverse order of the date list. Specifically, the deduplicated date list is arranged in reverse chronological order from most recent to oldest, with the newest date in the first position, the next newest in the second position, and so on. Reverse order is the only correct direction for calculating consecutive days because continuity must be traced back from the most recent day.

[0051] 4) Initialize the consecutive days. Specifically, take the first date of the inverted sequence list (i.e., the date the user last completed the task, denoted as D_latest) and perform initialization checks: If D_latest = today or D_latest = yesterday, then the consecutive days number is initialized to 1, because the user has completed a record within the last two days, and a consecutive chain exists; If D_latest < yesterday (meaning the most recent completion was more than a day ago, with a gap in between), then the consecutive days count is set to 0, and no further calculation is needed, as the continuous chain has been broken.

[0052] 5) Check continuity day by day. Specifically, starting from the second date in the reverse sequence, perform the following checks sequentially: Let the current date be D_current and the previous date be D_prev, check if D_prev - 1 day = D_current.

[0053] If they are equal, it means the two days are consecutive, the consecutive days number is incremented by 1, and the next date is checked; if they are not equal, it means there is a gap (which may be across months, across years, or the user did not complete the task on a certain day), the loop is immediately terminated, and earlier dates are no longer checked.

[0054] 6) Output the final consecutive days. Specifically, after the loop ends, the final value of the consecutive days is the precise calculation result. This value, along with the accumulated count, is passed to the next stage of rule matching.

[0055] This application invokes a preset query path, which includes a first query path and a second query path. Then, based on the first query path, it queries the cumulative number of times the user has completed the task type; and based on the second query path, it queries the number of consecutive days the user has completed the task type. Based on this processing flow, this application employs a dual-path parallel design, simultaneously utilizing the first and second query paths for data query processing. This effectively ensures that cumulative calculations and continuous calculations do not interfere with each other, improving the efficiency and intelligence of data query processing.

[0056] In some optional implementations of this embodiment, step S204 includes the following steps: Step S2041: Group the target reward strategy based on the preset reward type to obtain the corresponding cumulative reward strategy and continuous reward strategy.

[0057] In this embodiment, the reward type includes cumulative and consecutive types. The filtered target reward strategies can be split into two groups based on the reward type. The first group contains all strategies with rewardType = "cumulative", and the second group contains all strategies with rewardType = "consecutive". Each group carries one or more ruleIds (associated reward rule identifiers). The purpose of grouping is to allow subsequent rule matching to correspond to the cumulative number of times and the consecutive number of days, respectively.

[0058] Step S2042: Obtain all reward rule identifiers associated with the cumulative reward strategy and the continuous reward strategy.

[0059] In this embodiment, the identifiers of all associated reward rules can be obtained by extracting the identifiers of the grouped cumulative reward strategy and the continuous reward strategy.

[0060] Step S2043: Integrate all the reward rule identifiers to obtain the corresponding identifier data.

[0061] In this embodiment, the system collects all ruleIds from the two sets of policies into a list ruleIdList as the corresponding identification data.

[0062] Step S2044: Based on a preset query strategy, retrieve the rule configuration corresponding to the identifier data from the database.

[0063] In this embodiment, a single SQL batch query is executed: `SELECT * FROM reward_rule WHEREid IN (ruleIdList)`. The query result returns the complete configuration of all rules (i.e., rule configuration), including: trigger conditions (e.g., cumulative 10 times, consecutive 3 days), reward content (e.g., 100 points, 5 yuan coupon), reward type (cumulative or consecutive), and reward ID (rewardId). By using the IN statement to query multiple rules at once, the N+1 problem caused by executing a query for each ruleId individually is avoided.

[0064] Step S2045: Configure the rule as the reward rule.

[0065] Based on the above processing flow, this application groups the target reward strategy according to a preset reward type to obtain corresponding cumulative reward strategies and continuous reward strategies; then, it obtains all reward rule identifiers associated with the cumulative reward strategies and the continuous reward strategies; then, it integrates all the reward rule identifiers to obtain corresponding identifier data; and based on a preset query strategy, it queries the database to retrieve the rule configuration corresponding to the identifier data; subsequently, it uses the rule configuration as the reward rule, thereby enabling efficient and accurate retrieval of the reward rule corresponding to the target reward strategy from the database, improving the query efficiency of reward rules.

[0066] In some alternative implementations, step S205 includes the following steps: Step S2051: Based on the accumulated number of times, perform rule matching on the cumulative reward rule in the reward rule to obtain the first reward rule that is successfully matched.

[0067] In this embodiment, the system iterates through all acquired cumulative reward rules, extracts the set trigger threshold (e.g., 10 times) for each rule, and compares it with the user's current total number of completions (i.e., cumulative count). The judgment logic is: if the cumulative count ≥ the rule threshold, the rule is triggered. For example, if the rule is set to "100 points for 10 cumulative completions," and the user's current total count is 12, then 12 ≥ 10, and the rule is triggered. The rule that is triggered among all cumulative reward rules is the first reward rule that is successfully matched.

[0068] Step S2052: Based on the number of consecutive days completed, perform rule matching on the continuous reward rule in the reward rule to obtain a successfully matched second reward rule.

[0069] In this embodiment, the system iterates through all acquired continuous reward rules. For each continuous reward rule, its set trigger threshold (e.g., 3 consecutive days) is extracted and compared with the user's consecutive completion days. The judgment logic is: if the consecutive completion days ≥ the rule threshold, the rule is triggered. For example, if the rule is set to "reward a 5 yuan coupon for 3 consecutive days", and the user's current consecutive days are 4 days, 4 ≥ 3, the rule is triggered. The rule that is triggered among all continuous reward rules is the successfully matched second reward rule.

[0070] Step S2053: Integrate the first reward rule and the second reward rule to obtain the corresponding target reward rule.

[0071] In this embodiment, integrated data can be obtained by integrating the first reward rule and the second reward rule, and the integrated data can be used as the target reward rule.

[0072] Step S2054: Perform list construction processing on the target reward rules to obtain the corresponding target list.

[0073] In this embodiment, the specific implementation process of constructing a list of the target reward rules to obtain the corresponding target list will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0074] Step S2055: The target list is used as the list of rewards to be distributed.

[0075] This application obtains a first reward rule by matching cumulative reward rules based on the accumulated number of times and continuous reward rules based on the consecutive completion days. Then, it integrates the first and second reward rules to obtain a corresponding target reward rule. Finally, it constructs a list of the target reward rules to obtain a target list, which is then used as the list of rewards to be distributed. Based on this process, this application ensures that the two reward modes do not interfere with each other by matching cumulative and continuous rules separately based on the queried accumulated number of times and consecutive completion days, thus guaranteeing the accuracy of the generated target reward rules. Furthermore, by constructing a list of the target reward rules to obtain the list of rewards to be distributed, accurate data input can be provided for subsequent anti-duplicate verification and reward distribution.

[0076] In some alternative implementations, step S2054 includes the following steps: Step S20541: Obtain the preset conversion rules.

[0077] In this embodiment, the conversion rules include: each triggered reward rule is not directly added to the list as a record, but rather a complete reward entry needs to be generated based on the rule. Specifically, for each triggered reward rule, the system extracts four key pieces of information about the reward rule: rule ID, reward content (e.g., 100 points), reward type (cumulative or consecutive), and the specific trigger value at the time of triggering (e.g., "12th time cumulatively" or "4th consecutive day"). Then, these four pieces of information are combined into a reward entry to be issued.

[0078] Step S20541: Based on the conversion rule, the target reward rule is converted to obtain the corresponding reward item to be issued.

[0079] In this embodiment, based on the rule content of the above conversion rule, the corresponding conversion action can be performed on the above target reward rule to obtain the corresponding reward items to be issued.

[0080] The items to be distributed are aggregated into a preset list to obtain the corresponding generated list.

[0081] In this embodiment, the aforementioned preset list is a list template pre-built according to actual business needs. All generated reward entries to be distributed can be aggregated into this preset list, and the resulting generated list can be used as the corresponding target list (i.e., the reward list to be distributed). Each entry in this generated list is essentially a complete reward data entry, carrying all the fields required to be written to the database in the future. However, at this point, it is only a piece of data to be processed in memory and has not yet been actually written to the database as a record. Cumulative reward rules and continuous reward rules can be triggered simultaneously, so this list may contain both cumulative and continuous entries, meaning a user may receive multiple rewards in the same task.

[0082] The generated list is used as the target list.

[0083] Based on the above processing flow, this application obtains preset conversion rules; then, based on the conversion rules, it converts the target reward rules to obtain corresponding reward items to be distributed; subsequently, it aggregates the reward items to be distributed into a preset list to obtain a corresponding generated list; and finally, it uses the generated list as the target list. Based on the above implementation process, this application converts the target reward rules using conversion rules to obtain reward items to be distributed, then aggregates these reward items into a preset list, and uses the resulting generated list as the corresponding target list. This allows for quick and accurate completion of the list construction process for the target reward rules, ensuring the accuracy of the generated target list.

[0084] In some optional implementations of this embodiment, step S207 includes the following steps: The reward records are deduplicated in batches to obtain the corresponding first reward record.

[0085] In this embodiment, the process of batch deduplication of the reward records includes: the system filters out continuous records from all reward records, extracts their respective trigger values ​​(e.g., consecutive 3rd day, consecutive 5th day), and collects these trigger values ​​into a list of trigger values ​​to be created. Then, using the database IN statement, it queries all continuous reward records that the user has already claimed within the current period, and extracts the set of trigger values ​​for claimed rewards. The list of trigger values ​​to be created is compared with the set of claimed trigger values. Any trigger value appearing in the claimed set indicates that the user has previously claimed rewards for the same consecutive days, and the corresponding record is a duplicate, directly marked as a duplicate and filtered out; only records whose trigger values ​​are not in the claimed set are retained. This step uses batch querying to avoid the performance overhead of comparing each record individually.

[0086] The first reward record is filtered based on a preset request identifier to obtain the corresponding second reward record.

[0087] In this embodiment, the process of filtering the first reward record based on a preset request identifier includes: the system uses the snowflake algorithm to generate a globally unique request ID (reqId) for the current task related to the reward distribution processing of the target task, and verifies all reward records. The system queries the database to see if a reward record with the same reqId already exists. If it exists, it means that a reward record has been generated before this request, and these records belong to the duplicate distribution of the same request, so they are all marked as duplicates and intercepted; if they do not exist, the verification passes. The function of this layer is that even if the batch deduplication processing of the first layer misses duplicates due to extreme concurrency race conditions, this layer can still intercept them by request ID.

[0088] Filter out the third reward record that is in the pending distribution status from the second reward record.

[0089] In this embodiment, the process of filtering out the third reward record with a pending status from the second reward record includes: each reward record has three statuses: pending, issued, and issued without success. The system checks the current status of each reward record one by one. Only records with a pending status (as the target reward record) are sent to the next issuance process; records with a issued status are skipped and not processed; records with an issued without success enter the subsequent retry process. This layer is the final fallback, ensuring that even if duplicates are missed in the first two layers, issued records will not be processed repeatedly.

[0090] The third reward record is used as the target reward record.

[0091] This application performs batch deduplication on the reward records to obtain the corresponding first reward record; then, based on a preset request identifier, the first reward record is filtered to obtain the corresponding second reward record; subsequently, a third reward record with a pending status is selected from the second reward record; and finally, the third reward record is used as the target reward record. Based on the above processing flow, this application strictly executes a three-layer verification of the reward record control model in sequence. The first layer filters obvious duplicates from the business logic level, the second layer intercepts omissions under extreme concurrency from the request level, and the third layer provides a final safety net from the data status level. The three layers combined ensure that duplicate distribution will not occur in high-concurrency scenarios, improving the accuracy and intelligence of reward data distribution.

[0092] In some optional implementations of this embodiment, step S208 includes the following steps: Obtain the reward content type corresponding to the target reward record.

[0093] In this embodiment, information can be extracted from the aforementioned target reward records to obtain the required reward content type, such as points, coupons, cash bonuses, etc.

[0094] Call the downstream service interface corresponding to the reward content type.

[0095] In this embodiment, if the reward type is points, the corresponding points service interface is called; if the reward type is coupons, the corresponding coupon service interface is called; if the reward type is cash red envelopes, the corresponding payment service interface is called.

[0096] Retrieve the reward data from the target reward record.

[0097] In this embodiment, the required reward data, i.e., reward content, can be obtained by extracting information from the above-mentioned target reward records. For example, it may include points, coupons, cash red envelopes, etc.

[0098] The downstream service interface is used to perform the distribution process corresponding to the reward data.

[0099] In this embodiment, reward data from the target reward record can be sent to the corresponding downstream service using a downstream service interface. Specifically, if the reward data is points, the points service interface is called to write the points into the user's points account; if the reward data is a coupon, the coupon service interface is called to distribute the coupon to the user's wallet; if the reward data is a cash bonus, the payment service interface is called to transfer the funds into the user's account.

[0100] After the downstream service interface completes its execution, it returns a success or failure result. The system then updates the status of the corresponding reward record in the database based on the downstream service's return result. If the return is successful, the status is updated to "Distributed," indicating that the reward has actually reached the user; if the return is unsuccessful, the status is updated to "Distribution Failed," and the record will no longer participate in this distribution, awaiting processing by the subsequent retry mechanism.

[0101] This application obtains the reward content type corresponding to the target reward record; then calls the downstream service interface corresponding to the reward content type; subsequently obtains the reward data in the target reward record; and then performs the distribution process corresponding to the reward data based on the downstream service interface. Based on the above processing flow, this application decouples the distribution logic from the business logic by routing downstream services according to the reward type, thereby improving the intelligence of reward data distribution.

[0102] In some optional implementations, the system also provides retry and compensation mechanisms, the specific implementation process of which includes: 1) Scheduled task periodic scanning. The system starts a scheduled task (execution cycle, such as once every 5 minutes) to scan the database for all reward records with a status of "pending distribution" or "distribution failed" and whose retry count has not reached the preset limit (such as 3 times).

[0103] 2) Reissue records pending issuance. For records with a status of "pending issuance," it indicates that the record was shelved and not issued during the last scan due to reasons such as the unavailability of downstream services. The scheduled task will re-call the corresponding downstream issuance service to reissue the record.

[0104] 3) Retry for failed distribution records. For records with a status of "distribution failed", the scheduled task will re-invoke the corresponding downstream distribution service. After each retry, the retry count for that record will be incremented by 1.

[0105] 4) Mark as final failure after reaching the retry limit. When the number of retries for a record reaches the preset limit (e.g., 3 times), the scheduled task updates its status to "final failure" and no further retries are made. At the same time, the system triggers an alarm to notify the operations personnel, who will then manually handle the abnormal record.

[0106] The retry and compensation mechanism is the last line of defense to ensure the final consistency of reward distribution. Due to uncontrollable factors such as network jitter and temporary unavailability of downstream services, distribution may fail during execution. The scheduled task, through periodic scanning and automatic retries, minimizes the possibility of distribution failures caused by temporary faults. The maximum number of retries is set to avoid infinite retries consuming system resources. After reaching the limit, manual processing is switched to ensure that every abnormal record has a clear follow-up handling path.

[0107] In some optional implementations, the system also provides cache update and data consistency maintenance functions, the specific implementation process of which includes: 1) Reward rule details are written to the Guava local cache. All reward rule details retrieved during this task execution are written to the Guava local cache. The cache is configured with an automatic expiration time of 30 minutes and an asynchronous refresh mechanism is enabled. When the cache expires, the first access will trigger an asynchronous thread to load the latest rule data from the database and update the cache, preventing the rules from becoming invalid due to the cache not being updated for a long time.

[0108] 2) Redis policy cache access time refresh. The access time of the list of online reward policies accessed in this task is updated in Redis (i.e., the LRU eviction order is refreshed), ensuring that this policy data will not be evicted from the cache by Redis's LRU mechanism due to long-term inactivity, and guaranteeing that the policy data will still be available when the next task arrives.

[0109] 3) User cumulative data is written to Redis. The user's cumulative number of completions and consecutive days are written to Redis according to the "User ID + Date" dimension. This data serves as a fast retrieval source when the next task arrives. The system can directly retrieve these two values ​​from Redis without querying the database again for calculation, significantly reducing the processing latency of the next task.

[0110] The goal of cache updates is to ensure that data generated in the current task can be quickly reused in the next task. Guava's local cache stores rule details, reducing the pressure on the database for rule queries; Redis refreshes policy access times to prevent policies from being evicted by LRU; and writing user-accumulated data to Redis prepares for fast computation in the next task. These three cache updates work together to ensure that the system maintains low latency and high throughput even when high-frequency tasks arrive, while maintaining eventual data consistency through expiration time and refresh mechanisms.

[0111] In some alternative implementations, the user information obtained is subject to user consent and complies with relevant laws and policies.

[0112] Furthermore, any software tools or components not belonging to our company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0113] Among the alternative implementations, this application has the following advantages: This technical solution is applicable to fields such as health management and financial management that require task and reward systems. Through intelligent matching of strategy patterns and multi-layered protection design, this application achieves significant improvements in system maintainability, scalability, stability, and performance. First, the automatic registration mechanism of the strategy factory allows new task and reward types to be added with zero configuration, requiring only the implementation of the corresponding strategy. This reduces development and maintenance costs by over 70%, significantly improves code readability, and increases unit test coverage to over 95%. Second, the dual-mode reward triggering mechanism enriches operational gameplay; the combination of cumulative and continuous rewards makes the task system more flexible and diverse. Third, the batch deduplication check mechanism avoids the N+1 query problem, reducing database queries by 95% in high-concurrency scenarios, shortening reward creation response time by 80%, and increasing overall system throughput by 3 times. Fourth, the three-layer anti-duplicate distribution mechanism avoids financial losses compared to traditional solutions. Through these improvements, the system meets the needs of rapid business iteration while ensuring high quality and stability, becoming a benchmark technical solution in the industry.

[0114] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0115] It should be emphasized that, to further ensure the privacy and security of the aforementioned reward records, these reward records can also be stored in a node of a blockchain.

[0116] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0117] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. Foundational artificial intelligence technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0118] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0119] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0120] Further reference Figure 3 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a data processing apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0121] like Figure 3 As shown, the data processing device 300 described in this embodiment includes: an acquisition module 301, a first query module 302, a first processing module 303, a second query module 304, a second processing module 305, a creation module 306, a third processing module 307, and a distribution module 308. Wherein: The acquisition module 301 is used to acquire the task type and completion timestamp of the target task when it receives a notification request from the user to complete the target task. The first query module 302 is used to query the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type based on a preset query path. The first processing module 303 is used to obtain a list of reward strategies from a preset cache, and filter the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy. The second query module 304 is used to query the reward rules corresponding to the target reward strategy from a preset database; The second processing module 305 is used to perform rule matching on the reward rules based on the cumulative number of times and the number of consecutive days of completion, and generate a list of rewards to be issued based on the obtained matching results; Module 306 is used to create corresponding reward records based on the list of rewards to be distributed; The third processing module 307 is used to perform anti-duplicate verification on the reward records and filter out the target reward records that pass the verification. The distribution module 308 is used to obtain reward data from the target reward record and process the distribution of the reward data.

[0122] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here.

[0123] In some optional implementations of this embodiment, the first query module 302 includes: The first calling submodule is used to call a preset query path; wherein, the query path includes a first query path and a second query path; The first query submodule is used to query the cumulative number of times the user has completed the task type based on the first query path; The second query submodule is used to query the number of consecutive days the user has completed the task type based on the second query path.

[0124] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here.

[0125] In some optional implementations of this embodiment, the second query module 304 includes: The grouping submodule is used to group the target reward strategy based on a preset reward type to obtain the corresponding cumulative reward strategy and continuous reward strategy; The first acquisition submodule is used to acquire all reward rule identifiers associated with the cumulative reward strategy and the continuous reward strategy; The first integration submodule is used to integrate all the reward rule identifiers to obtain the corresponding identifier data; The third query submodule is used to query the rule configuration corresponding to the identifier data from the database based on a preset query strategy; The first determining submodule is used to configure the rule as the reward rule.

[0126] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here.

[0127] In some optional implementations of this embodiment, the second processing module 305 includes: The first matching submodule is used to perform rule matching on the cumulative reward rule in the reward rule based on the cumulative number of times, and obtain the first reward rule that is successfully matched. The second matching submodule is used to perform rule matching on the continuous reward rule in the reward rule based on the number of consecutive completion days, and obtain the second reward rule that is successfully matched. The second integration submodule is used to integrate the first reward rule and the second reward rule to obtain the corresponding target reward rule; A construction submodule is used to perform list construction processing on the target reward rules to obtain the corresponding target list; The second determining submodule is used to use the target list as the list of rewards to be distributed.

[0128] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here.

[0129] In some optional implementations of this embodiment, the second integration submodule includes: The acquisition unit is used to acquire preset conversion rules; The conversion unit is used to convert the target reward rule based on the conversion rule to obtain the corresponding reward item to be issued; The aggregation unit is used to aggregate the reward items to be distributed into a preset list to obtain the corresponding generated list; A determining unit is used to use the generated list as the target list.

[0130] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here. In some optional implementations of this embodiment, the third processing module 307 includes: The first processing submodule is used to perform batch deduplication on the reward records to obtain the corresponding first reward record; The second processing submodule is used to filter the first reward record based on a preset request identifier to obtain the corresponding second reward record; The third processing submodule is used to filter out the third reward records with a status of pending distribution from the second reward records; The third determination submodule is used to use the third reward record as the target reward record.

[0131] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here.

[0132] In some optional implementations of this embodiment, the disbursement module 308 includes: The second acquisition submodule is used to acquire the reward content type corresponding to the target reward record; The second calling submodule is used to call the downstream service interface corresponding to the reward content type; The third acquisition submodule is used to acquire reward data from the target reward record; The execution submodule is used to perform the distribution process corresponding to the reward data based on the downstream service interface.

[0133] In this embodiment, the operations performed by the above modules or units correspond one-to-one with the steps of the data processing method in the aforementioned embodiments, and will not be repeated here. To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0134] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0135] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0136] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for data processing methods. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0137] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions for the data processing method.

[0138] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0139] Compared with the prior art, the embodiments of this application have the following beneficial effects: In this embodiment, when a notification request is received from a user to complete a target task, the application first obtains the task type and completion timestamp of the target task; then, based on a preset query path, it queries the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type; next, it retrieves a reward strategy list from a preset cache, and filters the reward strategy list based on the completion timestamp to obtain the corresponding target reward strategy; and queries the reward rule corresponding to the target reward strategy from a preset database; subsequently, it performs rule matching on the reward rule based on the cumulative number of times and the number of consecutive days of completion, and generates a list of rewards to be distributed based on the obtained matching results; and creates corresponding reward records based on the list of rewards to be distributed; further, it performs anti-duplicate verification on the reward records and filters out the target reward records that pass the verification; finally, it obtains the reward data in the target reward records and processes the distribution of the reward data. Based on the above automated processing flow, this application provides an intelligent reward data processing method. It obtains the task type and completion timestamp of a user's completed target task, retrieves the user's cumulative number of attempts and consecutive completion days for that task type based on the query path, and filters the cached reward strategy list using the completion timestamp to obtain the target reward strategy. Then, it queries the corresponding reward rules and generates a list of rewards to be distributed based on rule matching using the cumulative number of attempts and consecutive completion days. On this basis, reward records are first created, and then anti-duplicate verification is performed to filter out the target reward records. Finally, the reward data in the target reward records is distributed. Thus, this application introduces an anti-duplicate verification step before reward distribution, filtering the created reward records layer by layer to ensure that only reward records that pass the verification enter the distribution process. This solves the problem of duplicate distribution caused by multiple concurrent requests or request retries in the background technology, effectively improving the accuracy of reward data distribution.

[0140] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the data processing method described above.

[0141] Compared with the prior art, the embodiments of this application have the following main advantages: In this embodiment, when a notification request is received from a user to complete a target task, the application first obtains the task type and completion timestamp of the target task; then, based on a preset query path, it queries the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type; next, it retrieves a reward strategy list from a preset cache, and filters the reward strategy list based on the completion timestamp to obtain the corresponding target reward strategy; and queries the reward rule corresponding to the target reward strategy from a preset database; subsequently, it performs rule matching on the reward rule based on the cumulative number of times and the number of consecutive days of completion, and generates a list of rewards to be distributed based on the obtained matching results; and creates corresponding reward records based on the list of rewards to be distributed; further, it performs anti-duplicate verification on the reward records and filters out the target reward records that pass the verification; finally, it obtains the reward data in the target reward records and processes the distribution of the reward data. Based on the above automated processing flow, this application provides an intelligent reward data processing method. It obtains the task type and completion timestamp of a user's completed target task, retrieves the user's cumulative number of attempts and consecutive completion days for that task type based on the query path, and filters the cached reward strategy list using the completion timestamp to obtain the target reward strategy. Then, it queries the corresponding reward rules and generates a list of rewards to be distributed based on rule matching using the cumulative number of attempts and consecutive completion days. On this basis, reward records are first created, and then anti-duplicate verification is performed to filter out the target reward records. Finally, the reward data in the target reward records is distributed. Thus, this application introduces an anti-duplicate verification step before reward distribution, filtering the created reward records layer by layer to ensure that only reward records that pass the verification enter the distribution process. This solves the problem of duplicate distribution caused by multiple concurrent requests or request retries in the background technology, effectively improving the accuracy of reward data distribution.

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

[0143] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

[0144] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

Claims

1. A data processing method, characterized in that, Includes the following steps: When a notification request is received from a user that the target task has been completed, the task type and completion timestamp of the target task are obtained; Based on a preset query path, the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type can be retrieved. Retrieve a list of reward strategies from a preset cache, and filter the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy; Retrieve the reward rules corresponding to the target reward strategy from the preset database; The reward rules are matched based on the cumulative number of times and the consecutive completion days, and a list of rewards to be distributed is generated based on the matching results. Create corresponding reward records based on the list of rewards to be distributed; The reward records are checked for duplicates, and the target reward records that pass the check are selected. Obtain the reward data from the target reward record and process the reward data for distribution.

2. The data processing method according to claim 1, characterized in that, The step of retrieving the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type based on a preset query path specifically includes: Invoke a preset query path; wherein, the query path includes a first query path and a second query path; Based on the first query path, retrieve the cumulative number of times the user has completed the task type; Based on the second query path, the number of consecutive days the user has completed the task type can be retrieved.

3. The data processing method according to claim 1, characterized in that, The step of retrieving the reward rule corresponding to the target reward strategy from a preset database specifically includes: The target reward strategy is grouped based on a preset reward type to obtain corresponding cumulative reward strategies and continuous reward strategies. Obtain all reward rule identifiers associated with the cumulative reward strategy and the continuous reward strategy; All the aforementioned reward rule identifiers are integrated and processed to obtain the corresponding identifier data; Based on a preset query strategy, the rule configuration corresponding to the identifier data is retrieved from the database; Configure the aforementioned rule as the reward rule.

4. The data processing method according to claim 1, characterized in that, The step of matching the reward rules based on the accumulated number of times and the consecutive completion days, and generating a list of rewards to be distributed based on the matching results, specifically includes: Based on the accumulated number of times, the cumulative reward rules in the reward rules are matched to obtain the first reward rule that is successfully matched. Based on the number of consecutive days of completion, the continuous reward rule in the reward rule is matched to obtain a second reward rule that is successfully matched. The first reward rule and the second reward rule are integrated to obtain the corresponding target reward rule; The target reward rules are processed into a list to obtain the corresponding target list; The target list is used as the list of rewards to be distributed.

5. The data processing method according to claim 4, characterized in that, The step of constructing a list of the target reward rules to obtain the corresponding target list specifically includes: Obtain the preset conversion rules; The target reward rule is transformed based on the transformation rule to obtain the corresponding reward items to be issued; The items of rewards to be distributed are summarized into a preset list to obtain the corresponding generated list; The generated list is used as the target list.

6. The data processing method according to claim 1, characterized in that, The step of performing anti-duplicate verification on the reward records and filtering out the target reward records that pass the verification specifically includes: The reward records are deduplicated in batches to obtain the corresponding first reward record; The first reward record is filtered based on a preset request identifier to obtain the corresponding second reward record; Filter out the third reward record that is in the pending distribution status from the second reward record; The third reward record is used as the target reward record.

7. The data processing method according to claim 1, characterized in that, The steps of obtaining reward data from the target reward record and distributing the reward data specifically include: Obtain the reward content type corresponding to the target reward record; Call the downstream service interface corresponding to the reward content type; Retrieve the reward data from the target reward record; The downstream service interface is used to perform the distribution process corresponding to the reward data.

8. A data processing apparatus, characterized in that, include: The acquisition module is used to acquire the task type and completion timestamp of the target task when it receives a notification request from the user that the target task has been completed. The first query module is used to query the cumulative number of times the user has completed the task type and the number of consecutive days the user has completed the task type based on a preset query path. The first processing module is used to obtain a list of reward strategies from a preset cache, and filter the list of reward strategies based on the completion timestamp to obtain the corresponding target reward strategy. The second query module is used to query the reward rules corresponding to the target reward strategy from a preset database; The second processing module is used to perform rule matching on the reward rules based on the cumulative number of times and the consecutive completion days, and generate a list of rewards to be issued based on the obtained matching results; A creation module is used to create corresponding reward records based on the list of rewards to be distributed; The third processing module is used to perform anti-duplicate verification on the reward records and filter out the target reward records that pass the verification. The distribution module is used to obtain reward data from the target reward record and process the distribution of the reward data.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the data processing method as described in any one of claims 1 to 7.

Images