Information generation method and device, electronic equipment and storage medium

Abstract

The invention provides an information generation method and device, electronic equipment and a storage medium, relates to the field of cloud storage, and can be applied to a cloud platform. The method comprises the following steps: receiving a resource use record message for a target resource, and determining memory cache time corresponding to the target resource from a pre-generated key value mapping table according to target resource use time in the resource use record message and predefined idempotent time efficiency; determining a target cache region for querying the target resource according to the memory cache time, the target resource use time and the idempotent time efficiency; and in response to determining that the target identifier of the target resource is not queried in the target cache region, generating resource record information of the target resource. According to the invention, the idempotent verification efficiency of the large-scale resource use record message is improved, and the accuracy and integrity of the idempotent verification are ensured.

Description

Technical Field

[0001] This disclosure relates to the field of cloud storage, and more particularly to an information generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of cloud computing technology, cloud platforms are offering increasingly diverse resource services, encompassing core products such as cloud servers, object storage, and databases. Their user base includes individual developers, SMEs, and large corporations. The volume of resource usage messages generated is exploding, with peak daily processing volumes reaching billions on a single platform. In processing these large-scale resource usage messages, idempotency verification of duplicate messages is crucial for ensuring service accuracy. Summary of the Invention

[0003] This disclosure presents an information generation method, apparatus, electronic device, and storage medium.

[0004] According to a first aspect of this disclosure, an information generation method is provided, comprising: receiving a resource usage record message for a target resource; determining, based on the target resource usage time and a predefined idempotency in the resource usage record message, a memory cache time corresponding to the target resource from a pre-generated key-value mapping table; determining, based on the memory cache time, the target resource usage time, and the idempotency, a target cache area for querying the target resource; and generating resource record information for the target resource in response to determining that the target resource was not found in the target cache area.

[0005] According to a second aspect of this disclosure, an information generation apparatus is provided, comprising: a cache time determination module configured to receive a resource usage record message for a target resource, and determine the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time in the resource usage record message and a predefined idempotency; a cache area determination module configured to determine the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and the idempotency; and an information generation module configured to generate resource record information for the target resource in response to determining that the target resource is not found in the target cache area.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: 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, the instructions being executed by the at least one processor to enable the at least one processor to perform a method as described in any implementation of the first aspect.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing a computer to perform a method as described in any implementation of the first aspect.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is an exemplary system architecture diagram to which this disclosure can be applied; Figure 2 This is a flowchart of the first embodiment of the information generation method according to this disclosure; Figure 3 This is a flowchart of a second embodiment of the information generation method according to the present disclosure; Figure 4 This is a flowchart of a third embodiment of the information generation method according to this disclosure; Figure 5 This is a flowchart of the fourth embodiment of the information generation method according to the present disclosure; Figure 6 This is a flowchart of the fifth embodiment of the information generation method according to this disclosure; Figure 7 This is a flowchart of the sixth embodiment of the information generation method according to the present disclosure; Figure 8 This is a schematic diagram of the structure of an embodiment of the information generation apparatus according to the present disclosure; Figure 9 This is a block diagram of an electronic device used to implement the information generation method of the embodiments of this disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0013] Figure 1 An exemplary system frame 100 is shown, to which embodiments of the information generation method or information generation apparatus of this disclosure may be applied.

[0014] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0015] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various applications for enabling information communication between the terminal devices 101, 102, and 103 and server 105 can be installed. These applications include cloud storage applications and instant messaging applications.

[0016] Terminal devices 101, 102, and 103 and server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0017] Server 105 can provide various services through its built-in applications, taking cloud storage applications as an example. Users can operate through the cloud storage applications on terminal devices 101, 102, and 103 and send information generation requests to server 105. Server 105 can receive the information generation requests and run the cloud storage applications for processing, performing the following steps: determining the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time and predefined idempotency in the resource usage record message; determining the target cache area for querying the target resource based on the memory cache time, target resource usage time, and idempotency; and generating resource record information for the target resource in response to determining that the target resource was not found in the target cache area.

[0018] It should be noted that the information generation method provided in this embodiment is generally executed by server 105, and correspondingly, the information generation device is generally located in server 105.

