Cache access method, device and equipment and computer program product

Abstract

The invention discloses a cache access method, device and equipment, and a computer program product. The cache access method comprises the following steps: receiving a transaction request; according to the transaction request and preset cache access strategy configuration information, determining a data access path of the transaction request, the data access path being a distributed cache or a local shared memory; and accessing the distributed cache or the local shared memory according to the data access path. According to the cache access method, a multi-layer cache strategy of financial system transactions is realized, the problem of timeliness when distributed cache is accessed for multiple times in the transactions is solved by introducing the shared memory, two cache mechanisms are combined and used based on the characteristics of access data, efficient processing of complex transactions in a financial scene is realized, and the service life of the transaction is prolonged. And the cache access strategy supports multi-dimensional flexible real-time configuration, so that the peak period processing efficiency and response speed of financial transactions are further improved.

Description

Technical Field

[0001] The present application relates to the field of cache application technology, and in particular to a cache access method, apparatus and device, and a computer program product. Background Art

[0002] Currently, financial transaction processing systems utilize two types of cache: distributed cache and local cache. Distributed cache, often implemented using Redis, offers high speed, flexibility, and rich data structures. Local cache, on the other hand, is faster, has low dependencies, and is simple to use. While both cache types are commonly used in system design, they each have their limitations in systems that prioritize high concurrency, low latency, and frequent cache access. Distributed cache requires network access, and in scenarios with frequent cache access, network latency is a significant issue. Local cache, due to its use of in-process memory, suffers from limited capacity and lack of sharing.

[0003] With the continuous development of banking and financial services and the continuous improvement of business products, the requirements for the systems supporting these businesses are becoming increasingly stringent. System processing performance and transaction processing time are key indicators that influence the customer experience. To improve system processing performance and optimize response time, system designers are introducing caching systems. Different caching methods are employed based on the specific business operations undertaken by the system. For example, some caching solutions ensure high availability of the cache system, and their cached data access operations ensure high performance of clustered systems. Finally, custom annotations are used to declaratively enhance the usability of the cache system, increasing its scalability and extensibility. Other solutions utilize a menu permission query method based on a multi-level distributed cache. This multi-level distributed caching mechanism provides unified management of menu and personnel permissions, achieving a highly cohesive and low-coupling system, reducing JVM memory usage, and improving system speed.

[0004] To ensure low latency and high availability, current system designs often use distributed Redis as a cache, or a combination of distributed Redis and local cache, to reduce database access and thus request response time. While this approach can achieve low latency to a certain extent, both solutions have limitations. For example, using distributed Redis as a cache requires network access. When a single business processing scenario requires multiple accesses to Redis, the network interaction time is relatively long. Local memory, which uses process-space memory as a cache, does not have the network overhead, but does have issues such as limited memory space. Summary of the Invention

[0005] Embodiments of the present application provide a cache access method, apparatus and device, and computer program product to improve the processing efficiency of financial transactions.

[0006] The embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, an embodiment of the present application provides a cache access method, the cache access method comprising:

[0008] Receive transaction requests;

[0009] Determining a data access path for the transaction request based on the transaction request and preset cache access policy configuration information, where the data access path is a distributed cache or a local shared memory;

[0010] The distributed cache or the local shared memory is accessed according to the data access path.

[0011] Optionally, the preset cache access policy configuration information is configured in the following manner:

[0012] Determining data attributes corresponding to different business dimensions, where the business dimensions include at least one of a single transaction dimension, an initiating system dimension, and a transaction product dimension;

[0013] If the data attribute corresponding to the business dimension is data with high access frequency but no real-time modification requirement, configure the data access path corresponding to the business dimension to be local shared memory;

[0014] If the data attribute corresponding to the business dimension is data with low access frequency but real-time modification requirements, the data access path corresponding to the business dimension is configured as a distributed cache.

[0015] Optionally, determining the data access path of the transaction request according to the transaction request and preset cache access policy configuration information includes:

[0016] Parsing the transaction request to obtain a parsing result of the transaction request, wherein the parsing result of the transaction request includes at least one of single transaction dimension information, initiating system dimension information, and transaction product dimension information;

[0017] Generate key index data for accessing the cache according to the parsing result of the transaction request;

[0018] Accessing the distributed cache or the local shared memory according to the data access path includes:

[0019] The distributed cache or the local shared memory is accessed according to the data access path and the key index data of the access cache.

[0020] Optionally, determining the data access path of the transaction request according to the key index data of the access cache and preset cache access policy configuration information includes:

