High-performance uploading voucher processing method and device, equipment and storage medium

Abstract

The invention relates to the technical field of data processing, can be applied to the fields of medical health, financial science and technology and the like, and discloses a high-performance uploading voucher processing method, device and equipment and a storage medium, and the method comprises the steps: obtaining a preset basic data mirror image file, and loading the basic data mirror image file to a memory to form initial memory cache data; extracting changed basic data from the log table from the basic data mirror image file generation moment to the application service starting moment, synchronizing the changed basic data to the memory, and complementing the initial memory cache data to obtain complete memory cache data; if the basic data is changed, pushing change information of the basic data through the message queue, and updating the complete memory cache data according to the change information; and when the uploading voucher is processed, calling the complete memory cache data in the memory to perform data verification on the uploading voucher. By means of the method, database I / O operation is reduced, and verification processing efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology and can be applied to fields such as medical health and financial technology. In particular, it relates to a high-performance method, apparatus, device and storage medium for uploading credentials. Background Technology

[0002] In a company's financial management system, the general ledger management system is the core support platform. It bears the core responsibility of generating accounting vouchers and managing the entire accounting balance process, serving as a crucial cornerstone for ensuring the accuracy and completeness of financial data. This system not only provides precise accounting data for the preparation of corporate financial statements and the generation of management decision-making reports, but also directly supports the implementation of regulatory compliance requirements. Its operational efficiency and data processing quality directly determine the scientific nature of corporate financial decisions and the timeliness of business responses, playing an irreplaceable role in the operation and management of companies across various industries.

[0003] Especially in the healthcare sector, with the deepening of healthcare system reform and the development of medical groups, large hospitals, chain medical institutions, and healthcare management platforms are continuously expanding their branches, resulting in a significant increase in the number of subsidiaries and a multi-dimensional explosive growth in their financial data. The financial data of these institutions not only covers routine operating income and expenditure but also includes special categories of data such as medical insurance settlement vouchers, research project funding accounting, drug and medical consumable procurement payments, and detailed patient treatment costs. Furthermore, they must strictly comply with medical insurance supervision and medical fee standards. During the voucher issuance process, real-time verification is required to ensure the consistency between financial data and medical business data for each medical insurance reimbursement voucher, the compliance of research funding expenditures, and the standardization of drug and medical consumable charges. This prevents medical insurance penalties or patient complaints due to non-compliant vouchers. However, traditional general ledger systems (such as Oracle EBS) frequently query basic data stored in the database, such as medical insurance catalogs, research funding budgets, and drug and consumable codes, when processing voucher verification in the healthcare field. This leads to a surge in database read / write pressure and a consistently high I / O load. During peak periods such as monthly medical insurance settlements and annual research funding audits, voucher processing efficiency drops significantly, not only extending the arrival cycle of medical insurance reimbursements but also potentially affecting the compliant use of research project funds due to accounting delays, thus restricting the agility of financial operations in healthcare institutions.

[0004] In the fintech sector, with the rapid development of internet banks, securities technology platforms, and third-party payment institutions, fintech companies are characterized by high-frequency transactions, massive amounts of data, and stringent regulations. Their general ledger management systems need to process dozens or even hundreds of transaction vouchers per second (such as user transfer vouchers, securities transaction clearing vouchers, and payment settlement vouchers) in real time, while also meeting multiple compliance requirements including anti-money laundering regulations, fund flow monitoring, and financial consumer rights protection. During voucher creation, basic data such as counterparty information, fund flows, transaction limits, and account status must be verified at millisecond levels to ensure that each voucher complies with regulatory requirements and business rules. However, traditional general ledger systems rely on real-time database queries for verification. During peak periods for fintech companies (such as peak payment periods during e-commerce promotions or the closing clearing period of securities trading days), the database I / O load far exceeds the capacity threshold, leading to voucher verification delays and transaction processing bottlenecks. This not only affects the timeliness of user fund arrivals and the trading experience but may also cause users to miss regulatory data reporting windows due to delayed voucher processing, triggering regulatory compliance risks.

[0005] In summary, whether it's the healthcare sector's requirements for medical insurance compliance and accurate accounting of research funding, or the fintech sector's demands for real-time transaction processing and regulatory compliance, the traditional general ledger management system's reliance on frequent database queries for voucher verification is no longer sufficient to cope with the challenges brought about by explosive data growth as companies expand and business complexity increases. Excessive database read / write pressure and high I / O load are particularly pronounced during peak business periods, leading to low voucher processing efficiency and extended accounting cycles, severely restricting the agility and compliance management capabilities of financial operations in the healthcare and fintech sectors. Summary of the Invention

[0006] The purpose of this invention is to provide a high-performance method, apparatus, device, and storage medium for uploading and processing vouchers, aiming to solve the problems of low voucher processing efficiency and extended accounting cycles in existing general ledger management systems.

[0007] In a first aspect, embodiments of the present invention provide a high-performance method for processing uploaded credentials, including: Obtain a preset basic data image file and load the basic data image file into memory to form initial memory cache data; Extract the basic data that has changed between the time the basic data image file was generated and the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data; If the basic data changes during the operation of the application service, the change information of the basic data is pushed through the message queue, and the complete memory cache data is updated according to the change information. When processing uploaded credentials, the complete memory cache data in the memory is called to verify the uploaded credentials.

[0008] Secondly, embodiments of the present invention provide a high-performance credential uploading processing device, comprising: The acquisition unit is used to acquire a preset basic data image file and load the basic data image file into memory to form initial memory cache data; The extraction unit is used to extract the basic data that has changed from the time the basic data image file was generated to the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data. The push unit is used to push the change information of the basic data through a message queue when the basic data changes during the operation of the application service, and update the complete memory cache data according to the change information; The calling unit is used to call the complete memory cache data in memory to verify the uploaded credentials when processing the uploaded credentials.

[0009] Thirdly, embodiments of the present invention provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the high-performance upload credential processing method described in the first aspect.

[0010] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the high-performance upload credential processing method described in the first aspect.

[0011] This invention discloses a high-performance method, apparatus, device, and storage medium for processing uploaded credentials, comprising: acquiring a preset basic data image file and loading the basic data image file into memory to form initial memory cache data; extracting basic data that has changed between the time the basic data image file was generated and the time the application service started from a log table, synchronizing the changed basic data into memory, and completing the initial memory cache data to obtain complete memory cache data; during the operation of the application service, if the basic data changes, pushing the change information of the basic data through a message queue, and updating the complete memory cache data according to the change information; when processing uploaded credentials, calling the complete memory cache data in memory to perform data verification on the uploaded credentials. This invention avoids accessing the database for each verification by caching the basic data for high-frequency verification in memory, significantly reducing the database read / write frequency and I / O pressure, effectively alleviating the load on the core database, and improving the system's sustainable operation capability. At the same time, memory access speed is much higher than disk access speed, cache verification can be completed in milliseconds, with rapid response, significantly improving the processing performance of the verification process, especially meeting the stringent requirements for real-time performance and response speed in high-concurrency scenarios. Furthermore, by reducing database resource consumption and freeing up CPU computing power and database connection pool resources, the system can handle other core business requests more efficiently, significantly enhancing overall throughput and system stability. This invention also provides a high-performance credential upload processing device, a computer-readable storage medium, and a computer device, all possessing the aforementioned beneficial effects, which will not be elaborated upon further here. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of an application environment for a high-performance upload credential processing method according to an embodiment of the present invention; Figure 2 A flowchart illustrating the high-performance credential uploading processing method; Figure 3 Another flowchart illustrating the high-performance credential uploading processing method; Figure 4 A schematic block diagram of a high-performance upload credential processing device; Figure 5 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 6This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

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

[0015] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more of its features, integrals, steps, operations, elements, components and / or collections thereof.

[0016] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0017] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0018] The high-performance credential uploading processing method provided in this invention can be applied to applications such as... Figure 1In this application environment, the client communicates with the server via a network. The server can obtain a preset basic data image file from the client and load it into memory to form initial memory cache data. It then extracts basic data that has changed between the creation time of the basic data image file and the start time of the application service from the log table, synchronizes the changed basic data to memory, and completes the initial memory cache data to obtain complete memory cache data. During application service operation, if the basic data changes, the change information is pushed through a message queue, and the complete memory cache data is updated according to the change information. When processing uploaded credentials, the complete memory cache data in memory is used to verify the uploaded credentials. In this invention, by caching the basic data for high-frequency verification in memory, database access is avoided for each verification, significantly reducing the database read / write frequency and I / O pressure, effectively alleviating the load on the core database, and improving the system's sustainable operation capability. Simultaneously, memory access speed is much higher than disk access speed, and cache verification can be completed in milliseconds, with rapid response, significantly improving the processing performance of the verification process, especially meeting the stringent requirements for real-time performance and response speed in high-concurrency scenarios. Furthermore, by reducing database resource consumption and freeing up CPU computing power and database connection pool resources, the system can handle other core business requests more efficiently, significantly enhancing overall throughput and system stability. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, AR devices, and portable wearable devices. The server can be implemented using a dedicated server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0019] Please see Figure 2 and Figure 3 This embodiment provides a high-performance method for uploading credentials, including: S101: Obtain a preset basic data image file and load the basic data image file into memory to form initial memory cache data; The acquisition of the preset base data image file includes: The system extracts basic data from the database and generates a basic data image file within a predetermined time.