[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 The diagram illustrates a flow 200 of a first embodiment of an information generation method according to the present disclosure. This information generation method includes the following steps: Step 201: Receive the resource usage record message for the target resource, and determine the memory cache time corresponding to the target resource from the pre-generated key-value mapping table based on the target resource usage time and the predefined idempotency in the resource usage record message.

[0021] In this embodiment, the execution subject of the information generation method (e.g.) Figure 1 If the server 105 shown receives a resource usage record message for the target resource, it will determine the memory cache time corresponding to the target resource from the pre-generated key-value mapping table based on the target resource usage time and the predefined idempotency in the resource usage record message.

[0022] The aforementioned executing entity receives resource usage record messages for the target resource. Here, the target resource refers to the cloud product resource of the cloud platform, and the resource usage record message refers to the billing message for that cloud product resource. For example, if a user purchases a 1GB virtual machine and uses it for 5 minutes, billing requires combining configuration information, discount information, user information, and other multi-dimensional information to calculate the consumption amount. The virtual machine is the target resource, and the generated billing information is the resource usage record message. It should be noted that a cloud platform (also known as a cloud computing platform) refers to a service based on hardware and software resources, providing computing, networking, and storage capabilities. Cloud computing platforms can be divided into three categories: storage-oriented cloud platforms primarily focused on data storage, computing-oriented cloud platforms primarily focused on data processing, and comprehensive cloud computing platforms that balance computing and data storage / processing.

[0023] For the received resource usage record information, the aforementioned execution entity will determine the target resource usage time (time) and the predefined idempotent validity period (SLA) (Service Level Agreement) in the resource usage record message, and determine the memory cache time (jvm_time) corresponding to the target resource from the pre-generated key-value mapping table (jvm_map).

[0024] For the business scenario of idempotent deduplication based on resource usage, under the technical settings of extremely large data volumes and ultra-high concurrency, the first thing to determine is the timeliness of idempotency, i.e., SLA. Without loss of generality, this embodiment sets it to 12 hours. That is, if the upstream cloud product sends a unique key unique_id, then regardless of how many processing requests are received within 12 hours, the downstream will only be billed once. However, after 12 hours, idempotency is not guaranteed. Of course, the value of SLA can also be set according to actual business needs; this embodiment does not impose specific limitations on this.

[0025] The aforementioned execution entity determines the distributed cache time based on idempotency. Generally, the distributed cache time is equal to the idempotency. The execution entity also obtains the reception time of the system's resource usage record messages. Then, it calculates the difference between the reception time (now time) and the distributed cache time to obtain the first time, and determines whether the target resource usage time is greater than or equal to the first time. If so, it generates the target for billing data: target=ab, where 'a' represents the product (i.e., 'a' is the product identifier), and 'b' represents the customer (i.e., 'b' is the customer identifier). These two are combined using a hyphen (-), thus 'ab' constitutes a unique target object identifier used to match the caching strategy.

[0026] The execution entity then determines the memory cache time (jvm_time) corresponding to the target resource from a pre-generated key-value mapping table based on the target identifier (target object identifier). The key-value mapping table stores the correspondence between target object identifiers and memory cache times; therefore, after determining the target object identifier, the execution entity can determine the corresponding jvm_time from the key-value mapping table.

[0027] Step 202: Determine the target cache area for the target resource to be queried based on the memory cache time, the target resource usage time, and idempotency.

[0028] In this embodiment, the execution entity determines the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and idempotency.

[0029] The problem described in this embodiment is a typical multi-objective problem: minimizing the memory footprint of the service instance and minimizing the latency (performance) of idempotent billing message processing. To reconcile these two conflicting objectives, this embodiment achieves the optimal solution under the management strategy through a multi-level caching approach. The first level of the multi-level caching is the JVM (Java Virtual Machine) memory cache (i.e., local memory cache). This cache is characterized by extremely high performance, with access latency in the nanosecond (ns) range. However, it has significant space constraints; storage capacity of 10 gigabytes (GB) is already costly, and larger amounts become prohibitively expensive. The second level of the multi-level caching is a Redis (remote dictionary service) cache (distributed cache). This cache is characterized by its large storage capacity, reaching terabyte (TB) levels through cluster configuration. However, due to storage network access and instruction processing, the average latency of Redis access is in the tens of milliseconds (ms). Therefore, this embodiment employs a multi-level caching approach combining JVM memory caching and Redis caching. Of course, multi-level caching can also be configured with third-level caching, fourth-level caching, etc., but this embodiment does not make specific limitations on this.

[0030] The aforementioned execution entity calculates the difference between "now time" and "jvm_time" to obtain the second time, and then determines the relationship between "time" and the first and second times. If it is determined that the second time ≥ time ≥ the first time, then the target cache for the queried resource is determined to be a distributed cache, i.e., a Redis cache. If it is determined that "time > second time", then the target cache for the queried resource is determined to be a local memory cache, i.e., a JVM memory cache.

[0031] Step 203: In response to determining that the target identifier of the target resource was not found in the target cache, resource record information of the target resource is generated.

[0032] In this embodiment, if the execution entity determines that the target identifier of the target resource is not found in the target cache, it generates resource record information of the target resource.

[0033] When the target cache is determined to be the Redis cache, the aforementioned execution entity will query the Redis cache using the data unique_id. If a unique_id is found, it means that it is a duplicate and no charge is incurred. Otherwise, charge is incurred and the data is stored in the Redis cache. The expiration time of the data is set to time – (now – redis_time) + random offset. This way, the data can be expired in time when it is no longer needed. For example, if it is currently 10 o'clock and a billing message data from 0 o'clock arrives, with an SLA of 12 hours, then this data only needs to be stored for 2 hours before it expires.

[0034] When the target cache is determined to be the JVM memory cache, the aforementioned execution entity will query the JVM memory cache using the data `unique_id`. If a match is found, it indicates a duplicate and no charge is incurred; otherwise, charge is applied, and the data is stored in the JVM memory cache. The data's expiration time is set to `time – (now – jvm_time) + random offset`, meaning that within the required storage timeframe, this data will definitely still be in the JVM memory cache. Additionally, the aforementioned execution entity will also simultaneously store the data in the Redis cache, setting its expiration time to `time – (now – redis_time) + random offset`.

[0035] In other words, whether it is the JVM memory cache or the Redis cache, if the data identifier is found in the cache, it is considered duplicate data and no charge will be incurred; if it is not found, charge will be incurred, new billing information will be generated, and the data will be stored in the target cache.

[0036] The information generation method provided in this disclosure first receives a resource usage record message for a target resource, and determines the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time and a predefined idempotency in the resource usage record message; then, determines the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and the idempotency; finally, in response to determining that the target identifier of the target resource is not found in the target cache area, resource record information of the target resource is generated. This method matches the memory cache time corresponding to the target resource through a pre-generated key-value mapping table, and dynamically delineates the target cache area for querying by combining the target resource usage time and idempotency validity period, thereby improving the idempotency verification efficiency of large-scale resource usage record messages. In addition, for the message characteristics of different target resources (different products, different user groups), personalized memory cache time is configured for them through the key-value mapping table, replacing the traditional uniform cache validity period strategy, thereby realizing differentiated cache strategy adaptation and optimizing system resource consumption. Finally, the target cache area is accurately delineated based on the three dimensions of target resource usage time, memory cache time, and idempotency validity period, avoiding duplicate or missed verification problems caused by ambiguous cache area range definition, and ensuring the accuracy and completeness of idempotency verification.

[0037] Furthermore, the collection, storage, use, processing, transmission, provision, and disclosure of any type of information, such as user personal information, involved in the technical solutions disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0038] Continue to refer to Figure 3 , Figure 3 A flow 300 of a second embodiment of the information generation method according to the present disclosure is shown. The information generation method includes the following steps: Step 301: Receive resource usage record message for the target resource; in response to determining that the usage time of the target resource is greater than or equal to the first time, determine the target identifier of the target resource.

