A method and system for data synchronization between cache and database

Abstract

This invention provides a method and system for synchronizing data between a cache and a database. The data synchronization system includes an application service, RabbitMQ middleware, a cache, and a database. The application service updates target data in the database; the application service deletes the target data from the cache; when the RabbitMQ middleware receives a cache deletion failure message from the application service, it triggers the application service to delete the target data from the cache again until the target data in the cache is successfully deleted. By updating the data first and then deleting the cache, data consistency between the cache and the database is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of database technology, and more specifically, to a method and system for synchronizing data between a cache and a database. Background Technology

[0002] In the field of database technology, to reduce the load on the database and improve response efficiency to users, database data is typically synchronized to a cache, which users can access to retrieve the corresponding data. Ensuring consistency between the database and the cache during data updates is a pressing technical problem that needs to be solved in this field.

[0003] In existing technologies, in the strategy of updating the database first and then deleting the cache, if the cache deletion fails, the program assumes that the data exists in the cache, and the user will retrieve the returned data from the cache. Since the database data has been updated, the data retrieved by the user at this time is inconsistent with the data in the database, which leads to inconsistency between the database and the cache. Summary of the Invention

[0004] In view of this, the present invention provides a data synchronization method between a cache and a database, which ensures data consistency between the cache and the database by updating the data first and then deleting the cache.

[0005] To achieve the above-mentioned objectives, the present invention provides the following specific technical solution:

[0006] A data synchronization method between a cache and a database is provided, applied to a data synchronization system between a cache and a database. The data synchronization system includes an application service, RabbitMQ middleware, a cache, and a database. The method includes:

[0007] The application service updates the target data in the database;

[0008] The application service deletes the target data from the cache;

[0009] When the RabbitMQ middleware receives a cache deletion failure message from the application service, it triggers the application service to delete the target data in the cache again until the target data in the cache is successfully deleted.

[0010] Optionally, the application service includes business code sub-services and non-business code sub-services;

[0011] The application service updates the target data in the database, specifically as follows:

[0012] The business code sub-service updates the target data in the database;

[0013] The application service deletes the target data from the cache, specifically by:

[0014] The non-business code subservice obtains the target data updated in the database by the business code subservice and deletes the target data from the cache.

[0015] Optionally, the data synchronization system further includes a Kafka message queue, and after the business code subservice updates the target data in the database, the method further includes:

[0016] The database writes the target data into the binlog.

[0017] The Kafka message queue subscribes to the target data in the binlog log;

[0018] The non-business code subservice obtains the target data updated in the database by the business code subservice, including:

[0019] The non-business code sub-service obtains the target data updated in the database by the business code sub-service by reading the Kafka message queue.

[0020] Optionally, the database includes a master database and at least one slave database, the application service includes a first application service and a second application service, and after the first application service updates the target data in the master database, the method further includes:

[0021] The first application service sets an update flag in the cache. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time.

[0022] The second application service reads the update tag of the target data in the cache;

[0023] If the update flag of the target data in the cache has not expired, the second application service reads the target data from the main database;

[0024] If the update tag of the target data in the cache has expired, the second application server reads the target data from the slave database.

[0025] Optionally, the database includes a master database and at least one slave database, the application service includes a first application service and a second application service, and after the first application service updates the target data in the master database, the method further includes:

[0026] The first application server sets an update flag on the local client. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time.

[0027] If the update flag of the target data in the local client has not expired, the first application server reads the target data from the main database;

[0028] If the update tag of the target data in the local client has expired, the first application server reads the target data from the slave database.

[0029] Optionally, before the non-business code subservice deletes the target data in the cache, the method further includes:

[0030] The non-business code sub-service sends a delayed message to the RabbitMQ middleware, and the delay time of the delayed message is the same as the expiration time of the update tag;

[0031] When the RabbitMQ middleware receives the delayed message, it triggers the non-business code sub-service to delete the target data in the cache.

[0032] A data synchronization system between a cache and a database includes an application service, RabbitMQ middleware, a cache, and a database;

[0033] The application service is used to update the target data in the database and delete the target data in the cache;

[0034] The RabbitMQ middleware is used to trigger the application service to delete the target data in the cache again when it receives a cache deletion failure message sent by the application service, until the target data in the cache is successfully deleted.

[0035] Optionally, the application service includes business code sub-services and non-business code sub-services;

[0036] The business code sub-service is used to update the target data in the database;

[0037] The non-business code sub-service is used to obtain the target data updated in the database by the business code sub-service, and delete the target data in the cache.

[0038] Optionally, the system also includes a Kafka message queue;

[0039] The database is used to write the target data into the binlog.