[0020] Specifically, in the actual deployment of the cache-based high-performance credential upload solution, the application service obtains a preset basic data image file and performs the data generation by extracting database data at a scheduled time every day at 2:00 AM. The specific process is as follows: The application service pre-configures a scheduled task to set the generation time of the basic data image file to 2:00 AM every day. This period is the off-peak business period for companies in the healthcare or fintech sectors (such as the non-clinic hours at night for healthcare institutions and the non-transaction clearing hours at night for fintech platforms). Performing the data extraction operation at this time can minimize the occupation of core business resources. At 2:00 AM every day, the scheduled task is automatically triggered. The application service establishes a stable connection with the enterprise's core financial database through a preset database connection pool, and then executes a structured data extraction script. The script first filters the latest valid data in the basic data table (which stores data such as subject codes and corresponding compliance attributes, customer codes and validity status, project codes and permission ranges, etc.) and the verification rule table (which stores voucher amount thresholds, field format standards, data association rules, etc.), and automatically excludes basic data entries that have been discontinued for more than 3 years (such as expired medical insurance catalog codes and invalid transaction account types) to reduce data redundancy. Then, the filtered structured data is organized into a JSON format dataset according to the logic of basic data classification and verification rule association. The dataset is then compressed into a smaller basic data image file using the GZIP compression algorithm and named according to the naming rule of basic data image_YYYYMMDD.zip (e.g., basic data image_20250908.zip) to ensure that the file can be quickly identified and traced by date. Once generated, the application service automatically stores the image file in the preset directory / data / cache / mirror / on the server. Simultaneously, it records information such as the image file's generation time (accurate to the second), file storage path, data size (e.g., 200MB), and generation time (e.g., 120 seconds) in the image generation log table. This provides a traceability basis for loading the image file and verifying data integrity during subsequent service startup. It also facilitates operations personnel in monitoring the daily image file generation status, ensuring that each basic data image file accurately reflects the complete picture of the basic data related to uploaded credentials verification in the database at 2:00 AM, providing a reliable initial data source for subsequent memory caching.