[0039] In this embodiment, the execution subject of the information generation method (e.g.) Figure 1 The server 105 shown will receive a resource usage record message for the target resource. In response to determining that the usage time of the target resource is greater than or equal to a first time, it will determine the target identifier of the target resource. The first time is the difference between the receiving time and the distributed cache time. The receiving time is the time when the resource usage record message is received. The distributed cache time is determined according to idempotency.

[0040] The aforementioned execution entity determines the distributed cache time based on idempotency. Generally, the distributed cache time is equal to the idempotency. The execution entity also obtains the reception time of the system's resource usage record messages. Then, it calculates the difference between the reception time (now time) and the distributed cache time to obtain the first time, and determines whether the target resource usage time is greater than or equal to the first time. If so, it generates the target for billing data: target=ab, where 'a' represents the product (i.e., 'a' is the product identifier), and 'b' represents the customer (i.e., 'b' is the customer identifier). These two are combined using a hyphen (-), thus 'ab' constitutes a unique target object identifier used to match the caching strategy.

[0041] Step 302: Determine the memory cache time corresponding to the target resource from the key-value mapping table based on the target identifier.

[0042] In this embodiment, the execution entity determines the memory cache time corresponding to the target resource from the key-value mapping table based on the target identifier. The execution entity then determines the corresponding memory cache time (jvm_time) of the target resource from the pre-generated key-value mapping table based on the target identifier (target object identifier). The key-value mapping table stores the correspondence between target object identifiers and memory cache times; therefore, after determining the target object identifier, the execution entity can determine the corresponding jvm_time from the key-value mapping table.

[0043] By comparing the difference between the receiving time and the distributed cache time (the first time) with the target resource usage time, resource usage record messages that exceed the idempotent validity period can be directly filtered out. That is, only messages whose target resource usage time is greater than or equal to the first time are processed with subsequent identifier extraction and cache strategy matching, avoiding invalid queries and processing of expired messages. This reduces the computing power consumption of the system for expired messages, improves the filtering efficiency of invalid messages, and reduces the overall resource utilization of the service.

[0044] Step 303: In response to determining that the target resource usage time is greater than or equal to the first time and less than the second time, the target cache is determined to be a distributed cache.

[0045] In this embodiment, if the execution entity determines that the usage time of the target resource is greater than or equal to a first time and less than a second time, it determines that the target cache is a distributed cache. The second time is the difference between the receiving time and the memory cache time. The execution entity calculates the difference between "now time" and "jvm_time" to obtain the second time, and then determines the relationship between "time" and the first and second times. If it determines that the second time ≥ "time" ≥ the first time, then the target cache for the queried target resource is determined to be a distributed cache, i.e., a Redis cache.

[0046] By using two time thresholds, namely the first time and the second time, a precise mapping rule between the time interval and the cache level is constructed. That is, the distributed cache is only designated as the target cache when the usage time of the target resource is within the interval of [first time, second time). This avoids the disorderly occupation of cache resources by messages with different time expiration times. Compared with the traditional coarse-grained chain of first checking memory and then checking the distributed cache, this strategy quantifies the responsibility boundary of the two-level cache into a clear time interval, thereby improving the accuracy of cache resource scheduling.

[0047] Step 304: In response to determining that the target identifier was not found in the distributed cache, resource record information for the target resource is generated.

[0048] In this embodiment, if the execution entity determines that the target identifier is not found in the distributed cache, it generates resource record information for the target resource. When the target cache is determined to be a Redis cache, the execution entity queries the Redis cache using the data unique_id. If a unique ID is found, it means the data is duplicated and no charge is incurred; otherwise, charge is incurred, resource record information for the target resource is generated, and the expiration time of the data is set to time – (now – redis_time) + random offset. This allows the data to expire promptly when it is no longer needed. For example, if it is currently 10:00 AM and a billing message arrives at 0:00 AM with a SLA of 12 hours, the data only needs to be stored for 2 hours before expiring.

[0049] Step 305: Store the target identifier in a distributed cache.

[0050] In this embodiment, the aforementioned execution entity also stores the target identifier in a distributed cache. That is, for cases where the target is not found, billing is performed, and the data and identifier are stored in the Redis cache.

[0051] Therefore, resource record information for the target resource is generated only when the target identifier is not found in the distributed cache. Logically, this ensures that only one valid record is generated for the same resource usage behavior within the idempotent validity period, thus guaranteeing the uniqueness of resource usage records and eliminating the risk of duplicate generation. If duplicate messages of the same resource usage behavior subsequently occur, deduplication can be directly performed using the target identifier in the distributed cache, without needing to repeatedly execute the record generation logic. Furthermore, the storage period set by the distributed cache based on idempotent validity ensures idempotent verification requirements over long periods, solving the problems of short validity and easy data loss associated with local memory caching.

[0052] from Figure 3 It can be seen from this that, with Figure 2Compared to the corresponding embodiments, the information generation method in this embodiment first constructs a precise mapping rule between the time interval and the cache level using two time thresholds: a first time and a second time. That is, the distributed cache is designated as the target cache only when the usage time of the target resource is within the interval [first time, second time), thereby avoiding the disorderly occupation of cache resources by messages with different time expiration dates. In addition, resource record information of the target resource is generated only when the target identifier is not found in the distributed cache. Logically, this ensures that only one valid record is generated for the same resource usage behavior within the idempotent time limit, thereby guaranteeing the uniqueness of resource usage records and eliminating the risk of duplicate generation.