[0040] The Kafka message queue is used to subscribe to the target data in the binlog.

[0041] The non-business code sub-service is specifically used to obtain the target data updated in the database by the business code sub-service by reading the Kafka message queue.

[0042] Optionally, the database includes a master database and at least one slave database, and the application service includes a first application service and a second application service;

[0043] The first application service is used to set an update flag in the cache after updating the target data in the master database. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time.

[0044] The second application service is used to read the update tag of the target data in the cache. If the update tag of the target data in the cache has not expired, the target data in the master database is read; if the update tag of the target data in the cache has expired, the target data in the slave database is read.

[0045] Optionally, the database includes a master database and at least one slave database, and the application service includes a first application service and a second application service;

[0046] The first application service is used to set an update flag on a local client after updating the target data in the master database. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time.

[0047] The first application server is further configured to read the target data in the master database if the update tag of the target data in the local client has not expired; and to read the target data in the slave database if the update tag of the target data in the local client has expired.

[0048] Optionally, the non-business code sub-service is further configured to send a delayed message to the RabbitMQ middleware before deleting the target data in the cache, wherein the delay time of the delayed message is the same as the expiration time of the update tag;

[0049] The RabbitMQ middleware is also used to trigger the non-business code sub-service to delete the target data in the cache when the delayed message is received.

[0050] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0051] The data synchronization method between cache and database disclosed in this invention adopts a strategy of updating data first and then deleting cache. The application service first updates the target data in the database, and then deletes the target data in the cache. When the RabbitMQ middleware receives the cache deletion failure information sent by the application service, it triggers the application service to delete the target data in the cache again until the target data in the cache is successfully deleted, thus ensuring data consistency between cache and database. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0053] Figure 1 This is a flowchart illustrating a data synchronization method between a cache and a database disclosed in an embodiment of the present invention;

[0054] Figure 2 This is a flowchart illustrating another data synchronization method between a cache and a database disclosed in an embodiment of the present invention;

[0055] Figure 3 This is a flowchart illustrating another data synchronization method between a cache and a database disclosed in an embodiment of the present invention;

[0056] Figure 4 This is a flowchart illustrating another data synchronization method between a cache and a database disclosed in an embodiment of the present invention;

[0057] Figure 5 This is a flowchart illustrating another data synchronization method between a cache and a database disclosed in an embodiment of the present invention. Detailed Implementation

[0058] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] The inventors discovered through research that, based on the order in which the database and cache are updated, there are four possible data synchronization scenarios:

[0060] First, update the database, then update the cache.

[0061] In this case, the data synchronization process is as follows:

[0062] 1) Request A initiates first, updating the database to 99, but has not yet updated the cache;

[0063] 2) Request B initiates, updates the database value to 98, and also updates the cache value to 98;

[0064] 3) Request A then updates the cached value to 99.

[0065] At this time, the value in the database is 98, but the value in the cache is 99, and the values ​​in the database and the cache are inconsistent.

[0066] 2. Update the cache first, then update the database.

[0067] In this case, the data synchronization process is as follows:

[0068] 1) Request A first updates the cache to 99, but has not yet updated the database;

[0069] 2) Request B to update the cache to 98, and also update the database to 98;

[0070] 3) Request A to update the database to 99 at this time.

[0071] This results in a cached value of 98 and a database value of 99, indicating a discrepancy between the data in the database and the cache.

[0072] 3. First, delete the cache, then update the database.

[0073] In this case, the data synchronization process is as follows:

[0074] 1) Request A to update the value. First, delete the value in the cache, but the database has not yet been updated.

[0075] 2) At this point, request B comes to query this value, finds that it does not exist in the cache, and then queries the database;

[0076] 3) Request B to retrieve the value from the database and then set the value into the cache;

[0077] 4) Request A then updates the value in the database to 99.

[0078] This leads to inconsistencies between the cache and the database, where the cached values ​​are always outdated, and the data in the database is inconsistent with the cached data.

[0079] IV. Update the database first, then delete the cache.

[0080] In this case, the data synchronization process is as follows:

[0081] 1) Request A initiates a query request, directly retrieves 100 from the database, but has not yet had time to set the cache;

[0082] 2) Request B to update the value, first update the database, then delete the cache;

[0083] 3) Request A only sets the cache to 100 at this point.

[0084] This inconsistency occurs because the cache suddenly expires. Furthermore, it requires that request B's update operation be faster than request A's query operation for inconsistency to occur. This situation is rare. This approach is generally suitable for projects with less stringent requirements.

