Ageing label generation method and device and storage medium

Abstract

The invention discloses a time efficiency label generation method and device and a storage medium, and relates to the technical field of logistics time efficiency, and the time efficiency label generation method comprises the steps: responding to a time efficiency label obtaining request, and determining whether the client time corresponding to the time efficiency label obtaining request is before the preset time; and if the client time is before the preset time, constructing query input based on a commodity identifier corresponding to the timeliness label acquisition request, and querying the white list data in the memory cache. When the subitems in the white list data are hit, the shipping warehouse information and the receiving place information corresponding to the timeliness label acquisition request are assembled into a key, and the precomputation state of the target route is inquired in the Redis cache based on the key assembled by the shipping warehouse information and the receiving place information. And if the pre-calculation state is normal, the next day arrival tag is used as a response of the timeliness tag acquisition request and is sent to the client. According to the method, the technical effect of high-robustness and high-certainty time-efficiency label calculation capability of the million-level QPS can be realized.

Description

Technical Field

[0001] This application relates to the field of logistics timeliness, and in particular to a method, apparatus and storage medium for generating timeliness labels. Background Technology

[0002] Currently, Vipshop suffers from a complex and uncertain fulfillment model, with weak operation and control in most aspects. Every time a user queries the delivery time tag, the system needs to check in real time whether there are any anomalies in the route from the shipping warehouse to the receiving location, such as weather effects or extended or closed delivery times due to epidemic control measures. With massive amounts of configuration data, this calculation is very time-consuming, resulting in significant latency. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, and storage medium for generating time-sensitive labels, aiming to solve the technical problem of calculating time-sensitive labels under ultra-high QPS and low latency conditions.

[0004] To achieve the above objectives, this application provides a method for generating a time-sensitive label, the method comprising: In response to a time-sensitive tag retrieval request, determine whether the client time corresponding to the time-sensitive tag retrieval request is before a preset time; If the client time is before the preset time, the query input is constructed based on the product identifier corresponding to the request, and the whitelist data in the memory cache is queried. When a sub-item in the whitelist data is hit, the shipping warehouse information and delivery location information corresponding to the timeliness tag acquisition request are assembled into a key, and the pre-calculated status of the target route is queried in the Redis cache based on the key assembled from the shipping warehouse information and delivery location information. If the pre-calculated status is normal, the next-day delivery tag will be used as the response to the timeliness tag request and sent to the client.

[0005] In one embodiment, before the step of assembling the shipping warehouse information and receiving address information corresponding to the timeliness tag acquisition request into a key, and querying the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and receiving address information, the method for generating timeliness tags further includes: When the triggering conditions for the route status pre-calculation process are met, the available routes to be calculated are determined based on the route table. Based on the route information of available routes, query the route status and calculate key parameters; The route status of each available route is determined by calculating key parameters based on the route status, and the calculation results are updated in the Redis cache.

[0006] In one embodiment, the triggering condition for the route state pre-calculation process includes at least one of the following: Reaching the pre-calculated time; Receive notifications of abnormal events from other systems; Changes to the underlying data table have been detected; The pre-computation task failed to execute.

[0007] In one embodiment, the step of calculating key parameters based on route status to determine the route status corresponding to each available route and updating the calculation results to the Redis cache includes: A dynamic graph is constructed by slicing by hour. The dynamic graph uses warehouses, transit stations and delivery areas as nodes, transportation routes as edges, and historical time-efficiency data to determine the edge weights. Based on the dynamic graph, determine the route status corresponding to the available routes; Update the calculation results to the Redis cache.

[0008] In one embodiment, after constructing the query input based on the product identifier corresponding to the timeliness tag acquisition request and querying the whitelist data in the memory cache, the method for generating the timeliness tag further includes: When a sub-item in the whitelist data is matched, the product sales type corresponding to the timeliness tag acquisition request is determined. If the sales type is pre-sale, the pre-sale product timeliness label is determined through the pre-sale product timeliness label calculation process, and the pre-sale product timeliness label is sent to the client as the response to the timeliness label acquisition request. If the sales type is not pre-sale, the process will jump to the steps of assembling the shipping warehouse information and receiving location information corresponding to the timeliness tag retrieval request into a key, and querying the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and receiving location information.

[0009] In one embodiment, before the step of determining whether the client time corresponding to the timeliness tag acquisition request is before a preset time, the timeliness tag generation method further includes: The request is based on the time-sensitive tag to obtain key parameters, which include at least the product identifier and the client time. Based on a pre-set list of key parameters, determine whether any key information is missing; When key information is missing, a key parameter completion process is triggered. Based on this process, the missing key parameters are obtained through the product identifier.

[0010] In one embodiment, after assembling the shipping warehouse information and receiving address information corresponding to the timeliness tag acquisition request into a key, and querying the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and receiving address information, the method for generating timeliness tags further includes: If the pre-calculated status is abnormal, calculate the fulfillment probability for each fulfillment date based on the influencing factors of the arrival date corresponding to the target route; Send the performance probability corresponding to the performance date to the client.

[0011] In one embodiment, after the step of sending the next-day delivery label as a response to the timeliness label retrieval request to the client, the method for generating the timeliness label further includes: If another time-sensitive tag acquisition request is received from another client within a preset time period, the similarity of key parameters between the other time-sensitive tag acquisition request and the time-sensitive tag acquisition request is determined. If the similarity is greater than or equal to the preset threshold, the next-day delivery tag will be used as the response to other time-sensitive tag requests and sent to other clients.

[0012] In addition, to achieve the above objectives, this application also provides an apparatus for generating a time-limited label. The apparatus includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the time-limited label generation method described above.

[0013] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the time-sensitive label generation method described above.

[0014] This application provides a method for generating time-sensitive labels. In response to a time-sensitive label retrieval request, it determines whether the client's time corresponding to the request is before a preset time. If the client's time is before the preset time, a query input is constructed based on the product identifier corresponding to the time-sensitive label retrieval request, and whitelist data in the memory cache is queried. When a sub-item in the whitelist data is matched, the shipping warehouse information and delivery address information corresponding to the time-sensitive label retrieval request are assembled into a key, and based on this key, the pre-calculated status of the target route is queried from the Redis cache. If the pre-calculated status is normal, a next-day delivery label is sent to the client as a response to the time-sensitive label retrieval request. Through a two-level caching architecture of memory and Redis caching, real-time computation of massive amounts of data is avoided, ensuring low latency and high concurrency. Simultaneously, the time-consuming and complex route status calculation tasks are asynchronously and pre-processed, ensuring lightweight and fast online queries. Through the pre-calculation and caching architecture, a technical effect of high robustness and high determinism in time-sensitive label computation with a QPS of millions is achieved. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating the method for generating the expiration label for this application (Example 1). Figure 2 A flowchart illustrating the second embodiment of the method for generating the expiration label for this application; Figure 3 A flowchart illustrating the fifth embodiment of the method for generating the time-limited label for this application; Figure 4 A flowchart illustrating the method for generating the expiration label for this application, provided in Embodiment Six. Figure 5 A flowchart illustrating the method for generating the expiration label for this application, provided in Embodiment Seven. Figure 6 A flowchart illustrating the method for generating the expiration label for this application, provided in Embodiment 8. Figure 7 This is a schematic diagram of the hardware operating environment involved in the time-sensitive label generation method in this application embodiment.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] Currently, Vipshop suffers from a complex and uncertain fulfillment model, with weak operation and control in most aspects. Every time a user queries a delivery time tag, the system needs to check in real-time for any anomalies in the route from the shipping warehouse to the delivery location, such as weather effects or delays or closures due to pandemic control measures. With massive amounts of configuration data, this calculation is extremely time-consuming, leading to significant latency. Furthermore, under extremely high QPS conditions, the excessive number of concurrent calls results in low system robustness.