[0053] Continue to refer to Figure 4 , Figure 4 A flow 400 of a third embodiment of the information generation method according to this disclosure is shown. The information generation method includes the following steps: Step 401: Receive resource usage record message for the target resource; in response to determining that the usage time of the target resource is greater than or equal to the first time, determine the target identifier of the target resource.

[0054] Step 402: Determine the memory cache time corresponding to the target resource from the key-value mapping table based on the target identifier.

[0055] Steps 401-402 are basically the same as steps 301-302 in the aforementioned embodiments. For specific implementation methods, please refer to the aforementioned description of steps 301-302, which will not be repeated here.

[0056] Step 403: In response to determining that the target resource usage time is greater than or equal to the second time, the target cache is determined to be a local memory cache.

[0057] In this embodiment, the execution subject of the information generation method (e.g.) Figure 1 (As shown in server 105) If it is determined that the usage time of the target resource is greater than or equal to the second time, the target cache is determined to be the local memory cache. If it is determined that time > the second time, then the target cache of the queried target resource is determined to be the local memory cache, that is, the JVM memory cache.

[0058] By directing messages whose target resource usage time exceeds the second time to the local memory cache, these messages are typically high-frequency, short-latency core business requests (such as real-time resource call messages from enterprise customers). The local memory cache has no network transmission overhead, and the query latency can reach the nanosecond level. Compared with the millisecond-level latency of distributed cache, it improves the efficiency of deduplication for single messages, supports the real-time message processing needs of billion-level high-concurrency scenarios, and avoids message queue congestion caused by cache access bottlenecks.

[0059] Step 404: In response to determining that the target identifier was not found in the local memory cache, resource record information for the target resource is generated.

[0060] In this embodiment, if the execution entity determines that the target identifier is not found in the local memory cache, it generates resource record information for the target resource. When the target cache is determined to be the JVM memory cache, the execution entity queries the JVM memory cache using the data unique_id. If found, it means duplicates are not charged; otherwise, it is charged, generating new billing information, i.e., generating resource record information for the target resource, and setting the data's expiration time to time – (now – jvm_time) + random offset. This ensures that the data will still be in the JVM memory cache within the specified storage time. Furthermore, the execution entity also simultaneously stores the data in the Redis cache and sets its expiration time to time – (now – redis_time) + random offset.

[0061] Step 405: Store the target identifier in the local memory cache.

[0062] In this embodiment, the execution entity stores the target identifier in a local memory cache. That is, the execution entity also stores the data and data identifier in the JVM memory cache.

[0063] This ensures that resource record information is generated only when the target identifier is not found in the local memory cache, guaranteeing that only one valid record is generated for high-frequency, recent resource usage behavior within the memory cache's validity period. This quickly intercepts duplicate messages generated by instantaneous retries and redundant node pushes in a distributed architecture, avoiding duplicate statistics in core business scenarios (such as real-time resource calls for enterprise customers), reducing the duplicate recording rate of high-frequency messages, and improving the accuracy of resource record data.

[0064] from Figure 4 It can be seen from this that, with Figure 3Compared to the corresponding embodiments, the information generation method in this embodiment first directs messages whose target resource usage time exceeds a second time to a local memory cache. These messages are typically high-frequency, short-latency core business requests (such as real-time resource call messages from enterprise customers). The local memory cache has no network transmission overhead, and the query latency can reach nanoseconds. Compared to the millisecond latency of distributed caching, this improves the efficiency of deduplication for single messages, supporting the real-time message processing needs of billion-level high-concurrency scenarios and avoiding message queue congestion caused by cache access bottlenecks. In addition, resource record information is generated only when the target identifier is not found in the local memory cache, ensuring that high-frequency, recent resource usage behavior generates only one valid record within the memory cache's validity period. This quickly intercepts duplicate messages generated by instantaneous retries and redundant node pushes in a distributed architecture, avoiding duplicate statistics problems in core business scenarios (such as real-time resource calls from enterprise customers), reducing the duplicate recording rate of high-frequency messages, and improving the accuracy of resource record data.

[0065] In some alternative implementations, for a new billing message, if time < now - redis time, meaning the target resource usage time is less than the first time, it means that the idempotent SLA has been exceeded, and billing is performed directly. This data does not need to be stored as idempotent data because the SLA setting has been exceeded.

[0066] Continue to refer to Figure 5 , Figure 5 A flowchart 500 is shown according to a fourth embodiment of the information generation method according to the present disclosure. The information generation method includes the following steps: Step 501: In response to determining to start the service instance, load idempotent cache data from a local file.

[0067] In this embodiment, for a write request, the execution body of the information generation method (e.g.) Figure 1 As shown in server 105, if the service instance is determined to start, idempotent cache data is loaded from the local file. Upon service instance startup, the aforementioned execution entity loads idempotent cache data from the local file `local_file` and initializes the global parameter `redis_time=sla`, where `sla` is the global SLA, for example, 12 hours.

[0068] Step 502: Determine the cache area for storing idempotent cache data based on the loading time of the idempotent cache data and the resource usage time of the idempotent cache data.

[0069] In this embodiment, the execution entity determines the cache area for storing idempotent cache data based on the loading time and resource usage time of the idempotent cache data. The execution entity determines the distributed cache time based on idempotency, loads the difference between the loading time (now) and redis_time of the idempotent cache data, and further determines the relationship between the resource usage time (time) of the idempotent cache data and this difference. This relationship is used to determine the cache area for storing the idempotent cache data. The cache area can be a Redis cache area or a JVM memory cache area.

[0070] This allows the service instance to load historical idempotent cache data from local files when it starts up, quickly achieving idempotent verification capabilities without waiting for distributed cache data synchronization to complete. This mechanism shortens the service instance's readiness time and avoids issues such as backlog of business requests or missed deduplication due to excessively long data synchronization times.

