Movie session data multi-level cache and low-delay synchronization method and system

Abstract

The invention discloses a movie session data multi-level cache and low-delay synchronization method and system, and relates to the technical field of data storage. According to the method, a three-level cache architecture comprising an L1 application-level local cache, an L2 distributed shared cache and an L3 persistent database is constructed, and a flow direction rule of step-by-step penetration and backfilling during data reading and a flow direction rule of firstly using the database and then using a reverse failure cache during data updating are defined; when the data is changed, capturing a database change event, decoupling through a message queue, synchronously executing the operations of immediately failing the L2 cache, broadcasting failing all L1 node caches, and asynchronously refreshing the L2 cache; according to the method, the problems of single-point bottleneck risk, cache consistency delay and response delay in the prior art are effectively solved, extremely high concurrent reading can be supported, millisecond-level and even microsecond-level low-delay response is realized while high data consistency is ensured, and the system availability and the user experience are remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of data storage technology, and specifically relates to a method and system for multi-level caching and low-latency synchronization of movie screening data. Background Technology

[0002] In online movie ticketing platforms, movie showtime data (such as showtime, theater, ticket price, and remaining seats) is core business data. This type of data is characterized by high read volume, low write volume, strong timeliness, and high concurrency pressure. Before a movie starts, a large number of users repeatedly query showtime information, resulting in a huge volume of requests. Once the showtime data changes (such as ticket price adjustments, seat locking / selling), all users need to be notified within a very short time to ensure data consistency and avoid overselling. Especially during the pre-sale or promotional activities of popular movies, the instantaneous access traffic is extremely high.

[0003] Online movie ticketing platforms typically centralize all cached requests in a distributed caching layer. If this layer experiences network instability or service unavailability, a large number of requests will directly penetrate to the underlying database, causing the database to crash due to excessive instantaneous pressure. When the showtime data in the database is updated, quickly and reliably invalidating the old data in the distributed cache is a challenge. Using simple timed expiration or delayed update strategies can lead to users seeing incorrect data for a short period (e.g., showing tickets available for sold-out shows). For users located throughout the country, each request needs to access the central distributed cache, making network latency a bottleneck affecting response speed.

[0004] Existing technologies suffer from single-point bottlenecks and risks, cache consistency latency, and response latency issues. Summary of the Invention

[0005] (a) Technical problems to be solved To address the problems in related technologies, this invention provides a method and system for multi-level caching and low-latency synchronization of movie screening data, thereby overcoming the aforementioned technical problems existing in the prior art.

[0006] (II) Technical Solution To solve the above-mentioned technical problems, the present invention is achieved through the following technical solution: S1. Construct a multi-level caching architecture; the multi-level caching architecture includes L1 application-level local cache, L2 distributed shared cache and L3 persistent database; S2. When the session data changes, trigger and capture the data change in the L3 persistent database to obtain the changed data. S3. Send the modified data to the message queue and update the L2 distributed shared cache and L1 application-level local cache respectively; S4. Receive query request data; Based on the query request data, query the L1 application-level local cache to determine if the match data is hit. If hit, return the match data to the client; otherwise, execute S5. S5. Based on the query request data, query the L2 distributed shared cache to determine if the match data is hit. If hit, write the match data to the L1 application-level local cache and return it to the client; otherwise, execute S6. S6. Based on the query request data, query the session data in the L3 persistent database; write the session data to the L2 distributed shared cache and the L1 application-level local cache respectively, and return it to the client; This invention constructs a three-level caching architecture consisting of an L1 application-level local cache, an L2 distributed shared cache, and an L3 persistent database. It specifies a process for data reading that involves progressively penetrating and backfilling from L1 to L3, and a synchronization mechanism where, during data updates, the L3 database is first persistently updated, and then L2 is invalidated via a message queue, broadcasting the invalidation of all L1 nodes. This method supports high-concurrency queries and optimizes response latency from milliseconds to microseconds. Through proactive cache invalidation and asynchronous refresh strategies, it achieves strong consistency across multiple cache levels, effectively solving single-point bottlenecks and old data latency issues, and ensuring system reliability and data accuracy under high load.