[0021] Matching the parsing result of the transaction request with the preset cache access policy configuration information;

[0022] A data access path for the transaction request is determined according to the matching result.

[0023] Optionally, the data in the distributed cache is stored in the following manner:

[0024] Generate a shard data file from the end-of-day local file by the end-of-day server. The end-of-day local file is generated by reading data from the management database. The data in the shard data file is data with low access frequency but with real-time modification requirements;

[0025] The shard data file is loaded into the distributed cache.

[0026] Optionally, the local shared memory is provided by a virtual machine, one or more container nodes are deployed on the virtual machine, one or more business services on each of the container nodes share the local shared memory on the same container node, and data in the local shared memory is stored in the following manner:

[0027] Uploading the end-of-day local file to the file server through the end-of-day server, wherein the end-of-day local file is generated by reading data from the management database;

[0028] Obtaining a data file from the file server through the container node, wherein the data in the data file is data with high access frequency but no real-time modification requirement;

[0029] The data file is loaded into the local shared memory of each container node on each container node.

[0030] Optionally, a memory management service is established in each container node, and the memory management service is used to perform at least one of the operations of creating a local shared memory, hot updating data, and destroying memory on each container node.

[0031] In a second aspect, an embodiment of the present application further provides a cache access device, the cache access device comprising:

[0032] A receiving unit, configured to receive a transaction request;

[0033] a determining unit, configured to determine a data access path for the transaction request according to the transaction request and preset cache access policy configuration information, wherein the data access path is a distributed cache or a local shared memory;

[0034] An access unit is configured to access the distributed cache or the local shared memory according to the data access path.

[0035] In a third aspect, an embodiment of the present application further provides a device, including:

[0036] A processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform any of the aforementioned cache access methods.

[0037] In a fourth aspect, an embodiment of the present application further provides a computer program product, comprising a computer program / instruction, which implements any of the aforementioned cache access methods when executed by a processor.

[0038] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: the cache access method of the embodiments of the present application first receives a transaction request; then, based on the transaction request and the preset cache access policy configuration information, determines the data access path of the transaction request, where the data access path is a distributed cache or a local shared memory; finally, accesses the distributed cache or the local shared memory based on the data access path. The cache access method of the embodiments of the present application implements a multi-layer cache strategy for financial system transactions. By introducing shared memory, it solves the timeliness problem when transactions access the distributed cache multiple times. Based on the characteristics of the accessed data, it combines the two cache mechanisms to achieve efficient processing of complex transactions in financial scenarios. The cache access strategy supports flexible real-time configuration in multiple dimensions, further improving the peak processing efficiency and response speed of financial transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] Figure 1 A schematic diagram of a cache access method according to an embodiment of the present application;

[0041] Figure 2 This is a comparative diagram of a local shared memory and a distributed Redis cache in an embodiment of the present application;

[0042] Figure 3 This is a schematic diagram of a cache architecture in an embodiment of the present application;

[0043] Figure 4 A schematic diagram of a local shared memory configuration in an embodiment of the present application;

[0044] Figure 5This is a schematic structural diagram of a cache access device according to an embodiment of the present application;

[0045] Figure 6 This is a structural diagram of a device in an embodiment of the present application. DETAILED DESCRIPTION

[0046] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0047] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0048] The embodiment of the present application provides a cache access method, such as Figure 1 As shown, a flow chart of a cache access method in an embodiment of the present application is provided. The cache access method at least includes the following steps S110 to S130:

[0049] Step S110: receiving a transaction request.

[0050] The cache access method of the embodiment of the present application is mainly aimed at financial transaction scenarios. Therefore, it is necessary to first receive a real-time transaction request initiated by the front end. The transaction request may carry information such as the transaction type (such as transfer, inquiry, payment, etc.), transaction amount, transaction time, initiating system, and transaction product type. This information is an important basis for subsequently determining the data access path. Of course, the specific information carried in the actual transaction request depends on the actual business scenario and business needs, and is not specifically limited here.

[0051] Step S120 : determining a data access path for the transaction request according to the transaction request and preset cache access policy configuration information, where the data access path is a distributed cache or a local shared memory.

[0052] The embodiments of the present application pre-configure a multi-layer cache access strategy based on the data access characteristics of financial transaction scenarios. The multi-layer cache access strategy consists of a distributed cache (such as Redis) and local shared memory. The distributed cache has the characteristics of high speed, flexibility, and rich data structure, while the local cache has the characteristics of faster speed, low dependency, and simplicity and ease of use. Therefore, the embodiments of the present application configure different cache access strategies based on the data characteristics of different transaction accesses. By combining the distributed cache and local shared memory, the data access requirements of different transaction scenarios are met, thereby improving the overall processing efficiency in financial transaction scenarios.