[0022] The main solution of this application is as follows: In response to a time-definiteness tag retrieval request, determine whether the client time corresponding to the request is before a preset time. If the client time is before the preset time, construct a query input based on the product identifier corresponding to the time-definiteness tag retrieval request and query the whitelist data in the memory cache. When a sub-item in the whitelist data is matched, assemble the shipping warehouse information and delivery address information corresponding to the time-definiteness tag retrieval request into a key, and query the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and delivery address information. If the pre-calculated status is normal, send the next-day delivery tag as the response to the time-definiteness tag retrieval request to the client. Through a two-level caching architecture of memory caching and Redis caching, real-time calculation of massive data is avoided, ensuring low latency and high concurrency. At the same time, the time-consuming and complex route status calculation tasks are asynchronous and pre-processed, ensuring lightweight and fast online queries. Through the pre-calculation and caching architecture, a technical effect of high robustness and high determinism in time-definiteness tag calculation capability at millions of QPS is achieved.

[0023] It should be noted that the executing entity in this embodiment can be a time-sensitive label generating device, or a computing service device with data processing, network communication, and program execution functions, such as a personal computer, server, virtual machine, etc., or a time-sensitive label generating device capable of performing the above functions, etc. This embodiment does not specifically limit it in this way. The following uses a time-sensitive label generating device as the executing entity as an example to describe this embodiment and the following embodiments.

[0024] Embodiment 1 of this application proposes a method for generating time-sensitive labels. Please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the method for generating a time-limited label for this application. The method for generating a time-limited label includes steps S10 to S40: Step S10: In response to the timeliness tag acquisition request, determine whether the client time corresponding to the timeliness tag acquisition request is before the preset time.

[0025] The delivery time tag is the logistics delivery time commitment information output and displayed to the user. It is an intuitive, standardized text or code used to inform the user of the expected delivery time of the goods. Client time refers to the local system time of the user's device, such as a mobile app or web browser, when the user initiates a request to retrieve the delivery time tag. The preset time, equivalent to the order cutoff time, is a pre-configured time threshold by the backend. The preset time is a configurable fixed value, typically set by operations personnel in the business configuration center based on factors such as warehouse capacity and logistics pickup deadlines.

[0026] In this embodiment, a timeliness tag acquisition request is received and key parameters are extracted, including clientTime, skuId, and delivery address information. Verification is performed to determine if the client time is before a preset time. By verifying the client time at the very beginning of the request chain, requests exceeding the preset time can be directly filtered out, avoiding unnecessary computational power consumption in subsequent steps and improving the overall response efficiency and QPS limit of the chain.

[0027] In a first feasible implementation, step S10 may include: parsing request parameters and extracting key dimension information, including the client time. Simultaneously, key dimension information, such as the shipping warehouse code and receiving region ID, is obtained from the request or through a completion process. Based on the obtained dimension information, a query key is constructed, and a high-level cache or configuration table is queried to obtain the dynamic preset time bound to that dimension. For example, the preset time for warehouse A is 22:30, and the preset time for warehouse B is 23:00. The client time is compared with the queried dynamic preset time to complete the judgment. This allows for refined operational strategies. For example, orders in remote areas can be cut off earlier, while the cut-off time for core cities can be extended, thereby maximizing order coverage and optimizing logistics efficiency. It also makes the scheduling of warehousing and logistics resources more rational.

[0028] For example, to avoid the performance waste of blindly acquiring all possible data, upon receiving a request to obtain a time-sensitive tag, the plaintext parameters directly carried are first extracted, primarily the client's time. Then, dimension keys that uniquely identify the business context of this request are identified and extracted, such as the product ID and user ID. However, the user request itself may not contain shipping warehouse or complete delivery address information. Using the obtained dimension keys, lightweight queries are initiated concurrently to multiple dedicated data services. For instance, the product ID is used to query the product details service to obtain the shipping warehouse code, and the user ID is used to query the user address service to obtain the delivery address ID.

[0029] Furthermore, to achieve high concurrency and low latency, a multi-level caching approach is employed. A query key is used to sequentially query multiple levels of cache to obtain dynamically preset times. First, the local application memory cache is queried; if a match is found, it is returned directly. If no match is found, the distributed cache is queried; if no match is found there, persistent storage is queried, and the results are written back to both the distributed and local caches. When all caches expire, the globally default cutoff time is used.

[0030] In a second feasible implementation, step S10 may include: directly extracting the clientTime field from the timeliness tag retrieval request. This field is generated and carried by the client when initiating the request. A preset time is read from the configuration center in memory or the local cache, and a simple numerical comparison is performed between the client time and the preset time, such as comparing the converted timestamps or minutes, to determine whether the client time corresponding to the timeliness tag retrieval request is before the preset time. The logic is simple, involving only one memory read and one comparison operation, and the time consumption is extremely short.

[0031] In a third feasible implementation, step S10 may include: extracting the client time field from the timeliness tag retrieval request. A preset time is read from the configuration center in memory or the local cache, the current system time is obtained from the application server, the absolute difference between the client time and the server time is calculated, and it is determined whether the difference is within an acceptable fault tolerance threshold, such as ±5 minutes. If the time difference is within the threshold, the client time is considered reliable, and the client time is compared with the preset time. If the time difference exceeds the threshold, the client time is considered unreliable, and the server time is used instead for comparison with the preset time. This effectively avoids misjudgments caused by inaccurate client time. Even if the user's time is inaccurate, the correct result conforming to the server logic can still be obtained.

[0032] The above are only three feasible implementation methods of step S10 provided in this embodiment. This embodiment does not specifically limit the specific implementation method of step S10.

[0033] Step S20: If the client time is before the preset time, then construct the query input based on the product identifier corresponding to the request obtained by the time-sensitive tag, and query the whitelist data in the memory cache.

[0034] Memory caching refers to a high-speed data storage method that stores data directly in the server's memory, rather than on disk or in a database. It offers extremely fast read and write speeds, low response latency, and minimizes request processing time. Whitelist data refers to a pre-selected list of products that meet specific criteria. Only products on the whitelist will proceed to the subsequent timeliness label determination process.