[0007] Preferably, step S1 includes the following steps: S11. Construct a three-level cache architecture, wherein the three-level cache architecture includes the multi-level cache architecture including L1 application-level local cache, L2 distributed shared cache and L3 persistent database; S12. Define the data read flow rules, data update and invalidation flow rules, and degradation and fault tolerance strategies for the three-level cache architecture; This invention constructs a three-level L1 / L2 / L3 caching architecture and clearly defines the data flow and fault tolerance strategy. While eliminating single point of failure risk, it achieves data consistency across cache layers and ensures high system availability through a degradation mechanism.

[0008] Preferably, step S2 includes the following steps: S21. When a business operation occurs, an update transaction is executed on the L3 persistent database; S22. After the database commits the update transaction, the data change capture module captures the change event of the data in that row in real time and obtains the data to be changed. Transform the event data to be changed into structured data to be changed; This invention ensures reliable data persistence to disk through transactions and utilizes CDC technology to capture changes in real time and transform them into structured data, guaranteeing the accuracy of the data source and providing a reliable data source for subsequent cross-caching layer consistency synchronization.

[0009] Preferably, step S3 includes the following steps: S31. Receive and persist the structured data to be changed through the message queue; S32. Based on the structured data to be changed, execute the immediate invalidation of L2 cache, broadcast the L1 cache invalidation instruction, and each business node receives and executes L1 cleanup and asynchronous L2 cache refresh operations. This invention decouples high-concurrency database updates and cache processing through message queues, and performs immediate invalidation, broadcast cleanup and asynchronous refresh operations, thereby achieving real-time consistency of cached data across clusters, providing the system's peak shaving and valley filling capabilities, and ensuring stability under high concurrency.

[0010] Preferably, step S32 includes the following steps: S321. Extract the structured data to be changed from the message queue; based on the structured data to be changed, send the DEL command to the L2 distributed shared cache through the synchronization service to accurately delete the cache key corresponding to the change session; S322. The synchronization service broadcasts cache invalidation instructions to the entire business application cluster through a low-latency publish / subscribe channel and receives the broadcast instructions. S323. After receiving the broadcast command, the server's cache listening module parses the command and performs a deletion operation in the L1 local cache to remove the cache item specified in the command. S324. After executing S321, S322, and S323, asynchronously query the latest full data of the structured data to be changed from the L3 persistent database to obtain the latest changed full data; The latest changes include rewriting all data to the L2 distributed shared cache and setting a new TTL; This invention achieves a balance between low-latency synchronization and high-concurrency handling by first precisely deleting the L2 cache key and broadcasting the invalidation of all L1 node local caches, and then asynchronously querying the latest data to refresh L2. This sequential operation ensures strong consistency of multi-level cache data while effectively avoiding database penetration in subsequent requests.

[0011] Preferably, step S4 includes the following steps: S41. Receive the query request, obtain the query request data, and route the query request data to the business application server. S42. Check if the query key exists in the L1 application-level local cache object; if the query key is in the L1 cache manager's cache object and has not been evicted, it is considered a hit, and the session data is returned to the client; otherwise, execute S5. This invention achieves ultra-fast microsecond-level response by prioritizing the query of the L1 cache in the application server's local memory and directly returning data when a cache hit occurs. At the same time, it effectively filters a large number of requests and reduces the load pressure on the backend system.

[0012] Preferably, step S5 includes the following steps: S51. When the query request data is not found in the L1 application-level local cache, the query request data is transferred to the L2 application-level local cache. S52. Check if the query key exists in the L2 application-level local cache of the application server; if the query key is in the L2 application-level local cache and has not been evicted, it is considered a hit, the session data is written to the L1 application-level local cache and returned to the client; otherwise, execute S6. This invention provides an efficient backup for requests and achieves automatic cache warm-up by querying the L2 distributed cache when L1 is missed and backfilling L1 when a cache hit occurs. While maintaining millisecond-level response, it effectively reduces database pressure and achieves performance transition of the cache layer.