[0053] Based on pre-configured cache access policy configuration information and the information contained in the current real-time transaction request, the cache access method suitable for the current transaction request can be determined. In other words, the data access path corresponding to the current transaction request can be determined, such as whether to access data through the distributed cache or local shared memory. By customizing the access path based on the characteristics of the data accessed by the current transaction request, the timeliness requirements of data access can be met while alleviating the problem of limited memory space.

[0054] Step S130: Access the distributed cache or the local shared memory according to the data access path.

[0055] After determining the data access path, the corresponding cache can be accessed according to the determined data access path. For example, if the matching data access path is a distributed cache, data is obtained by accessing the distributed cache. If the matching data access path is a local shared memory, data is obtained by accessing the local shared memory.

[0056] The cache access method of the embodiment of the present application implements a multi-layer cache strategy for financial system transactions. By introducing shared memory, it solves the timeliness problem when transactions access the distributed cache multiple times. Based on the characteristics of the accessed data, the two cache mechanisms are combined to achieve efficient processing of complex transactions in financial scenarios. The cache access strategy supports flexible real-time configuration in multiple dimensions, further improving the peak processing efficiency and response speed of financial transactions.

[0057] In some embodiments of the present application, the preset cache access policy configuration information is configured in the following manner: determining the data attributes corresponding to different business dimensions, the business dimensions including at least one of a single transaction dimension, an initiating system dimension, and a transaction product dimension; if the data attribute corresponding to the business dimension is data with a high access frequency but no real-time modification requirement, then the data access path corresponding to the business dimension is configured to be a local shared memory; if the data attribute corresponding to the business dimension is data with a low access frequency but a real-time modification requirement, then the data access path corresponding to the business dimension is configured to be a distributed cache.

[0058] When configuring cache access policies, the embodiments of the present application may configure cache access policies differently based on data attributes corresponding to different business dimensions.

[0059] Examples of these business dimensions include individual transaction dimensions, initiating system dimensions, and transaction product dimensions. The individual transaction dimension analyzes the data characteristics associated with each specific transaction. For example, in a transfer transaction, information such as the transaction amount, transaction institution, transaction teller, and transaction equipment will be considered. These attributes reflect key information such as the scale and parties involved in the transaction and serve as an important basis for determining data access strategies. The initiating system dimension primarily identifies the system originating the transaction request. Transaction data generated by different systems has distinct characteristics. For example, transaction data generated by mobile banking systems may prioritize user experience and response speed, while transaction data generated by corporate online banking systems may prioritize data security and accuracy. Analyzing the characteristics of the initiating systems can help understand the access patterns and requirements of their corresponding data. The transaction product dimension primarily considers the data characteristics of different financial transaction products. For example, data for fund transaction products may include frequently changing information such as net asset value and shares, while data for time deposit products is relatively stable. Understanding the characteristics of transaction products helps determine appropriate data access paths.

[0060] Based on the different business dimensions defined above, we can collect information such as the number of data accesses and access intervals within each business dimension to determine the data's access frequency. For example, we can count the number of times a certain type of transaction data is accessed over a period of time to calculate the average access frequency. Furthermore, we can assess the business's requirements for data real-time performance. For businesses with extremely high data real-time requirements, such as real-time transaction quotes and account balance updates, we need to determine whether the data requires real-time modification.

[0061] When the data attributes corresponding to a business dimension are frequently accessed but do not require real-time modification, configure the data access path corresponding to that business dimension to be in local shared memory. For example, for queries of historical transaction records or teller authority information, which are frequently queried and do not require real-time updates, these can be stored in local shared memory to improve query speed.

[0062] When the data attributes corresponding to a business dimension are accessed infrequently but require real-time modification, configure the data access path for that business dimension as a distributed cache. For example, a user's card activation request, while accessed relatively infrequently, requires real-time updates and can be stored in a distributed cache to quickly access the latest data.