[0085] As we can see, all four methods for synchronizing cache and database have certain problems. Only the fourth method—updating the database first and then deleting the cache—guarantees that the data in the database is correct and up-to-date, while the data in the cache will be somewhat outdated. This approach works fine in most business scenarios. However, in the strategy of updating the database first and then deleting the cache, if the cache deletion fails, it will lead to inconsistency between the database and the cache.

[0086] To address the aforementioned technical problems, this invention discloses a data synchronization method between a cache and a database, applied to a data synchronization system between a cache and a database. This system includes an application service, RabbitMQ middleware, a cache, and a database. (See also...) Figure 1 The data synchronization method specifically includes the following steps:

[0087] S101: The application service updates the target data in the database.

[0088] S102: The application service deletes the target data from the cache.

[0089] S103: When the RabbitMQ middleware receives a cache deletion failure message from the application service, it triggers the application service to delete the target data in the cache again until the target data in the cache is successfully deleted.

[0090] As can be seen, in the data synchronization method between the cache and the database disclosed in this embodiment, in the strategy of updating data first and then deleting the cache, the application service first updates the target data in the database, and then deletes the target data in the cache. When the RabbitMQ middleware receives the cache deletion failure information sent by the application service, it triggers the application service to delete the target data in the cache again until the target data in the cache is successfully deleted, thus ensuring data consistency between the cache and the database.

[0091] To avoid the problem of unclear business logic caused by over-coupling of application service business code, please refer to [link / reference]. Figure 2 This embodiment discloses another method for data synchronization between a cache and a database, applied to a data synchronization system between a cache and a database. The data synchronization system includes an application service, RabbitMQ middleware, a cache, a database, and a Kafka message queue. The application service includes business code sub-services and non-business code sub-services. For details, please refer to [link to relevant documentation]. Figure 2 The data synchronization method between the cache and the database disclosed in this implementation includes the following steps:

[0092] S201: The business code sub-service updates the target data in the database;

[0093] S202: The database writes the target data into the binlog.

[0094] S203: The Kafka message queue subscribes to the target data in the binlog log;

[0095] S204: The non-business code sub-service obtains the target data updated in the database by the business code sub-service by reading the Kafka message queue;

[0096] S205: If the RabbitMQ middleware receives a cache deletion failure message from the application service, it triggers the application service to delete the target data in the cache again until the target data in the cache is successfully deleted.

[0097] The data synchronization method between the cache and the database disclosed in this embodiment allows for independent cache deletion by non-business code sub-services, as they do not need to be associated with business logic. This avoids the problem of unclear business code caused by excessive coupling between application service and business code. Furthermore, this embodiment utilizes the Kafka message queue for publish-subscribe messaging, which can handle all action stream data in a consumer-scale website. The application sends requests using a third-party log backend mechanism without needing to extend the business system, thus resolving the coupling between the business system and the messaging mechanism.

[0098] The inventors discovered through research that large and medium-sized projects typically utilize database read / write separation to improve system throughput. A master database handles write requests and data updates, while one or more slave databases handle read requests, with data synchronized between the master and slave databases. However, due to a time delay in data synchronization between the master and slave databases, inconsistencies can arise. For example, if write request A updates data, but the master database hasn't yet updated the slave database, and read request B then queries the slave database, request B will retrieve the old value, not the updated value from the master database.

[0099] To address the aforementioned technical problems, this embodiment discloses another data synchronization method between a cache and a database, applied to a data synchronization system between a cache and a database. The data synchronization system includes an application service, RabbitMQ middleware, a cache, a database, and a Kafka message queue. The database includes a master database and at least one slave database. The application service includes a first application service and a second application service. (See also...) Figure 3 Specifically, it includes the following steps:

[0100] S301: The first application service updates the target data in the master database;

[0101] S302: The first application service sets an update flag in the cache. The update flag includes the business code, database identifier, table identifier, primary key identifier, and expiration time.

[0102] S303: The second application service reads the update flag of the target data in the cache;

[0103] S304: If the update flag for the target data in the cache has not expired, the second application service reads the target data from the main database;

[0104] S305: If the update flag for the target data in the cache has expired, the second application service reads the target data from the database.

[0105] As can be seen, for each read request, the update flag of the target data must be checked in the cache to see if it has expired. If the update flag has not expired, the target data is read from the master database. If the update flag has expired, the target data is read from the slave database, ensuring that the latest data is read every time the target data is read.