[0013] Preferably, step S6 includes the following steps: S61. When the query request data is not found in both the L1 application-level local cache and the L2 application-level local cache, the query request data is transferred to the L3 persistent database. S62. Execute a database query operation to find the data row corresponding to the primary key or unique index of the query request data in the database table of the L3 persistent database, and obtain the session data; write the session data to the L2 application-level local cache and the L1 application-level local cache, and return the session data to the client. This invention queries the L3 database when the first two levels of cache miss and then fills the results back into L1 and L2. This ensures data availability while effectively preventing repeated penetration of the same request in the future, thus achieving ultimate protection for data access and self-repair of cache performance.

[0014] A multi-level caching and low-latency synchronization system for movie screening data is provided to implement the aforementioned method for multi-level caching and low-latency synchronization of movie screening data. The system includes a multi-level caching architecture construction module, a data change capture module, a cache update module, and a data query module. The multi-level caching architecture building module is used to build and configure a three-level caching architecture, including L1 application-level local cache, L2 distributed shared cache and L3 persistent database; this module defines the data read flow, data update and invalidation flow, as well as degradation and fault tolerance strategies to ensure the high availability and consistency of the system. The data change capture module is used to capture change events in the L3 persistent database in real time when business operations (such as user ticket purchases) cause changes in session data. After the database commits an update transaction, the module extracts the change events and transforms them into structured data to be changed. This ensures the real-time nature and accuracy of data changes and provides a foundation for subsequent cache updates. The cache update module receives structured data from the data change capture module via a message queue, decoupling database updates from cache processing and avoiding impact on the core database. The synchronization service immediately sends a DEL command to the L2 cache to delete dirty data; it broadcasts an L1 cache invalidation instruction through a publish / subscribe channel, causing all business nodes to clear their local caches; and it asynchronously queries the latest data from the L3 database and rewrites it into the L2 cache, setting a TTL to improve subsequent read performance; thus ensuring data consistency and timely updates across multiple cache levels. The data query module is used to process client query requests, following the principle of hierarchical penetration. First, it queries the L1 application-level local cache. If a match is found, the data is returned directly. Otherwise, it queries the L2 distributed shared cache. If a match is found, the data is backfilled in L1 and returned. If neither match is found, it queries the L3 persistent database, retrieves the data, backfills the L2 and L1 caches, and returns it to the client. This module maximizes read performance while ensuring data correctness through efficient cache management and backfilling mechanisms, and supports degrading to direct database query when the L2 cache is unavailable.

[0015] (III) Beneficial Effects The present invention has the following beneficial effects: This invention effectively overcomes the bottleneck problems in existing technologies by constructing a three-level caching architecture consisting of L1 application-level local cache, L2 distributed shared cache, and L3 persistent database, combined with a low-latency data synchronization mechanism. This invention provides a complete solution that can support high concurrency, low latency, and strong consistency data access, and is particularly suitable for Internet business scenarios such as online movie ticketing where there are many reads and few writes and high data timeliness requirements, significantly improving the system's processing capacity and user experience.

[0016] This invention successfully solves the single point of failure bottleneck and risk. By storing the most frequently accessed data in the local memory (L1) of the application server, most read requests can be responded to locally at extremely fast speeds without accessing the remote distributed cache. This not only improves the response time from milliseconds to microseconds, greatly reducing the latency perceived by users, but also significantly reduces the pressure on the L2 distributed cache layer. When the L2 cache layer fails, the system has the ability to degrade and can bypass L2 to directly query the database, avoiding the risk of the entire system collapsing due to the failure of a single node, thereby improving the overall availability and resilience of the system.

[0017] This invention effectively solves the cache consistency problem and avoids business risks (such as overselling) caused by delayed data updates. By adopting a reverse invalidation process of "updating the database first and then invalidating the cache", and by using CDC technology to capture database changes, message queue decoupling, and publish / subscribe channel broadcast invalidation commands in real time, it achieves near real-time invalidation of L2 and all L1 node caches. Compared with the passive TTL expiration strategy, this proactive invalidation mechanism can ensure that users see the latest and most accurate data in a very short time after data changes, guaranteeing eventual data consistency, which is crucial for scenarios such as movie ticketing where data accuracy is extremely important.