[0063] like Figure 2As shown, a comparative diagram of a local shared memory and a distributed Redis cache in an embodiment of the present application is provided. For data with high access frequency but no real-time modification requirements, the data is obtained in the shared memory, wherein the use of shared memory solves the problem of limited local memory capacity of the process and the problem that data cannot be shared between processes, while having the access performance of the local memory. A shared memory access takes about 10us. In the financial business scenario, due to transaction security requirements, a business process requires an average of about 10 or more shared memory accesses, which takes: St = Ot*C = 10us*10 = 100us, that is, the data is cached in the shared memory for one business process, and the time it takes to access the cached data is 100us, compared to the time of caching the data in the distributed Redis cache (one Redis access takes about 2ms): St = Ot*C = 2ms*10 = 20ms = 20000us. Using the shared memory method at the cache data access level, the time consumption is improved by an order of magnitude, which reduces the time consumption of business processing and improves the system processing capability.

[0064] The embodiments of the present application store data in different caches based on data access frequency and real-time modification requirements, thereby avoiding resource waste. For example, storing less frequently accessed data in a distributed cache instead of occupying local shared memory resources can improve the efficiency of local shared memory usage. By properly configuring data access paths, access pressure on underlying storage systems such as databases can be reduced.

[0065] By configuring data access paths based on multiple business dimensions, such as individual transactions, initiating systems, and transaction products, caching strategies can be flexibly adjusted to meet different business needs and scenarios. For example, when business changes occur, configuration files or database settings can be easily modified to adjust data access paths to meet new business needs.

[0066] By combining local shared memory and distributed cache, we achieve efficient processing of complex transactions in financial scenarios. Especially during peak periods of financial transactions, by properly configuring data access paths, we can fully utilize system resources and improve system processing capabilities and response speed.

[0067] In some embodiments of the present application, determining the data access path of the transaction request based on the transaction request and preset cache access policy configuration information includes: parsing the transaction request to obtain a parsing result of the transaction request, the parsing result of the transaction request including at least one of single transaction dimension information, initiating system dimension information, and transaction product dimension information; generating key index data for accessing the cache based on the parsing result of the transaction request; accessing the distributed cache or the local shared memory based on the data access path includes: accessing the distributed cache or the local shared memory based on the data access path and the key index data of the access cache.

[0068] After receiving a transaction request, it can be parsed. A transaction request may contain multiple types of information. Through parsing, it is broken down into different dimensions, including at least one of individual transaction dimensions, initiating system dimensions, and transaction product dimensions. For example, individual transaction dimensions may include information such as the transaction amount, transaction time, trading institution, transaction teller, and transaction device number; initiating system dimensions indicate which system initiated the transaction; and transaction product dimensions primarily include information such as the product type and product number involved in the transaction.

[0069] Based on the parsed transaction request information, key index data that can be used to access the cache is generated, so that the required data can be quickly located in the cache based on these index data.

[0070] Key index data for accessing the cache is generated based on the parsed results of the transaction request (i.e., at least one of the following: individual transaction dimension information, initiating system dimension information, and transaction product dimension information). This index data refines and transforms the original transaction request information, enabling more efficient cache access. For example, the transaction product number, initiating system identifier, and transaction institution can be combined into a composite index to serve as the key index data for accessing the cache.

[0071] After determining the data access path and key index data for accessing the cache, the distributed cache or local shared memory is accessed based on this information. For example, if the data access path points to the distributed cache and the key index data is "transaction type A - product code B", the corresponding data is searched in the distributed cache based on the index key.

[0072] By generating key index data for accessing the cache, target data in the cache can be quickly located, reducing the time spent searching for data in the cache. In high-frequency trading scenarios, this efficient data access method ensures that trading requests can quickly obtain the required data, thereby reducing transaction latency and improving the responsiveness of the trading system.

[0073] In some embodiments of the present application, determining the data access path of the transaction request based on the key index data of the access cache and the preset cache access policy configuration information includes: matching the parsing result of the transaction request with the preset cache access policy configuration information; and determining the data access path of the transaction request based on the matching result.

[0074] After obtaining the parsing result of the transaction request based on the aforementioned embodiment, the parsed transaction information may include at least one of the single transaction dimension information, the initiating system dimension information, and the transaction product dimension information. According to the characteristics of the preset cache access policy configuration information and the structure of the transaction request parsing result, a suitable matching rule is selected to match the two. For example, each field in the transaction request parsing result can be matched one by one with the fields of the preset cache access policy configuration information, so as to match the corresponding cache access path.

[0075] By accurately matching the transaction request parsing results with the preset cache access policy configuration information, we can quickly determine the data access path that best suits the current transaction request, thereby reasonably allocating cache resources based on different transaction characteristics and business needs, and improving the overall cache utilization and performance.

[0076] In some embodiments of the present application, the data in the distributed cache is stored in the following manner: the end-of-day local file is generated into a shard data file through the end-of-day server, and the end-of-day local file is generated by reading the data in the management database. The data in the shard data file is data with low access frequency but with real-time modification requirements; the shard data file is loaded into the distributed cache.