[0035] In this embodiment, if the client's time is determined to be before a preset time, the timeliness tag retrieval request is parsed, the core field "product identifier" is extracted, and the product identifier is used as the query input to call the query interface of the memory cache to query the whitelist data. If the query matches, the product is in the whitelist; if it does not match, the product does not support next-day delivery, and a "non-next-day delivery" tag is returned, terminating the process. Whitelist data is typically synchronized from the persistent layer to memory via a scheduled task. When operations modify the configuration in the management backend, the memory cache of all application servers will be updated as early as the next synchronization cycle, allowing changes to business strategies to take effect quickly without restarting the service, providing significant business flexibility.

[0036] In a first feasible implementation, step S20 may include: loading the full whitelist data from the database into a local cache, while the application service subscribes to a message channel. When an operator modifies the whitelist in the management backend, a change event message is published to this channel. The product identifier is extracted from the request and used as the key to query the whitelist data in the local cache. When the application service receives the change event message, if the message body contains the modified product ID and the operation type ADD or DELETE, an incremental update operation is triggered. For an add operation, the product ID is directly added to the local cache data structure. For a delete operation, the product ID is removed from the local cache data structure. This significantly shortens the latency from data change to effectiveness, ensuring higher data consistency. At the same time, it maintains high performance for local memory queries.

[0037] For example, the memory cache may be shared by multiple functions. To ensure the uniqueness of the key, the core business identifier, such as the product ID, is extracted from the time-validated request and concatenated with a namespace prefix to form a complete query key with business semantics. For example, it can be concatenated as "WHITE_LIST_NEXT_DAY:"+skuId.

[0038] In addition, to reduce the latency impact of whitelist verification on requests, a standardized query key is used to access a high-performance cached data structure in the application server's local memory. The query operation is completed entirely within the application process's heap memory and does not involve any network I / O.

[0039] In addition, to ensure the service is operational immediately upon startup, an initialization task is automatically executed when the application service starts. This task retrieves the full set of whitelisted data from persistent storage and loads it all into the memory cache. Simultaneously, a low-frequency scheduled task is activated to retrieve the full data again and refresh the memory cache. This scheduled full synchronization can resolve long-term data inconsistencies caused by message loss that may occur with other synchronization methods, ensuring that the data will eventually be restored to normal.

[0040] Furthermore, to enhance business flexibility and responsiveness and compensate for the latency of scheduled synchronization, a near real-time mechanism is introduced. The application service subscribes to a message topic. When operations personnel perform add, delete, or modify operations on the whitelist in the management backend, a message is immediately published to that topic after the database is updated. The message includes the changed product ID and operation type. After consuming the message, the application service performs corresponding incremental updates to its local memory cache. This further shortens the time for operational configurations to take effect, achieving near real-time data processing through lightweight message communication while ensuring optimal performance for in-memory queries.

[0041] In a second feasible implementation, step S20 may include: an initialization component pulling the current full set of whitelist data from a persistent data source, such as a MySQL database. This data is typically a collection of product IDs. These product IDs are then loaded into a high-performance, thread-safe in-memory data structure, such as a HashSet. The HashSet provides O(1) time complexity queries based on hash values, extracting product identifiers as keys from time-verified requests and performing operations within the HashSet. To prevent the data in memory from becoming outdated, a low-frequency scheduled task is initiated. This scheduled task again pulls the full data from the database and completely replaces the current HashSet in memory. Query performance is maximized, completed with a single memory access, achieving ultra-low latency.

[0042] Step S30: When a sub-item in the whitelist data is hit, the shipping warehouse information and receiving location information corresponding to the timeliness tag acquisition request are assembled into a key, and the pre-calculated status of the target route is queried in the Redis cache based on the key assembled from the shipping warehouse information and receiving location information.

[0043] Warehouse information refers to the identifier and attributes of the physical warehouse where the goods are located. This includes the warehouse code, used to accurately identify which warehouse is responsible for shipping. It may also include the warehouse type, such as a central warehouse, regional warehouse, and the city or region it belongs to. Delivery address information refers to the identifier of the user-specified delivery address, which is the area code corresponding to the user's address. It typically uses a three-level address (province, city, district) or a four-level address (province, city, district, street code). Redis is a high-performance distributed in-memory key-value database that provides high-speed data access. Pre-computed status refers to the route timeliness status result pre-calculated and stored in Redis by an independent background process. It is a conclusive identifier, such as NORMAL, DELAYED, or BLOCKED.

[0044] In this embodiment, when a sub-item in the whitelist data is matched, the shipping warehouse code and the receiving address code are obtained. These codes are then concatenated into a single string according to a fixed rule to form the final cache key. Using this cache key, a query is initiated to the Redis cache to retrieve the pre-calculated status of the target route. By completing this process offline, online requests only require a single simple Redis query, reducing request processing time.

[0045] In a first feasible implementation, step S30 may include: obtaining the shipping warehouse code and the receiving address code. The shipping warehouse code and the receiving address code are concatenated into a string according to a fixed rule to form the final cache key. Using the cache key, a query is initiated to the Redis cache to obtain the pre-calculated status of the target route. The obtained pre-calculated status is a serialized rich state object, such as a JSON string, containing: status, core status codes (e.g., NORMAL, DELAYED, BLOCKED), expectedDays (estimated delivery days, e.g., 2 indicates delivery in 2 days), confidenceLevel (confidence level or probability), reasonCode (exception reason code, e.g., WEATHER indicates weather impact), and validUntil (expiration time of the pre-calculated result). The real-time query service parses this rich state object. If the status is DELAYED, it combines the estimated delivery days and probability to generate more interpretable and user-friendly labels such as expected delivery in 2 days, 95% probability, or possible delay due to weather. If a cache miss occurs, information such as the expiration time of the pre-calculated result in the object is used to make a more reasonable degradation decision. It can provide differentiated and information-rich timely labels, enhancing user perception and trust, and significantly improving the user experience.

[0046] For example, non-standard encoding can cause cache misses even when routes are the same. First, the shipping warehouse and receiving address codes are standardized and cleaned, including unifying capitalization, removing illegal characters, and validating the code's validity, such as checking if it's a known warehouse and region code. This cleaning operation ensures the uniqueness and accuracy of the keys, directly preventing cache misses caused by large amounts of dirty data from the source.

[0047] Furthermore, to address issues promptly, when a query is sent to Redis using the constructed key, a monitoring alert is immediately triggered if either the key exists but its value is null, or the key does not exist (two types of match errors), and degradation logic is initiated. This timely detection and alerting allows the operations team to intervene before the impact escalates.