[0018] This solution balances high performance and high reliability in its architecture design; the entire data flow is smoothed out through message queues, protecting the underlying database from sudden traffic surges; the "warm update" strategy of asynchronously refreshing the L2 cache loads the latest data back into the distributed cache in advance while ensuring data correctness, avoiding database penetration in subsequent requests.

[0019] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating a multi-level caching and low-latency synchronization method for movie screening data according to the present invention. Figure 2 This is a schematic diagram of a multi-level caching and low-latency synchronization system for movie screening data according to the present invention. Detailed Implementation

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

[0023] In the description of this invention, it should be understood that the terms "opening", "upper", "lower", "top", "middle", "inner", etc., which indicate orientation or positional relationship, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the components or elements referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the invention.

[0024] Example 1: Please see Figure 1 This invention discloses a method for multi-level caching and low-latency synchronization of movie screening data, comprising the following steps: S1. Construct a multi-level caching architecture; the multi-level caching architecture includes L1 application-level local cache, L2 distributed shared cache and L3 persistent database; S1 includes the following steps: S11. Construct a three-level cache architecture, wherein the three-level cache architecture includes the multi-level cache architecture including L1 application-level local cache, L2 distributed shared cache and L3 persistent database; The L1 application-level local cache resides in the memory of the business application server, employing an LRU or TTL strategy to store frequently accessed data, providing the fastest read speed. Its core function is to achieve extremely fast response by building the cache in application memory using the high-performance Caffeine library. A cache instance is initialized, and key parameters are configured, including setting a maximum capacity (e.g., 10,000 entries) to prevent memory overflow and a short expiration time after writes (e.g., 5 seconds) to ensure eventual consistency, guaranteeing that even with synchronization delays, older data will quickly and automatically expire. This cache instance can then be used by injecting it into the business query service. The L2 distributed shared cache uses a Redis cluster to store all session data, serving as a backup when the L1 cache misses and as a hub for data synchronization. Its core function is to provide data sharing and a concurrent buffer. A Redis cluster mode is used to achieve high availability and horizontal scalability. On the application side, a Lettuce client and its connection pool are configured to efficiently connect to the Redis cluster. A data serialization scheme is selected (such as readable JSON or a more efficient binary format), and key naming is standardized (e.g., business:ID). All data written to L2 must have an expiration time set to manage memory and prevent dirty data from persisting. The L3 persistent database uses relational databases such as MySQL as the final persistent storage for data; its core function is to serve as the system's only trusted data source. It employs the InnoDB storage engine and selects relational databases such as MySQL. The session data table structure is designed to include core business fields (such as theater, time, ticket price, number of seats, etc.), and appropriate indexes (such as primary key indexes and unique theater time indexes) are established to ensure query efficiency and data consistency. A master-slave replication architecture is deployed to achieve read-write separation, improving the overall processing capacity and reliability of the database. S12. Define the data read flow rules, data update and invalidation flow rules, and degradation and fault tolerance strategies for the three-level cache architecture; The data reading flow rule is L1 to L2 to L3, penetrating level by level; any data obtained from the lower-level cache is backfilled to the upper-level cache (L2 hit backfills L1, L3 hit backfills both L2 and L1). The data update and failure flow rule is that the update operation is first written to disk L3, and then reversed to the failure cache; the L3 database is updated to the failure L2 cache and then broadcast to the L1 cache of all nodes that have failed; this is achieved through subsequent CDC, message queues and synchronization services, but this rule must be established during the architecture design phase. The degradation and fault tolerance strategy states that L1 cache failure is normal, affecting single-machine performance but not correctness; if L2 cache is unavailable, the system should be able to degrade to "L1 to L3" mode. A switch needs to be configured at the application layer to automatically skip the L2 query step and directly query the database when Redis cluster unavailability is detected, and record the alarm; L3 database unavailability is a serious fault, as the system will lose its data source and can only rely on residual data in the cache, requiring immediate repair. S2. When the session data changes, trigger and capture the data change in the L3 persistent database to obtain the changed data. S2 includes the following steps: S21. When a business operation occurs (such as a user purchasing a ticket or an administrator adjusting the ticket price), the system first executes an update transaction (such as an UPDATE statement) on the L3 persistent database. S22. After the database commits the update transaction, the data change capture module (such as Canal, an incremental log subscription component based on MySQLbinlog) captures the change event of the data in real time and obtains the data to be changed. The event data to be changed is transformed into structured data to be changed; the structured data to be changed includes the table name to be changed, the unique session ID (showId), the operation type (update / delete), and the changed data and timestamp; S3. Send the modified data to the message queue and update the L2 distributed shared cache and L1 application-level local cache respectively; S3 includes the following steps: S31. Receive and persist the structured data to be changed through the message queue. This step decouples the high-throughput database update events from the subsequent potentially heavy cache processing operations, avoiding impact on the core business database and providing the system's peak shaving and valley filling capabilities. S32. Based on the structured data to be changed, execute the immediate invalidation of L2 cache, broadcast the L1 cache invalidation instruction, and each business node receives and executes L1 cleanup and asynchronous L2 cache refresh operations. S32 includes the following steps: S321. Extract the structured data to be changed from the message queue; based on the structured data to be changed, send a DEL command to the L2 distributed shared cache through the synchronization service to precisely delete the cache key corresponding to the change session; this operation aims to eliminate dirty data in the distributed layer as soon as possible, ensuring that any subsequent request to read the data from L2 will fail and must return to the database. S322. The synchronization service broadcasts a cache invalidation instruction to the entire business application cluster through a low-latency publish / subscribe channel (such as Redis Pub / Sub or a dedicated WebSocket connection), and receives the broadcast instruction; the format of the broadcast instruction is as follows: {"action": "delete", "scope": "L1", "key": "showId12345", "timestamp": 1620000000000}; S323. All online business application servers have subscribed to the above Pub / Sub channels. Upon receiving a broadcast command, the cache listening module in each server will immediately parse the command and perform a deletion operation in its respective L1 local cache, removing the cache item specified in the command. S324. After executing S321, S322, and S323, in order to improve subsequent read performance, the synchronization service asynchronously queries the latest full data of the structured data to be changed from the L3 persistent database after completing the core failure operation, and obtains the latest changed full data. The latest changes are then fully rewritten to the L2 distributed shared cache, and a new TTL is set. This operation is called a "warm update," designed to prevent subsequent requests from penetrating to the database due to L2 expiration. Even if there is a slight delay in this step, the correctness of the system will not be affected. The TTL refers to expiration time management. When writing to L2, an expiration time must be set, for example, 30 minutes, using the command SETEX key 1800 value. This is both a requirement for data security (preventing dirty data from persisting) and a necessity for memory management. S4. Receive query request data; Based on the query request data, query the L1 application-level local cache to determine if the match data is hit. If hit, return the match data to the client; otherwise, execute S5. S4 includes the following steps: S41. Receive user query requests and obtain query request data; the API gateway routes the HTTP query request data containing showId to a business application server; S42. The application server executes cache.getIfPresent(showId) through the cache manager (such as Caffeine) in the L1 application-level local cache to check if the key exists in the cache object of the application server's L1 application-level local cache. If the key is in the cache object of the L1 cache manager and has not been evicted, it is considered a hit, and the session data is returned to the client; otherwise, S5 is executed. Specifically, `cache.getIfPresent(key)` is a non-blocking local memory operation that takes microseconds. The condition that a key is null is the core of the query. In Caffeine, if a key exists but its value is null, this is usually considered a configuration error or data anomaly. Even if a key existed before, if it was automatically evicted due to the `maximumSize` (LRU) or `expireAfterWrite` (TTL) policy, the query will return null and be considered a cache miss. S5. Based on the query request data, query the L2 distributed shared cache to determine if the match data is hit. If hit, write the match data to the L1 application-level local cache and return it to the client; otherwise, execute S6. S5 includes the following steps: S51. When the query request data is not found in the L1 application-level local cache, the query request data is transferred to the L2 application-level local cache. S52. Execute GET show:{showId} through the Redis client to check if the key exists in the L2 application-level local cache of the application server. If the key exists in the L2 application-level local cache and has not been evicted, it is considered a hit. Write the session data to the L1 application-level local cache (the data obtained from the L2 application-level local cache is written back to the L1 application-level local cache of the current business application server with a short time-to-live (TTL, e.g., 3-5 seconds)) and return it to the client; otherwise, execute S6. Specifically, GET show:{showId} is a network I / O operation that takes milliseconds, and its performance is far lower than cache.getIfPresent(key) in the L1 application-level local cache. The condition for judgment is also = null; Redis's GET command will return nil when the key does not exist, and the client driver will convert it to null; possible reasons for a miss are that the data has never been written to L2; it may also be that the data has been deleted by the expiration policy (such as TTL expiration, memory eviction policy maxmemory-policy, or active DEL command), or it may be a Redis cluster failure (but in this scenario, it is usually considered a service degradation rather than a simple "miss"); S6. Based on the query request data, query the session data in the L3 persistent database; write the session data to the L2 distributed shared cache and the L1 application-level local cache respectively, and return it to the client; S6 includes the following steps: S61. When the query request data is not found in both the L1 application-level local cache and the L2 application-level local cache, the query request data is transferred to the L3 persistent database. S62. Execute a database query operation via JDBC (SELECT * FROM film_schedule WHERE id) to find the data row corresponding to the primary key or unique index of the query request data in the database table of the L3 persistent database, and obtain the session data; write the session data to the L2 application-level local cache (with a longer TTL) and the L1 application-level local cache (with a shorter TTL), and return the session data to the client.