[0077] like Figure 3 As shown, a schematic diagram of a cache architecture in an embodiment of the present application is provided. The data in the distributed cache can be obtained in the following ways:

[0078] First, the end-of-day server can initiate a data read task at a specific time (e.g., the end of each day after business operations have concluded) and retrieve relevant data from the management database through a pre-defined interface or connection method. The management database stores various business data during system operation, including but not limited to user information, transaction records, and account balances.

[0079] The read data is then generated into a local end-of-day file according to specific formats and rules. The file format can be common text or binary. When generating the file, the data can be initially organized and formatted for subsequent processing. For example, different types of data can be stored in different categories, or transaction records can be sorted chronologically.

[0080] The data in the generated end-of-day local files is then filtered to identify data with low access frequency but requiring real-time modification. This low-frequency data typically refers to data that is infrequently accessed during daily system operations, such as older data in historical transaction records and infrequently used configuration information. Data requiring real-time modification refers to data that may change frequently during business operations, such as temporary business parameters and special user status information.

[0081] The filtered data is sharded according to specific rules to generate sharded data files. Sharding rules can be determined based on data characteristics, business requirements, and system architecture. For example, data can be sharded by time range, storing data from different time periods in separate shard files; data can also be sharded by type, storing different types of data separately. The benefits of sharding are improved data parallel processing capabilities and access efficiency, while also facilitating data management and maintenance.

[0082] Finally, based on the system requirements and the characteristics of the distributed cache, an appropriate distributed cache system is selected and the generated sharded data files are loaded into the selected distributed cache. Different distributed cache systems have different characteristics and advantages. For example, Redis supports a wide range of data types and persistence features. Of course, those skilled in the art may also choose other types of distributed caches based on the needs of actual business scenarios, and this is not a specific limitation here.

[0083] By separating infrequently accessed data from regular data and adopting sharded storage, we can reduce interference with high-frequency data when accessing low-frequency data. This allows faster retrieval of high-frequency data from the cache when it is needed, improving overall data access efficiency. Sharded storage enables data from different shards to be accessed and processed in parallel. For example, when multiple business requests require access to data from different shards simultaneously, the distributed cache can handle these requests simultaneously, improving the system's concurrent processing capabilities.

[0084] In some embodiments of the present application, the local shared memory is provided by a virtual machine, on which one or more container nodes are deployed, and one or more business services on each of the container nodes share the local shared memory on the same container node, and the data in the local shared memory is stored in the following manner: uploading the end-of-day local file to the file server through the end-of-day server, and the end-of-day local file is generated by reading the data in the management database; obtaining the data file from the file server through the container node, and the data in the data file is data with high access frequency but no real-time modification requirement; loading the data file into the local shared memory of each container node on each container node.

[0085] like Figure 4 As shown, a schematic diagram of a local shared memory configuration in an embodiment of the present application is provided. The local shared memory in the embodiment of the present application is provided by a virtual machine, which can be created based on a cloud computing platform or server virtualization technology. The virtual machine acts as an abstraction layer for hardware resources and provides an operating environment for container nodes. When creating a virtual machine, the corresponding hardware resources, such as CPU, memory, and storage, are configured according to business needs.

[0086] One or more container nodes are deployed on a virtual machine. Container technologies, such as Docker, allow applications and their dependencies to be packaged into independent containers, enabling rapid deployment and isolated operation. Each container node can run different business services or multiple instances of the same business service. For example, deploying multiple container nodes running the same payment service on a single virtual machine can improve the system's concurrent processing capabilities.

[0087] Based on the end-of-day local files generated in the aforementioned embodiments, the end-of-day server can further filter out frequently accessed data that does not require real-time modification and upload it to the file server as data to be subsequently stored in the local shared cache. The file server can be a dedicated storage server or cloud storage service for centralized file storage and management. The upload process can be performed using protocols such as FTP and HTTP to ensure file integrity and security.

[0088] Container nodes retrieve data files from the file server, either through scheduled pulls or proactive requests based on business needs. For example, a container node can set up a scheduled task to periodically check for new data files from the file server and download them if available. Alternatively, when a container node starts, it can proactively request the latest data files from the file server. Finally, each container node loads the retrieved data files into local shared memory for fast access by business services.

[0089] This embodiment of the application stores frequently accessed data in the local shared memory of the container node, allowing business services to read data directly from local memory, avoiding network transmission delays and significantly improving data access speed. Using container technology to deploy business services provides greater system flexibility and portability, facilitating the expansion and reduction of business services.

