Cache refresh method and apparatus

Abstract

This invention relates to the field of Fintech and discloses a cache refresh method and apparatus applicable to service nodes of the same application service in a distributed system. At a first predetermined time, each service node determines, based on a cache refresh pre-check thread, whether the database has been updated relative to its local cache. Upon confirming an update, the first predetermined time is recorded in a cache refresh time record. At a second predetermined time, based on a cache refresh thread, the service node determines that the difference between the first and second predetermined times in the cache refresh time record is less than a first predetermined threshold, and then updates its local cache according to the database. The second predetermined time is after the first predetermined time. This method ensures data consistency in the local caches of each service node constituting the same application service in a distributed system from beginning to end.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of financial technology (Fintech), and in particular, to a cache refresh method and device. BACKGROUND

[0002] With the development of computer technology, more and more technologies (for example: big data, cloud computing or blockchain) are applied in the financial field, and the traditional financial industry is gradually changing to financial technology. For the massive transaction data generated in the financial field, the database can be used to store it. When the transaction is processed through a distributed system, through the cache refresh technology, the data of the database can be refreshed to the local cache of each service node, so as to greatly improve the response speed and system throughput of the service. However, the current cache refresh is completed by periodic asynchronous processing tasks, which obviously cannot achieve the synchronization of the cache refresh of each service node at the same time point. It is also because that the cache refresh of each service node cannot be synchronized at the same time point that it is difficult to keep the data consistency of the local cache of the multiple service nodes on which the same application service is deployed. However, in reality, when the same application service is deployed on multiple service nodes, the multiple service nodes need to provide services according to the same performance, that is, the data consistency of the JVM level cache of each service node needs to be ensured when the cache is refreshed, so as to ensure that the transaction request entering the distributed system and being routed to any service node has the same processing result.

[0003] For the problem that the cache refresh technology described above cannot ensure the consistency of the local cache data of each service node, the problem can be solved by adjusting the cache refresh to be triggered at a fixed time. However, even if the cache refresh is triggered at a fixed time, it still cannot solve the problem that the JVM (Java Virtual Machine) cache data of each service node is inconsistent and the function is disorderly caused by updating the database at the cache refresh critical point. SUMMARY

[0004] The present application provides a cache refresh method and device to achieve the goal that the local cache of each service node can still keep consistent when the database is updated at the cache refresh critical point.

[0005] In a first aspect, the embodiments of the present application provide a cache refreshing method, which is suitable for each service node of a same application service in a distributed system. The method comprises: determining, by the service node based on a cache refreshing pre-check thread at a first set time, whether the database is updated relative to the local cache, and recording the first set time in a cache refreshing time record after determining that the database is updated; determining, by the service node based on a cache refreshing thread at a second set time, that a difference between the first set time in the cache refreshing time record and the second set time is less than a first set threshold, and updating the local cache according to the database; and the second set time is located after the first set time.

[0006] In the above scheme, when determining whether to update the local cache of the service node based on comparison with the database, two types of threads are set in the service node. One thread is used to detect whether the database is updated at the first set time, and record the detection time (i.e. the first set time) at this time in the cache refreshing time record when it is determined that the database is updated. The other thread is used to determine whether the difference between the second time and the first set time in the cache refreshing time record is greater than the first set threshold at the second set time, and update the local cache of the service node according to the database when it is determined that the difference is less than the first set threshold. In this way, the consistency of the data of the local cache of each service node constituting the same application service in the distributed system can be achieved from the beginning to the end.

[0007] In a possible implementation, the service node does not refresh the local cache when it is determined based on the cache refreshing thread at the second set time that the difference between the first set time in the cache refreshing time record and the second set time is not less than the first set threshold.

[0008] In the above scheme, when the other thread determines at the second set time that the difference between the second time and the first set time in the cache refreshing time record is not less than the first set threshold, the service node will not refresh the local cache. In this way, for each service node constituting the same application service, it can be ensured that the problem of inconsistency of the local cache of each service node caused by the fact that some service nodes do not perform cache refreshing while other service nodes perform cache refreshing under the same cache refreshing thread does not occur. Furthermore, the processing result obtained when any one of the service nodes processes a transaction request is consistent, and the success rate of transaction processing is increased.

[0009] In one possible implementation, the first set time is determined based on a first period, and the second set time is determined based on a second period; the difference between the first set time and the second set time in the same period is not greater than a second set threshold; and the number of times the same data table in the database is updated within the sum of the first period and the second set threshold is not greater than 1.

[0010] In the above scheme, a first set time can be set in a first cycle, and a second set time can be set in a second cycle. Simultaneously, during a cycle of determining whether to refresh the local cache of the service node, the difference between the first set time and the second set time is no greater than the second set threshold. Therefore, if the number of updates to the same data table in the database within the sum of the first cycle and the second set threshold is no greater than 1, it can be guaranteed that the result of a user update at the first set time will be refreshed by the service node's local cache at the second set time. Conversely, the result of a user update in a cycle prior to the first set time will not be refreshed by the service node's local cache at the second time node. This ensures the consistency of data in the local caches of each service node constituting the same application service in the distributed system from beginning to end.