[0071] In some optional implementations of this embodiment, step 502 includes: in response to determining that the resource usage time is greater than or equal to a third time, determining that the cache area storing idempotent cache data is a distributed cache area, wherein the third time is the difference between the loading time and the distributed cache time, and the distributed cache time is determined according to the idempotency.

[0072] In this implementation, `redis_time = sla`. If `now - redis_time <= time`, the data is stored in the Redis cache, and its expiration time is set to `time - (now - redis_time) + random offset`. The random offset is typically 1-60 seconds to prevent a large amount of data from expiring simultaneously. Using a third time (load time - distributed cache time) as a threshold, only historical idempotent cache data with a resource usage time greater than or equal to the third time is synchronized to the distributed cache. This directly filters out invalid data exceeding the idempotency expiration time, avoiding wasted cache space and confusing deduplication logic caused by storing expired data. This increases the proportion of valid data in the distributed cache and improves the accuracy of idempotency verification.

[0073] In some optional implementations of this embodiment, step 502 includes: determining a first memory cache time from a key-value mapping table based on the cache identifier of the idempotent cache data, wherein the first memory cache time is the memory cache time corresponding to the idempotent cache data; in response to determining that the resource usage time is less than or equal to a fourth time, determining that the cache area storing the idempotent cache data is a local memory cache area, wherein the fourth time is the difference between the loading time and the first memory cache time.

[0074] In this implementation manner, the above-mentioned execution entity generates a target target=a-b for the billing data, where a represents a product, that is, a is a product identifier, and b represents a customer, that is, b is a customer identifier. The two are combined through a hyphen -, so that a-b constitutes a unique target object identifier for matching the cache policy. And according to this target identifier (target object identifier), the memory cache time jvm_time corresponding to the target resource is determined from the pre-generated key-value mapping table. The above-mentioned execution entity also calculates the difference between now and jvm_time, that is, the fourth time. If now-jvm_time>=time for the data, the data is stored in the memory jvm cache area, and the expiration time of the data is set to time–(now-jvm_time)+random offset (to prevent a large amount of data from expiring at the same time). It should be noted that since the redis cache area has sufficient space, it will also redundantly store the data in the jvm memory cache area.

[0075] Thus, by matching the cache identifier of the idempotent cache data with the key-value mapping table, the exclusive first memory cache time is obtained, and taking the fourth time (loading time - first memory cache time) as the threshold, only the historical data with the resource usage time less than or equal to the fourth time is synchronized to the local memory cache area, ensuring that only the historical data conforming to its own aging characteristics is carried in the local memory cache area after restart, improving the accuracy of cache layering, and avoiding the duplicate judgment deviation caused by inconsistent rules.

[0076] In addition, if time <now-redis_time, it means that the idempotent sla has been exceeded and it is directly discarded.

[0077] Step 503, receive a resource usage record message for the target resource, and determine the memory cache time corresponding to the target resource from the pre-generated key-value mapping table according to the target resource usage time in the resource usage record message and the predefined idempotent aging.

[0078] Step 504, determine the target cache area for querying the target resource according to the memory cache time, the target resource usage time, and the idempotent aging.

[0079] Step 505, in response to determining that the target identifier of the target resource is not found in the target cache area, generate a resource record information for the target resource.

[0080] Steps 503-505 are basically the same as steps 201-203 of the foregoing embodiment. The specific implementation manner can refer to the description of steps 201-203 above and will not be elaborated here.

[0081] From Figure 5 it can be seen that compared with Figure 2Compared to the corresponding embodiments, the information generation method in this embodiment loads historical idempotent cache data from a local file when the service instance starts. It can quickly have idempotent verification capability without waiting for the distributed cache data to be synchronized. This mechanism shortens the service instance's readiness time and avoids the problem of business request backlog or missed deduplication due to excessive data synchronization time.

[0082] Continue to refer to Figure 6 , Figure 6 A flow 600 of a fifth embodiment of the information generation method according to the present disclosure is shown. The information generation method includes the following steps: Step 601: Receive a resource usage record message for the target resource, and determine the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time and predefined idempotency in the resource usage record message.

[0083] Step 602: Determine the target cache area for the target resource to be queried based on the memory cache time, the target resource usage time, and idempotency.

[0084] Step 603: In response to determining that the target identifier of the target resource was not found in the target cache, resource record information of the target resource is generated.

[0085] Steps 601-603 are basically the same as steps 201-203 in the aforementioned embodiments. For specific implementation methods, please refer to the aforementioned description of steps 201-203, which will not be repeated here.

[0086] Step 604: In response to the detection that the memory cache time has changed to the second memory cache time and the second memory cache time is greater than the memory cache time, the target time is determined.

[0087] In this embodiment, the execution subject of the information generation method (e.g.) Figure 1 The server 105 shown responds to the recognition that the memory cache time has changed to a second memory cache time, and the second memory cache time is greater than the memory cache time, and determines a target time, wherein the target time is the difference between the change time of the memory cache time and the memory cache time.

[0088] In this embodiment, the JVM memory cache time (jvm_time) is generated through a pre-trained large model. Before training the large model, training sample data is collected, which may include data in the following dimensions: timestamps, peak message values, average message values, message latency frequency, time-related information, autoregressive correlation indicators, service machine memory indicators, billing message backlog indicators, etc. The large model learns based on the collected training samples. The trained large model can make predictions and generate the JVM memory cache time, i.e., jvm_time, such as 5 seconds or 2 hours. 10-50 large models will be trained sequentially to generate the JVM memory cache time (jvm_time) for each group of target billing message objects, i.e., a list (Result_list).