[0025] Example 2: Please see Figure 2 A multi-level caching and low-latency synchronization system for movie screening data is provided to implement the aforementioned method for multi-level caching and low-latency synchronization of movie screening data. The system includes a multi-level caching architecture construction module, a data change capture module, a cache update module, and a data query module. The multi-level caching architecture building module is used to build and configure a three-level caching architecture, including L1 application-level local cache, L2 distributed shared cache and L3 persistent database; this module defines the data read flow, data update and invalidation flow, as well as degradation and fault tolerance strategies to ensure the high availability and consistency of the system. The data change capture module is used to capture change events in the L3 persistent database in real time when business operations (such as user ticket purchases) cause changes in session data. After the database commits an update transaction, the module extracts the change events and transforms them into structured data to be changed. This ensures the real-time nature and accuracy of data changes and provides a foundation for subsequent cache updates. The cache update module receives structured data from the data change capture module via a message queue, decoupling database updates from cache processing and avoiding impact on the core database. The synchronization service immediately sends a DEL command to the L2 cache to delete dirty data; it broadcasts an L1 cache invalidation instruction through a publish / subscribe channel, causing all business nodes to clear their local caches; and it asynchronously queries the latest data from the L3 database and rewrites it into the L2 cache, setting a TTL to improve subsequent read performance; thus ensuring data consistency and timely updates across multiple cache levels. The data query module is used to process client query requests, following the principle of hierarchical penetration. First, it queries the L1 application-level local cache. If a match is found, the data is returned directly. Otherwise, it queries the L2 distributed shared cache. If a match is found, the data is backfilled in L1 and returned. If neither match is found, it queries the L3 persistent database, retrieves the data, backfills the L2 and L1 caches, and returns it to the client. This module maximizes read performance while ensuring data correctness through efficient cache management and backfilling mechanisms, and supports degrading to direct database query when the L2 cache is unavailable.