[0090] In some embodiments of the present application, a memory management service is established in each container node, and the memory management service is used to perform at least one of the operations of creating local shared memory, hot updating data, and destroying memory on each container node.

[0091] The embodiment of the present application establishes a memory management service in each container node to implement functions such as creation of shared memory, hot update of data, and memory destruction of each container node.

[0092] Creating shared memory: When a need arises to create local shared memory, an external system or the container node itself can initiate a creation request by calling the memory management service's interface. Upon receiving the request, the memory management service allocates a contiguous memory area within the container node's memory space based on the request parameters and marks it as shared memory. Once creation is complete, the service returns information about the shared memory to the requester, enabling subsequent operations on the shared memory.

[0093] Data hot update: During system operation, when data in shared memory needs to be updated, an external system or container node can send a data hot update instruction through the memory management service interface. After receiving the instruction, the memory management service finds the corresponding shared memory area and performs the data hot update.

[0094] Memory destruction: When shared memory is no longer needed, an external system or container node can initiate a memory destruction request by calling the memory management service's interface. Upon receiving the request, the memory management service locates the corresponding shared memory area, frees the memory space, and marks it as unused. At the same time, it deletes the associated data structures and management information.

[0095] The embodiments of the present application achieve centralized management and optimization of local shared memory by establishing a dedicated memory management service in each container node. The memory management service can dynamically adjust the memory allocation strategy based on the actual situation of the container node, improving memory utilization and management efficiency. In addition, through the operation interfaces such as creation, data hot update, and memory destruction provided by the memory management service, the use of shared memory can be flexibly adjusted according to actual needs, thereby better adapting to changing business needs and improving the scalability of the system.

[0096] In summary, the key points of this application are:

[0097] 1) This application implements a multi-layer caching strategy for financial system transactions. By introducing shared memory, it solves the timeliness problem when transactions access the cache multiple times. At the same time, for transactions with few single processing memory accesses and cache content changes, it uses Redis access. By combining the two caching mechanisms, efficient processing of complex transactions in financial scenarios is achieved.

[0098] 2) This application can select different cache access strategies based on the number of times the cache is accessed during a single transaction (transactions with low-frequency access to the cache query shared cache, and transactions with high-frequency access to the cache query Redis), and implements a flexible real-time configuration mechanism based on multiple dimensions such as transaction dimensions, initiating system, product code, etc., further improving the peak processing efficiency and response speed of financial transactions.

[0099] 3) This application takes into account the fact that financial scenarios may involve multiple cache accesses during the processing of complex transactions, and designs and adopts a more efficient shared cache to improve transaction processing efficiency and reduce communication costs during network transmission.

[0100] 4) This application establishes a complete data management link, which includes the end-of-day server reading the management library data into files and uploading them to the file server; the memory management service establishes shared memory and downloads data files from the file server according to instructions, hot updates the local shared memory, and completes the functions of creating, updating, and destroying shared memory.

[0101] This application makes full use of the host memory and uses the host memory to build a shared memory cache layer in parallel with the distributed Redis cache. Data is classified and stored according to the access characteristics of financial business data. Data with high access frequency and no real-time modification requirements are cached in shared memory. The use of shared memory avoids the previous problems of limited local cache capacity and lack of sharing between multiple processes. At the same time, it combines the low latency and simple and easy-to-use characteristics of local cache, which significantly improves business processing efficiency and business throughput.

[0102] The embodiment of the present application also provides a cache access device 500, such as Figure 5 , a schematic structural diagram of a cache access device according to an embodiment of the present application is provided. The cache access device 500 includes at least: a receiving unit 510, a determining unit 520, and an access unit 530, wherein:

[0103] Receiving unit 510, configured to receive a transaction request;

[0104] A determining unit 520 is configured to determine a data access path for the transaction request based on the transaction request and preset cache access policy configuration information, where the data access path is a distributed cache or a local shared memory;

[0105] The access unit 530 is configured to access the distributed cache or the local shared memory according to the data access path.

[0106] In some embodiments of the present application, the preset cache access policy configuration information is configured in the following manner: determining the data attributes corresponding to different business dimensions, the business dimensions including at least one of a single transaction dimension, an initiating system dimension, and a transaction product dimension; if the data attribute corresponding to the business dimension is data with a high access frequency but no real-time modification requirement, then the data access path corresponding to the business dimension is configured to be a local shared memory; if the data attribute corresponding to the business dimension is data with a low access frequency but a real-time modification requirement, then the data access path corresponding to the business dimension is configured to be a distributed cache.