[0089] For a unit time interval, such as one hour, a large model is used for model training to generate a JVM_time. Within this corresponding time interval, the billing system's indicator parameters are collected and analyzed, and a corresponding loss function model is designed to obtain the loss value of the recommended value. Relevant technical personnel combine the billing system's performance and changing trends to continuously iterate and fine-tune the large model to gradually minimize the loss value, ultimately achieving the overall optimal performance of the billing system.

[0090] The loss function is the main means of fine-tuning large models. It is based on data collection and analysis of the following system performance to derive corresponding metrics. All statistical time intervals are from the current recommendation time to the next recommendation time. Metrics may include: JVM memory hit rate (a higher hit rate indicates higher JVM memory utilization, more valuable memory space utilization, better overall performance, and also suggests that most data has idempotent deduplication requirements); JVM memory values, which can be broken down into statistical dimensions such as maximum, average, 95th percentile, maximum increase, and maximum decrease; Redis cache hit count (more hits increase overall message latency); and Redis cache performance.

[0091] Therefore, the loss function f can be designed as: f=100 / 60 JVM memory hit rate +20 Average JVM memory usage +10 Redis cache hit count +10 Average performance of Redis caching.

[0092] Furthermore, the experience of relevant technical personnel and the analysis and decision-making based on advance information allow for adjustments and optimizations to the Result_list. For example, the value of jvm_time can be increased or decreased; data in the target can be deleted; a new target(n+1) configuration can be added, generating a new cache management strategy list Result_list_v2. This significantly improves the system's flexibility and the speed of detecting anomalies, thereby enhancing the billing system's responsiveness.

[0093] Furthermore, the billing message model in this embodiment can be represented by the following quintuple: Message=<product,account,time,unique_id,data> ; Here, product represents the product, account represents the account, time represents the billing period, unique_id represents the unique key, and data represents specific information, such as the usage of a certain billing item.

[0094] Furthermore, based on the quintuple model above, the cached information in this embodiment can be represented using a key-value pair model: Map<key,value> =map<unique_id,time> .

[0095] In this embodiment, the aforementioned execution entity parses the jvm_time and generates the corresponding jvm_map.<key,value> The key-value information, key=target, value=jvm_time, means that the key-value relationship table stores jvm_map. When the output of the next large model's training values ​​is generated, Result_list is updated, and jvm_map needs to be updated synchronously. This can be handled separately using an asynchronous thread. However, jvm_map cannot be directly updated at this point because the actual cached content remains unchanged. For example, if the last jvm_time prediction was one hour ago, the JVM memory cache only caches the most recent hour's idempotent deduplicated data (messages older than one hour have expired). But if the current large model's jvm_time prediction is two hours ago, directly updating jvm_map to two hours would cause the next billing message, if it's 1.5 hours later, to directly query the JVM memory cache, which will not find the message, resulting in billing. However, the actual query should be a Redis cache check for deduplication and no billing. Therefore, the data in the JVM memory cache must be updated first, and then jvm_map updated.

[0096] At this time, when the above-mentioned execution entity recognizes that jvm_time changes from jvm_time1 to jvm_time2 and jvm_time2 > jvm_time1, it will calculate the target time point, where point = now - jvm_time1, and now is the change time of the memory cache time.

[0097] The above-mentioned execution entity will also process the data in the jvm memory cache, query and process all the data (time) that meets the condition of target = a - b, re-store it, and set the expiration time of the data to time – (now - jvm_time2) + random offset, so as to extend the expiration time of the data in the jvm memory to the new offset.

[0098] Step 605: Receive a new resource usage record message for the target resource and calculate the fifth time.

[0099] In this embodiment, the above-mentioned execution entity will receive a new resource usage record message for the target resource and calculate the fifth time. The fifth time is the difference between the new reception time of the new resource usage record message and the second memory cache time. For the new billing message, the above-mentioned execution entity will calculate the fifth time, which is the difference between the new reception time and the second memory cache time, denoted as now - jvm_time.

[0100] Step 606: In response to determining that the fifth time is greater than or equal to the target time, update the memory cache time of the target resource in the key-value mapping table to the second memory cache time.

[0101] In this embodiment, if the above-mentioned execution entity determines that the fifth time is greater than or equal to the target time, it will update the memory cache time of the target resource in the key-value mapping table to the second memory cache time. If now – jvm_time2 >= point, it means that the data in the jvm memory has been replenished. At this time, update jvm_time1 in jvm_map to jvm_time2 and clear the point time, that is, it becomes a comparison between time and now - jvm_time2 to determine which level of the multi-level cache to access.

[0102] If now – jvm_time2 < point, it means that the data in the jvm memory is still insufficient. At this time, if time >= point, then through the jvm memory cache duplicate check, this part of the data is complete; and for billing, it is stored in the jvm + edis cache at the same time. If now - redis_time < time < point, then through the redis memory cache duplicate check, and for billing, it is stored in the jvm + redis cache at the same time.

[0103] From Figure 6 It can be seen from this that, with Figure 2 Compared to the corresponding embodiments, the information generation method in this embodiment, when the memory cache time is upgraded from the original duration to a longer second memory cache time, compares the threshold between the target time (change time - original memory cache time) and the fifth time (new reception time - second memory cache time) to ensure that the policy update does not take effect immediately. Instead, it waits for a new message that meets the time condition to be triggered before updating the configuration in the key-value mapping table. This avoids the problem of incompatibility between historical data and the new policy caused by a sudden extension of the cache duration, eliminates the risk of duplicate or missed deduplication caused by policy mutation, makes the iteration of the cache policy smooth and imperceptible, and improves the consistency of idempotent verification.

[0104] Continue to refer to Figure 7 , Figure 7 A flow 700 of a sixth embodiment of the information generation method according to the present disclosure is shown. The information generation method includes the following steps: Step 701: Receive a resource usage record message for the target resource, and determine the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time and predefined idempotency in the resource usage record message.