[0011] In one possible implementation, the local cache of the service node includes a first cache definition table for each first cache data table; determining whether the database has been updated relative to the local cache includes: the service node obtaining a second cache definition table for each second cache data table in the database; the service node comparing the first cache definition table and the second cache definition table for the same cache data table to determine whether the database has been updated relative to the local cache.

[0012] In the above scheme, the database stores various cache data tables and cache definition tables for each cache data table. All user update operations on the database can be reflected through changes in the cache definition tables. Therefore, when determining whether the database has been updated relative to the local cache of the service node, the service node can first obtain the second cache definition tables for each second cache data table from the database. Then, the service node can compare the first and second cache definition tables in the local cache under the same cache data table to quickly determine whether the local cache has been updated relative to the database. This allows the service node to determine whether the current detection time should be updated to the cache refresh time record to facilitate subsequent cache refresh operations.

[0013] In one possible implementation, the local cache contains an old cache object; the old cache object records each first cache definition table and each first cache data table in the local cache; updating the local cache according to the database includes: the service node generating a new cache object in the local cache; the new cache object recording each second cache definition table and each second cache data table in the database; the service node processing each transaction entering the service node based on the old cache object pointed to by the thread-level cache data pointer; after each transaction is processed, the service node points the thread-level cache data pointer to the new cache object and deletes the old cache object, thereby processing each transaction entering the service node based on the new cache object.

[0014] In the above scheme, to ensure that the query results obtained when querying the cached data of the service node twice before and after the same transaction are refreshed when the service node refreshes the local cache, for each transaction that enters the service node before the service node refreshes the local cache, the service node can point it to the old cache object in the local cache based on the thread-level cache data pointer, so that the first cache definition table and the first cache data table in the old cache object can be used to process each transaction. When the service node determines that it needs to update the local cache based on the database, a new cache object can be generated in the local cache. After replacing the old cache object with the new cache object, the thread-level cache data pointer can be pointed to the new cache object, so that the second cache definition table and the first cache data table in the new cache object can be used to process each transaction that enters the service node at the time when the cache object begins to be replaced. After processing each transaction that enters the service node at the time when the cache object begins to be replaced based on the old cache object, the old cache object can be deleted. In this way, only one copy of the global cache data is retained in the service node outside of the short period of cache refresh, which can greatly reduce the waste of memory resources.

[0015] In one possible implementation, after each transaction is processed, the service node points the thread-level cache data pointer to the new cache object, including: after each transaction is processed, the service node points the thread-level cache data pointer to the new cache object based on an atomic operation.

[0016] In the above scheme, during the process of replacing the old cache object with the newly generated cache object in the service node, atomic operations can be used to ensure that each first cache definition table and each first cache data table have been successfully replaced by each second cache definition table and each second cache data table respectively. This avoids the problem of query failure or query result error caused by only one item being replaced while the other item is not replaced. In this way, the thread-level cache data pointer can be pointed to the new cache object.

[0017] In one possible implementation, the service node randomly selects another service node and sends the first clock information of the service node to the other service node; the first clock information is used by the other service node to determine whether it needs to synchronize its clock with the clock management system; the service node receives the second clock information sent by the other service node; after determining that the second clock information and the third clock information of the service node exceed a third preset threshold, the service node synchronizes its clock with the clock management system.

[0018] In the above scheme, a clock cross-checking mechanism is introduced on the basis of clock synchronization, which can realize the system time synchronization of each service node, reduce the difference in asynchronous task scheduling time, and thus further ensure the synchronization of cache refresh time.

[0019] Secondly, embodiments of this application provide a cache refresh device applicable to service nodes of the same application service in a distributed system. The device includes: an update determination unit, configured to determine, based on a cache refresh pre-detection thread at a first predetermined time, whether the database has been updated relative to the local cache, and after determining that an update has occurred, record the first predetermined time in a cache refresh time record; and a cache refresh unit, configured to, based on a cache refresh thread at a second predetermined time, update the local cache according to the database after determining that the difference between the first predetermined time and the second predetermined time in the cache refresh time record is less than a first predetermined threshold; the second predetermined time is located after the first predetermined time.

[0020] In one possible implementation, the cache refresh unit is further configured to, based on the cache refresh thread, determine that the difference between the first set time and the second set time in the cache refresh time record is not less than the first set threshold, and then not refresh the local cache.

[0021] In one possible implementation, the first set time is determined based on a first period, and the second set time is determined based on a second period; the difference between the first set time and the second set time in the same period is not greater than a second set threshold; and the number of times the same data table in the database is updated within the sum of the first period and the second set threshold is not greater than 1.

[0022] In one possible implementation, the local cache of the service node includes a first cache definition table for each first cache data table; the update determination unit is specifically used to: obtain a second cache definition table for each second cache data table in the database; compare the first cache definition table for the same cache data table with the second cache definition table to determine whether the database has been updated relative to the local cache.

[0023] In one possible implementation, the local cache contains an old cache object; the old cache object records each first cache definition table and each first cache data table in the local cache; the cache refresh unit is specifically used to: generate a new cache object in the local cache; the new cache object records each second cache definition table and each second cache data table of the database; process each transaction entering the service node based on the old cache object pointed to by the thread-level cache data pointer; after each transaction is processed, point the thread-level cache data pointer to the new cache object and delete the old cache object, thereby processing each transaction entering the service node based on the new cache object.