[0048] Furthermore, to provide the most accurate results possible in exceptional circumstances, a degradation operation is performed when the cache misses. Following a preset priority, the system first queries static degradation rules in local memory or configuration files. For example, for all routes from the East China warehouse to Xinjiang, if data is missing, the default return is 5-day delivery. If no static rule matches, the query conditions are broadened; for instance, instead of querying Shanghai warehouse > Xuhui District, the query now checks Shanghai warehouse > Shanghai city or even East China region > Shanghai city. If both of these levels fail, a hard-coded or configurable global default label is used, such as "Express delivery, estimated delivery in 3-4 days" or "Delivery information being updated."

[0049] In a second feasible implementation, step S30 may include: using the shipping warehouse code and the receiving address code, concatenating them into a cache key according to fixed rules, initiating a query to the Redis cache, parsing the status code and directly routing the query, and executing the business logic branch based on the retrieved status code. If Redis returns a null value or the query times out, a fallback process is initiated, returning a preset default value. Even if the pre-calculated status is not found, a clear and conservative expectation can be obtained, avoiding page errors or long wait times and improving user experience.

[0050] In step S40, if the pre-calculated status is normal, the next-day delivery tag is used as the response to the timeliness tag acquisition request and sent to the client.

[0051] In this embodiment, if the pre-calculated status is normal, a next-day delivery label is returned, and this label is sent to the client as a response to the timeliness label retrieval request. By returning the next-day delivery label, the user's decision-making cost is reduced, improving shopping cart conversion rate and user satisfaction.

[0052] In a first feasible implementation, step S40 may include: constructing a structured object containing rich fields, including not only tag codes, but also expectedDate (the precise expected delivery date), displayText (suggested display text, such as expected delivery before 18:00 tomorrow), and confidenceLevel (confidence level). The backend generates suggested display text and other prompts in real time based on business rules. The rich information object is then returned to the client. This provides a more accurate and information-rich display, resulting in a better user experience.

[0053] For example, to avoid inconsistencies that may arise from recalculation, the expected delivery date is precisely calculated based on the estimated delivery days and the client time of the current request. The next day of the client time is used as the baseline starting point, and an offset is made according to the estimated delivery days; for example, if expectedDays is 2, it means the baseline date is delayed by one day.

[0054] Furthermore, to improve timeliness accuracy, suggested delivery text is dynamically generated based on the calculated date and context. This includes selecting different text templates based on factors such as confidence level. For example, high confidence (greater than 0.95) indicates delivery tomorrow; medium confidence (between 0.8 and 0.95) indicates expected delivery tomorrow; and low confidence (less than 0.8) indicates expected delivery tomorrow or the day after. The precise expected delivery date and other variables are then populated into the selected template to generate the final text.

[0055] In addition, to effectively reduce repeated query requests for the same product within a short period of time and further improve overall throughput and stability, appropriate control header information is set before sending the HTTP response, such as setting Cache-Control: max-age=300, instructing the client or intermediate gateway to cache this result for 5 minutes.

[0056] In a second feasible implementation, step S40 may include: upon determining a normal status, directly filling in an enumeration value or short string code representing next-day delivery, such as delivery_label:"NEXT_DAY", directly serializing the simplified object into a network transmission format, such as JSON, and returning it to the client via an HTTP response. The backend logic is simple and fixed, consuming minimal CPU resources and minimizing the amount of data transmitted over the network.

[0057] In this embodiment, in response to a time-definiteness tag retrieval request, it is determined whether the client time corresponding to the time-definiteness tag retrieval request is before a preset time. If the client time is before the preset time, a query input is constructed based on the product identifier corresponding to the time-definiteness tag retrieval request, and the whitelist data in the memory cache is queried. When a sub-item in the whitelist data is matched, the shipping warehouse information and delivery location information corresponding to the time-definiteness tag retrieval request are assembled into a key, and based on the key assembled from the shipping warehouse information and delivery location information, the pre-calculated status of the target route is queried in the Redis cache. If the pre-calculated status is normal, the next-day delivery tag is sent to the client as a response to the time-definiteness tag retrieval request. Through a two-level caching architecture of memory caching and Redis caching, real-time calculation of massive data is avoided, ensuring low latency and high concurrency. At the same time, the time-consuming and complex route status calculation tasks are asynchronous and pre-processed, ensuring lightweight and fast online queries. Through the pre-calculation and caching architecture, the technical effect of high robustness and high determinism in time-definiteness tag calculation capability at millions of QPS is achieved.

[0058] Based on Embodiment 1, in Embodiment 2 of this application, the content that is the same as or similar to that in Embodiment 1 can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2This is a flowchart illustrating the second embodiment of the timeliness tag generation method in this application. Before the step of assembling the shipping warehouse information and receiving address information corresponding to the timeliness tag acquisition request into a key, and querying the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and receiving address information, the timeliness tag generation method further includes: Step S31: When the triggering conditions for the route status pre-calculation process are met, determine the available routes to be calculated based on the route table.

[0059] The route table is the core configuration table for next-day delivery time calculation. It is specifically used to store and manage the route configurations that require next-day delivery calculation. It defines which routes can provide next-day delivery service and records the current timeliness status of those routes.

[0060] In this embodiment, the first step is to determine which trigger condition was activated. If it's a rule change, the event will include information such as the affected fulfillment mode, shipping city, and receiving region. If it's a scheduled task, the event is triggered on a timer and lacks specific dimension information, meaning all routes need to be processed. If it's a newly added route, the event will include a unique identifier or key dimension for the newly created route, such as the shipping warehouse or receiving region. The database table storing route configurations is queried. Based on different trigger events, different SQL query conditions are constructed to filter the routes that need to be calculated from the route table. For rule changes, all relevant routes in the route table are matched based on the fulfillment mode (business_mode), shipping city (send_city), and receiving region (rev_region) carried in the event. For scheduled tasks, all routes that have not been deleted are queried from the route table. For newly added routes, the new route is precisely retrieved based on the route ID or key dimension carried in the event. This reduces unnecessary computation and shortens the execution time of the entire pre-computation cycle, which is key to achieving high performance and low cost.

[0061] Step S32: Based on the route information of available routes, query the route status and calculate key parameters.

[0062] Route status refers to whether a specific delivery route can support the next-day delivery service commitment at the current time. It is mainly determined by whether additional time has been added or whether delivery time has been suspended. Adding time means the route can still deliver, but due to unforeseen circumstances, it will take longer than normal. Suspending delivery time means the route is temporarily unable to provide delivery service due to serious abnormalities.