[0105] Step 702: Determine the target cache area for the target resource to be queried based on the memory cache time, the target resource usage time, and idempotency.

[0106] Step 703: In response to determining that the target identifier of the target resource was not found in the target cache, resource record information of the target resource is generated.

[0107] Steps 701-703 are basically the same as steps 201-203 in the aforementioned embodiments. For specific implementation methods, please refer to the aforementioned description of steps 201-203, which will not be repeated here.

[0108] Step 704: In response to the detection that the memory cache time has changed to the second memory cache time and the second memory cache time is less than the memory cache time, update the memory cache time of the target resource in the key-value mapping table to the second memory cache time.

[0109] In this embodiment, the execution subject of the information generation method (e.g.) Figure 1If server 105 (as shown) detects that the memory cache time has changed to the second memory cache time, and the second memory cache time is less than the original memory cache time, it updates the memory cache time of the target resource in the key-value mapping table to the second memory cache time. When the execution entity detects that `jvm_time1` corresponding to `target=ab` has changed to `jvm_time2`, and `jvm_time2 < jvm_time1` (i.e., the time has shortened), it can directly update `jvm_map`, that is, directly update `jvm_time1` in `jvm_map` to `jvm_time2`. This is because the cached data for `jvm_time2` exists in both the JVM and Redis caches; only the data in the JVM cache exists for a longer period. However, during this longer period, JVM cache deduplication will not be performed because `jvm_time2` is smaller.

[0110] Furthermore, if the machine instance is shut down, the shutdown main process waits for all messages to complete processing and is not allowed to process new billing messages. After the wait is complete, all cached data in Redis is stored in the local file `local_file`. Because the data in Redis has an expiration time, some data may be lost after the service restarts.

[0111] from Figure 7 It can be seen from this that, with Figure 6 Compared to the corresponding embodiments, the information generation method in this embodiment, when the memory cache time is downgraded from the original duration to a shorter second memory cache time, does not require waiting for additional time conditions to trigger. It directly updates the cache time configuration of the target resource in the key-value mapping table, thereby reducing the local memory cache coverage of the target resource and quickly releasing redundant memory space occupied by the original long cache time. For example, when the cache time of high-frequency resources is reduced from 30 minutes to 5 seconds, historical identifier data in local memory that exceeds the 5-second time limit can be quickly expired and cleaned up, reducing the local memory occupation of the target resource, effectively alleviating the memory pressure on the service instance, and reducing the frequency and pause time of JVM garbage collection.

[0112] Further reference Figure 8 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of an information generation apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0113] like Figure 8As shown, the information generation device 800 of this embodiment includes: a cache time determination module 801, a cache area determination module 802, and an information generation module 803. The cache time determination module 801 is configured to receive a resource usage record message for a target resource, and determine the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time in the resource usage record message and a predefined idempotency. The cache area determination module 802 is configured to determine the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and the idempotency. The information generation module 803 is configured to generate resource record information for the target resource in response to determining that the target resource is not found in the target cache area.

[0114] In this embodiment, the specific processing of the cache time determination module 801, the cache area determination module 802, and the information generation module 803 in the information generation device 800, and the resulting technical effects, can be found in reference to [reference needed]. Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiments will not be repeated here.

[0115] In some optional implementations of this embodiment, the cache time determination module 801 is further configured to: in response to determining that the target resource usage time is greater than or equal to a first time, determine the target identifier of the target resource, wherein the first time is the difference between the receiving time and the distributed cache time, the receiving time is the time when the resource usage record message is received, and the distributed cache time is determined according to idempotent timeliness; determine the memory cache time corresponding to the target resource from the key-value mapping table according to the target identifier.

[0116] In some optional implementations of this embodiment, the cache determination module 802 is further configured to: determine the target cache as a distributed cache in response to determining that the target resource usage time is greater than or equal to a first time and less than a second time, wherein the second time is the difference between the reception time and the memory cache time.

[0117] In some optional implementations of this embodiment, the information generation module 803 is further configured to: generate resource record information of the target resource in response to determining that the target identifier is not found in the distributed cache; and store the target identifier in the distributed cache.

[0118] In some optional implementations of this embodiment, the cache determination module 802 is further configured to: determine the target cache as a local memory cache in response to determining that the target resource usage time is greater than or equal to the second time.

[0119] In some optional implementations of this embodiment, the information generation module 803 is further configured to: generate resource record information of the target resource in response to determining that the target identifier is not found in the local memory cache; and store the target identifier in the local memory cache.

[0120] In some optional implementations of this embodiment, the information generation apparatus 800 further includes: a loading module configured to load idempotent cache data from a local file in response to determining the start service instance; and a determining module configured to determine a cache area for storing idempotent cache data based on the loading time of the idempotent cache data and the resource usage time of the idempotent cache data.

[0121] In some optional implementations of this embodiment, the determining module is further configured to: in response to determining that the resource usage time is greater than or equal to a third time, determine that the cache area storing idempotent cache data is a distributed cache area, wherein the third time is the difference between the loading time and the distributed cache time, and the distributed cache time is determined according to the idempotency.

[0122] In some optional implementations of this embodiment, the determining module is further configured to: determine a first memory cache time from a key-value mapping table based on the cache identifier of the idempotent cache data, wherein the first memory cache time is the memory cache time corresponding to the idempotent cache data; and in response to determining that the resource usage time is less than or equal to a fourth time, determine that the cache area storing the idempotent cache data is a local memory cache area, wherein the fourth time is the difference between the loading time and the first memory cache time.

[0123] In some optional implementations of this embodiment, the information generation device 800 further includes: a first update module configured to, in response to recognizing that the memory cache time has changed to a second memory cache time, and the second memory cache time is greater than the memory cache time, determine a target time, wherein the target time is the difference between the change time of the memory cache time and the memory cache time; receive a new resource usage record message for the target resource, calculate a fifth time, wherein the fifth time is the difference between the new reception time of the new resource usage record message and the second memory cache time; and, in response to determining that the fifth time is greater than or equal to the target time, update the memory cache time of the target resource in the key-value mapping table to the second memory cache time.