[0024] In one possible implementation, the cache refresh unit is further configured to: after each transaction is processed, point the thread-level cache data pointer to the new cache object based on an atomic operation.

[0025] In one possible implementation, the apparatus further includes a clock synchronization unit; the clock synchronization unit is configured to: randomly select another service node and send the first clock information of the service node to the other service node; the first clock information is used by the other service node to determine whether it needs to synchronize its clock with the clock management system; receive the second clock information sent by the other service node; and synchronize its clock with the clock management system after determining that the second clock information and the third clock information of the service node exceed a third preset threshold.

[0026] Thirdly, embodiments of this application provide a computing device, including:

[0027] Memory, used to store program instructions;

[0028] A processor is configured to invoke program instructions stored in the memory and execute any implementation method of the first aspect according to the obtained program.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform any implementation method as described in the first aspect. Attached Figure Description

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

[0031] Figure 1 A schematic diagram of the architecture of a distributed system provided in this application embodiment;

[0032] Figure 2 A schematic diagram illustrating a cache refresh method provided in an embodiment of this application;

[0033] Figure 3 A schematic diagram of a cache refresh device provided in an embodiment of this application;

[0034] Figure 4 A computing device provided in an embodiment of this application. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] like Figure 1 The diagram shown is an architectural representation of a distributed system according to an embodiment of this application, wherein the distributed system includes at least one service node 110 and at least one database 120. As an example, Figure 1This example uses five service nodes: Service Node 1 (identified as 1101), Service Node 2 (identified as 1102), Service Node 3 (identified as 1103), Service Node 4 (identified as 1104), and Service Node 5 (identified as 1105). Based on the actual needs of the product (i.e., application service), for example, processing Service Node 1 and Service Node 2 can constitute a limit-related application service, where Service Node 1 and Service Node 2 share the same database, such as Database 1 (identified as 1201); similarly, processing Service Node 1, Service Node 3, and Service Node 4 can constitute an interest-related application service, where Service Node 1, Service Node 3, and Service Node 4 share the same database, such as Database 2 (identified as 1202); and furthermore, processing Service Node 2, Service Node 4, and Service Node 5 can constitute a user identity verification application service, where Service Node 2, Service Node 4, and Service Node 5 share the same database, such as Database 3 (identified as 1203).

[0037] for Figure 1 The distributed system shown utilizes cache refresh technology to refresh database data to the local cache of each service node, which can greatly improve service response speed and system throughput. However, current cache refresh is accomplished through periodic asynchronous processing tasks. For example, in the quota-related application service consisting of service node 1 and service node 2 in the above example, the cache of one of the service nodes can be refreshed every 30 seconds. For instance, the cache of service node 1 is refreshed at 1 minute and 15 seconds, the cache of service node 2 is refreshed at 1 minute and 45 seconds, the cache of service node 2 is refreshed at 2 minutes and 15 seconds, the cache of service node 2 is refreshed at 2 minutes and 45 seconds, and so on. This obviously cannot achieve synchronous cache refresh of each service node at the same time. It is precisely because it is impossible to achieve synchronous cache refresh of each service node at the same time that it is difficult to maintain data consistency in the local cache of multiple service nodes where the same application service is deployed. In reality, when the same application service is deployed on multiple service nodes, these multiple service nodes need to provide services to the outside world with the same performance. That is, when the JVM-level cache data of each service node is refreshed, the data consistency needs to be guaranteed to ensure that when a transaction request enters the distributed system and is routed to any service node, it will have the same processing result.

[0038] The problem that the cache refresh technology described above cannot ensure the consistency of local cached data on each service node can be solved by adjusting to timed cache refresh. However, timed refresh still cannot solve the problem of inconsistent JVM cached data and functional disorder on each service node caused by updating the database at the cache refresh critical point. For example, in a transaction with a limit, the cache refresh service is set to execute at a critical point of 15 seconds. At 15:001, service node 1 schedules an asynchronous task to refresh the cache. At this time, the cache version of service node 1 is version 1, with a transfer limit of 10,000. At 15:002, because the user changes the transfer limit to 50,000, the data in the database is refreshed, and the data version in the database is version 2. At 15:003, service node 2 schedules an asynchronous task to refresh the cache. At this time, the cache version of node 2 is version 2, with a transfer limit of 50,000. Then, in the next cycle, before the cache refresh at 45 seconds, the cache data of service node 1 and service node 2 will remain inconsistent. During this period, if a new transaction request for a transfer of 20,000 comes in, if it is routed to service node 1, the transaction will fail due to the limit. However, when the user retryes and is routed to service node 2, the transfer will succeed because the 50,000 limit has not been reached.

[0039] The aforementioned techniques for periodically triggering cache refreshes on each service node still suffer from issues such as inconsistencies in JVM cache data and functional malfunctions caused by updating the database at the cache refresh threshold. This application provides a cache refresh method applicable to service nodes of the same application service in a distributed system, such as... Figure 2 The diagram shown is a schematic representation of a cache refresh method provided in an embodiment of this application. The method includes:

[0040] Step 201: The service node determines whether the database has been updated relative to the local cache based on the cache refresh pre-check thread at a first set time, and records the first set time in the cache refresh time record after confirming the update.

[0041] Step 202: The service node, based on the cache refresh thread at a second set time, determines that the difference between the first set time and the second set time in the cache refresh time record is less than a first set threshold, and then updates the local cache according to the database; the second set time is after the first set time.

[0042] In the above scheme, when determining whether to update the local cache of a service node based on a comparison with the database, two types of threads are set up in the service node. One thread, the cache refresh pre-check thread, is used to check whether there is an update in the database at a first predetermined time, and when an update is confirmed, the detection time (i.e., the first predetermined time) is recorded in the cache refresh time record. The other thread, the cache refresh thread, is used to determine whether the difference between the second predetermined time and the first predetermined time in the cache refresh time record is greater than a first predetermined threshold at a second predetermined time, and when the difference is determined to be less than the first predetermined threshold, the local cache of the service node is updated according to the database. In this way, the consistency of data in the local caches of each service node constituting the same application service in the distributed system can be achieved from beginning to end.

[0043] The following will provide a detailed explanation of some of the steps mentioned above, with examples.

[0044] For example, in the previous example, the quota-related application service consisting of service node 1 and service node 2 in the distributed system corresponds to database 1. That is, service node 1 and service node 2 can connect to database 1 respectively and read and write to database 1. In this embodiment, for an application service, a cache refresh time stamp table can be created in the database corresponding to the application service, such as sys_cache_refresh. This table is used to mark the refresh start time when the cache needs to be refreshed, which is represented by a timestamp in milliseconds. Optionally, in this embodiment, the cache refresh time record is a cache refresh time stamp table. Referring to Table 1, Table 1 is the cache refresh time stamp table provided in this embodiment. When any service node in an application service detects that the cache data in the database it is connected to has been updated, it can update the current time to the begin_time field of this table.

[0045] Field name Type Null? Primary key Remark begin_time varchar(21) NO PRI Refresh start time

[0046] Table 1 Cache refresh time stamp table

[0047] For an application service consisting of several service nodes in a distributed system, this embodiment of the application can create a cache refresh time stamp table in the database corresponding to the application service. This table is used to update the current time to the begin_time field when any of the service nodes detects an update in the database. After completing these preparatory works, this embodiment of the application can create two types of polling threads in the several service nodes constituting the same application service. By periodically triggering these two types of polling threads, the consistency of JVM cached data in each service node can be ensured when the several service nodes update the database at the cache refresh critical point.

[0048] The two types of polling threads are as follows:

[0049] 1. Create a polling thread for cache refresh pre-checking, which is periodically scheduled every N seconds. For example, the task can be controlled to execute at 0 seconds / 30 seconds per minute using a Cron expression (0, 30****?), which is used to mark the refresh start time when the cache needs to be refreshed. Optionally, in this embodiment, the first period is 0 seconds / 30 seconds per minute. The specific execution steps of this polling thread are as follows:

[0050] a. Read all the latest cache configurations in the cache definition table sys_cache_def in the database, and compare each cache configuration with the old version cache definition cacheDefMap of the JVM cache; Optionally, in this embodiment, the cache definition table sys_cache_def is the second cache definition table, and the old version cache definition cacheDefMap is the first cache definition table;

[0051] b. If it is a newly added cache configuration, or if the cache configuration changes from 0 (disabled) to 1 (enabled), then the cache needs to be updated, and the comparison ends.

[0052] c. If the cache configuration changes from 1-enabled to 0-disabled, then the cache needs to be updated, and the comparison ends.

[0053] d. If the refreshNo version number configured in the cache is inconsistent with the refreshNo version number of the old version cache, then the cache needs to be updated, and the comparison ends.

[0054] e. After the comparison is completed, if it is found that the cache needs to be updated, update the begin_time field of the cache refresh time marker table from the current time to the cache refresh time marker to mark the cache refresh start time.

[0055] f. After the comparison is completed, if no cache configuration needs to be updated, the begin_time field of the cache refresh flag table will not be updated.

[0056] In a distributed system, the service nodes constituting a particular application service can periodically schedule cache refresh pre-check tasks according to the steps described above. Upon discovering that the database has updated cached data, the service node will update the cache refresh start time in the cache refresh timestamp table. If the database update occurs precisely at the critical point of the cache refresh pre-check task execution, then as long as one service node captures this database update, the database cache refresh start time will be updated. In the subsequent cache refresh execution phase, all service nodes will read the updated cache refresh start time from that service node and execute the cache refresh operation.

[0057] 2. Create a polling thread for cache refresh execution, changing the original periodic scheduling every N seconds to timed triggering. For example, change the 30-second periodic scheduling to using a Cron expression (15, 45****?) to control the task to execute at 15 seconds / 45 seconds per minute to handle cache refresh tasks. Optionally, in this embodiment, the second period is 15 seconds / 45 seconds per minute. The specific execution steps of this polling thread are as follows:

[0058] a. Read the cache refresh start time from the cache refresh time stamp table and compare it with the current system time;