[0063] In this embodiment, key dimension information for matching rules is extracted from the route information of available routes. This includes elements such as `business_mode` (fulfillment mode), `warehouse_code` (shipping warehouse), `send_city` (shipping city), and `rev_region` (receiving region). The parsed dimension information is assembled into a request object that the rule engine or query service can recognize. The request must contain all possible combinations of matching dimensions. The rule query service is invoked to determine whether there are any effective time-extension rules or time-lapse rules for the route at the current time. Matching is performed according to the following dimension priority: most precise matching is `shipping city (secondary level) + receiving region (tertiary level)`; second most precise matching is `shipping city (secondary level) + receiving city (secondary level)`; and a wider range of matching is `shipping city (secondary level) + receiving province (primary level)`. The rule query service returns a structured response, including `is_extension` (whether time is added, 1 or 0) and `extensionHours` (the duration of the time extension, if so, how many hours). `is_restrict` indicates whether the shutdown period is valid, and can be either 1 or 0. `reasonCode` is the reason code, identifying the cause of the anomaly, such as weather or an epidemic. The results returned by the rule service are transformed into standardized parameter objects that the pre-calculation process can understand, i.e., key parameters for route status calculation. By querying the rule configuration, the control policies set by operators, such as time-out and shutdown, are transformed into executable calculation parameters, reducing the complexity of the pre-calculation program and improving maintainability.

[0064] Step S33: Calculate key parameters based on route status to determine the route status corresponding to each available route, and update the calculation results to the Redis cache.

[0065] In this embodiment, a dedicated computing service interface is invoked to obtain key parameters for route status calculation. First, it checks whether timeout is disabled. If `is_restrict` (whether timeout is disabled) is 1, the route status is determined to be BLOCKED, regardless of other parameters. If it is 0, the next step is performed. Next, it checks whether time extension is needed, verifying that `is_extension` (whether time extension is needed) is 1. If it is 1, the route status is determined to be DELAYED. If it is 0, the route status is determined to be NORMAL. Based on the currently calculated route information, a unique key is assembled to store the route status. The status result returned by the computing service is constructed into a cached value that can be quickly read by the online service and written to Redis. When an event is triggered, the most time-consuming calculations, such as rule matching and route reachability analysis, are completed in advance. When the online service processes user requests, no complex calculations are required; a simple operation is sufficient to obtain the result. This achieves offline computation and cached query functionality.

[0066] In this embodiment, a pre-computation and caching architecture is used to pre-compute complex and time-consuming route status calculations in real-time links offline, and the results are stored in Redis. This allows online high-concurrency requests to obtain timeliness tags with only a single millisecond-level cache read, thereby achieving extremely low latency at millions of QPS while ensuring high service availability and deterministic timeliness commitments.

[0067] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a method for generating time-sensitive tags, which can be referred to the above description and will not be repeated hereafter. In this regard, the triggering conditions for the route status pre-calculation process include at least one of the following: The pre-calculated time has been reached.

[0068] Receive notifications of abnormal events from other systems.

[0069] Changes to the underlying data table have been detected.

[0070] The pre-computation task failed to execute.

[0071] In this embodiment, abnormal event notifications from other systems include: Warehouse Management System (WMS) notifications of warehouse overload, production line malfunctions, etc.; Transportation Management System (TMS) notifications of traffic disruptions due to heavy rain / snow in a certain area, epidemic control measures, etc.; and Customer Service System notifications of numerous user complaints about delivery delays on a certain route, etc. The system receives abnormal event notifications and detects changes in underlying data tables, such as a warehouse suspension of shipments due to heavy rain reported by the WMS, or an order cut-off time modified by operations personnel in the configuration backend. The system can immediately detect and trigger a recalculation of the relevant routes without waiting for the next pre-calculation cycle. This ensures that the cached data is almost synchronized with real-world changes, greatly reducing information lag and preventing users from seeing incorrect "normal delivery" labels after an anomaly has occurred.

[0072] Furthermore, the detection of changes to the underlying data tables and the receipt of abnormal event notifications usually include information about the scope of impact. The system can accurately pinpoint a few or dozens of affected routes for incremental calculations, rather than blindly recalculating thousands of routes.

[0073] Furthermore, the failure of the pre-computation task triggers a self-healing mechanism. It treats the failed task as an exceptional event requiring immediate handling and performs a rapid retrieval, preventing data from remaining outdated due to a single, accidental failure.

[0074] Furthermore, the ability to receive notifications of abnormal events from other systems enables the timeliness system to seamlessly integrate with external systems such as Warehouse Management System (WMS), Transportation Management System (TMS), and weather forecasting. It can acquire real-time dynamic information beyond its own data tables, which is crucial for timeliness assessment. This allows its computational decisions to be based on the real-time health of the entire supply chain, resulting in more intelligent and accurate judgments.

[0075] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a method for generating time-sensitive tags, which can be referred to the above description and will not be repeated hereafter. Based on this, the steps of calculating key parameters according to the route status to determine the route status corresponding to each available route, and updating the calculation results to the Redis cache, include: Step S331: Construct a dynamic graph by hourly slices. The dynamic graph uses warehouses, transit stations, and delivery areas as nodes, transportation routes as edges, and historical time-sensitive data to determine edge weights.

[0076] Hourly slicing is a data processing and modeling methodology that divides the entire day into 24 independent time segments, rather than treating it as a single entity, and then analyzes, calculates, and models each hourly segment separately. A dynamic graph is a graph theory model used to describe logistics networks. It consists of nodes and edges, and the properties of this graph change dynamically over time.

[0077] In this embodiment, detailed fulfillment data of historical orders is extracted from the data warehouse, including order creation time, shipping warehouse, transit stations along the route, final delivery area, and actual transportation time between each node. Then, the day is divided into 24 time slices, hourly. For each hourly slice, a dynamic graph is independently constructed. Warehouses, transit stations, and delivery areas are treated as nodes in the graph, and transportation routes are treated as edges. A weight is calculated for each edge in the graph. The weight represents the average transportation time required to traverse that edge within that specific hourly slice. All historical transportation data belonging to that hourly slice are aggregated. For example, the average time for all transportation records from warehouse A to transit station B every Monday from 09:00 to 10:00 is calculated. When it is necessary to predict the delivery time of a new route, such as from warehouse A to delivery area C, the corresponding hourly slice dynamic graph can be found based on the order time. The shortest path from A to C is found in the graph, i.e., the node sequence with the least total time. The weights of all edges on the path are summed, and the processing time of each node is added to obtain the scientifically predicted total transportation time. It can achieve accurate prediction of total path time.

[0078] Step S332: Based on the dynamic graph, determine the route status corresponding to the available routes.

[0079] In this embodiment, an available route to be judged is obtained, including the shipping warehouse code and the receiving area code. Based on the time point of interest for the current calculation task, a dynamic graph model with the corresponding time period and hourly slice is selected. On the selected dynamic graph, starting from the shipping warehouse and ending at the delivery area, a shortest path algorithm, i.e., the one with the minimum total weight, such as Dijkstra's algorithm, is run. The weights of all edges on the found optimal path are summed to obtain the predicted total transportation time. Based on the total transportation time and the order cutoff time, expectedDays, i.e., the estimated delivery days, is calculated. For example, if the total time is within 24 hours, then expectedDays=1, meaning next-day delivery. The confidence level is calculated based on the historical stability of each segment on the path, i.e., the variance and the amount of data. The judgment logic is as follows: if the predicted total time is within the standard next-day delivery time limit (e.g., <24 hours) and the confidence level is higher than the safety threshold (e.g., >90%), it is judged as normal. If the predicted total time exceeds the standard time limit, it is judged as delayed. If no connected path from the starting point to the ending point cannot be found in the graph, it is considered an obstruction. By considering complete paths, time fluctuations, and historical stability, it provides more accurate and reliable timeliness predictions than simple rule matching, thus improving the user experience.