[0106] When using a clustered cache deployment, such as Redis, every read request requires interaction with Redis, which can impact system throughput to some extent. However, in real-world business scenarios, some applications can tolerate short-term data inconsistencies between the master and slave databases without affecting the overall system load complexity. For example, when an author writes an article and updates it to the article list, the author can see the update, but other users can't see it temporarily, which is acceptable. Based on this, this embodiment discloses another data synchronization method between a cache and a database, applied to a data synchronization system between a cache and a database. This data synchronization system includes an application service, RabbitMQ middleware, a cache, a database, and a Kafka message queue. The database includes a master database and at least one slave database. The application service includes a first application service and a second application service. (See [link to relevant documentation]). Figure 4 Specifically, it includes the following steps:

[0107] S401: The first application service updates the target data in the master database;

[0108] S402: The first application service sets an update flag on the local client. The update flag includes the business code, database identifier, table identifier, primary key identifier, and expiration time.

[0109] S403: The first application service reads the update flag of the target data in the local client;

[0110] S404: If the update flag for the target data in the local client has not expired, the first application service reads the target data from the main database.

[0111] S405: If the update flag for the target data in the local client has expired, the first application service reads the target data from the slave database.

[0112] The data synchronization method between the cache and the database disclosed in this embodiment ensures that the data read by the first application service is always the latest data and there are no performance issues. Since the second application service cannot see the update mark of the target data, it reads the data from the slave database.

[0113] To enable the second application service to read the updated target data, a background update mechanism can be used. For details, please refer to [link / reference needed]. Figure 5 :

[0114] S501: The business code sub-service updates the target data in the database;

[0115] S502: The database writes the target data into the binlog log;

[0116] S503: The Kafka message queue subscribes to the target data in the binlog log;

[0117] S504: The non-business code sub-service obtains the target data updated in the database by the business code sub-service by reading the Kafka message queue;

[0118] S505: Non-business code sub-services send a delayed message to the RabbitMQ middleware. The delay time of the delayed message is the same as the expiration time of the update tag of the target data.

[0119] S506: When the RabbitMQ middleware receives a delayed message, it triggers a non-business code sub-service to delete the target data from the cache.

[0120] In this implementation, the second application service user's read request may briefly retrieve the old value. To shorten this time and allow other users to quickly obtain the latest value, the first application service user can initiate another read request, reading the update flag of the target data in the local client and then the target data from the master database. This time, the read value will definitely be the new value. The second application service then sets this new value into its cache. This ensures that the cache contains the new value, even though the slave database has not yet completed synchronization. Finally, once the slave database synchronization is complete, the values ​​are consistent.

[0121] As can be seen, the data synchronization method between the cache and the database provided by this invention, in the strategy of updating the data first and then deleting the cache, ensures data consistency between the cache and the database in the event of cache failure, and data consistency between the master database and the slave database in read-write separation.

[0122] Based on the data synchronization method between cache and database disclosed in the above embodiments, this embodiment correspondingly discloses a data synchronization system between cache and database, including application service, RabbitMQ middleware, cache and database;

[0123] The application service is used to update the target data in the database and delete the target data in the cache;

[0124] The RabbitMQ middleware is used to trigger the application service to delete the target data in the cache again when it receives a cache deletion failure message sent by the application service, until the target data in the cache is successfully deleted.

[0125] Optionally, the application service includes business code sub-services and non-business code sub-services;

[0126] The business code sub-service is used to update the target data in the database;

[0127] The non-business code sub-service is used to obtain the target data updated in the database by the business code sub-service, and delete the target data in the cache.

[0128] Optionally, the system also includes a Kafka message queue;

[0129] The database is used to write the target data into the binlog.

[0130] The Kafka message queue is used to subscribe to the target data in the binlog.

[0131] The non-business code sub-service is specifically used to obtain the target data updated in the database by the business code sub-service by reading the Kafka message queue.

[0132] Optionally, the database includes a master database and at least one slave database, and the application service includes a first application service and a second application service;

[0133] The first application service is used to set an update flag in the cache after updating the target data in the master database. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time.

[0134] The second application service is used to read the update tag of the target data in the cache. If the update tag of the target data in the cache has not expired, the target data in the master database is read; if the update tag of the target data in the cache has expired, the target data in the slave database is read.

[0135] Optionally, the database includes a master database and at least one slave database, and the application service includes a first application service and a second application service;

[0136] The first application service is used to set an update flag on a local client after updating the target data in the master database. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time.

[0137] The first application server is further configured to read the target data in the master database if the update tag of the target data in the local client has not expired; and to read the target data in the slave database if the update tag of the target data in the local client has expired.

[0138] Optionally, the non-business code sub-service is further configured to send a delayed message to the RabbitMQ middleware before deleting the target data in the cache, wherein the delay time of the delayed message is the same as the expiration time of the update tag;

[0139] The RabbitMQ middleware is also used to trigger the non-business code sub-service to delete the target data in the cache when the delayed message is received.