[0026] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0027] The preferred embodiments of the invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A multi-level cache and low-latency synchronization method for movie session data, characterized in that, The method comprises the following steps: S1, constructing a multi-level cache architecture; The multi-level cache architecture comprises an L1 application-level local cache, an L2 distributed shared cache, and an L3 persistent database; S2, when the game data is changed, triggering and capturing the data change of the L3 persistent database to obtain the changed data; S3, sending the changed data to a message queue and updating the L2 distributed shared cache and the L1 application-level local cache respectively; S4, receiving a query request data; Based on the query request data, the L1 application-level local cache is queried to determine whether the game data is hit, if yes, the game data is returned to the client, otherwise, S5 is executed; S5, based on the query request data, the L2 distributed shared cache is queried to determine whether the game data is hit, if yes, the game data is written into the L1 application-level local cache and returned to the client, otherwise, S6 is executed; S6, based on the query request data, the game data in the L3 persistent database is queried; the game data is written into the L2 distributed shared cache and the L1 application-level local cache and returned to the client.

2. The method of claim 1, wherein, The S1 comprises the following steps: S11, constructing a three-level cache architecture, the three-level cache architecture comprises the multi-level cache architecture comprising an L1 application-level local cache, an L2 distributed shared cache, and an L3 persistent database; S12, defining the data reading flow direction rule, the data updating and invalidation flow direction rule, and the degradation and fault tolerance strategy of the three-level cache architecture.