[0080] Step S333: Update the calculation results to the Redis cache.

[0081] In this embodiment, a unique Redis key is generated based on the currently processed route information. The calculated route status is serialized into a string format, ready to be stored in Redis. A write command is sent to Redis, associating the generated key with the serialized value, and the calculation result is updated in the Redis cache. Storing complex pre-calculated results in Redis transforms online high-concurrency queries from minute-level calculations to millisecond-level reads.

[0082] In this embodiment, by calculating the total path travel time, the exact number of hours required can be predicted, and gradient and probabilistic labels such as estimated delivery the next day or estimated delivery in two days can be provided. When calculating tens of thousands of routes, there is no need to repeatedly perform data aggregation and model building; only efficient graph traversal is needed to improve computational efficiency.

[0083] As an optional implementation, the steps of calculating key parameters based on route status to determine the route status corresponding to each available route and updating the calculation results to the Redis cache include: using a machine learning model to predict the route status in real time over a future period. First, historical data for each route is collected, including time features such as hour, day of the week, and holidays; weather features such as temperature, precipitation, and wind speed; traffic features such as real-time traffic index; operational features such as warehouse workload, order volume, and historical on-time delivery rate; and event features such as known large-scale events and promotional activities. Model training is then performed, using historical data to train classification models, such as gradient boosting trees and neural networks, to predict route status, including normal, extended delay, and closed. Alternatively, a regression model can be trained to predict latency, and then the status can be classified based on the latency. After model training is complete, real-time features are input into the model to obtain the prediction results. The model can be retrained periodically or updated in real time using online learning. By fusing and analyzing massive amounts of multi-dimensional features through machine learning models, high-precision and forward-looking prediction of route status is achieved, upgrading from passive response to proactive intelligent early warning, greatly improving operational efficiency and user experience.

[0084] As an alternative implementation, the steps of calculating key parameters based on route status to determine the route status of each available route and updating the calculation results to the Redis cache include: performing dynamic thresholding and adaptive adjustments; dynamically calculating the cutoff time for each route based on the warehouse's current processing capacity and order volume. For example, the normal cutoff time is 11 PM, but when the order volume exceeds a certain threshold, the cutoff time is automatically moved forward to 10 PM. Monitoring the warehouse's order processing speed, such as the number of orders processed and the number of pending orders in the past hour. Using a queuing theory model, first calculating the current total workload: Total workload = Number of pending orders / Service rate. If the warehouse has 500 pending orders and the service rate is 100 orders / hour, then completing the current workload will take 500 / 100 = 5 hours. Predicting future order growth; based on historical data or real-time trends, predicting how many new orders will arrive from now until the target cutoff time. Establishing a balance equation; determining the maximum time for receiving new orders from this moment onwards; and calculating the latest cutoff time based on the current time. Based on the above formula, the maximum remaining time to receive new orders is recalculated every few minutes, and then the latest cut-off time to guarantee next-day delivery under the current load is calculated. By sensing warehouse load in real time and applying operations research models, the cut-off time is turned into a dynamic variable, thereby intelligently maximizing the number of orders received while ensuring fulfillment quality, achieving the best balance between operational efficiency and user experience.

[0085] Based on any of the above embodiments of this application, Embodiment 5 of this application proposes a method for generating time-sensitive labels, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating Embodiment 5 of the method for generating time-sensitive labels in this application. Following the steps of constructing query input based on the product identifier corresponding to the time-sensitive label acquisition request and querying whitelist data in the memory cache, the method for generating time-sensitive labels further includes: Step S21: When a sub-item in the whitelist data is matched, determine the product sales type corresponding to the timeliness tag acquisition request.

[0086] The product sales type refers to whether the product is a pre-sale item. Pre-sale items have a special sales and fulfillment cycle; typically, the consumer places an order first, and the merchant ships the goods at a pre-agreed future date. Non-pre-sale items represent the platform's most common sales model; when a consumer places an order, the goods are usually already in stock in the warehouse, and standard warehousing, shipping, and logistics timeliness rules apply. The next-day delivery label is primarily designed for non-pre-sale items.

[0087] In this embodiment, for requests that have been whitelisted, the core parameter `isPresale`, indicating whether a product is pre-sold, is extracted from its context to determine the sales type. This allows for the identification of the corresponding product's sales type. By pre-determining and routing requests accordingly, unnecessary complex calculations for pre-sale products are avoided. Pre-sale products typically have fixed shipping and delivery dates, eliminating the need to worry about real-time route status; direct routing saves computational resources. This simple sales type determination enables intelligent request routing, ensuring the accuracy of business logic while optimizing resource allocation.

[0088] Step S22: If the sales type is pre-sale, determine the pre-sale product timeliness label through the pre-sale product timeliness label calculation process, and send the pre-sale product timeliness label as the response to the timeliness label acquisition request to the client.

[0089] In this embodiment, based on the product ID or pre-sale activity ID, preset timeliness rules are queried from the pre-sale configuration center or product master data. These rules include a fixed shipping time, such as shipping on the 3rd day after successful payment, rather than relying on real-time warehouse status; a fixed logistics timeliness, such as delivery within 2 days after shipment, rather than relying on real-time route status; and a unified display text, such as expected delivery within 5 days after payment. Based on these fixed rules, the final timeliness tag is calculated. The expected shipping date is calculated based on the user's payment time and a fixed shipping preparation cycle. The expected delivery date is calculated as: Expected Delivery Date = Expected Shipping Date + Fixed Logistics Timeliness. The configured fixed text is used directly, or a text such as "Expected Delivery Date: Month X, Day X" is generated based on the above dates. The calculation results are encapsulated into a response object and returned to the client. Independent calculation logic is provided for pre-sale products to ensure that the timeliness tag is generated based on the merchant's inventory preparation cycle rather than real-time logistics capabilities. Replacing complex real-time queries with fixed rule calculations greatly improves processing efficiency and saves computing resources.

[0090] Step S23: If the sales type is non-pre-sale, proceed to the step of assembling the shipping warehouse information and receiving location information corresponding to the timeliness tag acquisition request into a key, and querying the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and receiving location information.

[0091] In this embodiment, upon confirming that the sales type is non-pre-sale, the program logic will execute a redirection, extract the shipping warehouse and receiving location information from the request, concatenate them into a cache key, and query the Redis cache to retrieve the pre-calculated status result. By ensuring that non-pre-sale products enter the optimized cache query path, a low-latency response is guaranteed.