[0021] When a third-party payment platform in the fintech field deploys a high-performance credential upload solution based on caching, its application service completes the generation of the basic data image file during the daily business downtime period (preset to be 1:00-3:00 AM). When the service restarts or starts for the first time before the business starts at 7:00 AM, it will prioritize the acquisition and memory loading operations of the preset basic data image file to form the initial memory cache data. After the application service starts, it first automatically retrieves the files stored in the default storage path configured by the system (i.e., the finance / cache / mirror_files directory on the platform server) according to the naming rule "Payment Voucher Basic Data Mirror_YYYYMMDD.tar.gz". In this naming rule, "YYYYMMDD" corresponds to the generation date of the mirror file. The application service traverses the file names in the directory and selects the file with the latest date, which is the default basic data mirror file to be loaded on that day. (This file is generated from valid basic data extracted from the platform's core database at 2:00 AM. It contains core data related to payment voucher verification, such as user account status data, transaction amount limit rules, payment channel codes and corresponding compliance verification standards, and counterparty information templates required for anti-money laundering monitoring. It has also been compressed to reduce storage usage.) After obtaining the image file, the application service first calls the preset file verification interface to compare the SHA-256 hash value of the file with the corresponding image file hash value recorded in the database image file log table to confirm that the file has not been damaged or tampered with during storage or transmission, thus ensuring the integrity of the basic data. After the verification is successful, the application service starts the built-in decompression module to decompress the tar.gz format image file and extract the structured basic data organized in CSV format (each row of data corresponds to a basic data record, including fields such as data identifier, data content, and effective status). Subsequently, following the logic of data function classification and fast indexing, the application service loads the decompressed basic data into memory in batches: for example, user account status data is used as the index key, with the current available balance and frozen status of the account as the values ​​to build an in-memory hash table; transaction amount limit rules are used as the composite index key of payment channel code and user level, with the maximum amount of a single transaction and the maximum amount of a daily cumulative transaction as the values ​​to build another set of in-memory index structures; at the same time, anti-money laundering related counterparty information verification templates, payment voucher field format standards, and other rule-type data are stored in the verification rule set data structure in memory.Once all basic and rule data are loaded, the application service forms a complete initial memory cache in memory. This data covers all the basic verification criteria required after the payment voucher is uploaded, and can directly support the real-time verification of various payment vouchers such as user transfer vouchers and merchant settlement vouchers during the morning peak business period of 8:00. This eliminates the need for frequent access to the underlying database during the verification process, laying the foundation for improved payment voucher processing efficiency.

[0022] In the healthcare sector, a large tertiary hospital group deployed a high-performance, cache-based voucher upload solution. Its general ledger management system needed to process various core financial vouchers, including medical insurance settlement vouchers, research funding expenditure vouchers, and drug and consumable procurement vouchers. The verification of these vouchers relied on a large amount of medical-specific basic data. The system was pre-programmed to extract basic data from the core database at 3:00 AM daily (the hospital's off-peak nighttime hours for outpatient and settlement business) to generate a mirror file. This mirror file contained key data such as the latest medical insurance catalog codes and corresponding reimbursement ratios, unique identifiers and pricing standards for drugs and consumables, research project funding budget items and expenditure limits, and patient settlement identity verification rules. This data was named according to the rule "Medical Basic Data Mirror_YYYYMMDD.dat" and stored in the hospital / finance / cache / mirror directory on the server. When the hospital's general ledger system service starts at 7:00 AM daily, it automatically retrieves the latest image file from the directory as the preset base data image file. First, it verifies the file's integrity using an MD5 hash comparison (to prevent errors in reimbursement voucher verification due to corrupted medical insurance catalog data). After successful verification, a dedicated decompression module is called to decompress the image file. Then, the data is loaded into memory according to a fast retrieval logic based on data type: a hash table is built using the medical insurance catalog code as the index key, storing the corresponding reimbursement ratio and applicable disease range; the remaining project funding and compliance clauses are stored using the research project number as the index; and drug and consumable identifiers and charging standards are stored in a memory array according to category. After all data is loaded, the system forms an initial memory cache. When processing medical insurance settlement vouchers subsequently, the system can directly call the medical insurance catalog data in memory to verify whether the voucher item is within the reimbursement scope, without querying the database, effectively avoiding the problem of excessive database load during the morning peak medical insurance reimbursement period.

[0023] S102: Extract the basic data that has changed between the time the basic data image file was generated and the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data; Specifically, the system extracts the basic data that changed between the time the basic data image file was generated and the time the application service started from the log table, synchronizes the changed basic data to memory, and completes the initial memory cache data to obtain the complete memory cache data, including: Obtain the generation time of the basic data image file and the startup time of the application service, and determine the time range for data completion from the generation time of the basic data image file to the startup time of the application service. Retrieve detailed information on all basic data changes pre-recorded in the log table. The detailed information includes, but is not limited to, the change time, unique data identifier, change type, and the data content after the change. Filter the detailed information in the log table based on the time range to extract all basic data change records whose change time falls within the time range; For each selected basic data change record, locate the corresponding basic data item in the initial memory cache data based on the unique data identifier in the change record; If the basic data item already exists in the initial memory cache data and the change type is modification, then update the basic data item with the changed data content; If the underlying data item already exists in the initial memory cache data and the change type is deletion, then mark the underlying data item as invalid; If the basic data item does not exist in the initial memory cache data and the change type is "add", then the changed data content will be added to the initial memory cache data as a new basic data item.

[0024] More specifically, in a cache-based high-performance credential upload solution, after the application service starts and loads the basic data image file generated from the database (such as the initial data source generated at midnight every day) as the initial memory cache data, to address the issue that the image file only contains data from the time of generation and may contain data changes before the service starts, data needs to be supplemented through the log table to ensure the integrity of the memory cache. First, the system automatically obtains the generation time of the basic data image file (e.g., 3 AM every day) and the actual start time of the current application service (e.g., 9 AM on the current day), and uses these two times as boundaries to define the data supplementation time range as 3 AM to 9 AM, accurately pinpointing the basic data change interval that needs to be supplemented.

[0025] Subsequently, the system retrieves all pre-recorded basic data change details in the log table. This information includes not only the change time of the basic data, but also the unique data identifier (such as data ID) used to uniquely identify the data, the change type that distinguishes between "modify", "delete", and "add", and the specific content of the changed data (such as field update values, complete attributes of added data, etc.), ensuring that the information dimensions of each change record are complete and providing a reliable basis for subsequent filtering and processing.

[0026] Based on the established time range (3:00 AM to 9:00 AM), the system filters the change details in the log table by time dimension, automatically filtering out records whose change time is not within this range, and only retaining all basic data change records whose change time is between 3:00 AM and 9:00 AM. This ensures that the filtered change data are all valid changes that occurred before the application service started and after the image file was generated, avoiding interference from invalid data.

[0027] For each basic data change record after filtering, the system accurately locates and matches the corresponding basic data item in the initial memory cache based on the unique data identifier in the record: If the basic data item already exists in the initial memory cache and the change type is "modification", the "modified data content" in the change record is used to overwrite the original content of the corresponding data item in the initial cache, completing the real-time data update; if the basic data item already exists and the change type is "deletion", the data item is marked as "invalid" in the initial memory cache to prevent the misuse of deleted data during subsequent business verification; if the corresponding data item is not located in the initial memory cache based on the unique data identifier and the change type is "add", the "modified data content" in the change record is used as a brand new basic data item and directly added to the initial memory cache to complete the new data.

[0028] Through the above-mentioned determination of the time range of the changed data, retrieval of detailed information, filtering, location and classification, the initial memory cache data was fully supplemented, and finally a complete memory cache data covering all valid changes from the time the basic data image file was generated to the time the application service started was formed. This laid a complete and accurate data foundation for efficient verification based directly on the memory data in the subsequent general ledger voucher preparation process.

[0029] In the healthcare sector, the general ledger system of a large tertiary hospital group needs to process high-frequency vouchers such as medical insurance settlements and research funding expenditures. Every day at 3:00 AM (outside of off-peak periods for medical treatment settlements), it generates a basic data mirror file (containing data such as medical insurance catalog codes, research project funding limits, and drug and consumable pricing standards), and starts the application service at 7:00 AM to handle daytime financial processing needs. After the application service starts, it first reads the generation time of the daily mirror file from the "Mirror Generation Log Table" as "2025-09-10 03:00:00," and simultaneously obtains the system startup time as "2025-09-10 07:00:00," determining the data completion time range to be between these two times. Subsequently, the system calls the "Medical Data Change Log Table," which pre-stores records of changes to basic medical data. Each record in this table includes the change time, a unique data identifier (such as the medical insurance project code "M20250901", drug ID "Y00382", and research project number "K2025012"), the change type (modification / deletion / addition), and the changed data content (such as the medical insurance reimbursement ratio being adjusted from 60% to 80%, the drug status being marked as "discontinued", and the research funding limit being increased by 500,000 yuan). After filtering based on the time range, the system extracts three change records: first, the record of modifying the reimbursement ratio for the medical insurance project "M20250901" (outpatient medication for chronic diseases) at 04:20; second, the record of deleting the drug "Y00382" (expired antibiotics) at 05:15; and third, the record of increasing the funding limit for the research project "K2025012" (clinical research on tumors) at 06:30. For the first record, the system located the corresponding data item in the initial memory cache using the medical insurance project code "M20250901". Since the change type was "modification", the system immediately updated the original 60% data in the cache with "80% reimbursement ratio". For the second record, the system found the drug data item in the initial cache using the drug ID "Y00382" and added an "invalid" mark to the data item according to the "delete" type. This drug information will not be called again during subsequent medical insurance settlement voucher verification. For the third record, after searching the initial cache, no data corresponding to the research project number "K2025012" was found. The system added the changed content such as "500,000 yuan funding limit" and project leader, budget item, etc., according to the "add" type, using the index logic of "project number and funding information" to the initial cache. Finally, the system completed the memory cache data, which is consistent with the business status at the time of the 7 o'clock service start, and can support the real-time compliance verification of subsequent medical insurance settlement vouchers.

[0030] In the fintech field, a certain internet bank's general ledger system needs to process high-frequency transaction vouchers such as user transfers and loan repayments. It generates a basic data mirror file (containing user account information, transfer limits, anti-money laundering blacklists, etc.) at 2:00 AM daily (outside peak trading hours) and starts application services at 8:00 AM to handle daytime transaction peaks. After the application service starts, it first retrieves the mirror generation time "2025-09-10 02:00:00" from the "Mirror Log Table," and then reads the system startup time "2025-09-10 08:00:00" to determine the data completion time range. Next, the system calls the "Financial Data Change Log Table," which records the change time, unique account identifier (such as user account ID "622848XXXXXX1592"), change type, and change content (such as the transfer limit being adjusted from 50,000 yuan to 100,000 yuan, account status "cancelled," and new account opening information). After filtering the time range, two key change records were extracted: one was the transfer limit modification record for user account "622848XXXXXX1592" at 03:30, and the other was the account opening record for new user account "622848XXXXXX7341" at 07:10. There was also one deletion record for canceled account "622848XXXXXX0265" at 05:45. During processing, the system located the account data item in the initial cache using the account ID "622848XXXXXX1592" and updated the transfer limit to 100,000 yuan as "Modified". The system found the corresponding account "622848XXXXXX0265" and marked it as invalid as "Deleted" to avoid subsequent credential verification calling the canceled account information. For "622848XXXXXX7341", since there was no data for this account in the initial cache, the system added the account opening date, initial balance, default limit, and other information to the cache as "Added". After all changes are processed, the initial cache is completed into a full in-memory cache, which can support real-time verification of dozens of transfer vouchers per second during the day without frequent database access.

[0031] S103: If the basic data changes during the operation of the application service, the change information of the basic data is pushed through the message queue, and the complete memory cache data is updated according to the change information; Specifically, in the high-performance credential upload solution based on caching, when the application service is continuously running, if the master data module detects changes in the basic data (such as data field modification, adding data entries, or deleting invalid data), the system will immediately trigger the asynchronous push mechanism of the message queue (MQ) to accurately transmit the change information of the basic data to the application server. To ensure the accuracy and completeness of subsequent memory update operations, the pushed change information must include key core dimensions, specifically covering the unique data identifier used to uniquely identify the data (such as a dedicated data ID), clearly distinguishing the change type of the three operations: "modify," "delete," and "add," and the corresponding data content (for modification or addition operations, it includes the changed data field values, attribute information, etc.; for deletion operations, only a clear identification is needed), to avoid deviations in memory cache updates due to missing information.

[0032] The application server monitors the message channels related to changes in basic data in the message queue in real time. Once a change message is received, it quickly initiates the parsing and processing process: First, based on the unique data identifier in the change message, it accurately locates the corresponding basic data item in the built complete in-memory cache data. If the target data item is successfully located and the change type is "modification", the "modified data content" in the change message is used to directly overwrite the original information of the data item in the complete in-memory cache, realizing real-time updates of cached data and ensuring that the data is consistent with the latest business status. If the target data item is located and the change type is "deletion", the data item is marked as "invalid" in the complete in-memory cache to prevent the accidental use of invalid data during subsequent general ledger voucher verification, ensuring the accuracy of the verification results. If the target data item is not located in the complete in-memory cache and the change type is "addition", the "modified data content" in the change message is used as a brand new basic data item and directly added to the complete in-memory cache data, realizing dynamic completion of cached data.

[0033] Through this message queue-based change push and memory update mechanism, the complete memory cache data can always be synchronized with the latest basic data in the business system. There is no need to rely on frequent database queries to obtain change information. This not only greatly reduces the I / O access pressure of the database, but also ensures the real-time and accuracy of the memory cache data. It provides stable and reliable data support for efficient verification based on memory data in the subsequent general ledger voucher creation process, and further strengthens the advantages of the solution in improving system response speed and optimizing high-concurrency scenario processing capabilities.

[0034] In the healthcare field, during the operation of the general ledger system of a large tertiary hospital group, it is necessary to process the verification of medical insurance settlement vouchers and drug procurement vouchers in real time. Its complete memory cache data includes core basic data such as medical insurance catalog codes, drug and consumable charging standards, and scientific research funding limits. When the medical insurance bureau updates the reimbursement ratio of a certain chronic disease drug (uniquely identified as "Y00456", drug name "metformin hydrochloride extended-release tablets") at 10:30 am, from the original 65% to 80%, the hospital's medical insurance management system, as the source of basic data change, immediately generates a data packet containing change information. This data packet clearly marks the unique data identifier "Y00456", the change type "modification", the changed data content "reimbursement ratio 80%" and the change timestamp "2025-09-12 10:30:22", and pushes it to the preset message queue (MQ) topic. The application service of the hospital's general ledger system has pre-subscribed to this MQ topic and is monitoring data changes in real time. Upon receiving the data packet, it first verifies the data packet format (confirming that it contains key fields such as unique identifier and change type) and the data validity (verifying that "Y00456" belongs to the hospital's drug code). After the verification is successful, the application service locates the basic data item corresponding to the drug in the complete memory cache based on "Y00456". It finds that the data item already exists and the change type is "modified". It then replaces the original 65% of the data in the cache with "reimbursement ratio 80%" and updates the last update timestamp of the data item synchronously. In addition, at 14:15 on the same day, the hospital pharmacy system removed a batch of expired medical consumables (unique identifier "C01234") from the shelves, triggering a "deletion" change in the basic data. The pharmacy system generated a change information data packet containing "C01234" and "deletion" type, and pushed it to the same MQ topic. After receiving it, the application service located the consumable data item corresponding to "C01234" in the cache, marked it as "invalid", and the consumable information will not be called again when verifying drug purchase vouchers in the future, so as to ensure that the cached data is consistent with the actual business status.

[0035] In the fintech field, when a certain internet bank's general ledger system application service is running, it stores basic data such as user account transfer limits, anti-money laundering monitoring lists, and payment channel compliance codes in a complete in-memory cache to support real-time verification of dozens of transfer vouchers per second. When a VIP user (account unique identifier "622848XXXXXX9527") applies to increase their daily transfer limit from 200,000 yuan to 500,000 yuan via mobile banking at 15:40, after the bank's back-end account management system approves the application, it immediately generates a change information data packet, including the account ID "622848XXXXXX9527", the change type "modification", the changed data "daily transfer limit 500,000 yuan", and the timestamp "2025-09-12 15:40:58", and pushes it to the MQ topic. After the application service of the internet bank's general ledger system subscribes to this topic, it quickly receives data packets and verifies the reasonableness of the account ID format and limit value (confirming that 500,000 yuan is within the bank's VIP user limit range). After the verification is successful, it locates the user's limit data item in the complete memory cache based on the account ID and updates the original limit information of 200,000 yuan with "500,000 yuan". At 16:20 on the same day, the bank's compliance department adds a new anti-money laundering monitoring list (account ID "621700XXXXXX3816", affiliated institution "a suspicious payment company"). The compliance system generates a change data packet containing the account ID, the "new" type, and complete institution information, and pushes it to the same MQ topic. After receiving it, the application service searches the complete memory cache and finds no data corresponding to the account ID. Therefore, it adds the account information and affiliated institution as new data items to the cache according to the index logic of "account ID-anti-money laundering information". When processing transfer vouchers involving this account, the cached data can be directly called to complete the anti-money laundering verification without accessing the underlying database.

[0036] In some embodiments, when pushing basic data change information via message queue (MQ), the lack of measures to handle message loss and consumption failure can easily lead to message loss due to network fluctuations or brief MQ service anomalies. This can result in inconsistencies between cached data and business data, affecting the accuracy of uploaded credential verification. To solve this problem, the method includes the following steps: When the master data module detects that basic data has been added, modified, or deleted, it triggers an asynchronous push process via a message queue to push the change information of the basic data (the change information includes at least the unique identifier of the basic data, the change type, the data information after the change, and the version identifier). During the push process, a message sending confirmation (ACK) mechanism is enabled. The master data module determines that the change message has been successfully pushed only after the message queue (MQ) service returns a receiving confirmation signal. If no receiving confirmation signal is received, a retry mechanism is triggered. The number of retries in the retry mechanism is configurable (e.g., 3 times) and the retry interval is configurable (e.g., 100ms) until the push is successful or the configured maximum number of retries is reached. Next, configure a message persistence mechanism for the dedicated channel for transmitting basic data change information in the message queue (MQ). The message persistence mechanism adopts a topic partitioning and replica mechanism such as Kafka, which stores the changed messages on multiple replica nodes to avoid the loss of unconsumed changed messages due to the restart of the message queue (MQ) service. Then, the application server receives the change message through a dedicated listening channel of the message queue (MQ) and processes it. If the change message cannot be processed normally due to "version verification failure" or "abnormal data format", it is transferred to the preset dead-letter queue (DLQ). At the same time as transferring to the dead-letter queue, an alarm mechanism is triggered, which includes at least SMS alarms and operation and maintenance platform notifications. At the same time, a manual retry function for dead-letter messages is configured for the dead-letter queue, allowing operation and maintenance personnel to manually trigger the consumption of change messages in the dead-letter queue. Through the above steps, a full-link reliability assurance mechanism is constructed to ensure that all valid basic data change messages can be consumed by the application server, thereby ensuring the accuracy of the synchronization between memory cache data and business data, and ultimately guaranteeing the accuracy of the uploaded credential verification operation based on memory cache data.

[0037] In some embodiments of a high-performance caching-based credential upload scheme, when the underlying data changes, relying solely on asynchronous message push updates via MQ to update the cache may lead to data inconsistency due to message delivery characteristics. For example, when a company adjusts the single-transaction limit for "marketing activity expense reimbursement" from 50,000 yuan to 60,000 yuan, the master data module first updates the corresponding record in the database and then pushes the change message to the application server via MQ. If the MQ experiences a 30-second delay due to network congestion, and a credential upload verification request accesses the business rule within those 30 seconds, the application server's memory cache will still contain the old value of 50,000 yuan, resulting in a discrepancy between the verification result and the actual business rule. If multiple changes occur simultaneously (such as an immediate adjustment to 65,000 yuan), message out-of-order updates may cause the cache to first update to 65,000 yuan, and then revert to 60,000 yuan due to delayed older messages, further exacerbating data discrepancies.

[0038] To address this issue, the improved solution introduces a write-through strategy when handling data changes at the application layer: When the master data module receives a request to adjust the upper limit of market activity expense reimbursement to 60,000 yuan, it first performs a database update operation, modifying the upper limit field for this business type in the database from 50,000 yuan to 60,000 yuan to ensure the accuracy of persistent storage; simultaneously with the successful commit of the database transaction, the master data module directly calls the application server's cache update interface to synchronously update the upper limit of the corresponding business type in the memory cache from 50,000 yuan to 60,000 yuan, and upgrades the version number from V2 to V3, achieving real-time consistency between the database and the cache; after completing the cache synchronization update, a change message containing the new version number V3 is pushed via MQ as a redundant notification mechanism.

[0039] This strategy ensures that even if MQ messages are not consumed promptly due to delays or out-of-order delivery, the memory cache is synchronized with the latest value through a write-through mechanism. When uploading credentials for verification, the same business rules as the database are always invoked, fundamentally avoiding data inconsistency risks. For example, in the scenario described above, after the change request is processed, regardless of whether the MQ message is delayed, the cache already contains 60,000 yuan. Subsequent verification requests will receive accurate results, ensuring strong data consistency. Simultaneously, the MQ message is retained as a supplementary synchronization mechanism for other nodes in a distributed scenario, balancing performance and reliability.

[0040] S104: When processing the uploaded credentials, the complete memory cache data in the memory is called to verify the uploaded credentials.

[0041] Specifically, during the processing of uploaded credentials, the process of verifying the uploaded credentials by calling the complete memory cache data includes: Parse the uploaded voucher and extract the core fields to be verified. The core fields include at least the basic data code, voucher amount, business type, and voucher creation date. Retrieve the complete memory cache data in memory; Based on the field format validation rules of the complete memory cache data, verify whether the format of the document creation date conforms to the preset date standard, and verify whether the voucher amount is the predetermined numerical type; If the format of the document creation date conforms to the preset date standard and the document amount is a predetermined numerical type, then based on the association relationship of the basic data in the complete memory cache data, the cache basic data record corresponding to the basic data code in the uploaded document is matched, and the existence of the basic data code in the cache basic data record is verified. If the basic data code exists in the basic data record, then combine the amount limit rules of the corresponding business type in the complete memory cache data to verify whether the voucher amount is within the amount range allowed by the business type, and to verify whether there is a logical matching relationship between the voucher amount and the business type. If the voucher amount is within the allowed range for the business type, and there is a logical matching relationship between the voucher amount and the business type, then the uploaded voucher verification is deemed successful. If at least one of the following verification criteria—basic data code, voucher amount, business type, and document creation date—does not meet the requirements, a verification failure message will be generated.

[0042] This embodiment eliminates basic data format errors through field format validation (date, amount type), ensures data validity through basic data encoding matching, and finally ensures business logic compliance through business type amount rule validation. Each validation step is based on complete and real-time updated in-memory cached data (cached data is completed through logs and pushed by MQ changes to ensure completeness and timeliness). This design avoids validation deviations caused by asynchrony between database data and business data, and covers core risk points through comprehensive validation, significantly reducing subsequent accounting problems caused by voucher data errors.

[0043] In the healthcare sector, when processing uploaded medical examination expense reimbursement vouchers, the financial system of a large chain of medical examination institutions first parses the structured data of the uploaded voucher to extract the core fields to be verified: the basic data code is the medical examination item code "T20250901" (corresponding to "full-body in-depth medical examination package"), the voucher amount is "1280 yuan", the business type is "corporate group medical examination expense reimbursement", and the document creation date is "2025-09-18". Subsequently, the system directly calls the complete memory cache data that is pre-built and updated in real time. This cache contains the medical examination item code library, the amount limit rules for group medical examination reimbursement business, and the field format verification standards. The system first verifies whether the document creation date "2025-09-18" conforms to the preset date standard "YYYY-MM-DD" according to the field format validation rules in the cache (the format is correct after verification). At the same time, it confirms that the voucher amount "1280 yuan" is an integer value (without characters or special symbols, the verification passes). Next, based on the association between "physical examination item codes and package information" in the cache, it matches the cached basic data record corresponding to "T20250901" in the voucher and finds that the code exists in the list of valid physical examination items and the package status is "on sale" (verification passes). Then, combined with the amount limit rules of the "corporate group examination fee reimbursement" business type in the cache (the maximum reimbursement for a single physical examination is 1500 yuan), it verifies whether 1280 yuan is within the allowed range (yes), and confirms that the pricing of the "full-body in-depth physical examination package" has a logical matching relationship with "1280 yuan" (there is no disconnect between the pricing and the reimbursement amount). Finally, it determines that the uploaded voucher has passed the verification. If the basic data code of a voucher is "T20259999" (not in the cached project library), or the voucher amount is "1600 yuan" (exceeding the group inspection reimbursement limit), or the voucher date format is "2025.09.18" (not in line with the preset standard), the system will generate a verification failure message containing specific non-compliant items (such as "invalid basic data code" or "voucher amount exceeds the business type limit") and send it back to the enterprise reimbursement submission end.

[0044] In the fintech field, when a third-party payment platform processes merchant settlement voucher uploads, it first parses the voucher data to extract core fields: the basic data code is merchant number "MCH20250810", voucher amount "56,800 yuan", business type "monthly merchant transaction settlement", and voucher creation date "2025-09-30 16:45:30". The system then calls the complete memory cache data, which stores the list of valid merchants, the amount limit rules for each settlement business, and the format validation logic. The system first verifies whether the document creation date "2025-09-30 16:45:30" conforms to the preset standard "YYYY-MM-DDHH:MM:SS" (correct format, verification passed), and whether the voucher amount "56800 yuan" is a valid numerical type (no abnormal characters, verification passed). Then, based on the association between merchant number and merchant status in the cache, it matches the cache record corresponding to "MCH20250810" to confirm that the merchant is in a normal cooperation status and exists in the valid list (verification passed). Next, combined with the amount limit rules of the "monthly merchant transaction settlement" business type in the cache (the minimum monthly settlement amount for this merchant is 1000 yuan, and the maximum amount is 100000 yuan), it verifies whether 56800 yuan is within the allowed range (yes), and confirms that there is a logical matching relationship between "monthly settlement" and "56800 yuan" (this amount is consistent with the merchant's monthly transaction statistics), and determines that the voucher verification is successful. If a voucher's business type is "Monthly Merchant Transaction Settlement" but the amount is "800 yuan" (below the minimum limit), or the basic data code "MCH20259999" is not in the cached merchant list, or the voucher amount is "fifty-six thousand eight hundred yuan" (non-numeric type), the system will generate verification failure information including reasons such as "voucher amount is below the minimum limit for business type" and "basic data code does not exist," to help merchants quickly correct voucher data.

[0045] In some embodiments, it also includes: The complete memory cache data that maintains real-time performance in the current memory is fully extracted, and the extracted complete memory cache data is compressed into a cache snapshot compressed package. Store the cached snapshot compressed package to a preset local disk directory, and record the generation time of the cached snapshot compressed package and store the generation time in the snapshot management log.

[0046] Specifically, in the high-performance caching-based credential upload solution, to ensure the traceability and emergency recovery capabilities of the memory-cached data, the system periodically or as needed performs a full extraction operation on the complete, real-time memory-cached data. This complete memory-cached data is formed after the initial basic data mirror loading, log table data completion, and real-time synchronization of changes through the message queue. It covers all the core information required for credential verification, including all valid basic data codes (such as "ACC-20250908-001", "ACC-20250908-002", etc.), the amount limit rules corresponding to each business type (such as the single amount of 100.00-10000.00 yuan for "department daily office supplies procurement"), the preset format standard for the document creation date (YYYY-MM-DD), and the requirements for the credential amount value type (retaining two decimal places for non-negative values), ensuring that the fully extracted data can completely support subsequent possible credential verification scenarios or data recovery needs.

[0047] After the full extraction is complete, the system will use an efficient compression algorithm (such as GZIP) to compress the extracted complete memory cache data. During the compression process, the system strictly ensures the integrity and accuracy of the data, ensuring that no basic data entries or business rule information are lost, while effectively reducing the data size. The final result is a cache snapshot compressed package with a standardized naming convention, for example, named in the format CacheSnapshot_YYYYMMDDHHMMSS.zip (where YYYYMMDDHH...). MMSS represents the time when the extraction operation was initiated, which helps to quickly identify the period in which the snapshot was generated.

[0048] After compression, the system automatically stores the cached snapshot archive to a preset local disk directory. This directory is pre-configured with dedicated storage permission control and disk space monitoring mechanisms, such as setting the path to app / cache_snapshots. This prevents unauthorized personnel from tampering with or deleting snapshot files and monitors the remaining disk space in real time to avoid snapshot storage failure due to insufficient space. At the same time, the system accurately records the generation time of the cached snapshot archive (accurate to the millisecond level, such as "2025-09-08 16:20:30.456") and associates the generation time with key attribute information such as the snapshot archive file name, storage path, original data size, compressed data size, and compression ratio, and writes them together to the snapshot management log. The snapshot management log is stored in a structured text format. For example, a single log record is 2025-09-08 16:20:30.456|CacheSnapshot_20250908162030.zip| / app / cache_snapshots / |200MB|80MB|60%. This makes it convenient for operations and maintenance personnel to query the snapshot generation history and trace the cached data status of a specific period. It also provides a clear index for rapid recovery when memory cached data is abnormal, further strengthening the data security capabilities of the solution.

[0049] In the healthcare sector, the general ledger system of a large tertiary hospital group needs to ensure the stability of voucher verification for business operations such as medical insurance settlement and research funding accounting. Its in-memory cache maintains real-time, complete data, including the latest medical insurance catalog codes and reimbursement ratios, research project funding limits and usage progress, drug and consumable pricing standards, and inventory status. Based on the hospital's low-traffic period (1:00-1:30 AM daily, during which there are no high-frequency operations such as medical insurance settlement and research funding approval), a scheduled task is configured to trigger a cache snapshot generation process: the application service first performs a full extraction of the current complete in-memory cache data, ensuring that the extracted data covers all basic data related to voucher verification, including the latest reimbursement ratios for medical insurance items such as M20251001 (hypertension outpatient medication), the remaining funding amount for research projects such as K2025023 (cardiovascular clinical research), and the real-time pricing standards for drugs such as Y00568 (aspirin enteric-coated tablets). Furthermore, a read-only lock mechanism is used during the extraction process to prevent data from being affected by real-time changes, ensuring the integrity of the extracted data. After extraction, the application service uses the GZIP compression algorithm to compress the fully extracted cached data into a smaller cache snapshot archive. The archive is named Hospital_Cache_Snapshot_YYYYMMDDHHMMSS.zip, facilitating time-based tracking and reducing disk storage usage. The application service then automatically stores this archive in the preset local disk directory hospital / finance / cache_snapshot. This directory is configured with a disk space monitoring and alerting mechanism to prevent storage overflow due to excessive snapshot files. Simultaneously, the application service adds a new record to the snapshot management log table, detailing the cache snapshot archive's generation time (2025-10-10 01:15:30), archive filename, storage path, data volume before compression, data volume after compression, and generation time. The generation time is associated with the snapshot filename, facilitating quick location of the most recent valid snapshot file in case of cache failure, providing reliable data support for cache recovery.

[0050] In the fintech field, an internet bank's general ledger system needs to handle the voucher verification requirements for high-frequency transfers and loan repayments. Its in-memory cache data, updated in real-time, includes key data such as daily transfer limits for user accounts, anti-money laundering monitoring lists (including account IDs and associated institutions), payment channel compliance codes, and clearing rates. The bank, considering off-peak hours (2:00-2:20 AM daily, when user transactions are less than 5% of the daytime peak), initiates a cache snapshot generation task: the application service first performs a full extraction of the complete in-memory cache data, ensuring it covers the latest transfer limit for 622848XXXXXX9527 (VIP user), the anti-money laundering flag for 621700XXXXXX3816 (suspicious account), and the compliance status of PAY202509 (third-party payment channel), among all verification-related data. During the extraction process, a "data consistency verification" mechanism is used to ensure that every extracted data point is completely consistent with the real-time in-memory data. After extraction, the application service uses the LZ4 compression algorithm (balancing compression efficiency and decompression speed) to compress the full cache data into a cache snapshot compressed package in the format Bank_Cache_Snapshot_20251010020815.lz4. This compression algorithm can compress 1.8GB of original cache data to approximately 350MB, significantly saving disk space. Next, the application service stores the compressed package in a preset local disk directory fintech / bank / cache_snapshot, which is configured with a RAID5 disk array to ensure data storage security. Simultaneously, the application service records key information in the snapshot management log: the cache snapshot generation time 2025-10-10 02:08:15, the compressed package filename, the original data size, the compressed data size, and the generation task ID SNAP20251010001. The generation time is associated with the task ID and storage path, allowing operations personnel to quickly query historical snapshot information through the snapshot management log. If a memory cache crash occurs subsequently, the log can be used to locate the most recent snapshot file, shortening cache recovery time.

[0051] In some embodiments, it also includes: When a memory cache crash is detected, retrieve the most recently generated cache snapshot archive from a preset directory on the local disk; The cache snapshot compressed package is decompressed, the complete memory cache data is extracted and loaded into memory to form the basic data for cache recovery; Query the log table, and based on the generation time of the most recent cache snapshot compressed package recorded in the snapshot management log, filter and extract all changes to basic data from the generation time to the application service restart time; The basic data corresponding to the extracted change records is synchronized to the memory where the cached basic data has been loaded and restored, and incremental completion is performed on the cached basic data.

[0052] Specifically, during the operation of the high-performance caching-based credential upload solution, if the system detects a cache crash through a real-time monitoring mechanism (such as a memory status detection module) (e.g., due to abnormal service restarts, memory overflow, or other issues causing cache data loss or unavailability), it will immediately initiate a cache recovery process to ensure the continuity of the credential upload verification business. First, the system automatically locates the preset cache snapshot storage directory on the local disk. By reading the naming information of all cache snapshot compressed packages in this directory and sorting them in descending order by generation time, it quickly locates and retrieves the most recently generated cache snapshot compressed package. This snapshot package stores the complete memory cache data extracted most recently before the crash, covering all basic data encoding, business type amount limit rules, field format validation standards, and other core validation information.

[0053] Subsequently, the system calls the decompression algorithm matched during compression (such as the GZIP decompression algorithm) to decompress the obtained cache snapshot compressed package. During the decompression process, data integrity verification (such as verifying the file CRC value) is performed simultaneously to ensure that the extracted complete memory cache data is undamaged and complete. After the verification passes, the system loads the batch of data completely into the re-initialized memory space, forming the basic data for cache recovery. At this point, the memory already has the complete verification data foundation at the most recent snapshot time before the crash, which can initially support basic credential verification needs. However, it is necessary to further supplement the changed data from the snapshot generation to the present to ensure real-time performance.

[0054] To achieve real-time replenishment of cached data, the system first accesses the snapshot management log, extracting the generation time of the most recent cache snapshot compressed package, such as 2025-09-08 16:20:30.456, and also records the restart time of the current application service (i.e., the time when the service restarts after a memory cache crash, such as 2025-09-08 17:15:40.123). Using these two times as time boundaries, the system determines the time range of basic data changes that need to be replenished to be from 2025-09-08 16:20:30.456 to 2025-09-08 17:15:40.123. Next, the system queries the basic data log table, filters and extracts all basic data change records within this time range. These records include a unique data identifier for each change, the change type (add / modify / delete), the changed data content, and the specific change time. For example, newly added basic data code ACC-20250908-003, and modified travel expense reimbursement limit rules, etc.

[0055] Finally, the system synchronizes all extracted change records one by one to the memory containing the cached recovery base data, according to the chronological order of the change records, and performs incremental completion operations: For "added" change records, after confirming that the data item does not exist in the cached recovery base data based on the unique data identifier, the changed data content is added to memory as a new data item; for "modified" change records, after locating the corresponding data item in memory, the changed content overwrites the original data; for "deleted" change records, the corresponding data item is found in memory and marked as invalid. Through this incremental completion step, the cached recovery base data in memory is updated to the real-time complete data up to the time of application service restart, maintaining consistency with the memory cache state before the crash, ensuring that the latest and most complete cached data can be called when subsequent credential verification is uploaded, thus fully restoring the high-performance verification capability of the solution.

[0056] In the healthcare field, the general ledger system of a large tertiary hospital group experienced a memory cache crash alarm due to a memory overflow during the peak medical insurance settlement period at 10:30 AM. (The system detects this in real time through a memory usage monitoring module, and a crash is identified when the usage suddenly drops below 10% and there is no normal data interaction.) The system immediately initiated a recovery process: First, it retrieved the most recently generated cache snapshot compressed file, Hospital_Cache_Snapshot_20251010011530.zip, from the preset hospital / finance / cache_snapshot directory on the local disk, sorted by the timestamp of the snapshot file name. (This snapshot was generated at 1:15 AM that day and contains complete basic data such as the medical insurance catalog, research funding, and drug and consumable information at that time.) Next, the system calls a dedicated decompression module to decompress the compressed package, extract the complete memory cache data, load it into the application service memory, and form the basic data for cache recovery. At this time, the memory already contains basic data such as the reimbursement ratio of M20251001 (hypertension outpatient medication) and the remaining funds of K2025023 (cardiovascular clinical research), but lacks the change data between 1:15 am and 10:30 am. Subsequently, the system queried the medical basic data change log table. Based on the snapshot generation time of 2025-10-10 01:15:30 recorded in the snapshot management log, it filtered and extracted three change records between that time and the application service restart time of 2025-10-10 10:35:00: First, the reimbursement ratio of medical insurance project M20251001 was modified at 8:20 (e.g., from 65% to 80%). Second, the charging standard of Y00568 (enteric-coated aspirin tablets) was deleted at 9:10 (due to drug removal from shelves). Third, the funding limit of scientific research project K2025023 was increased at 10:00 (e.g., from 800,000 yuan to 1,000,000 yuan). Finally, the system synchronized the basic data corresponding to these three change records to the memory that had been loaded with cached basic data: updated the original data of M20251001 with 80% of the reimbursement ratio, marked Y00568 as invalid, added an additional 200,000 yuan of funding to K2025023, completed the incremental completion of the cached basic data, and enabled the memory cache to be quickly restored to the real-time state before the crash. It only took 2 minutes to resume supporting medical insurance settlement voucher verification and did not have a significant impact on patient reimbursement business.

[0057] In the fintech sector, a certain internet bank's general ledger system experienced a memory cache crash due to a node failure during the peak user transfer period at 3:00 PM (the system uses node heartbeat detection; if no data response is received from the node after three consecutive failures, a crash recovery is triggered). After the recovery process was initiated, the system first accessed the local disk fintech / bank / cache_snapshot preset directory and filtered for the most recent compressed file based on the snapshot generation timestamp (generated at 2:08 AM that day, containing basic data such as user account limits and anti-money laundering lists). Using the LZ4 fast decompression algorithm, the system extracted the original cached data and loaded it into memory, forming the basic data for cache recovery. At this point, the memory stored data such as the daily transfer limit of 200,000 yuan for VIP user 622848XXXXXX9527 and the anti-money laundering flag for suspicious account 621700XXXXXX3816, but lacked change information from 2:08 AM to 3:00 PM. Subsequently, the system queried the financial basic data change log table, using the snapshot generation time of 2025-10-10 02:08:15 as the starting point, and filtered for two key change records between the snapshot generation time of 2025-10-10 15:05:00 and the restart time: First, the transfer limit for user 622848XXXXXX9527 was modified at 10:15 (increased from 200,000 yuan to 500,000 yuan); second, a new account was added for user 622848XXXXXX7341 at 14:30 (default limit 50,000 yuan, status normal). The system synchronized these two change records to memory: updating the limit data for 622848XXXXXX9527, and adding the account information of 622848XXXXXX7341 as a new data item to the cache, completing the incremental completion of basic data restoration from the cache. After restoration, the system immediately supported user transfer voucher verification, avoiding user complaints and regulatory risks caused by transaction interruptions.

[0058] In some embodiments, it also includes: Attach a version identifier to each basic data record in the memory cache; When pushing changes to basic data via message queue, extract the new version identifier from the changes. Compare the new version identifier with the version identifier of the underlying data; If the version number of the new version identifier is greater than the version number of the version identifier of the base data, the change information is determined to be an update message, and the cached data update operation is performed. If the version number of the new version identifier is less than or equal to the version number of the version identifier of the base data, the change information is determined to be out-of-order duplicate information.

[0059] Specifically, in the high-performance credential upload solution based on caching, to address potential out-of-order and duplicate issues when pushing basic data change information via message queues, and to ensure the accuracy and consistency of cached data, the system attaches a unique version identifier to each basic data record in the memory cache. The version identifier uses a structured format combining a unique identifier for the basic data and a version number. For example, if the basic data is coded as ACC-20250908-001 (corresponding to the basic configuration data for the department's daily office supplies procurement), after being loaded into memory from the image file for the first time and log completion is completed, its initial version identifier is set to ACC-20250908-001_V1, where V1 represents the initial version. Each subsequent valid change increments the version number in a natural number sequence (e.g., V2, V3), ensuring that the version evolution trajectory of each piece of basic data is clearly traceable.

[0060] When the master data module detects a change in basic data (such as the single reimbursement limit for ACC-20250908-001 being adjusted from 10,000 yuan to 12,000 yuan), the system will push the change information of the basic data through the message queue according to the preset mechanism. The change information will also forcibly carry the new version identifier. The new version identifier corresponding to this change is ACC-20250908-001_V2. It also includes core information such as the change type (modification) and the changed data content (amount limit of 12,000 yuan), providing key basis for subsequent version verification on the memory cache side.

[0061] The application server monitors the message queue's change channel in real time. Once it receives the aforementioned change information, it first extracts the new version identifier ACC-20250908-001_V2 from the message. Based on the unique identifier ACC-20250908-001 in the underlying data, it precisely locates the corresponding underlying data record in the memory cache and then obtains the current version identifier of that record (at this point, ACC-20250908-001_V1). Subsequently, the system compares the version numbers in the two version identifiers (i.e., compares the number 2 after extracting V with 1).

[0062] If the version number (2) of the new version identifier is greater than the version number (1) of the basic data record in the memory cache, the change information is determined to be a valid update message, and the cache data update operation is immediately executed: the content of the upper limit of RMB 12,000 in the change information is used to overwrite the original configuration of the corresponding data item in memory, and the version identifier of the data record is updated synchronously to ACC-20250908-001_V2 to ensure that the memory data is consistent with the latest business status; if the system receives change information for ACC-20250908-001 with version identifier ACC-20250908-001_V1 or V0 due to network delay, message retransmission, etc., and finds that the new version number (1 or 0) is less than or equal to the version number (2) of the current memory data through version number comparison, the change information is directly determined to be out-of-order duplicate information, and no cache update operation is performed to avoid the problem of memory cache data rollback or inconsistency caused by old version data overwriting new version data, further ensuring the reliability of complete cache data in memory, and providing accurate and real-time data support for the upload voucher verification process.

[0063] In the healthcare field, a provincial medical insurance settlement platform stores basic data such as medical insurance catalog items and drug reimbursement ratios in its memory cache. Each record is appended with an incrementing version identifier (e.g., the initial version of medical insurance item M20251101 is 1, and the version number increments by 1 after each valid change). When the medical insurance bureau adjusts the reimbursement ratio of this item at 9:30 AM (e.g., from 60% to 70%), the change system generates change information containing the new version identifier 2 and pushes it to the platform application service via a message queue. Upon receiving the change information, the application service extracts the version number 2 from the change information and compares it with the current version number 1 of M20251101 in the memory cache. Since 2 > 1, it is determined to be an update message, and the cached data is immediately updated with the new reimbursement ratio, while simultaneously upgrading the version number to 2. If, due to network delays, the previous version number 1 change information (originally 60%) is only pushed to the service, the application service will extract version number 1 and compare it with the updated version number 2 in the cache. Since 1 < 2, it will be judged as out-of-order duplicate information and will be discarded without performing the update, thus avoiding the rollback of medical insurance settlement data due to message timing issues.

[0064] In the fintech field, a securities trading platform's memory cache stores basic data such as user trading permissions and daily position limits. Each record's version identifier is generated in the form of a timestamp plus a sequence number (e.g., user U20250512's initial position limit version is 20251013080000_1). When a user requests an increase in their position limit at 14:20, the system generates a new version identifier, 20251013142000_2. After being pushed via a message queue, the application service extracts this version number and compares it with the user's current version, 20251013080000_1, in the cache. Because the new timestamp is updated and the sequence number is larger, it is determined to be a valid update message, and the limit adjustment is executed, updating the version number. If the change information (version 20251013141500_2) arrives at 14:25 on the same day due to queue congestion, the application service will extract its version number and compare it with the updated 20251013142000_2 in the cache. Since the timestamp is earlier, it will be determined to be out-of-order information and no update will be performed. This ensures that the user's transaction permission data always reflects the latest status and avoids permission abnormalities caused by duplicate messages.

[0065] This embodiment caches the basic data for high-frequency verification in memory, avoiding database access for each verification. This significantly reduces the database read / write frequency and I / O pressure, effectively alleviating the load on the core database and improving the system's sustainable operation. Simultaneously, memory access speed is far faster than disk access; cached verification can be completed in milliseconds, providing rapid response and significantly improving the processing performance of the verification process, especially meeting the stringent requirements for real-time performance and response speed in high-concurrency scenarios. Furthermore, by reducing database resource consumption and freeing up CPU computing power and database connection pool resources, the system can handle other core business requests more efficiently, significantly enhancing overall throughput and system stability. Moreover, when a large number of users or the system concurrently access the verification interface, the memory cache can quickly respond to requests, avoiding delays, timeouts, or service degradation caused by database bottlenecks, ensuring business continuity and user experience, and supporting large-scale business growth.

[0066] Please see Figure 4 This embodiment provides a high-performance credential upload processing device 400, including: The acquisition unit 401 is used to acquire a preset basic data image file and load the basic data image file into memory to form initial memory cache data; Extraction unit 402 is used to extract the basic data that has changed from the time the basic data image file was generated to the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data; The push unit 403 is used to push the change information of the basic data through a message queue when the basic data changes during the operation of the application service, and update the complete memory cache data according to the change information. Calling unit 404 is used to call the complete memory cache data in memory to verify the uploaded credentials when processing the uploaded credentials.

[0067] Furthermore, the acquisition unit 401 includes: The file generation subunit is used to extract basic data from the database and generate a basic data image file within a predetermined time.

[0068] Furthermore, the extraction unit 402 includes: The range determination subunit is used to obtain the generation time of the basic data image file and the application service startup time, and determine the data completion time range as the time from the generation time of the basic data image file to the startup time of the application service. The information retrieval subunit is used to retrieve detailed information on all basic data changes pre-recorded in the log table. The detailed information includes, but is not limited to, the change time, unique data identifier, change type, and changed data content of the basic data. The information filtering subunit is used to filter the detailed information in the log table based on the time range and extract all basic data change records whose change time is within the time range. The data item location subunit is used to locate the corresponding basic data item in the initial memory cache data for each selected basic data change record based on the unique data identifier in the change record. The data item update subunit is used to update the basic data item with the changed data content if the basic data item already exists in the initial memory cache data and the change type is modification. The invalid subunit is used to mark the basic data item as invalid if the basic data item already exists in the initial memory cache data and the change type is deletion; A new sub-unit is added to the initial memory cache data if the basic data item does not exist in the initial memory cache data and the change type is "add".

[0069] Furthermore, the calling unit 404 includes: The voucher parsing subunit is used to parse the uploaded voucher and extract the core field information to be verified. The core field information includes at least the basic data code, voucher amount, business type and voucher creation date. The data retrieval subunit is used to retrieve complete memory-cached data in memory; The data verification subunit is used to verify whether the format of the document creation date conforms to the preset date standard and whether the voucher amount is a predetermined numerical type, based on the field format verification rules of the complete memory cache data. The record matching subunit is used to match the cached basic data record corresponding to the basic data code in the uploaded voucher according to the association relationship of the basic data in the complete memory cache data if the format of the document date conforms to the preset date standard and the voucher amount is a predetermined numerical type, and to verify whether the basic data code exists in the cached basic data record. The amount verification subunit is used to verify whether the voucher amount is within the allowed amount range of the business type, and to verify whether there is a logical matching relationship between the voucher amount and the business type, if the basic data code exists in the basic data record, in conjunction with the amount restriction rules of the corresponding business type in the complete memory cache data. The verification passed subunit is used to determine that the uploaded voucher has passed verification if the voucher amount is within the amount range allowed by the business type and the voucher amount has a logical matching relationship with the business type; The failure information generation subunit is used to generate verification failure information if at least one of the following verification criteria—basic data encoding, voucher amount, business type, and document creation date—does not meet the requirements.

[0070] Furthermore, it also includes: The full extraction unit is used to extract all the real-time memory cache data in the current memory and compress the extracted full memory cache data into a cache snapshot compressed package. The compressed package storage unit is used to store the cache snapshot compressed package to a preset local disk directory, and at the same time record the generation time of the cache snapshot compressed package and store the generation time in association with the snapshot management log.

[0071] Furthermore, the description also includes: The retrieval unit is used to retrieve and obtain the most recently generated cache snapshot compressed package from a preset directory on the local disk when a memory cache crash is detected. The decompression processing unit is used to decompress the cache snapshot compressed package, extract the complete memory cache data and load it into memory to form the cache recovery basic data; The filtering and extraction unit is used to filter and extract all changes to basic data from the snapshot management log table based on the most recent generation time of the cached snapshot compressed package recorded in the snapshot management log, from the generation time to the application service restart time. The incremental completion unit is used to synchronize the basic data corresponding to the extracted change record to the memory that has been loaded with the cached recovery basic data, and to perform incremental completion on the cached recovery basic data.

[0072] Furthermore, it also includes: An append unit is used to append a version identifier to each basic data record in the memory cache; The identifier extraction unit is used to extract the new version identifier from the change information when the change information of the basic data is pushed through the message queue. The comparison unit is used to compare the new version identifier with the version identifier of the underlying data; The first determination unit is used to determine that the change information is an update message if the version number of the new version identifier is greater than the version number of the version identifier of the basic data, and to perform a cache data update operation. The second determination unit is used to determine that the change information is out-of-order duplicate information if the version number of the new version identifier is less than or equal to the version number of the version identifier of the basic data.

[0073] This invention provides a high-performance credential upload processing device. First, a preset basic data image file is acquired and loaded into memory to form initial memory cache data. Then, basic data that has changed between the creation time of the basic data image file and the start time of the application service is extracted from the log table, and the changed basic data is synchronized to memory to complete the initial memory cache data, resulting in complete memory cache data. During application service operation, if the basic data changes, the change information is pushed through a message queue, and the complete memory cache data is updated according to the change information. When processing uploaded credentials, the complete memory cache data in memory is used to verify the uploaded credentials. By caching frequently verified basic data in memory, database access is avoided for each verification, significantly reducing the database read / write frequency and I / O pressure, effectively alleviating the load on the core database, and improving the system's sustainable operation capability. Simultaneously, memory access speed is much higher than disk access speed, and cache verification can be completed in milliseconds, with rapid response, significantly improving the processing performance of the verification process, especially meeting the stringent requirements for real-time performance and response speed in high-concurrency scenarios. In addition, by reducing database resource consumption and freeing up CPU computing power and database connection pool resources, the system can handle other core business requests more efficiently, resulting in a significant improvement in overall throughput and system stability.

[0074] Specific limitations regarding the high-performance credential upload processing device can be found in the limitations of the high-performance credential upload processing method described above, and will not be repeated here. Each unit in the aforementioned high-performance credential upload processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each unit.

[0075] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a high-performance credential upload processing method on the server side.

[0076] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the client-side functions or steps of a high-performance credential upload processing method.

[0077] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain a preset basic data image file and load the basic data image file into memory to form initial memory cache data; Extract the basic data that has changed between the time the basic data image file was generated and the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data; If the basic data changes during the operation of the application service, the change information of the basic data is pushed through the message queue, and the complete memory cache data is updated according to the change information. When processing uploaded credentials, the complete memory cache data in the memory is called to verify the uploaded credentials.

[0078] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain a preset basic data image file and load the basic data image file into memory to form initial memory cache data; Extract the basic data that has changed between the time the basic data image file was generated and the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data; If the basic data changes during the operation of the application service, the change information of the basic data is pushed through the message queue, and the complete memory cache data is updated according to the change information. When processing uploaded credentials, the complete memory cache data in the memory is called to verify the uploaded credentials.

[0079] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0080] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0081] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0082] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A high performance upload credential processing method, characterized by, include: Obtain a preset basic data image file and load the basic data image file into memory to form initial memory cache data; Extract the basic data that has changed between the time the basic data image file was generated and the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data; If the basic data changes during the operation of the application service, the change information of the basic data is pushed through the message queue, and the complete memory cache data is updated according to the change information. When processing uploaded credentials, the complete memory cache data in the memory is called to verify the uploaded credentials.

2. The high-performance upload credential processing method according to claim 1, characterized in that, The process of obtaining the preset basic data image file includes: The system extracts basic data from the database and generates a basic data image file within a predetermined time.

3. The high-performance upload credential processing method according to claim 1, characterized in that, The process involves extracting the changed basic data from the log table between the time the basic data image file was generated and the time the application service started, synchronizing the changed basic data to memory, and completing the initial memory cache data to obtain the complete memory cache data, including: Obtain the generation time of the basic data image file and the start time of the application service, and determine the time range for data completion as the time from the generation time of the basic data image file to the start time of the application service. Retrieve detailed information on all basic data changes pre-recorded in the log table. The detailed information includes, but is not limited to, the change time, unique data identifier, change type, and changed data content of the basic data. Based on the time range, the detailed information in the log table is filtered to extract all basic data change records whose change time falls within the time range; For each selected basic data change record, the corresponding basic data item is located in the initial memory cache data based on the unique data identifier in the change record. If the basic data item already exists in the initial memory cache data and the change type is modification, then the basic data item is updated with the changed data content; If the basic data item already exists in the initial memory cache data and the change type is deletion, then the basic data item is marked as invalid. If the basic data item does not exist in the initial memory cache data and the change type is "add", then the changed data content will be added to the initial memory cache data as a new basic data item.

4. The high-performance upload credential processing method according to claim 1, characterized in that, The step of verifying the uploaded credentials by calling the complete memory cache data in memory during the credential processing includes: The uploaded voucher is parsed to extract the core field information to be verified. The core field information includes at least the basic data code, voucher amount, business type and voucher creation date. Retrieve the complete memory cache data in memory; Based on the field format validation rules of the complete memory cache data, verify whether the format of the document creation date conforms to the preset date standard, and verify whether the voucher amount is a predetermined numerical type; If the format of the document creation date conforms to the preset date standard and the voucher amount is a predetermined numerical type, then according to the association relationship of the basic data in the complete memory cache data, the cache basic data record corresponding to the basic data code in the uploaded voucher is matched, and it is verified whether the basic data code exists in the cache basic data record. If the basic data encoding exists in the basic data record, then, in conjunction with the amount limit rules corresponding to the business type in the complete memory cache data, verify whether the voucher amount is within the amount range allowed by the business type, and verify whether there is a logical matching relationship between the voucher amount and the business type; If the amount of the voucher is within the range allowed by the business type, and the amount of the voucher has a logical matching relationship with the business type, then the uploaded voucher is deemed to have passed the verification. If at least one of the following verification criteria—basic data encoding, voucher amount, business type, and document creation date—fails, a verification failure message will be generated.

5. The high-performance upload credential processing method according to claim 1, characterized in that, Also includes: The complete memory cache data that maintains real-time performance in the current memory is fully extracted, and the extracted complete memory cache data is compressed into a cache snapshot compressed package. The cache snapshot compressed package is stored in a preset local disk directory, and the generation time of the cache snapshot compressed package is recorded and the generation time is associated with and stored in the snapshot management log.

6. The high-performance upload credential processing method according to claim 5, characterized in that, Also includes: When a memory cache crash is detected, retrieve the most recently generated cache snapshot archive from a preset directory on the local disk; The cache snapshot compressed package is decompressed to extract complete memory cache data and load it into memory, forming the basic data for cache recovery; Based on the generation time of the most recent cache snapshot compressed package recorded in the snapshot management log, filter and extract all basic data change records from the generation time to the application service restart time from the log table; The basic data corresponding to the extracted change records is synchronized to the memory that has been loaded with the cached recovery basic data, and incremental completion is performed on the cached recovery basic data.

7. The high-performance upload credential processing method according to claim 1, characterized in that, Also includes: Attach a version identifier to each basic data record in the memory cache; When the change information of the basic data is pushed through the message queue, the new version identifier is extracted from the change information; Compare the new version identifier with the version identifier of the underlying data; If the version number of the new version identifier is greater than the version number of the version identifier of the basic data, the change information is determined to be an update message, and a cache data update operation is performed. If the version number of the new version identifier is less than or equal to the version number of the version identifier of the base data, the change information is determined to be out-of-order duplicate information.

8. A high-performance credential uploading processing device, characterized in that, include: The acquisition unit is used to acquire a preset basic data image file and load the basic data image file into memory to form initial memory cache data; The extraction unit is used to extract the basic data that has changed from the time the basic data image file was generated to the time the application service started from the log table, synchronize the changed basic data to memory, and complete the initial memory cache data to obtain complete memory cache data. The push unit is used to push the change information of the basic data through a message queue when the basic data changes during the operation of the application service, and update the complete memory cache data according to the change information; The calling unit is used to call the complete memory cache data in memory to verify the uploaded credentials when processing the uploaded credentials.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the high-performance upload credential processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the high-performance upload credential processing method as described in any one of claims 1 to 7.

Images