[0124] In some optional implementations of this embodiment, the information generation device 800 further includes: a first update module, configured to update the memory cache time of the target resource in the key-value mapping table to the second memory cache time in response to recognizing that the memory cache time has changed to a second memory cache time and the second memory cache time is less than the memory cache time.

[0125] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0126] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0127] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0128] like Figure 9 As shown, device 900 includes a computing unit 901, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 902 or a computer program loaded from storage unit 908 into random access memory (RAM) 903. RAM 903 may also store various programs and data required for the operation of device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0129] Multiple components in device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0130] The computing unit 901 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above, such as information generation methods. For example, in some embodiments, the information generation method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program may be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by the computing unit 901, one or more steps of the information generation method described above may be performed. Alternatively, in other embodiments, the computing unit 901 may be configured to perform information generation methods by any other suitable means (e.g., by means of firmware).

[0131] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0132] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0133] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0134] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0135] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0136] Cloud computing refers to a technological system that enables access to elastic and scalable shared physical or virtual resources via a network. These resources can include servers, operating systems, networks, software, and storage devices, and can be deployed and managed in an on-demand, self-service manner. Cloud computing technology can provide efficient and powerful data processing capabilities for applications such as artificial intelligence and blockchain, as well as for model training.

[0137] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0138] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0139] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An information generation method, comprising: Receive a resource usage record message for a target resource, and determine the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time and predefined idempotency in the resource usage record message. Based on the memory cache time, the target resource usage time, and the idempotency, determine the target cache area for querying the target resource; In response to determining that the target identifier of the target resource is not found in the target cache, resource record information of the target resource is generated.

2. The method according to claim 1, wherein, The step of determining the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time in the resource usage record message and a predefined idempotent validity period includes: In response to determining that the usage time of the target resource is greater than or equal to a first time, a target identifier of the target resource is determined, wherein the first time is the difference between the receiving time and the distributed cache time, the receiving time is the time when the resource usage record message is received, and the distributed cache time is determined according to the idempotent timeliness; The memory cache time corresponding to the target resource is determined from the key-value mapping table based on the target identifier.

3. The method according to claim 2, wherein, The step of determining the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and the idempotency includes: In response to determining that the target resource usage time is greater than or equal to the first time and less than the second time, the target cache is determined to be a distributed cache, wherein the second time is the difference between the reception time and the memory cache time.

4. The method according to claim 3, wherein, In response to determining that the target identifier of the target resource is not found in the target cache, the generation of resource record information for the target resource includes: In response to determining that the target identifier is not found in the distributed cache, resource record information for the target resource is generated; The target identifier is stored in the distributed cache.

5. The method according to claim 3, wherein, The step of determining the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and the idempotency further includes: In response to determining that the target resource usage time is greater than or equal to the second time, the target cache is determined to be a local memory cache.

6. The method according to claim 5, wherein, In response to determining that the target identifier of the target resource is not found in the target cache, the generation of resource record information for the target resource includes: In response to determining that the target identifier is not found in the local memory cache, resource record information for the target resource is generated; The target identifier is stored in the local memory cache.

7. The method according to claim 1, further comprising: In response to determining whether to start the service instance, load idempotent cache data from a local file; The cache area for storing the idempotent cache data is determined based on the loading time of the idempotent cache data and the resource usage time of the idempotent cache data.

8. The method according to claim 7, wherein, The step of determining the cache area for storing the idempotent cache data based on the loading time of the idempotent cache data and the resource usage time of the idempotent cache data includes: In response to determining that the resource usage time is greater than or equal to a third time, the cache area storing the idempotent cache data is determined to be a distributed cache area, wherein the third time is the difference between the loading time and the distributed cache time, and the distributed cache time is determined based on the idempotent validity period.

9. The method according to claim 7, wherein, The step of determining the cache area for storing the idempotent cache data based on the loading time of the idempotent cache data and the resource usage time of the idempotent cache data includes: The first memory cache time is determined from the key-value mapping table based on the cache identifier of the idempotent cache data, wherein the first memory cache time is the memory cache time corresponding to the idempotent cache data; In response to determining that the resource usage time is less than or equal to a fourth time, the cache area storing the idempotent cache data is determined to be a local memory cache area, wherein the fourth time is the difference between the loading time and the first memory cache time.

10. The method according to claim 1, further comprising: In response to the detection that the memory cache time has changed to a second memory cache time, and the second memory cache time is greater than the memory cache time, a target time is determined, wherein the target time is the difference between the change time of the memory cache time and the memory cache time; Receive a new resource usage record message for the target resource, and calculate a fifth time, wherein the fifth time is the difference between the new reception time of the new resource usage record message and the second memory cache time; In response to determining that the fifth time is greater than or equal to the target time, the memory cache time of the target resource in the key-value mapping table is updated to the second memory cache time.

11. The method of claim 10, further comprising: In response to the detection that the memory cache time has changed to the second memory cache time, and the second memory cache time is less than the memory cache time, the memory cache time of the target resource in the key-value mapping table is updated to the second memory cache time.

12. An information generation apparatus, comprising: The cache time determination module is configured to receive a resource usage record message for a target resource, and determine the memory cache time corresponding to the target resource from a pre-generated key-value mapping table based on the target resource usage time in the resource usage record message and a predefined idempotent validity period. The cache area determination module is configured to determine the target cache area for querying the target resource based on the memory cache time, the target resource usage time, and the idempotency. The information generation module is configured to generate resource record information for the target resource in response to determining that the target identifier of the target resource is not found in the target cache.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-11.

Images