[0140] The data synchronization system between the cache and the database provided by this invention ensures data consistency between the cache and the database in the event of cache failure by updating the data first and then deleting the cache, and also ensures data consistency between the master database and the slave database in read-write separation.

[0141] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0142] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0143] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0144] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for synchronizing data between a cache and a database, characterized in that, A data synchronization system is applied between a cache and a database. The data synchronization system includes an application service, RabbitMQ middleware, a cache, a Kafka message queue, and a database. The application service includes business code sub-services and non-business code sub-services, where the non-business code sub-services do not need to be associated with business logic. The method includes: The business code sub-service updates the target data in the database; The database writes the target data into the binlog. The Kafka message queue subscribes to the target data in the binlog log; The non-business code sub-service reads the Kafka message queue, obtains the target data updated in the database by the business code sub-service, and deletes the target data in the cache. The cache deletion operation of the non-business code sub-service is independent of the business code of the application service. When the RabbitMQ middleware receives a cache deletion failure message from the application service, it triggers the application service to delete the target data in the cache again until the target data in the cache is successfully deleted. The database includes a master database and at least one slave database, and the application services include a first application service and a second application service. After the first application service updates the target data in the master database, the method further includes: The first application service sets an update flag in the cache. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time. The second application service reads the update tag of the target data in the cache; If the update flag of the target data in the cache has not expired, the second application service reads the target data from the main database; If the update tag of the target data in the cache has expired, the second application service reads the target data from the slave database; Before the non-business code subservice deletes the target data in the cache, the method further includes: The non-business code sub-service sends a delayed message to the RabbitMQ middleware, the delay time of which is the same as the expiration time of the update tag; When the RabbitMQ middleware receives the delayed message, it triggers the non-business code sub-service to delete the target data in the cache. The database includes a master database and at least one slave database, and the application services include a first application service and a second application service. After the first application service updates the target data in the master database, the method further includes: The first application service sets an update flag on the local client. The update flag includes a business code, database identifier, table identifier, primary key identifier, and expiration time. The master database and the slave database synchronize the update of the target data within the expiration time. If the update flag of the target data in the local client has not expired, the first application service reads the target data in the main database; If the update tag of the target data in the local client has expired, the first application service reads the target data from the slave database; In response to a read request initiated by the first application service user, the update flag of the target data in the local client is read, and the target data in the master database is read. The second application service then sets the target data read from the master database into the cache to ensure that the cache contains the new value. After the slave database is synchronized with the data, the data in the master database, slave database, and cache is kept consistent.

2. A data synchronization system between a cache and a database, characterized in that, This includes application services, RabbitMQ middleware, cache, Kafka message queue, and database. The application services include business code sub-services and non-business code sub-services, and the non-business code sub-services do not need to be associated with business logic. The business code sub-service updates the target data in the database; The database writes the target data into the binlog. The Kafka message queue subscribes to the target data in the binlog log; The non-business code sub-service reads the Kafka message queue, obtains the target data updated in the database by the business code sub-service, and deletes the target data in the cache. The cache deletion operation of the non-business code sub-service is independent of the business code of the application service. The RabbitMQ middleware is used to trigger the application service to delete the target data in the cache again when it receives a cache deletion failure message sent by the application service, until the target data in the cache is successfully deleted; The database includes a master database and at least one slave database, and the application services include a first application service and a second application service. The first application service is used to set an update flag in the cache after updating the target data in the master database. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time. The second application service is used to read the update tag of the target data in the cache, and if the update tag of the target data in the cache has not expired, read the target data in the main database; If the update tag of the target data in the cache has expired, read the target data from the slave database; The non-business code sub-service is also used to send a delayed message to the RabbitMQ middleware before deleting the target data in the cache, wherein the delay time of the delayed message is the same as the expiration time of the update tag; The RabbitMQ middleware is also used to trigger the non-business code sub-service to delete the target data in the cache when the delayed message is received; The database includes a master database and at least one slave database, and the application services include a first application service and a second application service. The first application service is used to set an update flag on a local client after updating the target data in the master database. The update flag includes a business code, a database identifier, a table identifier, a primary key identifier, and an expiration time. The master database and the slave database synchronize the update of the target data within the expiration time. The first application service is further configured to read the target data in the main database if the update tag of the target data in the local client has not expired; If the update flag for the target data in the local client has expired, read the target data from the slave database; In response to a read request initiated by the first application service user, the update flag of the target data in the local client is read, and the target data in the master database is read. The second application service then sets the target data read from the master database into the cache to ensure that the cache contains the new value. After the slave database is synchronized with the data, the data in the master database, slave database, and cache is kept consistent.

Images