[0059] b. If the difference between the current time and the cache refresh start time is less than N seconds, a new cache data object is created first, then the original cache refresh process is executed, and the global cache data is replaced with the new cache version after the cache refresh is completed.

[0060] c. If the difference between the current time and the cache refresh start time is greater than or equal to the first set threshold, it is considered that no instruction to refresh the cache has been received. The cache refresh will not be performed in this cycle. The cache refresh will be performed again after the cache refresh pre-check thread re-marks the cache refresh start time in the next cycle. This process is repeated.

[0061] This process ensures that data updates at the critical point of cache refresh are delayed until the next scheduled task execution time. For example, if the database cache data is updated at 15 seconds, regardless of whether the cache refresh threads on each service node capture this update, the refresh will be delayed until 45 seconds. This avoids inconsistencies in the local caches of each service node due to data updates at the critical point during the next cache refresh cycle. Specifically, assuming the database data is updated at 2 minutes and 15 seconds, and there have been no updates in the short period before that, meaning the cache refresh start time in the cache refresh time stamp table must be before 1 minute and 30 seconds, the difference between the current time and the refresh start time must be greater than 30 seconds. Therefore, the cache refresh task scheduled at 2 minutes and 15 seconds will not refresh the local cache regardless of whether it captures the database update at this critical point. After the 2 minutes and 30 seconds mark time is updated, each service node can perform a normal cache refresh at 2 minutes and 45 seconds. Optionally, in this embodiment, the first threshold is set to 30 seconds.

[0062] Additionally, assuming the database data is updated at the critical point of 2 minutes and 0 seconds before the cache refresh start time, as long as one service node can capture the database update, the refresh start time of the cache refresh time marker table will be updated. Then, at 2 minutes and 15 seconds, each service node can read the cache refresh start time marked by that service node and determine that the difference between the current time and the refresh start time is less than 30 seconds. Then, each service node can perform a cache refresh.

[0063] Based on the above analysis, the corresponding data update time of the database and the time when the data is finally flushed to the JVM cache of each service node are shown in Table 2 below, thus ensuring the synchronization of the JVM-level cache refresh time of each service node in the distributed system.

[0064] Database update data time Actual execution of each node cache refresh time (1 minute 30 seconds, 2 minutes 0 seconds] 2 minutes 15 seconds (2 minutes 0 seconds, 2 minutes 30 seconds] 2 minutes 45 seconds (2 minutes 30 seconds, 3 minutes 0 seconds] 3 minutes 15 seconds …… ……

[0065] Table 2. Correspondence between database update time and the time when data is finally flushed to the JVM cache of each service node.

[0066] The following two specific examples illustrate this point.

[0067] Example 1:

[0068] In the previous example, service node 1 and service node 2 in the distributed system constitute a quota product (i.e., application service). Taking database 1 as an example, if a user updates database 1 at 2 minutes and 0 seconds, either service node 1 or service node 2, upon detecting the update, can update the timestamp corresponding to 2 minutes and 0 seconds to the begin_time field of the cache refresh time stamp table. Thus, at 2 minutes and 15 seconds, service node 1 and service node 2 read the refresh start time as 2 minutes and 0 seconds from the begin_time field of the cache refresh time stamp table of database 1. By comparing the refresh start time of 2 minutes and 0 seconds with their current time of 2 minutes and 15 seconds, and determining that the difference is less than a first set threshold, such as 30 seconds, both service node 1 and service node 2 will refresh their local cache based on the current database 1. It should be noted that during this process, since database 1 has already updated the cached data at 2 minutes and 0 seconds, the user will not update database 1 again within a relatively fixed time period (such as 45 seconds). Therefore, when service node 1 and service node 2 update their local caches at different milliseconds at 2 minutes and 15 seconds, database 1 will not be updated again. In other words, although service node 1 and service node 2 may update their local caches at different milliseconds at 2 minutes and 15 seconds, both will be updating based on the same version of the database data. At this time, it can be guaranteed that the local caches of service node 1 and service node 2 will be consistent.

[0069] Example 2:

[0070] In the previous example, service node 1 and service node 2 in the distributed system constitute a quota product (i.e., application service). Taking database 1 as an example, if at 2 minutes and 0 seconds, neither service node 1 nor service node 2 detects that database 1 has been updated, then neither service node 1 nor service node 2 needs to update the value of the begin_time field in the cache refresh time stamp table. This means that the value of the begin_time field in the cache refresh time stamp table is at least 1 minute and 30 seconds (or an earlier time than 1 minute and 30 seconds). Then, at 2 minutes and 15 seconds, service node 1 and service node 2 read the refresh start time as 1 minute and 30 seconds from the begin_time field of the cache refresh time stamp table of database 1. The two service nodes compare the refresh start time of 1 minute and 30 seconds with their current time of 2 minutes and 15 seconds and determine that the difference is greater than a first set threshold, such as 30 seconds. Therefore, neither service node 1 nor service node 2 will refresh their local cache based on the current database 1. It should be noted that during this process, since database 1 has already updated the cached data at 1 minute and 30 seconds, the user will not update database 1 again within a relatively fixed time period (e.g., 45 seconds). That is, when the cache refresh pre-check task is executed at 2 minutes and 0 seconds, the user will not update the database at this time. Therefore, when service node 1 and service node 2 determine whether their local caches are inconsistent with the cached data of database 1 at 2 minutes and 0 seconds, neither service node 1 nor service node 2 will detect any inconsistency between their local caches and the cached data of database 1. Consequently, service node 1 and service node 2 will not update the value of the begin_time field in the cache refresh time stamp table. Optionally, in this embodiment, the second set threshold is the difference between 15 seconds and 0 seconds per minute, or the difference between 30 seconds and 15 seconds per minute, or the difference between 45 seconds and 30 seconds per minute, or the difference between 60 seconds and 45 seconds per minute. That is, in this example, the second set threshold is 15 seconds. Optionally, in this embodiment, the sum of the first period and the second set threshold is 45 seconds (the sum of 30 seconds and 15 seconds), that is, a relatively fixed time period indicated in this embodiment is the sum of the first period and the second set threshold, which is 45 seconds.