3. The method of claim 2, wherein, The S2 comprises the following steps: S21, when a business operation occurs, updating a transaction of the L3 persistent database; S22, after the database submits the updating transaction, a data change capturing module captures the change event of the row data in real time to obtain the to-be-changed event data; The to-be-changed event data is converted into to-be-changed structured data.

4. The method of claim 3, wherein, The S3 comprises the following steps: S31, receiving and persisting the to-be-changed structured data through a message queue; S32, based on the to-be-changed structured data, executing the immediate invalidation of the L2 cache, broadcasting the L1 cache invalidation instruction, receiving and executing the L1 cleaning by each business node, and asynchronously refreshing the L2 cache operation.

5. The method of claim 4, wherein, The S32 comprises the following steps: S321, extracting the to-be-changed structured data from the message queue; based on the to-be-changed structured data, sending a DEL command to the L2 distributed shared cache through a synchronous service to accurately delete the cache key corresponding to the game; S322, the synchronous service broadcasts the cache invalidation instruction to the entire business application cluster through a low-latency publish / subscribe channel to obtain a broadcast instruction; S323, after receiving the broadcast instruction, the instruction is parsed through a cache listening module in the server, and a deletion operation is executed in the L1 local cache to remove the cache item specified in the instruction; S324, after S321, S322, and S323 are executed, the latest full data of the to-be-changed structured data is queried from the L3 persistent database asynchronously to obtain the latest changed full data; The latest changed full data is written into the L2 distributed shared cache again, and a new TTL is set.

6. The method of claim 4, wherein, The S4 comprises the following steps: S41, receiving a query request to obtain query request data; routing the query request data to a service application server; S42, checking whether the query key exists in the cache object of the L1 application level local cache; if the query key exists in the cache object of the L1 cache manager and is not evicted, it is judged as a hit, and the game data is returned to the client; otherwise, S5 is executed.

7. The method of claim 6, wherein, The S5 includes the following steps: S51, when the query request data does not hit in the L1 application level local cache, transmitting the query request data to the L2 application level local cache; S52, checking whether the query key exists in the cache object of the L2 application level local cache of the application server; if the query key exists in the cache object of the L2 application level local cache and is not evicted, it is judged as a hit, the game data is written into the L1 application level local cache, and is returned to the client; otherwise, S6 is executed.

8. The method of claim 7, wherein, The S6 includes the following steps: S61, when the query request data does not hit in the L1 application level local cache and the L2 application level local cache, transmitting the query request data to the L3 persistent database; S62, performing a database query operation to find the corresponding data row of the primary key or unique index of the query request data in the database table of the L3 persistent database, to obtain the game data; writing the game data into the L2 application level local cache and the L1 application level local cache, and returning the game data to the client.

9. A multi-level cache and low-latency synchronization system for movie session data, the system comprising: Implement a movie session data multi-level cache and low delay synchronization method according to any one of claims 1-8, the system includes a multi-level cache architecture construction module, a data change capture module, a cache update module and a data query module.

Images