[0092] In this embodiment, the two fundamentally different business processes of pre-sales and non-pre-sales are completely separated, ensuring that each uses the most suitable time-sensitive calculation logic, thus guaranteeing tag accuracy from the source. The pre-sale process returns quickly to avoid invalid calculations, while the non-pre-sale process enters a high-performance cache query chain, realizing on-demand allocation and maximum utilization of computing resources. Through explicit process jumps, the modules are decoupled into modules with single responsibilities and independent maintainability, improving scalability and maintainability.

[0093] Based on any of the above embodiments of this application, Embodiment Six of this application proposes a method for generating time-sensitive labels, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating a sixth embodiment of the method for generating time-sensitive labels in this application. Before the step of determining whether the client time corresponding to the time-sensitive label acquisition request is before a preset time, the method for generating time-sensitive labels further includes: Step S11: Obtain the request based on the time-sensitive tag and obtain key parameters, including at least the product identifier and the client time.

[0094] In this embodiment, the interface receives a request to obtain a time-sensitive tag. From the parsed request data, key parameters explicitly stated in the document are extracted, including at least product identifiers such as product ID and client time. By extracting these two core parameters, product identifier and client time, accurate input conditions are provided for rapid workflow routing in subsequent processes.

[0095] Step S12: Based on the pre-set key parameter details table, determine whether there is any missing key information.

[0096] In this embodiment, all acquired parameters are compared with a key parameter detail table. It is checked whether each required parameter has been successfully retrieved to determine if any critical information is missing. By identifying missing critical information, potential anomalies caused by missing or incorrect data can be intercepted early in the process.

[0097] Step S13: When key information is missing, a key parameter completion process is triggered to obtain the missing key parameters through the product identifier based on the key parameter completion process.

[0098] In this embodiment, when critical information is missing, the system identifies which or more critical parameters are missing. A critical parameter completion process is then triggered, using the product identifier as a clue to query other data sources to retrieve the missing information. For example, to complete shipping warehouse information, the system calls the services of the product center or inventory center, passing in the product identifier, and queries the warehouse containing the product's default shipping warehouse or available inventory, thereby completing the shipping warehouse information. By proactively completing missing data, the request failure rate is significantly reduced, improving the user experience.

[0099] In this embodiment, the original request is transformed into a structurally complete and reliable business context through standardized parameter extraction, completeness verification, and intelligent completion, providing accurate input for subsequent complex decisions.

[0100] Based on any of the above embodiments of this application, Embodiment Seven of this application proposes a method for generating time-sensitive labels, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 5 , Figure 5 This is a flowchart illustrating Embodiment Seven of the method for generating timeliness tags in this application. Following the steps of assembling the shipping warehouse information and receiving address information corresponding to the timeliness tag acquisition request into a key, and querying the pre-calculated status of the target route in the Redis cache based on the key assembled from the shipping warehouse information and receiving address information, the method for generating timeliness tags further includes: Step S34: If the pre-calculated status is abnormal, calculate the fulfillment probability corresponding to each fulfillment date based on the arrival date influencing factors corresponding to the target route.

[0101] In this embodiment, if the pre-calculated status is abnormal, the relevant context information is obtained to confirm the abnormal status and determine whether the abnormal rule is to extend the delivery time or close the time limit. If the rule explicitly specifies the extension duration, such as 12 hours, the extension duration is directly converted into a delay in the delivery date. For example, if the normal delivery time is 24 hours and the extension is 12 hours, the total delivery time becomes 36 hours. If the route is blocked, the delivery probability for any delivery date is calculated as 0. A label indicating temporary unreachability is returned, rather than a probability distribution. Simultaneously, the delivery probability for each delivery date is calculated using methods such as Monte Carlo simulation, historical statistics, and machine learning models to calculate the next-day delivery probability, the second-day delivery probability, and the third-day delivery probability, respectively. Transforming the abnormal status into a probability distribution effectively manages user expectations and reduces order loss. By quantifying and displaying the probability of achieving different delivery dates, clear decision-making basis is provided to users, improving the transparency and credibility of delivery time commitments.

[0102] Step S35: Send the performance probability corresponding to the performance date to the client.

[0103] In this embodiment, the fulfillment probabilities corresponding to the fulfillment dates are assembled into a structured response object. The assembled response object is then serialized into a network transmission format and encapsulated into a standard HTTP response. The encapsulated HTTP response is sent back to the client via a server framework. This transforms the complex internal probabilistic calculations into clear expectations that are perceptible to the user, thus completing the final transformation from data intelligence to user value.

[0104] In this embodiment, by providing probabilistic timeliness information, the transparency of timeliness commitments and the user's sense of participation in decision-making are greatly enhanced, effectively improving satisfaction.

[0105] Based on any of the above embodiments of this application, Embodiment Eight of this application proposes a method for generating time-sensitive labels, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 6 , Figure 6 This is a flowchart illustrating an eighth embodiment of the method for generating timeliness labels in this application. Following the step of sending a next-day delivery label as a response to the timeliness label retrieval request to the client, the method for generating timeliness labels further includes: Step S41: When another time-sensitive tag acquisition request is received from another client within a preset time period, determine the similarity of key parameters between the other time-sensitive tag acquisition request and the time-sensitive tag acquisition request.

[0106] In this embodiment, a very short time window is preset. Within this time window, each new time-definiteness tag request is not processed immediately, but is temporarily stored. For each other time-definiteness tag retrieval request received within the time window, its key parameters are extracted and compared with the key parameters of the first request. Key parameters include product identifier, delivery region ID, and shipping warehouse code. All temporarily stored requests are compared with the baseline request, and the similarity of key parameters is calculated. For exact matching (highest similarity), if the product identifier, delivery region ID, and shipping warehouse code of two requests are completely identical, they are considered to have a 100% similarity. This means that they are querying the time-definiteness of the same product shipped from the same shipping warehouse to the same address, and the calculation results will inevitably be the same. For dimensional matching (high similarity), if the product identifiers are different but the shipping warehouse code and delivery region ID are the same, they may share the pre-calculated results of the route status. For a group of requests with high similarity, only one calculation is performed, and then the result is copied to all requests in the group. This avoids redundant calculations and greatly reduces the access pressure on downstream resources such as the database and cache.

[0107] Step S42: If the similarity is greater than or equal to the preset threshold, the next-day delivery tag is used as the response to other time-sensitive tag acquisition requests and sent to other clients.

[0108] In this embodiment, the similarity result is verified to determine whether it is greater than or equal to a preset threshold. For example, if the threshold is 95%, the product identifier and the delivery region ID must be completely identical. The final time-sensitive tag result calculated from the context of the currently being processed or recently completed baseline request is obtained. For each similar request for other time-sensitive tags, an independent response is constructed and sent to the corresponding client. This significantly reduces the query pressure on downstream services such as databases and caches, and subsequent similar requests do not need to wait and can directly obtain results, thereby significantly reducing the response time of these requests.

[0109] In this embodiment, by introducing a small delay to identify the similarity of requests, the processing of massive duplicate requests is transformed from expensive repetitive computation to inexpensive memory copying, achieving a leap in throughput and optimization of resource utilization efficiency.