[0071] Currently, responding to transaction requests entering a distributed system based on local cached data on each service node can improve service response speed and system throughput. However, if the cache version is refreshed between two queries within the same transaction, inconsistencies can occur, potentially leading to serious financial transaction problems such as inconsistent product information in the database or incompatibility between old and new versions due to feature changes. Therefore, ensuring the consistency of the cache version when service nodes refresh their local cache based on the database's cached data is of paramount importance.

[0072] To address the issue of inconsistent query data for the same transaction caused by inconsistent cache versions, this application embodiment implements cache refresh version consistency through a thread-level variable `globalRefs`. Furthermore, except for the brief period during cache refresh, the application system cache retains only one copy of the global cache data. This approach significantly reduces the waste of memory resources. The solution described below is a detailed account of this application:

[0073] Before describing the solution in this application, the terms used in the solution will be explained as follows:

[0074] Referring to Table 3, the definition of global cache references, GlobalCacheRefs, provided in the embodiments of this application includes:

[0075]

[0076] Table 3 Definitions of Global Cache References

[0077] The global cache reference includes cache data references and cache definition references. The attribute type GlobalDataCache represents the overall structure of the JVM cache data area, while SysCacheDef represents the cache definition configuration.

[0078] Referring to Table 4, the cached data variable definitions provided in the embodiments of this application include:

[0079]

[0080] Table 4 Definition of Cache Data Variables

[0081] In a distributed system, each service node that constitutes the same application service periodically schedules a polling thread to refresh its cache. If the cached data in the database differs from the local cached data, each service node needs to update its local cached data based on the database's cached data. This ensures the consistency of the local caches across all service nodes, allowing any transaction request to be routed to a service node for correct processing when it enters the distributed system. Specifically, updating the local cached data based on the database's cached data can be implemented using the following method:

[0082] a. After the application service starts, each service node loads the data from the database into the local cache. The local cache will always retain a copy of the global cache data, including the cache definition cacheDefs and the cache data globalData.

[0083] b. When a transaction arrives and a new thread is created to execute the request, the thread-level variable `globalRefs` is initialized and points to the local global cache data `cacheDefs` and `globalData`. At this time, no cache refresh is performed, and the initialization process does not require locking. After initialization, the cached version obtained throughout the entire transaction processing is the current cached version.

[0084] c. When the cache refresh polling thread detects changes in the database cache data, it will perform a cache refresh. During the cache refresh process, it will first create new data objects newCacheDefs and newGlobalData in memory to store the new version of the cache definition configuration and cache data.

[0085] d. Before the cache refresh process ends, the globalRefs pointer for all transaction requests received by the system is always initialized to point to the old versions of cached data cacheDefs and globalData, and the reference to the old version cache object is released only after the transaction is completed. During this process, the initialization of thread-level variables needs to be implemented using locking.

[0086] e. At the end of the cache refresh, the global cache variables `cacheDefs` and `globalData` are replaced to point to the new cache data objects `newCacheDefs` and `newGlobalData`, thus replacing the global cache data with the latest cache version. This replacement process is also implemented using locking.

[0087] f. After the cache refresh is complete, the thread-level variable `globalRefs` for new transactions entering the system will be initialized to the new version of the global cache data. Once all transactions prior to this point have been executed, the old version of the cache data will be automatically garbage collected as all references are released. Therefore, except for the brief period during the cache refresh process, only one copy of the cache data is ever retained in the local cache.

[0088] It should be noted that, in the embodiments of this application, atomic operations include: during the cache refresh process, the process of initializing thread-level variables upon transaction arrival and replacing the new version of the global cache upon cache refresh completion is implemented through a synchronization lock. Mutual exclusion access is achieved by locking the same object, ensuring that the cache definition and cache data are atomically assigned, thereby ensuring the consistency of the cache definition and cache data themselves.

[0089] In addition, to improve the efficiency of normal transaction execution, locking operations are not performed when the system does not perform cache refresh, thereby reducing the overhead of acquiring and releasing locks.