[0107] In some embodiments of the present application, the determination unit 520 is specifically used to: parse the transaction request to obtain a parsed result of the transaction request, the parsed result of the transaction request including at least one of single transaction dimension information, initiating system dimension information, and transaction product dimension information; generate key index data for accessing the cache based on the parsed result of the transaction request; the access unit is specifically used to: access the distributed cache or the local shared memory based on the data access path and the key index data of the access cache.

[0108] In some embodiments of the present application, the determining unit 520 is specifically configured to: match the parsing result of the transaction request with the preset cache access policy configuration information; and determine the data access path of the transaction request according to the matching result.

[0109] In some embodiments of the present application, the data in the distributed cache is stored in the following manner: the end-of-day local file is generated into a shard data file through the end-of-day server, and the end-of-day local file is generated by reading the data in the management database. The data in the shard data file is data with low access frequency but with real-time modification requirements; the shard data file is loaded into the distributed cache.

[0110] In some embodiments of the present application, the local shared memory is provided by a virtual machine, on which one or more container nodes are deployed, and one or more business services on each of the container nodes share the local shared memory on the same container node, and the data in the local shared memory is stored in the following manner: uploading the end-of-day local file to the file server through the end-of-day server, and the end-of-day local file is generated by reading the data in the management database; obtaining the data file from the file server through the container node, and the data in the data file is data with high access frequency but no real-time modification requirement; loading the data file into the local shared memory of each container node on each container node.

[0111] In some embodiments of the present application, a memory management service is established in each container node, and the memory management service is used to perform at least one of the operations of creating local shared memory, hot updating data, and destroying memory on each container node.

[0112] It can be understood that the above-mentioned cache access device can implement each step of the cache access method provided in the above-mentioned embodiment. The relevant explanations about the cache access method are applicable to the cache access device and will not be repeated here.

[0113] Figure 6 This is a schematic diagram of the structure of a device in the embodiment of the present application. Figure 6 As shown, the device includes one or more processors (or processing units), may further include one or more memories coupled to the processors, and may further include a communication module coupled to the processors.

[0114] The communication module can be used to communicate with other devices or apparatuses, such as sending or receiving data and / or signals. The communication module can include at least one communication module for communication. The communication module can include any interface necessary for communicating with other devices. Exemplarily, the communication module can be a transceiver, circuit, bus, module, or other type of communication module.

[0115] The processor may include, but is not limited to, at least one of the following: a general-purpose computer, a special-purpose computer, a microcontroller, a digital signal processor (DSP), or one or more of a controller-based multi-core controller architecture. A device may have multiple processors, such as application-specific integrated circuit chips, which are time-slave to a clock synchronized with a main processor.

[0116] The memory may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, at least one of the following: read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), or other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, at least one of the following: random access memory (RAM), or other volatile memories that do not persist during a power outage.

[0117] A computer program includes computer-executable instructions that are executed by an associated processor. The program may be stored in ROM. The processor may perform any suitable actions and processes by loading the program into RAM.

[0118] The possible implementation of the present application can be realized by means of a program, so that the communication device can perform any process discussed in the above embodiments. The possible implementation of the present application can also be realized by hardware or by a combination of software and hardware.

[0119] In some embodiments, the program may be tangibly contained in a computer-readable storage medium that may be included in the device (such as in a memory) or other storage device accessible by the device. The program may be loaded from the computer-readable storage medium into RAM for execution. The computer-readable storage medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0120] The present application also provides a computer-readable storage medium having computer instructions or program codes stored thereon, which, when executed by a processor, causes the processor to perform the methods and functions described in any of the above embodiments. A computer-readable medium may be any tangible medium containing or storing a program for or related to an instruction execution system, apparatus, or device. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. Computer-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrated therein. More detailed examples of computer-readable storage media include electrical connections with one or more wires, magnetic media (e.g., magnetic disks, floppy disks, hard disks, tapes, magnetic storage devices), optical media (e.g., optical storage devices, DVDs), semiconductor media (e.g., solid-state drives), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), or any suitable combination thereof.

[0121] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The embodiments of the present application also provide at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes one or more computer-executable instructions, such as instructions included in a program module, which are executed in a device on a real or virtual processor of the target to perform the processes, methods and functions involved in any of the above embodiments. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method.

[0122] The present application also provides a computer program product, including a computer program or instructions, which, when run on a computer, causes the computer to perform the processes, methods, and functions in the above-described embodiments. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of the program modules can be combined or divided between program modules as needed. The machine executable instructions for the program modules can be executed in local or distributed devices. In distributed devices, the program modules can be located in local and remote storage media.