[0110] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method of generating the expiration label of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0111] This application provides a time-limited label generation apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the time-limited label generation method in Embodiment 1 above.

[0112] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a time-sensitive label generation apparatus suitable for implementing embodiments of this application. The time-sensitive label generation apparatus in the embodiments of this application may include, but is not limited to, mobile terminals such as laptops, servers, and virtual machines, as well as fixed terminals such as desktop computers. Figure 7 The time-limited label generation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0113] like Figure 7As shown, the time-limited tag generation apparatus may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the time-limited tag generation apparatus. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the time-sensitive tag generating apparatus to communicate wirelessly or wiredly with other devices to exchange data. Although time-sensitive tag generating apparatuses with various systems are shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0114] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0115] The timeliness label generation apparatus provided in this application, employing the timeliness label generation method in the above embodiments, can solve the technical problem of calculating performance timeliness labels under ultra-high QPS and low latency conditions. Compared with the prior art, the beneficial effects of the timeliness label generation apparatus provided in this application are the same as those of the timeliness label generation apparatus provided in the above embodiments, and other technical features in this timeliness label generation apparatus are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0116] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0117] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0118] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the time-limited label generation method in the above embodiments.

[0119] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0120] The aforementioned computer-readable storage medium may be included in the time-sensitive label generating apparatus; or it may exist independently and not be assembled into the time-sensitive label generating apparatus.

[0121] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the timeliness tag generation device, the timeliness tag generation device: determines a dynamic class name based on the business field values ​​of the data to be processed received through the unified data access interface, and sends the data to be processed and the dynamic class name to the dynamic object service. The data received through the unified data access interface is in JSON format and contains business field values. After the dynamic object service verifies the data to be processed, it constructs a dynamic object based on the data. Based on the business field values, it loads the corresponding pre-configured rule tree from the rule configuration library and extracts the target field values ​​required for rule calculation from the dynamic object. It then determines the governance decision result based on the rule tree and the target field values. Finally, based on the governance decision result, it dispatches the governance task to the corresponding governance process executor for processing.

[0122] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0125] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for generating time-limited labels, which can solve the technical problem of calculating time-limited labels under ultra-high QPS and low latency conditions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the time-limited label generation method provided in the above embodiments, and will not be repeated here.

[0126] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the time-sensitive label generation method described above.

[0127] The computer program product provided in this application can solve the technical problem of calculating performance timeliness tags under ultra-high QPS and low latency conditions. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the timeliness tag generation method provided in the above embodiments, and will not be repeated here.

[0128] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A method of generating an aging label, characterized by, The generation method of the time limit label comprises: In response to a time limit label acquisition request, determining whether a client time corresponding to the time limit label acquisition request is before a preset time; If the client time is before the preset time, constructing a query input based on a commodity identifier corresponding to the time limit label acquisition request to query whitelist data in a memory cache; When a sub-item in the whitelist data is hit, assembling shipping warehouse information and delivery location information corresponding to the time limit label acquisition request into a key, and querying a pre-computed state of a target route in a Redis cache based on the key assembled from the shipping warehouse information and the delivery location information; If the pre-computed state is normal, sending a next-day delivery label as a response to the time limit label acquisition request to a client.

2. The method of generating an aging tag of claim 1, wherein, Before the step of assembling the shipping warehouse information and the delivery location information corresponding to the time limit label acquisition request into a key, and querying the pre-computed state of the target route in the Redis cache based on the key assembled from the shipping warehouse information and the delivery location information, the generation method of the time limit label further comprises: When a trigger condition of a route state pre-computation process is met, determining available routes to be computed based on a route table; Querying route state computation key parameters based on route information of the available routes; Determining route states corresponding to each of the available routes according to the route state computation key parameters, and updating the computation results to the Redis cache.

3. The method of generating an aging tag of claim 2, wherein, The trigger condition of the route state pre-computation process comprises at least one of the following: Arriving at a pre-computation time; Receiving an abnormal event notification from other systems; Detecting changes to underlying data tables; Pre-computation task execution failure.

4. The method of generating an aging tag of claim 2, wherein, The step of determining the route states corresponding to each of the available routes according to the route state computation key parameters, and updating the computation results to the Redis cache comprises: Building a dynamic graph by hour slicing, wherein the dynamic graph takes warehouses, transfer stations and distribution areas as nodes, takes transportation routes as edges, and determines edge weights based on historical time limit data; Determining the route states corresponding to the available routes based on the dynamic graph; Updating the computation results to the Redis cache.

5. The method of generating an aging tag of claim 1, wherein, After the step of constructing a query input based on a commodity identifier corresponding to the time limit label acquisition request to query whitelist data in a memory cache, the generation method of the time limit label further comprises: When a sub-item in the whitelist data is hit, determining a sales type of a commodity corresponding to the time limit label acquisition request; If the sales type is pre-sale, determining a pre-sale commodity time limit label through a pre-sale commodity time limit label computation process, and sending the pre-sale commodity time limit label as a response to the time limit label acquisition request to the client; If the sales type is non-pre-sale, jumping to the step of assembling shipping warehouse information and delivery location information corresponding to the time limit label acquisition request into a key, and querying a pre-computed state of a target route in a Redis cache based on the key assembled from the shipping warehouse information and the delivery location information.

6. The method of generating an aging tag of claim 1, wherein, Before the step of determining whether the client time corresponding to the time limit label acquisition request is before the preset time, the time limit label generation method further comprises: Based on the time limit label acquisition request, acquiring key parameters, wherein the key parameters at least include the commodity identifier and the client time; Based on the pre-set key parameter specification table, determining whether there is a key information missing; When there is a key information missing, triggering a key parameter completion process to acquire the missing key parameters through the commodity identifier based on the key parameter completion process.

7. The method of generating an aging tag of claim 1, wherein, After the step of assembling the delivery warehouse information and the delivery location information corresponding to the time limit label acquisition request into a key, and querying the pre-computed state of the target route in the Redis cache based on the key assembled by the delivery warehouse information and the delivery location information, the time limit label generation method further comprises: If the pre-computed state is abnormal, calculating the performance probability corresponding to each performance date according to the arrival date influencing factors corresponding to the target route; Sending the performance probability corresponding to the performance date to the client.

8. The method of generating an aging tag of claim 1, wherein, After the step of sending the next-day delivery label as the response to the time limit label acquisition request to the client, the time limit label generation method further comprises: When other time limit label acquisition requests are received again from other clients within a preset period, determining the key parameter similarity between the other time limit label acquisition requests and the time limit label acquisition request; If the similarity is greater than or equal to a preset threshold, sending the next-day delivery label as the response to the other time limit label acquisition request to the other client.

9. A device for generating time-sensitive labels, characterized in that, The time limit label generation device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the time limit label generation method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the time limit label generation method according to any one of claims 1 to 8.

Images