[0090] Based on this method, the consistency of cached versions of the same transaction can be achieved when the service node refreshes the local cached data based on the database cached data. In addition, since there are only two cached data in the local cache for a short period of time, and only one cached data is kept in the local cache most of the time, the waste of memory resources can be greatly reduced.

[0091] Furthermore, clock synchronization among service nodes is another strong guarantee for the synchronization of JVM-level cache refresh times across service nodes in a distributed system. It ensures that each service node schedules asynchronous tasks to refresh the cache at the same time, minimizing cache consistency issues caused by clock asynchrony. Building upon the basic NTP (Network Time Protocol) synchronization, this application further implements a clock cross-checking mechanism among service nodes within the distributed system.

[0092] Create a polling thread to periodically perform clock crossover checks. Since the check logic is lightweight, it can be defined to check every 60 seconds to detect time inconsistencies more promptly. The specific steps are as follows:

[0093] a. The current service node 1 randomly selects any other service node 2 from all service nodes in the system for cross-checking;

[0094] b. The current service node 1 sends a request to the randomly selected service node 2, including the current time of service node 1 and the IP address of service node 1;

[0095] c. When Service Node 2 receives the clock check request from Service Node 1, it obtains the current time of Service Node 1 and compares whether the current time of Service Node 2 is behind a certain threshold (e.g., 100 milliseconds) of the time of Service Node 1. If it is behind, it will issue an alarm and notify the clock management system to resynchronize the clock to Service Node 2. At the same time, it will return the current time and IP address of Service Node 2 to Service Node 1.

[0096] d. Service node 1 obtains the current time returned by service node 2 and compares whether the current time of service node 1 is behind a certain threshold (such as 100 milliseconds) of the current time of service node 2. If it is behind, it will also issue an alarm and notify the clock management system to resynchronize the clock to service node 1.

[0097] It's important to note that after service node 1 obtains the current system time and sends it to service node 2, service node 2 then compares this time with its own current time. Theoretically, there should be a message sending delay between these two times. However, since this message communication takes a very short time (usually less than 2 milliseconds), this time difference is negligible. Similarly, when service node 1 obtains the current time returned by service node 2 and compares it with its own current time, the process is the same.

[0098] Each service node randomly selects other service nodes to perform clock checks according to the above steps. Through continuous pairwise cross-checks, the consistency of clocks among all service nodes in the system is ultimately ensured.

[0099] Based on the same concept, embodiments of this application provide a cache refresh device, such as... Figure 3 The diagram shown is a schematic of a cache refresh device provided in an embodiment of this application. The device includes an update determination unit 301 and a cache refresh unit 302.

[0100] The update determination unit 301 is used to determine whether the database has been updated relative to the local cache based on the cache refresh pre-detection thread at a first set time, and after determining that an update has been made, record the first set time in the cache refresh time record;

[0101] The cache refresh unit 302 is used to update the local cache according to the database after determining, based on the cache refresh thread at a second set time, that the difference between the first set time and the second set time in the cache refresh time record is less than a first set threshold; the second set time is located after the first set time.

[0102] Furthermore, for this device, the cache refresh unit 302 is also configured to, based on the cache refresh thread, determine that the difference between the first set time and the second set time in the cache refresh time record is not less than the first set threshold, and then not refresh the local cache.

[0103] Furthermore, for this device, the first set time is determined based on a first cycle, and the second set time is determined based on a second cycle; the difference between the first set time and the second set time in the same cycle is not greater than the second set threshold; the number of times the same data table in the database is updated within the sum of the first cycle and the second set threshold is not greater than 1.

[0104] Furthermore, for this device, the local cache of the service node includes a first cache definition table for each first cache data table; the update determination unit 301 is specifically used to: obtain a second cache definition table for each second cache data table in the database; compare the first cache definition table for the same cache data table with the second cache definition table to determine whether the database has been updated relative to the local cache.

[0105] Furthermore, for this device, the local cache contains old cache objects; the old cache objects record each first cache definition table and each first cache data table in the local cache; the cache refresh unit 302 is specifically used for: generating a new cache object in the local cache; the new cache object records each second cache definition table and each second cache data table of the database; processing each transaction entering the service node based on the old cache object pointed to by the thread-level cache data pointer; after each transaction is processed, pointing the thread-level cache data pointer to the new cache object and deleting the old cache object, thereby processing each transaction entering the service node based on the new cache object.

[0106] Furthermore, for this device, the cache refresh unit 302 is also used to: after each transaction is processed, based on atomic operations, point the thread-level cache data pointer to the new cache object.

[0107] Furthermore, the device also includes a clock synchronization unit 303; the clock synchronization unit 303 is used to: randomly select another service node and send the first clock information of the service node to the other service node; the first clock information is used by the other service node to determine whether it needs to synchronize its clock with the clock management system; receive the second clock information sent by the other service node; and synchronize its clock with the clock management system after determining that the second clock information and the third clock information of the service node exceed a third preset threshold.

[0108] This application also provides a computing device, which may specifically be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), etc. The computing device may include a central processing unit (CPU), memory, input / output devices, etc. Input devices may include a keyboard, mouse, touchscreen, etc., and output devices may include display devices, such as liquid crystal displays (LCDs) and cathode ray tubes (CRTs).