[0123] In general, various embodiments of the present application can be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software, which can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are shown and described as block diagrams, flow charts, or using some other graphical representation, it should be understood that the blocks, devices, systems, techniques, or methods described herein can be implemented as, by way of non-limiting example, hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0124] It should be noted that although the embodiments of the present application are described above in conjunction with the accompanying drawings, the above embodiments are not independent of each other, and they can also be combined to obtain other embodiments. The methods, situations, categories, and divisions of the embodiments in the embodiments of the present application are only for the convenience of description and should not constitute special limitations. The features of the various methods, categories, situations, and embodiments can be combined with each other when they are logical. The various embodiments of the present application can be combined arbitrarily to achieve different technical effects. The embodiments of the present application no longer list various combinations.

[0125] In addition, although the operations of the method of the present disclosure are described in a particular order in the accompanying drawings, this does not require or imply that these operations must be performed in this particular order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can change the order of execution. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step, and / or one step can be decomposed into multiple steps. It should also be noted that the features and functions of two or more devices according to the present disclosure can be embodied in one device. Conversely, the features and functions of a device described above can be further divided into being embodied by multiple devices.

[0126] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0127] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims

1. A cache access method, characterized in that: The cache access method includes: Receive transaction requests; Determining a data access path for the transaction request based on the transaction request and preset cache access policy configuration information, where the data access path is a distributed cache or a local shared memory; The distributed cache or the local shared memory is accessed according to the data access path.

2. The cache access method according to claim 1, wherein: The preset cache access policy configuration information is configured in the following manner: Determining data attributes corresponding to different business dimensions, where the business dimensions include at least one of a single transaction dimension, an initiating system dimension, and a transaction product dimension; If the data attribute corresponding to the business dimension is data with high access frequency but no real-time modification requirement, configure the data access path corresponding to the business dimension to be local shared memory; If the data attribute corresponding to the business dimension is data with low access frequency but real-time modification requirements, the data access path corresponding to the business dimension is configured as a distributed cache.

3. The cache access method according to claim 1, wherein: Determining the data access path of the transaction request according to the transaction request and the preset cache access policy configuration information includes: Parsing the transaction request to obtain a parsing result of the transaction request, wherein the parsing result of the transaction request includes at least one of single transaction dimension information, initiating system dimension information, and transaction product dimension information; Generate key index data for accessing the cache according to the parsing result of the transaction request; Accessing the distributed cache or the local shared memory according to the data access path includes: The distributed cache or the local shared memory is accessed according to the data access path and the key index data of the access cache.

4. The cache access method according to claim 3, wherein: Determining the data access path of the transaction request according to the transaction request and the preset cache access policy configuration information includes: Matching the parsing result of the transaction request with the preset cache access policy configuration information; A data access path for the transaction request is determined according to the matching result.

5. The cache access method according to claim 1, wherein: The data in the distributed cache is stored in the following manner: Generate a shard data file from the end-of-day local file by the end-of-day server. The end-of-day local file is generated by reading data from the management database. The data in the shard data file is data with low access frequency but with real-time modification requirements; The shard data file is loaded into the distributed cache.

6. The cache access method according to claim 1, wherein: The local shared memory is provided by a virtual machine, on which one or more container nodes are deployed. One or more business services on each container node share the local shared memory on the same container node. The data in the local shared memory is stored in the following manner: Uploading the end-of-day local file to the file server through the end-of-day server, wherein the end-of-day local file is generated by reading data from the management database; Obtaining a data file from the file server through the container node, wherein the data in the data file is data with high access frequency but no real-time modification requirement; The data file is loaded into the local shared memory of each container node on each container node.

7. The cache access method according to claim 6, wherein: A memory management service is established in each container node, and the memory management service is used to perform at least one of the following operations: creation of a local shared memory, hot data update, and memory destruction on each container node.

8. A cache access device, characterized in that: The cache access device comprises: A receiving unit, configured to receive a transaction request; a determining unit, configured to determine a data access path for the transaction request according to the transaction request and preset cache access policy configuration information, wherein the data access path is a distributed cache or a local shared memory; An access unit is configured to access the distributed cache or the local shared memory according to the data access path.

9. A device comprising: processor; and a memory arranged to store computer-executable instructions, wherein when the instructions are executed, the processor is caused to perform the cache access method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the cache access method according to any one of claims 1 to 7 is implemented.

Images