[0109] The memory may include read-only memory (ROM) and random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In the embodiments of this application, the memory may be used to store program instructions for a cache refresh method;

[0110] The processor is used to call program instructions stored in the memory and execute a cache refresh method according to the obtained program.

[0111] like Figure 4 The diagram shown is a schematic representation of a computing device provided in an embodiment of this application. The computing device includes:

[0112] The processor 401, memory 402, transceiver 403, and bus interface 404 are provided; wherein the processor 401, memory 402, and transceiver 403 are connected via bus 405.

[0113] The processor 401 is used to read the program in the memory 402 and execute the above-described cache refresh method;

[0114] Processor 401 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. It can also be a hardware chip. The aforementioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0115] The memory 402 is used to store one or more executable programs and can store data used by the processor 401 when performing operations.

[0116] Specifically, the program may include program code, which includes computer operation instructions. Memory 402 may include volatile memory, such as random-access memory (RAM); memory 402 may also include non-volatile memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 402 may also include combinations of the above types of memory.

[0117] Memory 402 stores the following elements: executable modules or data structures, or subsets thereof, or extended sets thereof:

[0118] Operation instructions: This includes various operation instructions used to perform various operations.

[0119] Operating system: includes various system programs used to implement various basic business functions and handle hardware-based tasks.

[0120] The 405 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0121] Bus interface 404 can be a wired communication interface, a wireless bus interface, or a combination thereof. The wired bus interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless bus interface can be a WLAN interface.

[0122] This application also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute a cache refresh method.

[0123] Those skilled in the art will understand that embodiments of this application can be provided as methods or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0124] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0125] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0126] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes ​ The steps of the function specified in one or more boxes.

[0127] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0128] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A cache flush method, characterized by, The method is suitable for service nodes of the same application service in a distributed system, and comprises: The service node determines whether the database is updated relative to the local cache based on a cache refresh pre-check thread at a first set time, and records the first set time in a cache refresh time record after determining that the database is updated; The service node updates the local cache according to the database after determining that a difference between the first set time and a second set time in the cache refresh time record is less than a first set threshold based on a cache refresh thread at the second set time; the second set time is located after the first set time; The first set time is determined according to a first period, and the second set time is determined according to a second period; a difference between the first set time and the second set time in the same period is not greater than a second set threshold; a same data table of the database is updated not more than once within a time length of a sum of the first period and the second set threshold.

2. The method of claim 1, wherein, The method further comprises: The service node does not refresh the local cache after determining that the difference between the first set time and the second set time in the cache refresh time record is not less than the first set threshold based on the cache refresh thread at the second set time.

3. The method of claim 1, wherein, The local cache of the service node comprises a first cache definition table for each first cache data table; The determination of whether the database is updated relative to the local cache comprises: The service node acquires a second cache definition table for each second cache data table in the database; The service node compares the first cache definition table and the second cache definition table for the same cache data table to determine whether the database is updated relative to the local cache.

4. The method of claim 1, wherein, The local cache is provided with an old cache object; the old cache object records each first cache definition table and each first cache data table in the local cache; The updating of the local cache according to the database comprises: The service node generates a new cache object in the local cache; the new cache object records each second cache definition table and each second cache data table of the database; The service node processes each transaction entering the service node based on an old cache object pointed to by a thread-level cache data pointer; The service node points the thread-level cache data pointer to the new cache object and deletes the old cache object after the processing of each transaction is completed, so that each transaction entering the service node is processed based on the new cache object.

5. The method of claim 4, wherein: The service node points the thread-level cache data pointer to the new cache object after the processing of each transaction is completed, comprising: The service node points the thread-level cache data pointer to the new cache object based on an atomic operation after the processing of each transaction is completed.

6. The method according to any one of claims 1 to 5, wherein, The method further comprises: The service node randomly selects another service node and sends first clock information of the service node to the another service node; the first clock information is used for the another service node to determine whether clock synchronization to a clock management system is needed; The service node receives second clock information sent by the another service node; The service node performs clock synchronization to the clock management system after determining that the second clock information and third clock information of the service node exceed a third set threshold.

7. A cache flush apparatus, characterized by comprising: The device is suitable for each service node of a same application service in a distributed system, and the device comprises: An update determination unit is configured to determine whether a database is updated relative to a local cache based on a cache refresh pre-check thread at a first set time, and record the first set time in a cache refresh time record after determining that the database is updated; A cache refresh unit is configured to update the local cache according to the database after determining that a difference between the first set time in the cache refresh time record and a second set time is less than a first set threshold based on a cache refresh thread at the second set time; the second set time is located after the first set time; The first set time is determined according to a first period, and the second set time is determined according to a second period; a difference between the first set time and the second set time in a same period is not greater than a second set threshold; a same data table of the database is updated not more than once within a time length of a sum of the first period and the second set threshold.

8. A computer device, comprising: The device comprises: A memory configured to store a computer program; A processor configured to call the computer program stored in the memory and execute the method according to any one of claims 1-6 according to an obtained program.

9. A computer-readable storage medium, characterized in that, The storage medium stores computer executable instructions, and the computer executable instructions are used to make a computer execute the method according to any one of claims 1-6.

Images