Unified query parameter based dual channel access method for cache database

Abstract

This application provides a dual-channel access method for cached databases based on unified query parameters. First, the original query parameters are obtained and uniformly parsed to construct a unified query parameter structure containing a query condition tree and meta-parameters from query conditions with different input formats. Based on this unified query parameter structure, a cache index path is generated. The cache index path simultaneously includes a set of filter tokens, sorting rules, and range intervals, enabling a unified expression of query conditions between cache queries and database queries. During the data access phase, the cache index is accessed first based on the cache index path. If the corresponding data exists in the cache, it is returned directly; otherwise, a database query statement is automatically generated and executed. After the query is completed, the cache is updated. This achieves cache-first dual-channel access, simplifies query processing logic, improves cache hit rate, reduces repeated database access, and makes the query transformation and origin retrieval process more unified and efficient.

Description

Technical Field

[0001] This application relates to the field of computer data storage and caching, and in particular to a dual-channel access method for a cache database based on unified query parameters. Background Technology

[0002] In the field of computer data storage and caching technology, application systems often need to handle both cache queries and database queries simultaneously, but these differ significantly in query languages ​​and parameter formats. Inconsistencies in the formats of Hypertext Transfer Protocol query strings, Object Tags format query parameters, and cache index paths lead to multiple layers of format conversion logic at the application layer, increasing maintenance costs. Most existing query parameter parsers only support simple key-value pairs, lacking the ability to recognize AND / OR logical combinations and operator prefixes, making it difficult to express complex query conditions. Furthermore, the parsed results are disconnected from the cache index structure; cache queries are based on key-value pairs, while database queries are based on Structured Query Language (SCL), making direct reuse impossible. Developers must manually write cache key concatenation and origin-fetching logic. In addition, origin-fetching strategies for cache misses are typically hard-coded into the application code, lacking unified management. This prevents query conditions with different input formats but identical semantics from sharing cache nodes, impacting cache hit rates.

[0003] The aforementioned issues complicate the query transformation process, increase development workload, and limit system scalability. Therefore, a dual-channel access method for a cached database based on unified query parameters is needed to simplify the query processing flow and improve data query response performance. Summary of the Invention

[0004] The purpose of this application is to at least solve one of the aforementioned technical defects, particularly the technical defects of complex query processing flow and low response performance of data query in the prior art.

[0005] Firstly, this application provides a dual-channel access method for a cached database based on unified query parameters, the method comprising:

[0006] Retrieve the original query parameters from the query request;

[0007] The original query parameters are parsed uniformly to construct a unified query parameter structure;

[0008] The unified query parameter structure includes a query condition tree and meta-parameters;

[0009] Generate a cache index path based on the unified query parameter structure;

[0010] The cache index path includes a set of filter tokens, a sorting rule, and a range.

[0011] Access the cache index according to the cache index path, and when the data item set corresponding to the cache index path in the cache index contains a data item, return the cached data;

[0012] When the number of data items in the set of data items corresponding to the cache index path in the cache index is empty, a database query statement is generated according to the cache index path and the database query is executed to obtain the query result and update the cache.

[0013] As a feasible implementation method, the step of uniformly parsing the original query parameters and constructing a unified query parameter structure includes:

[0014] Identify the input format of the original query parameters;

[0015] When the input format is a Hypertext Transfer Protocol query string, the key-value pairs are parsed by the delimiter and nested logical combination tags are identified. When the input format is an object tag format, the object attributes are traversed and the corresponding parameter values ​​are parsed.

[0016] The registry is used to check whether the current parameter name is a meta parameter based on the meta parameter key name.

[0017] The registry predefines the mapping relationship between parameter names and meta-parameter types for the meta-parameter key names.

[0018] If the current parameter name is a meta parameter, the parameter value is stored in the meta parameter area of ​​the unified query parameter structure according to the registration type;

[0019] The meta-parameter region includes sorting rules, range intervals, and a set of original transparent parameters;

[0020] If the current parameter name is not a meta parameter, the parameter value corresponding to the current parameter name will be parsed as a normal query parameter and converted into a query condition tree node.

[0021] As a feasible implementation method, the ordinary query parameters are parsed into a query condition tree through operator prefix identification and / or logical combination, specifically including:

[0022] Scan field names and identify the operator types corresponding to the field name prefixes;

[0023] The operator types include equal operator, not equal operator, greater than operator, less than operator, fuzzy matching operator, and non-matching operator;

[0024] Based on the identified operator type, extract the field name after removing the prefix and the corresponding parameter value, and construct the field name, the operator type and the parameter value into a key-value query parameter node, which serves as the leaf node of the query condition tree;

[0025] Detect logical combination markers in the original query parameters. When an AND logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the AND logical node; when an OR logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the OR logical node.

[0026] Recursively form a multi-level query condition tree;

[0027] Wherein, the leaf nodes are key-value query parameter nodes, and the non-leaf nodes are AND logical nodes and OR logical nodes;

[0028] Furthermore, the meta-parameters include range parameters, sorting parameters, or pass-through parameters as is. The step of storing parameter values ​​into the meta-parameter area of ​​the unified query parameter structure according to the registration type includes:

[0029] When the registration type is sorting type, parse the sorting field and ascending / descending order, and store the parsing result in the sorting rule;

[0030] When the registration type is a range type, the range interval is constructed and stored based on the offset and the number of limits, or based on the page number and the number per page.

[0031] When the registration type is the original transparent transmission type, the parameter name and parameter value are stored in the original transparent transmission parameter set.

[0032] As a feasible implementation method, generating the cache index path based on the unified query parameter structure includes:

[0033] Traverse the key-value query parameter nodes in the query condition tree, connect the operator identifier of each key-value query parameter node with the parameter value using a preset separator to form a token value, use the field name as the key and the token value as the value to generate the filter token set;

[0034] Extract sorting rules from the meta parameters and generate index path components corresponding to the sorting rules;

[0035] Extract the range interval from the meta parameters and generate the index path component corresponding to the range interval;

[0036] Furthermore, before generating the set of filter tokens, the data type corresponding to the field is determined according to a preset scenario mechanism. When the field value needs to be converted, the parameter value is converted according to the data type corresponding to the field, and the converted parameter value is used as the parameter value part in the token value.

[0037] The data types mentioned include string type, numeric type and boolean type.

[0038] As one possible implementation, accessing the cache index according to the cache index path includes:

[0039] Create a cached index path accessor, which initializes the unorchestrated token pool, the orchestrated token pool, the unorchestrated sorted pool, and the orchestrated sorted pool according to the filter token set and sorting rules;

[0040] Receive field orchestration instructions and move the specified field from the unorchestrated token pool or the unorchestrated sorting pool into the corresponding orchestrated set;

[0041] Following the hierarchical order of the cache index tree, the cache index nodes are accessed layer by layer according to the fields in the orchestrated set;

[0042] The cache index tree includes a first layer, an anonymous layer, and a leaf layer. In the first layer, the corresponding branch under the root node is accessed according to the orchestrated fields. In the anonymous layer, the fields in the unorchestrated token pool are accessed sequentially. In the leaf layer, the data set corresponding to the leaf node is accessed.

[0043] When a leaf node is reached, it is determined whether the orchestrated token pool, the unorchestrated token pool, and the unorchestrated sort pool are all empty. If all sets are empty, the index path traversal is considered complete.

[0044] Sort the data set corresponding to the leaf node according to the sorting field in the sorting pool, and truncate the data set corresponding to the leaf node according to the range interval to obtain the matching data record;

[0045] The starting value of the range interval is included, but the ending value is not included. When the ending value is a preset null value, all data from the starting value to the end of the data set is extracted.

[0046] As a possible implementation, generating a database query statement based on the cached index path and executing the database query includes:

[0047] The token values ​​corresponding to each field in the filter token set are parsed into database query conditions, and multiple database query conditions are combined into a conditional clause using logical AND relation;

[0048] The sorting rules are mapped to sorting clauses, each sorting clause including a sorting field and a sorting direction;

[0049] The range interval is mapped to a restriction clause, the restriction clause including an offset and a restriction number;

[0050] The conditional clause, the sorting clause, and the restriction clause are combined to generate a database query statement, which is then executed.

[0051] And, obtaining the query results and updating the cache includes:

[0052] After a successful database query, the cache index insertion interface is called asynchronously to insert the query result into the node corresponding to the cache index path in the cache index.

[0053] When the insertion interface returns success, the cache update is completed;

[0054] When the insertion interface returns a failure or an exception occurs, log the error and return the query result.

[0055] Unified encapsulation of cache query errors and database query errors, returning a uniformly formatted error response to the caller.

[0056] As one possible implementation, the method further includes configuring a cache update strategy, specifically including:

[0057] The cache update strategy is determined to be at least one of the write-back strategy, write-through strategy, or bypass caching strategy;

[0058] When using a write-back strategy, write to the cache first and delay writing to the database.

[0059] When using a write-through strategy, writes are made to both the cache and the database simultaneously.

[0060] When using a bypass caching strategy, the cache is updated or invalidated after being written to the database.

[0061] Secondly, this application provides a dual-channel access device for a cached database based on unified query parameters, comprising:

[0062] The processing module is used to obtain the original query parameters from the query request;

[0063] The processing module is also used to uniformly parse the original query parameters and construct a unified query parameter structure;

[0064] The unified query parameter structure includes a query condition tree and meta-parameters;

[0065] The processing module is also used to generate a cache index path based on the unified query parameter structure;

[0066] The cache index path includes a set of filter tokens, a sorting rule, and a range.

[0067] The processing module is further configured to access the cache index according to the cache index path, and when the data item set corresponding to the cache index path in the cache index contains a data item, return the cached data;

[0068] The processing module is further configured to generate a database query statement based on the cache index path and execute the database query to obtain the query result when the number of data items in the data item set corresponding to the cache index path in the cache index is empty, and update the cache.

[0069] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.

[0070] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.

[0071] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0072] Based on any of the above embodiments, the method provided in this application first obtains the original query parameters and performs unified parsing. This constructs a unified query parameter structure containing a query condition tree and meta-parameters for query conditions in different input formats. Based on this unified query parameter structure, a cache index path is generated. The cache index path simultaneously includes a set of filter tokens, sorting rules, and range intervals, enabling a unified expression of query conditions between cache queries and database queries, avoiding multiple format conversions and manual concatenation of cache keys. During the data access phase, the cache index is accessed first based on the cache index path. If the corresponding data exists in the cache, it is returned directly; otherwise, a database query statement is automatically generated and executed. After the query is completed, the cache is updated. This achieves cache-first dual-channel access, simplifies the query processing logic, improves the cache hit rate, reduces repeated database accesses, and makes the query transformation and origin retrieval process more unified and efficient. Attached Figure Description

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

[0074] Figure 1 A flowchart illustrating a dual-channel access method for a cached database based on unified query parameters, provided in one embodiment of this application;

[0075] Figure 2A schematic diagram of the overall architecture of a dual-channel access method for a cached database based on unified query parameters provided in one embodiment of this application;

[0076] Figure 3 This is a schematic diagram of operators provided for one embodiment of this application;

[0077] Figure 4 A schematic diagram of the metadata architecture provided for one embodiment of this application;

[0078] Figure 5 This is a schematic diagram of an index path access process provided in one embodiment of this application;

[0079] Figure 6 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0081] First, let's explain several important concepts that may be involved:

[0082] Query_Params_Builder: Query parameter builder that parses HTTP query strings or JSON objects into a unified query parameter tree.

[0083] Query_Params: A unified query parameter tree structure that includes filter conditions, sorting rules, and meta parameters.

[0084] Index_Path: The index path describes the traversal path in the cache index tree, including tokens, sorts, and range.

[0085] Index_Path_Visitor: The index path visitor maps index paths to actual index tree traversal operations.

[0086] Operator encoding: Encodes the query operator information into the token value, in the format "operator_value".

[0087] Meta-parameter query: Control parameters in the parameters, such as offset, limit, sort, etc.

[0088] Dual-channel access: Supports data access via both cache and database channels simultaneously.

[0089] In the field of computer data storage and caching technology, application systems often need to handle both cache queries and database queries simultaneously, but these differ significantly in query languages ​​and parameter formats. Inconsistencies in the formats of Hypertext Transfer Protocol query strings, Object Tags format query parameters, and cache index paths lead to multiple layers of format conversion logic at the application layer, increasing maintenance costs. Most existing query parameter parsers only support simple key-value pairs, lacking the ability to recognize AND / OR logical combinations and operator prefixes, making it difficult to express complex query conditions. Furthermore, the parsed results are disconnected from the cache index structure; cache queries are based on key-value pairs, while database queries are based on Structured Query Language (SCL), making direct reuse impossible. Developers must manually write cache key concatenation and origin-fetching logic. In addition, origin-fetching strategies for cache misses are typically hard-coded into the application code, lacking unified management. This prevents query conditions with different input formats but identical semantics from sharing cache nodes, impacting cache hit rates.

[0090] Specifically, some feasible implementations of the query method may include:

[0091] ORM query builder: The query object is bound to the database SQL, making it difficult to directly map to the cached index.

[0092] HTTP query parameters: The format is simple and lacks the ability to combine complex logic.

[0093] The cache-specific query API has a different parameter format than the business query parameters and requires manual conversion.

[0094] Query parameter parser: The parsed results are disconnected from the cached index structure and require secondary conversion.

[0095] The aforementioned issues complicate the query transformation process, increase development workload, and limit system scalability. Therefore, a dual-channel access method for a cached database based on unified query parameters is needed to simplify the query processing flow and improve data query response performance.

[0096] Therefore, the following limitations exist:

[0097] Inconsistent query parameter formats: HTTP query parameters, ORM query objects, and cached index paths use different formats, requiring format conversion at multiple levels.

[0098] Cache queries and database queries are separated: cache queries are based on key-value pairs, while database queries are based on SQL. The two use different query languages ​​and parameter formats.

[0099] There is a lack of a unified query parameter parsing framework: the parsed results cannot be directly used for cached index queries and need to be manually converted into index paths.

[0100] Limited expressive power of query conditions: HTTP query parameters typically only support simple key-value pairs and lack support for complex logical combinations (AND / OR nesting).

[0101] Dispersed cache origin retrieval logic: The origin retrieval logic when the cache misses is usually hard-coded in the application, lacking a unified origin retrieval strategy management.

[0102] In summary, the technical concept of this application lies in the method provided. First, by obtaining the original query parameters from the query request and uniformly parsing them, query conditions from different input formats are constructed into a unified query parameter structure containing a query condition tree and meta-parameters. This eliminates the need for the application layer to write separate parsing logic for different formats, simplifying the query processing flow. Based on the unified parsing, a cache index path is generated according to the unified query parameter structure. The cache index path simultaneously contains a set of filter tokens, sorting rules, and range intervals. The filter conditions are encoded by concatenating operator identifiers with parameter values ​​to form a set of filter tokens. The sorting rules and range intervals are extracted from the meta-parameters and mapped to index path components. Thus, the three levels of query condition filtering, sorting, and range limitation are completely expressed as path information that can be directly used for cache index positioning, eliminating the need for manual key-value concatenation or additional back-to-source logic for the conversion between cache queries and database queries. During the data access phase, the cache index is first accessed based on the cache index path. The cache index path accessor locates the corresponding node in the cache index tree through field arrangement and layer-by-layer traversal. When the corresponding data item set in the cache index contains the data item, the cached data is directly returned, thereby leveraging the high responsiveness of the cache to reduce query latency. When the number of data items is zero, the filter token set, sorting rules, and range intervals are automatically converted into conditional clauses, sorting clauses, and restriction clauses in the database query statement, respectively. After combination, the database query is executed, and the query results are asynchronously updated to the cache index after a successful query. This allows subsequent queries with the same conditions to directly hit the cache, reducing the pressure of repeated database accesses and achieving cache-first dual-channel data access. Thus, this application, through the layered cooperation of unified query parameter parsing, cache index path generation, and dual-channel access, enables seamless conversion of query conditions between the cache and the database, simplifies query processing logic, improves cache hit rate and query efficiency, and reduces the development and maintenance costs of application systems in query conversion and cache-to-origin return.

[0103] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.

[0104] Figure 1 This is a flowchart illustrating a dual-channel access method for a cached database based on unified query parameters, provided in one embodiment of this application. Figure 1As shown, this application provides a dual-channel access method for a cached database based on unified query parameters, the method comprising:

[0105] S101. Obtain the original query parameters from the query request;

[0106] S102. Perform unified parsing on the original query parameters to construct a unified query parameter structure;

[0107] The unified query parameter structure includes a query condition tree and meta-parameters;

[0108] S103. Generate a cache index path based on the unified query parameter structure;

[0109] The cache index path includes a set of filter tokens, a sorting rule, and a range.

[0110] S104. Access the cache index according to the cache index path. When the data item set corresponding to the cache index path in the cache index contains a data item, return the cached data.

[0111] S105. When the number of data items in the data item set corresponding to the cache index path in the cache index is empty, generate a database query statement according to the cache index path and execute the database query to obtain the query result, and update the cache.

[0112] like Figure 2 As shown, Figure 2 This is a schematic diagram of the overall architecture of a dual-channel access method for a cached database based on unified query parameters provided in one embodiment of this application. The entire architecture is divided into six levels from front-end client request to back-end data retrieval, arranged from top to bottom according to the processing flow:

[0113] The first layer is the client request layer, which receives query requests sent by the client and supports two types of raw query parameter input: Hypertext Transfer Protocol query string and object tag format.

[0114] The second layer is the query parameter builder, which is responsible for parsing, format conversion and meta-parameter extraction operations on the raw query parameters output by the client request layer, and converting raw query parameters of different formats into a structured query parameter structure.

[0115] The third layer is the query parameter structure. This layer stores the query parameter tree obtained after parsing and transformation. The query parameter tree contains three parts: logical combination nodes, key-value query parameter nodes, and meta-parameters, realizing the integrated storage of query conditions and meta-parameters.

[0116] The fourth layer is the transformation layer, which is responsible for converting the structured query parameter structure into a cache index path and automatically mapping the filter conditions, sorting rules and ranges in the query parameter tree to the components corresponding to the cache index path.

[0117] The fifth layer is the cache index layer, which provides a cache index access interface and supports data lookup, data insertion, and data erasure operations. This layer locates the target node based on the transformed cache index path.

[0118] The sixth layer is the data acquisition layer, which employs a dual-channel data acquisition mechanism. It prioritizes acquiring data through the cache channel. If the target data is not found in the cache, it automatically switches to the database channel for querying, ultimately outputting the acquired data. The entire architecture achieves fully automated processing from inputting raw query parameters to accessing the cached index and then retrieving data from the database.

[0119] The method provided in this embodiment first obtains the original query parameters and performs unified parsing on them. This unifies query conditions from different input sources into a unified query parameter structure containing a query condition tree and meta-parameters, eliminating the need for the application layer to write separate parsing logic for different formats, thus simplifying the query processing flow. After obtaining the unified query parameter structure, a cache index path is generated based on this structure. The cache index path simultaneously contains a set of filter tokens, sorting rules, and range intervals, thereby expressing the query conditions as path information that can be directly used for cache index location. This eliminates the need for manual key-value pairing or additional back-to-source logic for the conversion between cache queries and database queries. During the data access phase, the cache index is accessed first based on the cache index path. When the corresponding data item set in the cache index contains the data item, the cached data is directly returned, leveraging the high responsiveness of the cache to reduce query latency. When the number of data items is zero, a database query statement is automatically generated based on the cache index path and executed. After obtaining the query results, the cache is updated, ensuring that subsequent identical query conditions can directly hit the cache, reducing the pressure of repeated database accesses and achieving cache-first dual-channel data access.

[0120] As a feasible implementation method, the step of uniformly parsing the original query parameters and constructing a unified query parameter structure includes:

[0121] Identify the input format of the original query parameters;

[0122] When the input format is a Hypertext Transfer Protocol query string, the key-value pairs are parsed by the delimiter and nested logical combination tags are identified. When the input format is an object tag format, the object attributes are traversed and the corresponding parameter values ​​are parsed.

[0123] The registry is used to check whether the current parameter name is a meta parameter based on the meta parameter key name.

[0124] The registry predefines the mapping relationship between parameter names and meta-parameter types for the meta-parameter key names.

[0125] If the current parameter name is a meta parameter, the parameter value is stored in the meta parameter area of ​​the unified query parameter structure according to the registration type;

[0126] The meta-parameter region includes sorting rules, range intervals, and a set of original transparent parameters;

[0127] If the current parameter name is not a meta parameter, the parameter value corresponding to the current parameter name will be parsed as a normal query parameter and converted into a query condition tree node.

[0128] In this implementation, the input format of the original query parameters is first identified during the unified parsing process. Corresponding key-value pair parsing and attribute traversal methods are used for Hypertext Transfer Protocol query strings and object tag formats, respectively. This ensures that different forms of query input can be converted into key-value data in the unified parsing process, reducing parsing branches caused by differences in input format. Based on the parsing, the current parameter name is checked through the meta-parameter key name registry. Parameter values ​​belonging to meta-parameters are stored in the meta-parameter area of ​​the unified query parameter structure, while parameter values ​​not belonging to meta-parameters are parsed as ordinary query parameters into query condition tree nodes. This achieves separate processing of meta-parameters and ordinary query parameters, preventing meta-parameters from being mistakenly used as filtering conditions in the query condition tree. This ensures clear logical boundaries between filtering conditions, sorting rules, range intervals, and the original parameter set during subsequent cache index path generation, making the index path generation process more accurate and reliable.

[0129] As a feasible implementation method, the ordinary query parameters are parsed into a query condition tree through operator prefix identification and / or logical combination, specifically including:

[0130] Scan field names and identify the operator types corresponding to the field name prefixes;

[0131] The operator types include equal operator, not equal operator, greater than operator, less than operator, fuzzy matching operator, and non-matching operator;

[0132] Based on the identified operator type, extract the field name after removing the prefix and the corresponding parameter value, and construct the field name, the operator type and the parameter value into a key-value query parameter node, which serves as the leaf node of the query condition tree;

[0133] Detect logical combination markers in the original query parameters. When an AND logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the AND logical node; when an OR logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the OR logical node.

[0134] Recursively form a multi-level query condition tree;

[0135] Wherein, the leaf nodes are key-value query parameter nodes, and the non-leaf nodes are AND logical nodes and OR logical nodes;

[0136] Furthermore, the meta-parameters include range parameters, sorting parameters, or pass-through parameters as is. The step of storing parameter values ​​into the meta-parameter area of ​​the unified query parameter structure according to the registration type includes:

[0137] When the registration type is sorting type, parse the sorting field and ascending / descending order, and store the parsing result in the sorting rule;

[0138] When the registration type is a range type, the range interval is constructed and stored based on the offset and the number of limits, or based on the page number and the number per page.

[0139] When the registration type is the original transparent transmission type, the parameter name and parameter value are stored in the original transparent transmission parameter set.

[0140] In this implementation, the parsing of ordinary query parameters determines the operator type during the field name scanning stage by identifying the operator prefix. Then, the field name (with prefix removed), operator type, and parameter value are combined to construct a key-value query parameter node. This ensures that each filtering condition carries complete operational semantics when entering the query condition tree, preventing the loss of operator information during subsequent conversions. Based on this, by detecting AND and OR logical tags, multiple key-value query parameter nodes or sub-logical nodes are constructed into AND and OR logical node child nodes according to their logical relationships, thus recursively forming a multi-level query condition tree, enabling the structured expression of complex logical combinations. Simultaneously, meta-parameters are stored according to registration type in sorting rules, range intervals, and the set of parameters passed in as is. This ensures that sorting fields and ascending / descending order directions, offsets and limit quantities or page numbers and number of parameters per page, as well as parameters requiring pass-in as is, are all categorized into their corresponding meta-parameter areas, providing a directly usable data source for the sorting rules and range intervals in the subsequent generation of the cache index path.

[0141] As a feasible implementation method, generating the cache index path based on the unified query parameter structure includes:

[0142] Traverse the key-value query parameter nodes in the query condition tree, connect the operator identifier of each key-value query parameter node with the parameter value using a preset separator to form a token value, use the field name as the key and the token value as the value to generate the filter token set;

[0143] Extract sorting rules from the meta parameters and generate index path components corresponding to the sorting rules;

[0144] Extract the range interval from the meta parameters and generate the index path component corresponding to the range interval;

[0145] Furthermore, before generating the set of filter tokens, the data type corresponding to the field is determined according to a preset scenario mechanism. When the field value needs to be converted, the parameter value is converted according to the data type corresponding to the field, and the converted parameter value is used as the parameter value part in the token value.

[0146] The data types mentioned include string type, numeric type and boolean type.

[0147] In this implementation, when generating the cache index path, the key-value query parameter nodes in the query condition tree are traversed. Each node's operator identifier and parameter value are connected using a preset separator to form a token value. A set of filter tokens is then generated, with field names as keys and token values ​​as values. This transforms the structured filtering conditions in the query condition tree into a flattened key-value mapping in the cache index path, preserving operator semantics while facilitating subsequent index matching. Before generating the filter token set, field values ​​are type-converted according to a preset scenario mechanism to ensure consistency in parameter values ​​of different data types before token encoding, reducing matching deviations caused by type differences in the cache index. Simultaneously, sorting rules and range intervals are extracted from the meta-parameters and corresponding index path components are generated. This ensures that sorting and range limitations are incorporated into the cache index path along with the filtering conditions, guaranteeing that the cache index path fully expresses the filtering, sorting, and range limitations of the query conditions. This allows cache index access and database query generation to directly reuse the path information, reducing redundant processing in the conversion stage.

[0148] As one possible implementation, accessing the cache index according to the cache index path includes:

[0149] Create a cached index path accessor, which initializes the unorchestrated token pool, the orchestrated token pool, the unorchestrated sorted pool, and the orchestrated sorted pool according to the filter token set and sorting rules;

[0150] Receive field orchestration instructions and move the specified field from the unorchestrated token pool or the unorchestrated sorting pool into the corresponding orchestrated set;

[0151] Following the hierarchical order of the cache index tree, the cache index nodes are accessed layer by layer according to the fields in the orchestrated set;

[0152] The cache index tree includes a first layer, an anonymous layer, and a leaf layer. In the first layer, the corresponding branch under the root node is accessed according to the orchestrated fields. In the anonymous layer, the fields in the unorchestrated token pool are accessed sequentially. In the leaf layer, the data set corresponding to the leaf node is accessed.

[0153] When a leaf node is reached, it is determined whether the orchestrated token pool, the unorchestrated token pool, and the unorchestrated sort pool are all empty. If all sets are empty, the index path traversal is considered complete.

[0154] Sort the data set corresponding to the leaf node according to the sorting field in the sorting pool, and truncate the data set corresponding to the leaf node according to the range interval to obtain the matching data record;

[0155] The starting value of the range interval is included, but the ending value is not included. When the ending value is a preset null value, all data from the starting value to the end of the data set is extracted.

[0156] This implementation creates a cached index path accessor and initializes four orchestration sets based on the filter token set and sorting rules. This ensures that the filter and sorting fields to be accessed are respectively assigned to the un-orchestrated and orchestrated regions before traversal begins, providing an ordered foundation for subsequent field-based orchestration instructions to move specified fields from the pending region to the processed region. During traversal, the index nodes are accessed layer by layer using the fields in the orchestrated set, following the hierarchical order of the cached index tree's first level, anonymous level, and leaf level. The corresponding data sets are accessed at the leaf level, making the access paths for filter and sorting fields in the index tree clear and improving the accuracy of index location. When a leaf node is reached, the traversal process ends by checking that the orchestrated token pool, un-orchestrated token pool, and un-orchestrated sorting pool are all empty, ensuring that all fields in the index path have been accessed. Finally, the dataset is sorted according to the sorting field in the sorting pool, and matching data records are obtained by truncation according to the range interval with the starting value included and the ending value excluded. This ensures that the returned data records have both a clear order and an accurate limit on the number of data records, thus meeting the sorting and pagination requirements in the query conditions.

[0157] As a possible implementation, generating a database query statement based on the cached index path and executing the database query includes:

[0158] The token values ​​corresponding to each field in the filter token set are parsed into database query conditions, and multiple database query conditions are combined into a conditional clause using logical AND relation;

[0159] The sorting rules are mapped to sorting clauses, each sorting clause including a sorting field and a sorting direction;

[0160] The range interval is mapped to a restriction clause, the restriction clause including an offset and a restriction number;

[0161] The conditional clause, the sorting clause, and the restriction clause are combined to generate a database query statement, which is then executed.

[0162] And, obtaining the query results and updating the cache includes:

[0163] After a successful database query, the cache index insertion interface is called asynchronously to insert the query result into the node corresponding to the cache index path in the cache index.

[0164] When the insertion interface returns success, the cache update is completed;

[0165] When the insertion interface returns a failure or an exception occurs, log the error and return the query result.

[0166] Unified encapsulation of cache query errors and database query errors, returning a uniformly formatted error response to the caller.

[0167] This implementation automatically converts cached index paths into database query statements when a cached index misses. This is achieved by parsing the token values ​​in the filter token set into database query conditions, merging them into conditional clauses using logical AND relationships, mapping sorting rules to sorting clauses, and mapping range intervals to restriction clauses. These three clauses are then combined to generate a complete database query statement. This eliminates the need for manual concatenation of database query statements based on query conditions, improving the efficiency of origin server queries. Upon successful database query, the query results are written to the corresponding path node in the cached index via an asynchronous call to the cached index insertion interface. This ensures that subsequent queries with the same conditions can directly hit the cache, reducing repeated origin server queries. When the insertion interface fails or an exception occurs, an error log is recorded, and the query results are returned, preventing cache update failures from affecting normal data return. Furthermore, cache query errors and database query errors are uniformly encapsulated and returned to the caller in a unified format, eliminating the need for the caller to adapt error handling logic for two different channels, simplifying the caller's access method.

[0168] As one possible implementation, the method further includes configuring a cache update strategy, specifically including:

[0169] The cache update strategy is determined to be at least one of the write-back strategy, write-through strategy, or bypass caching strategy;

[0170] When using a write-back strategy, write to the cache first and delay writing to the database.

[0171] When using a write-through strategy, writes are made to both the cache and the database simultaneously.

[0172] When using a bypass caching strategy, the cache is updated or invalidated after being written to the database.

[0173] This implementation, based on dual-channel access to the cache database, allows for flexible write paths by configuring at least one of a write-back strategy, a write-through strategy, or a bypass caching strategy. This enables the synchronization method between the cache and database to be selected according to the actual scenario, providing flexibility for different consistency and performance requirements. When using a write-back strategy, the data is written to the cache first and then delayed to the database, improving the timeliness of write responses. When using a write-through strategy, the data is written to both the cache and the database simultaneously, ensuring data consistency between the two. When using a bypass caching strategy, the data is written to the database first, then the cache is updated or invalidated, separating the cache update logic from the database write logic, facilitating independent control over cache invalidation and update timing. Thus, the configuration of the cache update strategy, in conjunction with the dual-channel access mechanism on the query end, enables coordinated management between the cache and the database in both read and write directions.

[0174] The following examples illustrate this application based on specific application scenarios:

[0175] Figure 3 This is a schematic diagram of operators provided in one embodiment of this application. The system supports... Figure 3 The operator prefix shown.

[0176] First, the operator is identified by scanning the field name prefixes, extracting the field name and operator type, and constructing the corresponding KV_Query_Param node. Then, nested logic is parsed, supporting AND / OR nested logic combinations, for example:

[0177] Input format:

[0178] AND=(name=John, GT_age=18, NE_status=deleted)

[0179] Analysis results:

[0180] Logical_Query_Param {

[0181] op: AND,

[0182] children: [

[0183] KV_Query_Param {field: "name", op: EQ, value: "John"},

[0184] KV_Query_Param {field: "age", op: GT, value: 18},

[0185] KV_Query_Param {field: "status", op: NE, value: "deleted"} ]

[0187] }

[0188] Separation of meta parameters from regular query parameters:

[0189] Regular query parameters refer to query conditions used to filter data records, such as name=John (name equals John), GT_age=18 (age greater than 18), and NE_status=deleted (status not equal to deleted). These parameters collectively define "what kind of data to query," which will ultimately be converted into the filtering conditions (tokens_) of the cached index.

[0190] Meta-parameters are parameters that control how query results are returned, including pagination parameters (offset, limit, page, page_size), sorting parameters (sort, order), and pass-through parameters (such as query_id, lang, etc.). These parameters do not participate in data filtering, but rather control how the data is presented.

[0191] The purpose of this separation is to ensure that the two types of parameters follow completely different paths in subsequent processing. Regular query parameters are parsed into a query condition tree (Logical_Query_Param) and ultimately encoded into tokens (filtering conditions) in the index path, while meta-parameters are mapped to other components of the index path: sort maps to sorting rules (sorts_), offset / limit maps to range intervals (range_), and parameters passed in as is map to raw_entries_. Without this prior separation, meta-parameters would be incorrectly treated as regular filtering conditions, causing cached index queries to fail.

[0192] Figure 4 This is a schematic diagram of the metadata architecture provided in one embodiment of this application. Regarding the internal structure of Meta_Params, although there is no independent Meta_Params class in the code, the "meta-parameters" conceptually correspond to the three fields shown in the diagram in the Query_Params object.

[0193] On the one hand, ordinary query parameters are parsed into a query condition tree (AND / OR logical nodes + key-value pair nodes), which is stored in the children_ list inherited from Logical_Query_Param.

[0194] For meta-parameters, including parameters passed through as is, such as {"query_id": "abc123", "lang": "zh"}, the type is map.<string, Value> It does not participate in filtering and is passed through to the result processor.

[0195] It also includes sorting rules, such as [{"name": "age", "desc": false}], of type vector. <sort>Each Sort contains a field name and an ascending / descending order flag.

[0196] It also includes range intervals, for example, {"beg": 0, "end": 20} means taking the 0th to 19th, with the type struct { int64 beg; int64 end;}, and end = -1 means there is no upper limit.

[0197] The extraction process includes:

[0198] Use Query_Meta_Keys (meta parameter key name registry) to check if the current parameter name is a meta parameter;

[0199] If it is a meta parameter, store it in sorts_, range_, or raw_entries_ according to its registration type (SORT / ORDER / LIMIT / OFFSET / RAW / IGN);

[0200] If it is not a meta parameter (i.e., a regular query parameter), it is handed over to the query condition parser parse_entry_t() to construct a query condition tree node;

[0201] Finally, Query_Params carries the filter condition tree, sorting rules, range intervals, and pass-through parameters, which are then converted into a complete Index_Path.

[0202] How Query_Meta_Keys works: It's a mapping table of key names to types, pre-defining which parameter names belong to meta parameters through a registration mechanism. For example, after registering {"limit", LIMIT}, when the input parameter contains limit=20, the system recognizes it as type LIMIT and stores its value in range_.end. If the parameter name is not in the registry (get_type returns NONE), it is treated as a normal query parameter.

[0203] Specifically, the unified parsing of query parameters is the first step in the processing flow of this application, and the specific execution logic is as follows:

[0204] First, identify the input format of the original query parameters: if the input is a Hypertext Transfer Protocol query string, then parse it according to the delimiter to obtain key-value pairs, and identify the nested logical combination tags; if the input is an object tag format, then directly traverse all the attributes of the object and parse the parameter value corresponding to each attribute.

[0205] Secondly, operator prefix recognition is performed on all the parsed parameters in sequence: the field name of each parameter is scanned one by one to identify the operator type corresponding to the field name prefix. This application supports six types of operators by default: equal to operator, not equal to operator, greater than operator, less than operator, fuzzy matching operator, and non-matching operator. After recognition, the actual field name and parameter value after removing the prefix are extracted, and the actual field name, operator type, and parameter value are combined to construct a key-value query parameter node. This node is retained as the leaf node of the subsequent query condition tree.

[0206] Next, logical combination identification is performed to construct a multi-level query condition tree: logical combination markers carried in the original query parameters are detected. If an AND logical marker is detected, multiple key-value query parameter nodes or the constructed child logical nodes are stored as child nodes of the AND logical node; if an OR logical marker is detected, multiple nodes are stored as child nodes of the OR logical node; nested logical combination markers are recursively identified to finally form a multi-level query condition tree, where all leaf nodes are key-value query parameter nodes and all non-leaf nodes are AND or OR logical nodes, realizing a structured expression of nested logic of arbitrary complexity.

[0207] Finally, perform the meta-parameter separation operation: check whether the current parameter name belongs to a meta-parameter by checking the predefined meta-parameter key name registry. The meta-parameter key name registry pre-stores the mapping relationship between parameter names and meta-parameter types, and supports developers to customize and register new meta-parameters. If the current parameter is a meta-parameter, the parameter value is stored in the corresponding meta-parameter area of ​​the query parameter structure according to the registered meta-parameter type. If the current parameter does not belong to a meta-parameter, it is added to the query condition tree as a normal query parameter.

[0208] This application divides the meta-parameters into three categories, each corresponding to a different storage logic: The first category is sorting parameters, which are stored in the sorting rule area and, after parsing, save the sorting field and ascending / descending order; the second category is pagination parameters, which are stored in the range interval area and, based on the input offset and limit number, or page number and number per page, construct a half-open, half-closed range interval; the third category is pass-through parameters, which are stored in the pass-through parameter set as is, with the parameter name and parameter value stored as is, not participating in subsequent filtering and index generation, and directly pass-through to the result processing module for use.

[0209] Operator encoding mechanism:

[0210] The system uses operator prefix encoding to completely preserve query operator information in the token value:

[0211] Encoding format: tokens_[field_name] = op_to_name(op) + '_' + value

[0212] Encoding example:

[0213] name=John→tokens_["name"] = "EQ_John"

[0214] NE_status=deleted→tokens_["status"] = "NE_deleted"

[0215] GT_age=18→tokens_["age"] = "GT_18"

[0216] Coding advantages:

[0217] Operator information is fully preserved, allowing the index layer to perform precise query matching;

[0218] All query conditions are converted to a uniform format;

[0219] Easy to parse and match.

[0220] Conversion process:

[0221] Step 1: Extract tokens:

[0222] Iterate through all KV_Query_Params;

[0223] Apply operator encoding: get_value_id() = op_to_name(op) + '_' + value;

[0224] Step 2: Extract sorts:

[0225] Parse the sorting field and direction from the meta parameters;

[0226] The prefix "-" indicates descending order (true), and no prefix indicates ascending order (false).

[0227] Step 3: Extract the range:

[0228] Construct a half-open interval [beg, end] from offset / limit or page / page_size.

[0229] In general, after completing the unified parsing of query parameters and obtaining a structured query parameter structure, the conversion from the query parameter structure to the cached index path is performed. The specific process is as follows: First, generate a filter token set: Traverse the key-value query parameter nodes of all leaf nodes in the query condition tree, concatenate the operator identifier and parameter value of each node using a preset separator to form a token value; then, using the actual field name after removing the prefix as the key, concatenate the resulting token value and store it in the filter token set. This encoding method can completely preserve the semantics of the operators in each query condition, ensuring that the operation requirements of the original query conditions can be fully restored during subsequent index matching and database query transformation.

[0230] The second step is to generate sorting rule components: extract the parsed sorting type parameters from the meta-parameter area of ​​the query parameter structure, and directly generate sorting rule components from the parsed sorting fields and ascending / descending order directions, which are then retained as part of the cache index path.

[0231] The third step is to generate range interval components: extract the constructed half-open and half-closed range intervals from the meta-parameter area of ​​the query parameter structure, and directly generate range interval components, which are retained as part of the cache index path.

[0232] Before generating the set of filter tokens, this application will also perform field type conversion processing through a preset scenario mechanism: based on the current scenario definition, determine the target data type required by the current field. If the type of the parameter value obtained from the original parsing does not match the target type, then perform automatic type conversion. The converted parameter value is then used to concatenate and generate the token value, so as to avoid the failure of cache index matching due to type differences under different input formats.

[0233] Figure 5 This is a schematic diagram of an index path access process provided in one embodiment of this application. For index path access (visitor pattern), Index_Path_Visitor implements the visitor design pattern. Its role is to map a pre-constructed Index_Path to the actual cached index tree, driving the index tree to perform traversal operations and extract matching data. If the cached index tree is likened to a multi-level file directory system, Index_Path is the file path, and Index_Path_Visitor is the "traverser" that searches for files layer by layer along the path.

[0234] Workflow: The entire process consists of 4 steps, which will be explained one by one below.

[0235] Step 1: Create Visitors (Initialize Orchestration Plan):

[0236] The constructor of Index_Path_Visitor takes an Index_Path object as an argument. Index_Path contains the following three parts:

[0237] tokens (token set): A set of key-value pairs encoded from ordinary query parameters, such as {"name": "EQ_John", "age": "GT_18"}, where each token represents a filtering condition.

[0238] `sorts_` (sorting rules): This is parsed from the `sort` parameter. For example, `[{"name": "age", "desc": false}]` means sorting by age in ascending order.

[0239] `range_` (range range): This is parsed from the `offset` / `limit` parameters. For example, `{"beg": 0, "end": 20}` means retrieving items 0 to 19.

[0240] During initialization, the visitor creates four sets of "orchestration plans":

[0241] anon_plan_ (Unorchestrated Token Pool): Initially contains all field names from tokens_, i.e., all filter fields whose access order has not yet been scheduled.

[0242] anon_sort_plan_ (Unsorted Sort Pool): Initially contains all field names from sorts_, i.e., all sorting fields whose access order has not yet been assigned.

[0243] plan_ (Orchestrated Token Pool): Initially empty, fields will be moved from anon_plan_ to plan_ through orchestration.

[0244] sort_plan_ (Organized sort pool): Initially empty, fields are subsequently moved in from anon_sort_plan_ through orchestration.

[0245] To give an example: This is equivalent to putting all the items on a to-do list in the "to be organized" area, waiting for them to be categorized and put into the "already arranged" area later.

[0246] Step 2: Field Arrangement (Specify Access Order by Name):

[0247] A cached index tree typically contains a multi-level structure: HEAD level (root node), ANON level (anonymous node), and LEAF level (leaf node). Each level handles different fields. When designing the index tree structure, the system assigns fields with different naming conventions to different levels.

[0248] HEAD layer: Stores primary keys or partition identifiers, such as user IDs, table names, etc.

[0249] ANON layer: Stores general filtering fields, i.e., fields that the system does not require to be pre-named and can be dynamically expanded.

[0250] LEAF layer: Stores actual data or data pointers

[0251] The `arrange()` method is the core of field arrangement. It takes a field name (e.g., "name") and performs the following operations:

[0252] Check if the field name exists in anon_plan_ (unorchestrated token pool).

[0253] If it exists, remove it from anon_plan_ and add it to plan_ (the orchestrated token pool).

[0254] If not in anon_plan_, then check if it is in anon_sort_plan_ (unsorted sort pool).

[0255] If it is in the sort pool, move it to sort_plan_ (the sorted sort pool).

[0256] The significance of this step is that external entities (such as the index tree builder) can determine which fields are handled by the HEAD layer, which by the ANON layer, and which are used as sorting fields based on the responsibilities of each node. Through orchestration, visitors know that "when traversing the HEAD layer, the field named 'name' should be accessed, and when traversing the LEAF layer, the range of the 'age' field should be checked."

[0257] Step 3: Index tree traversal (recursively accessing nodes at each level):

[0258] The traversal process uses a recursive approach, visiting each level of the index tree in the order of HEAD → ANON → LEAF. Two access methods are used here:

[0259] `visit(field_name)`: Used to access an orchestrated field. When called, it retrieves the token value corresponding to the field from `plan_` (e.g., retrieves "EQ_John" corresponding to "name" from the token set), and then removes the field from `plan_` (indicating "visited"). This applies to named nodes in the index tree that have explicit field names.

[0260] `visit_anon(flag)`: Used to access unsorted fields. This method retrieves the remaining fields from `anon_plan_` or `anon_sort_plan_` in a first-in, first-out order, returning a string in the format "field name=value". It supports a "preview" flag (FG_DRY): when this flag is set, only the next field to be accessed is viewed without consuming it. This is suitable for anonymous node layers in the index tree that do not require pre-naming and can be dynamically expanded.

[0261] During the traversal, the visitor maintains a pointer to the current tree node. Each time a level is visited, the pointer is moved down one level until a leaf node is reached.

[0262] Step 4: Data Extraction (Truncation of Results Based on Range):

[0263] Once the traversal reaches a leaf node, the visitor uses the following two methods to determine whether the traversal is complete:

[0264] done(): Returns true if plan_ (the orchestrated token pool) is empty and anon_done() returns true, indicating that all fields have been accessed.

[0265] anon_done(): Returns true when both anon_plan_ and anon_sort_plan_ are empty, indicating that all unsorted fields have been visited.

[0266] At the same time, the result is truncated by applying `range_` (range interval) to the leaf nodes. For example, when `range_` is `{"beg": 0, "end": 20}`, only records from 0 to 19 are retrieved. This step corresponds to the LIMIT / OFFSET semantics in database queries.

[0267] Specifically, the cache index of this application adopts a three-level tree structure design, with the following hierarchical division and responsibilities: The first level is the header, used to store the primary key or partition identifier; the second level is the anonymous level, used to store dynamically expanded filter fields; and the third level is the leaf level, used to store the actual data or pointers to the actual data. The traversal of the cache index path is driven by the visitor approach, and the specific process is as follows: First, initialize the orchestration pool: Create a cache index path visitor. The visitor initializes four sets respectively: un-orchestrated token pool, orchestrated token pool, un-orchestrated sorting pool, and orchestrated sorting pool, according to the generated filter token set and sorting rules. All filter fields are stored in the un-orchestrated token pool, and all sorting fields are stored in the un-orchestrated sorting pool.

[0268] The second step is to perform field orchestration: receive predefined field orchestration instructions, move the specified fields from the corresponding unorchestrated set to the corresponding orchestrated set, and determine the order of fields to be traversed at the current index tree level.

[0269] The third step is to traverse the cached index nodes in a hierarchical order: following the fixed order of the first layer, the anonymous layer, and the leaf layer, the cached index nodes are accessed layer by layer. In the first layer, the corresponding branch under the root node is accessed based on the orchestrated primary key or partition identifier. In the anonymous layer, all dynamic filtering fields in the unorchestrated token pool are traversed in turn, and the corresponding index nodes are entered in turn. Finally, in the leaf layer, the data set stored in the corresponding leaf node is accessed.

[0270] The fourth step is to perform data truncation: When a leaf node is accessed and the orchestrated token pool, unorchestrated token pool, and unorchestrated sort pool are all empty, the index path traversal is considered complete. First, the data set stored in the leaf node is sorted according to the sorting field in the orchestrated sort pool. After sorting, matching data records are truncated according to the predefined half-open and half-closed range. The starting value of the range is included, but the ending value is not included. If the ending value is a preset null value, all data from the starting value to the end of the data set is truncated.

[0271] Dual-channel data acquisition mechanism:

[0272] First channel: Cache query:

[0273] Call Index.find(path, meta, items);

[0274] If the cache is hit and items are not empty, return immediately.

[0275] Cache miss → Enter the second channel.

[0276] Second channel: Database query:

[0277] Convert Index_Path into a database query (tokens → WHERE, sorts → ORDER BY, range → LIMIT / OFFSET);

[0278] Execute a database query;

[0279] Asynchronous cache update: Index.insert(items).

[0280] This application adopts a cache-first dual-channel data acquisition mechanism, and the specific execution logic is as follows: First, perform a cache query: based on the converted cache index path, access the corresponding node in the cache index. If the cache is hit, that is, the corresponding data set contains at least one data item, then directly return the data in the cache to complete the query process.

[0281] The second step is to trigger a database origin query: If the cache miss occurs, meaning the number of data items in the corresponding data set is zero, the cache index path is automatically converted into a query statement that conforms to database specifications. Each token in the filter token set is parsed into a corresponding database query condition, and multiple query conditions are combined using logical AND relations to generate a condition clause. The sorting rules in the cache index path are mapped to the sorting clause of the database query. The range in the cache index path is mapped to the restriction clause of the database query. The condition clause, sorting clause, and restriction clause are combined to obtain a complete database query statement, which is then executed to obtain the result data.

[0282] The third step is to update the cache and return the results: After a successful database query, the cache index insertion interface is called asynchronously to insert the query result data into the node corresponding to the cache index path in the cache index, thus completing the cache update. If the cache insertion operation fails or an exception occurs, only the corresponding error log is recorded, and the database query result data is still returned normally. The normal return of the query result will not be affected by the cache update failure. Errors generated during the cache query stage and errors generated during the database query stage are uniformly encapsulated and processed, and finally a uniform format error response is returned to the caller. The caller does not need to adapt the error handling logic of the cache channel and the database channel separately.

[0283] Regarding cache update strategies, the system supports multiple cache update strategies:

[0284] Write-back: Data is first written to the cache and then delayed in being written to the database. This method offers high performance but carries the risk of inconsistency issues.

[0285] Write-through: Writes to both the cache and the database simultaneously, offering good consistency but higher latency;

[0286] Cache-Aside: Reads are first checked in the cache, and writes are first written to the database, providing flexibility and control.

[0287] This application supports three configurable cache update strategies. Developers can choose the appropriate strategy based on the data consistency and write performance requirements of their business scenarios: The first is the write-back strategy: When writing data, the data is first written to the cache, and then the data is written to the database with a delay. The advantage of this strategy is its fast write response speed, suitable for scenarios with high concurrent write volume and relatively low data consistency requirements. The second is the write-through strategy: When writing data, the data is written to both the cache and the database simultaneously. The write is considered complete only when both the cache and the database are successfully written. The advantage of this strategy is that the data in the cache and the database are always consistent, suitable for scenarios with high data consistency requirements. The third is the bypass caching strategy: When writing data, the data is first written to the database. After the database write is successful, the corresponding data in the cache is updated or invalidated. The advantage of this strategy is that the write logic and the cache update logic are separated, suitable for scenarios with batch data writes.

[0288] The key points of this application are:

[0289] Key Point 1: Unified Query Parameter Parsing Architecture

[0290] It supports multiple input formats, including Hypertext Transfer Protocol query strings and object tag formats;

[0291] Automatically identify the type of operator carried in the field name prefix. For example, if the field name prefix carries the not equal to operator, it will be identified as an not equal to query.

[0292] Supports nested combinations with logical AND and OR logic;

[0293] Built-in meta-parameter processing, including pagination and sorting.

[0294] Key Point Two: Transparent Conversion of Query Parameters to Index Paths

[0295] The query parameter structure can be converted into a cache index path;

[0296] Supports mapping complex query condition trees to flat key-value pairs;

[0297] Automatically handle field type conversions through a scenario mechanism;

[0298] Meta-parameters are automatically extracted and mapped to the index path component.

[0299] Key Point 3: Unified Access Interface for Cached Indexes

[0300] The cache index interface provides a unified operation interface for data lookup, data insertion, and data erasure;

[0301] Supports node location via cached index path;

[0302] The built-in visitor method separates path traversal from node access;

[0303] Automatically handle range queries that cross leaf nodes.

[0304] Key Point Four: Dual-Channel Data Acquisition Mechanism

[0305] When a cache hit occurs, data is returned directly from the cache index interface;

[0306] When the number of cached data items is zero, a database query is automatically triggered and the cache is updated.

[0307] Provides unified error handling and result encapsulation.

[0308] Key Point 5: Scalable Meta-parameter Management

[0309] Meta parameter key names: The registry supports custom meta parameter names;

[0310] Supports both case-sensitive mode and case-neutral mode;

[0311] Meta parameters are automatically separated from query conditions.

[0312] In this application, some specific implementation methods can be replaced, for example:

[0313] Query parameter parsing:

[0314] Alternative Solution 1: Syntax-based parsing:

[0315] It supports expressions (age > 18 AND status != 'deleted'), function calls, and range queries;

[0316] Advantages: Stronger expressive power; Risks: Increased parsing complexity.

[0317] Alternative Solution 2: Configuration-based parsing:

[0318] Define query parameter rules through configuration files;

[0319] Advantages: Flexible configuration; Risks: Increased configuration complexity.

[0320] Cache origin pull strategy:

[0321] Alternative Solution 1: Prefetching Strategy

[0322] Based on access pattern prediction, timed full prefetching, and incremental prefetching;

[0323] Advantages: Improved hit rate; Risks: Potential for prefetching useless data.

[0324] Alternative Solution 2: Tiered caching

[0325] L1 cache (memory) → L2 cache (local disk) → database;

[0326] Advantages: Reduced database access; Risks: Increased system complexity.

[0327] Meta-parameter management:

[0328] Alternative Solution 1: Expandable Meta-parameters:

[0329] Supports user-defined meta-parameters (such as cursor and filter);

[0330] Advantages: Flexible expansion; Risks: Need to manage naming conflicts.

[0331] Alternative Solution 2: Meta-parameter Hierarchy:

[0332] Standard layer, extension layer, and application layer are managed in a hierarchical manner.

[0333] Advantages: Clear layering; Risks: Increased processing complexity.

[0334] This application achieves the following specific technical effects:

[0335] First, this application standardizes the entire process of parsing different input formats, separating meta parameters, generating cache index paths, and automatically converting database queries through a unified query parameter parsing and automatic conversion mechanism. Developers do not need to write parsing code for different input formats, nor do they need to manually concatenate cache keys, write database query statements, or write source return logic. They only need to provide the original query parameters to automatically complete the entire process from parsing to data acquisition, which greatly reduces the amount of repetitive development work and lowers the maintenance cost of the application system.

[0336] For example, this invention implements a unified query parameter parsing architecture through Query_Params_Builder:

[0337] Detailed explanation of the effects:

[0338] It supports multiple input formats such as HTTP Query String and JSON Object, and parses them into a unified internal structure;

[0339] The application layer does not need to care about the format used by the client, and the processing logic is unified;

[0340] When adding a new input format, only the parser needs to be extended, without affecting the business logic.

[0341] Compared to traditional solutions:

[0342] Traditional approach: HTTP Query String → Application layer parsing A → Business logic

[0343] JSON Object → Application Layer Parsing B → Business Logic

[0344] Problem: Two sets of parsing logic result in high maintenance costs.

[0345] This invention: HTTP Query String → Query_Params_Builder → Query_Params → Business Logic

[0346] JSON Object → (Unified Parser) ↑

[0347] Easy to extend to new formats

[0348] This application natively supports query condition expressions using various operators through an operator prefix recognition mechanism. Furthermore, through recursive recognition and logical combination, it supports arbitrary levels of nested AND and OR logic combinations, enabling the expression of complex query condition requirements in most business scenarios. Developers do not need to develop additional logic combination processing modules to meet the expression requirements of complex queries.

[0349] Specifically, the conversion from Query_Params to Index_Path enables seamless integration of the Database and Cache modules:

[0350] Effect description:

[0351] The query parameter tree (Logical_Query_Param) is automatically converted into flat key-value pairs (tokens_).

[0352] Operator information is fully preserved through an encoding mechanism (e.g., "GT_18" indicates greater than 18);

[0353] Meta parameters (sort, offset, limit) are automatically mapped to the index path component;

[0354] No need to manually write cache key concatenation code;

[0355] Technical advantages:

[0356] Supports complex query conditions: nested AND / OR logic, multiple operators (EQ / NE / LT / GT / LK / IL, etc.);

[0357] Type safety: Automatically handles field type conversions through the Scenario mechanism;

[0358] Unified error handling: Errors during the conversion process are handled at the same level.

[0359] Because this application performs unified parsing and unified encoding on original query parameters with different input formats, as long as the semantics of the original query parameters are the same, the final generated cache index path will be completely consistent regardless of whether the input formats are different. This allows queries with the same semantics to share the same cache node, avoiding the problem of generating different cache keys under different input formats and causing the same query conditions to be unable to reuse the cache. This effectively improves the overall cache hit rate, reduces the pressure of repeated database access, and lowers the database load.

[0360] Specifically, query standardization ensures that query inputs of different formats generate the same Index_Path:

[0361] Effect description:

[0362] The HTTP format name=John&age=18 and the JSON format {"name":"John","age":18} generate the same tokens.

[0363] The same tokens access the same cache node, thus achieving cache sharing.

[0364] Operator encoding ensures that queries using different operators do not interfere with each other (e.g., EQ_John and NE_John).

[0365] Performance improvement estimate:

[0366] Scenario: User A uses HTTP format, and User B uses JSON format; the query conditions are the same.

[0367] Traditional solution:

[0368] The cache key is based on the original string, and the two generate different key-value pairs;

[0369] The cache cannot be shared; each cached cache must be retrieved from the origin server individually.

[0370] The cache hit rate is approximately 50%.

[0371] Invention solution:

[0372] The standardized Index_Path is the same;

[0373] Caches can be shared;

[0374] The cache hit rate is close to 100%.

[0375] This application implements automatic conversion between cache queries and database queries. When the cache is hit, the cached data is returned directly. When the cache is missed, the database query is automatically triggered and the cache is updated asynchronously. The entire process of querying the origin and updating the cache is completely transparent to the upper layer call. Developers do not need to manually write the logic for querying the origin and updating the cache, which reduces the workload of development and avoids errors caused by manually writing logic.

[0376] Specifically, regarding improved development efficiency, the unified query parameter processing framework significantly reduces development workload:

[0377] Specific effect comparison:

[0378] Traditional solution development process:

[0379] 1. Develop an HTTP query parameter parser (1-2 person-days)

[0380] 2. Write a JSON object parser (1 person-day)

[0381] 3. Manually build cache query keys (1-2 person-days)

[0382] 4. Handling various boundary situations (1 person-day)

[0383] 5. Write the cache origin retrieval logic (1-2 person-days)

[0384] 6. Write query result encapsulation code (0.5 person-days)

[0385] Total workload: 5-8 person-days

[0386] Development process for this application:

[0387] 1. Call Query_Params_Builder (0.25 man-days)

[0388] 2. Convert to Index_Path (0.25 person-days)

[0389] 3. Calling Index.find() (0.25 person-days)

[0390] 4. Process query results (0.25 person-days)

[0391] Total workload: 0.5-1 person-day

[0392] Efficiency improvement: 5-15 times

[0393] This application manages meta-parameters through a registry of meta-parameter key names, allowing developers to customize and register new meta-parameter names according to business needs. When developers add custom meta-parameters, they do not need to modify the core code for query parsing and index generation; they only need to register them in the registry. The architecture itself has good scalability. At the same time, the registry of meta-parameter key names supports two case-sensitive modes: case-sensitive mode and case-neutral mode, which can adapt to different requirements for parameter name case in different scenarios.

[0394] Specifically, the query performance improvement in this application significantly reduces query latency through a cache-first strategy:

[0395] Performance comparison:

[0396] Hypothetical scenario:

[0397] Memory access latency: ~100ns;

[0398] Database access latency: ~10ms;

[0399] Cache hit rate: 80%;

[0400] Number of queries: 1000.

[0401] No caching solution:

[0402] Total delay = 1000 × 10ms = 10 seconds.

[0403] This invention's solution (80% hit rate):

[0404] Cache hit latency = 800 × 100ns = 0.08ms;

[0405] Cache miss delay = 200 × 10ms = 2 seconds;

[0406] Total latency = 0.08ms + 2 seconds ≈ 2 seconds.

[0407] Performance improvement: (10 seconds - 2 seconds) / 10 seconds = 80%.

[0408] Practical application results:

[0409] High-frequency query scenarios: Hot data hits the cache, reducing response time from milliseconds to microseconds;

[0410] Reduced database load: 80% of queries do not require database access, reducing database pressure;

[0411] Improved system throughput: Strong caching concurrency capabilities significantly improve overall QPS.

[0412] This application supports horizontal scaling in multiple dimensions: First, it supports expanding operator types. When developers need to add special operators such as regular expression matching queries and geographic location range queries, they only need to add new operator type definitions in the operator prefix recognition stage. There is no need to modify the cache index path encoding logic and database query conversion logic, resulting in extremely low scaling costs. Second, it supports distributed caching system deployment. Since the cache index path generated by this application is highly standardized, standardized cache routing keys can be directly generated based on the cache index path to route query requests to the corresponding distributed cache nodes, thereby achieving horizontal scaling of distributed caching and adapting to the caching deployment needs of large-scale data scenarios.

[0413] A unified architecture provides a solid foundation for system expansion:

[0414] Expandability:

[0415] Added data source: Implemented a unified Index interface, which can be smoothly integrated with Redis / Memcached, etc.;

[0416] Added query type: Extended operator prefix (such as regular expression matching, geolocation query);

[0417] New meta-parameters: Custom meta-parameters are now supported via the Query_Meta_Keys registration mechanism;

[0418] Distributed caching: The standardized design of Index_Path naturally supports distributed cache key routing.

[0419] This application also provides a dual-channel access device for a cached database based on unified query parameters, including:

[0420] The processing module is used to obtain the original query parameters from the query request;

[0421] The processing module is also used to uniformly parse the original query parameters and construct a unified query parameter structure;

[0422] The unified query parameter structure includes a query condition tree and meta-parameters;

[0423] The processing module is also used to generate a cache index path based on the unified query parameter structure;

[0424] The cache index path includes a set of filter tokens, a sorting rule, and a range.

[0425] The processing module is further configured to access the cache index according to the cache index path, and when the data item set corresponding to the cache index path in the cache index contains a data item, return the cached data;

[0426] The processing module is further configured to generate a database query statement based on the cache index path and execute the database query to obtain the query result when the number of data items in the data item set corresponding to the cache index path in the cache index is empty, and update the cache.

[0427] The method provided in this embodiment first obtains the original query parameters and performs unified parsing on them. This unifies query conditions from different input sources into a unified query parameter structure containing a query condition tree and meta-parameters, eliminating the need for the application layer to write separate parsing logic for different formats, thus simplifying the query processing flow. After obtaining the unified query parameter structure, a cache index path is generated based on this structure. The cache index path simultaneously contains a set of filter tokens, sorting rules, and range intervals, thereby expressing the query conditions as path information that can be directly used for cache index location. This eliminates the need for manual key-value pairing or additional back-to-source logic for the conversion between cache queries and database queries. During the data access phase, the cache index is accessed first based on the cache index path. When the corresponding data item set in the cache index contains the data item, the cached data is directly returned, leveraging the high responsiveness of the cache to reduce query latency. When the number of data items is zero, a database query statement is automatically generated based on the cache index path and executed. After obtaining the query results, the cache is updated, ensuring that subsequent identical query conditions can directly hit the cache, reducing the pressure of repeated database accesses and achieving cache-first dual-channel data access.

[0428] As an optional implementation, the specific methods by which the processing module uniformly parses the original query parameters and constructs a unified query parameter structure include:

[0429] Identify the input format of the original query parameters;

[0430] When the input format is a Hypertext Transfer Protocol query string, the key-value pairs are parsed by the delimiter and nested logical combination tags are identified. When the input format is an object tag format, the object attributes are traversed and the corresponding parameter values ​​are parsed.

[0431] The registry is used to check whether the current parameter name is a meta parameter based on the meta parameter key name.

[0432] The registry predefines the mapping relationship between parameter names and meta-parameter types for the meta-parameter key names.

[0433] If the current parameter name is a meta parameter, the parameter value is stored in the meta parameter area of ​​the unified query parameter structure according to the registration type;

[0434] The meta-parameter region includes sorting rules, range intervals, and a set of original transparent parameters;

[0435] If the current parameter name is not a meta parameter, the parameter value corresponding to the current parameter name will be parsed as a normal query parameter and converted into a query condition tree node.

[0436] In this implementation, the input format of the original query parameters is first identified during the unified parsing process. Corresponding key-value pair parsing and attribute traversal methods are used for Hypertext Transfer Protocol query strings and object tag formats, respectively. This ensures that different forms of query input can be converted into key-value data in the unified parsing process, reducing parsing branches caused by differences in input format. Based on the parsing, the current parameter name is checked through the meta-parameter key name registry. Parameter values ​​belonging to meta-parameters are stored in the meta-parameter area of ​​the unified query parameter structure, while parameter values ​​not belonging to meta-parameters are parsed as ordinary query parameters into query condition tree nodes. This achieves separate processing of meta-parameters and ordinary query parameters, preventing meta-parameters from being mistakenly used as filtering conditions in the query condition tree. This ensures clear logical boundaries between filtering conditions, sorting rules, range intervals, and the original parameter set during subsequent cache index path generation, making the index path generation process more accurate and reliable.

[0437] As an optional implementation, the processing module is used to parse the ordinary query parameters into a query condition tree through operator prefix identification and / or logical combination, specifically including:

[0438] Scan field names and identify the operator types corresponding to the field name prefixes;

[0439] The operator types include equal operator, not equal operator, greater than operator, less than operator, fuzzy matching operator, and non-matching operator;

[0440] Based on the identified operator type, extract the field name after removing the prefix and the corresponding parameter value, and construct the field name, the operator type and the parameter value into a key-value query parameter node, which serves as the leaf node of the query condition tree;

[0441] Detect logical combination markers in the original query parameters. When an AND logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the AND logical node; when an OR logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the OR logical node.

[0442] Recursively form a multi-level query condition tree;

[0443] Wherein, the leaf nodes are key-value query parameter nodes, and the non-leaf nodes are AND logical nodes and OR logical nodes;

[0444] Furthermore, the meta-parameters include range parameters, sorting parameters, or pass-through parameters as is. The specific method by which the processing module stores parameter values ​​into the meta-parameter area of ​​the unified query parameter structure according to the registration type includes:

[0445] When the registration type is sorting type, parse the sorting field and ascending / descending order, and store the parsing result in the sorting rule;

[0446] When the registration type is a range type, the range interval is constructed and stored based on the offset and the number of limits, or based on the page number and the number per page.

[0447] When the registration type is the original transparent transmission type, the parameter name and parameter value are stored in the original transparent transmission parameter set.

[0448] In this implementation, the parsing of ordinary query parameters determines the operator type during the field name scanning stage by identifying the operator prefix. Then, the field name (with prefix removed), operator type, and parameter value are combined to construct a key-value query parameter node. This ensures that each filtering condition carries complete operational semantics when entering the query condition tree, preventing the loss of operator information during subsequent conversions. Based on this, by detecting AND and OR logical tags, multiple key-value query parameter nodes or sub-logical nodes are constructed into AND and OR logical node child nodes according to their logical relationships, thus recursively forming a multi-level query condition tree, enabling the structured expression of complex logical combinations. Simultaneously, meta-parameters are stored according to registration type in sorting rules, range intervals, and the set of parameters passed in as is. This ensures that sorting fields and ascending / descending order directions, offsets and limit quantities or page numbers and number of parameters per page, as well as parameters requiring pass-in as is, are all categorized into their corresponding meta-parameter areas, providing a directly usable data source for the sorting rules and range intervals in the subsequent generation of the cache index path.

[0449] As an optional implementation, the specific method by which the processing module generates the cache index path based on the unified query parameter structure includes:

[0450] Traverse the key-value query parameter nodes in the query condition tree, connect the operator identifier of each key-value query parameter node with the parameter value using a preset separator to form a token value, use the field name as the key and the token value as the value to generate the filter token set;

[0451] Extract sorting rules from the meta parameters and generate index path components corresponding to the sorting rules;

[0452] Extract the range interval from the meta parameters and generate the index path component corresponding to the range interval;

[0453] Furthermore, the processing module is also used to determine the data type corresponding to the field according to a preset scenario mechanism before generating the filter token set. When the field value needs to be converted, the parameter value is converted according to the data type corresponding to the field, and the converted parameter value is used as the parameter value part in the token value.

[0454] The data types mentioned include string type, numeric type and boolean type.

[0455] In this implementation, when generating the cache index path, the key-value query parameter nodes in the query condition tree are traversed. Each node's operator identifier and parameter value are connected using a preset separator to form a token value. A set of filter tokens is then generated, with field names as keys and token values ​​as values. This transforms the structured filtering conditions in the query condition tree into a flattened key-value mapping in the cache index path, preserving operator semantics while facilitating subsequent index matching. Before generating the filter token set, field values ​​are type-converted according to a preset scenario mechanism to ensure consistency in parameter values ​​of different data types before token encoding, reducing matching deviations caused by type differences in the cache index. Simultaneously, sorting rules and range intervals are extracted from the meta-parameters and corresponding index path components are generated. This ensures that sorting and range limitations are incorporated into the cache index path along with the filtering conditions, guaranteeing that the cache index path fully expresses the filtering, sorting, and range limitations of the query conditions. This allows cache index access and database query generation to directly reuse the path information, reducing redundant processing in the conversion stage.

[0456] As an optional implementation, the specific method by which the processing module accesses the cache index according to the cache index path includes:

[0457] Create a cached index path accessor, which initializes the unorchestrated token pool, the orchestrated token pool, the unorchestrated sorted pool, and the orchestrated sorted pool according to the filter token set and sorting rules;

[0458] Receive field orchestration instructions and move the specified field from the unorchestrated token pool or the unorchestrated sorting pool into the corresponding orchestrated set;

[0459] Following the hierarchical order of the cache index tree, the cache index nodes are accessed layer by layer according to the fields in the orchestrated set;

[0460] The cache index tree includes a first layer, an anonymous layer, and a leaf layer. In the first layer, the corresponding branch under the root node is accessed according to the orchestrated fields. In the anonymous layer, the fields in the unorchestrated token pool are accessed sequentially. In the leaf layer, the data set corresponding to the leaf node is accessed.

[0461] When a leaf node is reached, it is determined whether the orchestrated token pool, the unorchestrated token pool, and the unorchestrated sort pool are all empty. If all sets are empty, the index path traversal is considered complete.

[0462] Sort the data set corresponding to the leaf node according to the sorting field in the sorting pool, and truncate the data set corresponding to the leaf node according to the range interval to obtain the matching data record;

[0463] The starting value of the range interval is included, but the ending value is not included. When the ending value is a preset null value, all data from the starting value to the end of the data set is extracted.

[0464] This implementation creates a cached index path accessor and initializes four orchestration sets based on the filter token set and sorting rules. This ensures that the filter and sorting fields to be accessed are respectively assigned to the un-orchestrated and orchestrated regions before traversal begins, providing an ordered foundation for subsequent field-based orchestration instructions to move specified fields from the pending region to the processed region. During traversal, the index nodes are accessed layer by layer using the fields in the orchestrated set, following the hierarchical order of the cached index tree's first level, anonymous level, and leaf level. The corresponding data sets are accessed at the leaf level, making the access paths for filter and sorting fields in the index tree clear and improving the accuracy of index location. When a leaf node is reached, the traversal process ends by checking that the orchestrated token pool, un-orchestrated token pool, and un-orchestrated sorting pool are all empty, ensuring that all fields in the index path have been accessed. Finally, the dataset is sorted according to the sorting field in the sorting pool, and matching data records are obtained by truncation according to the range interval with the starting value included and the ending value excluded. This ensures that the returned data records have both a clear order and an accurate limit on the number of data records, thus meeting the sorting and pagination requirements in the query conditions.

[0465] As an optional implementation, the specific method by which the processing module generates and executes a database query statement based on the cached index path includes:

[0466] The token values ​​corresponding to each field in the filter token set are parsed into database query conditions, and multiple database query conditions are combined into a conditional clause using logical AND relation;

[0467] The sorting rules are mapped to sorting clauses, each sorting clause including a sorting field and a sorting direction;

[0468] The range interval is mapped to a restriction clause, the restriction clause including an offset and a restriction number;

[0469] The conditional clause, the sorting clause, and the restriction clause are combined to generate a database query statement, which is then executed.

[0470] Furthermore, the specific methods by which the processing module obtains the query results and updates the cache include:

[0471] After a successful database query, the cache index insertion interface is called asynchronously to insert the query result into the node corresponding to the cache index path in the cache index.

[0472] When the insertion interface returns success, the cache update is completed;

[0473] When the insertion interface returns a failure or an exception occurs, log the error and return the query result.

[0474] Unified encapsulation of cache query errors and database query errors, returning a uniformly formatted error response to the caller.

[0475] This implementation automatically converts cached index paths into database query statements when a cached index misses. This is achieved by parsing the token values ​​in the filter token set into database query conditions, merging them into conditional clauses using logical AND relationships, mapping sorting rules to sorting clauses, and mapping range intervals to restriction clauses. These three clauses are then combined to generate a complete database query statement. This eliminates the need for manual concatenation of database query statements based on query conditions, improving the efficiency of origin server queries. Upon successful database query, the query results are written to the corresponding path node in the cached index via an asynchronous call to the cached index insertion interface. This ensures that subsequent queries with the same conditions can directly hit the cache, reducing repeated origin server queries. When the insertion interface fails or an exception occurs, an error log is recorded, and the query results are returned, preventing cache update failures from affecting normal data return. Furthermore, cache query errors and database query errors are uniformly encapsulated and returned to the caller in a unified format, eliminating the need for the caller to adapt error handling logic for two different channels, simplifying the caller's access method.

[0476] As an optional implementation, the processing module is also used to configure the cache update strategy, specifically including:

[0477] The cache update strategy is determined to be at least one of the write-back strategy, write-through strategy, or bypass caching strategy;

[0478] When using a write-back strategy, write to the cache first and delay writing to the database.

[0479] When using a write-through strategy, writes are made to both the cache and the database simultaneously.

[0480] When using a bypass caching strategy, the cache is updated or invalidated after being written to the database.

[0481] This implementation, based on dual-channel access to the cache database, allows for flexible write paths by configuring at least one of a write-back strategy, a write-through strategy, or a bypass caching strategy. This enables the synchronization method between the cache and database to be selected according to the actual scenario, providing flexibility for different consistency and performance requirements. When using a write-back strategy, the data is written to the cache first and then delayed to the database, improving the timeliness of write responses. When using a write-through strategy, the data is written to both the cache and the database simultaneously, ensuring data consistency between the two. When using a bypass caching strategy, the data is written to the database first, then the cache is updated or invalidated, separating the cache update logic from the database write logic, facilitating independent control over cache invalidation and update timing. Thus, the configuration of the cache update strategy, in conjunction with the dual-channel access mechanism on the query end, enables coordinated management between the cache and the database in both read and write directions.

[0482] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0483] Indicatively, such as Figure 6 As shown, Figure 6 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 6 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0484] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0485] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0486] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

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

[0488] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

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

Claims

1. A dual-channel access method for a cached database based on unified query parameters, characterized in that, include: Retrieve the original query parameters from the query request; The original query parameters are parsed uniformly to construct a unified query parameter structure; The unified query parameter structure includes a query condition tree and meta-parameters; Generate a cache index path based on the unified query parameter structure; The cache index path includes a set of filter tokens, a sorting rule, and a range. Access the cache index according to the cache index path, and when the data item set corresponding to the cache index path in the cache index contains a data item, return the cached data; When the number of data items in the set of data items corresponding to the cache index path in the cache index is empty, a database query statement is generated according to the cache index path and the database query is executed to obtain the query result and update the cache.

2. The method according to claim 1, characterized in that, The process of uniformly parsing the original query parameters and constructing a unified query parameter structure includes: Identify the input format of the original query parameters; When the input format is a Hypertext Transfer Protocol query string, the key-value pairs are parsed by the delimiter and nested logical combination tags are identified. When the input format is an object tag format, the object attributes are traversed and the corresponding parameter values ​​are parsed. The registry is used to check whether the current parameter name is a meta parameter based on the meta parameter key name. The meta-parameter key name registry predefines the mapping relationship between parameter names and meta-parameter types; If the current parameter name is a meta parameter, the parameter value is stored in the meta parameter area of ​​the unified query parameter structure according to the registration type; The meta-parameter region includes sorting rules, range intervals, and a set of original transparent parameters; If the current parameter name is not a meta parameter, the parameter value corresponding to the current parameter name will be parsed as a normal query parameter and converted into a query condition tree node.

3. The method according to claim 2, characterized in that, The ordinary query parameters are parsed into a query condition tree through operator prefix identification and / or logical combination methods, specifically including: Scan field names and identify the operator types corresponding to the field name prefixes; The operator types include equal operator, not equal operator, greater than operator, less than operator, fuzzy matching operator, and non-matching operator; Based on the identified operator type, extract the field name after removing the prefix and the corresponding parameter value, and construct the field name, the operator type and the parameter value into a key-value query parameter node, which serves as the leaf node of the query condition tree; Detect logical combination markers in the original query parameters. When an AND logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the AND logical node; when an OR logical marker is detected, multiple key-value query parameter nodes or sub-logical nodes are treated as child nodes of the OR logical node. Recursively form a multi-level query condition tree; Wherein, the leaf nodes are key-value query parameter nodes, and the non-leaf nodes are AND logical nodes and OR logical nodes; Furthermore, the meta-parameters include range parameters, sorting parameters, or pass-through parameters as is. The step of storing parameter values ​​into the meta-parameter area of ​​the unified query parameter structure according to the registration type includes: When the registration type is sorting type, parse the sorting field and ascending / descending order, and store the parsing result in the sorting rule; When the registration type is a range type, the range interval is constructed and stored based on the offset and the number of limits, or based on the page number and the number per page. When the registration type is the original transparent transmission type, the parameter name and parameter value are stored in the original transparent transmission parameter set.

4. The method according to claim 1, characterized in that, The step of generating a cache index path based on the unified query parameter structure includes: Traverse the key-value query parameter nodes in the query condition tree, connect the operator identifier of each key-value query parameter node with the parameter value using a preset separator to form a token value, use the field name as the key and the token value as the value to generate the filter token set; Extract sorting rules from the meta parameters and generate index path components corresponding to the sorting rules; Extract the range interval from the meta parameters and generate the index path component corresponding to the range interval; Furthermore, before generating the set of filter tokens, the data type corresponding to the field is determined according to a preset scenario mechanism. When the field value needs to be converted, the parameter value is converted according to the data type corresponding to the field, and the converted parameter value is used as the parameter value part in the token value. The data types include string type, numeric type and boolean type.

5. The method according to claim 1, characterized in that, Accessing the cache index according to the cache index path includes: Create a cached index path accessor, which initializes the unorchestrated token pool, the orchestrated token pool, the unorchestrated sorted pool, and the orchestrated sorted pool according to the filter token set and sorting rules; Receive field orchestration instructions and move the specified field from the unorchestrated token pool or the unorchestrated sorting pool into the corresponding orchestrated set; Following the hierarchical order of the cache index tree, the cache index nodes are accessed layer by layer according to the fields in the orchestrated set; The cache index tree includes a first layer, an anonymous layer, and a leaf layer. In the first layer, the corresponding branch under the root node is accessed according to the orchestrated fields. In the anonymous layer, the fields in the unorchestrated token pool are accessed sequentially. In the leaf layer, the data set corresponding to the leaf node is accessed. When a leaf node is reached, it is determined whether the orchestrated token pool, the unorchestrated token pool, and the unorchestrated sort pool are all empty. If all sets are empty, the index path traversal is considered complete. Sort the data set corresponding to the leaf node according to the sorting field in the sorting pool, and truncate the data set corresponding to the leaf node according to the range interval to obtain the matching data record; The starting value of the range interval is included, but the ending value is not included. When the ending value is a preset null value, all data from the starting value to the end of the data set is extracted.

6. The method according to claim 1, characterized in that, The step of generating a database query statement based on the cached index path and executing the database query includes: The token values ​​corresponding to each field in the filter token set are parsed into database query conditions, and multiple database query conditions are combined into a conditional clause using logical AND relation; The sorting rules are mapped to sorting clauses, each sorting clause including a sorting field and a sorting direction; The range interval is mapped to a restriction clause, the restriction clause including an offset and a restriction number; The conditional clause, the sorting clause, and the restriction clause are combined to generate a database query statement, which is then executed. And, obtaining the query results and updating the cache includes: After a successful database query, the cache index insertion interface is called asynchronously to insert the query result into the node corresponding to the cache index path in the cache index. When the insertion interface returns success, the cache update is completed; When the insertion interface returns a failure or an exception occurs, log the error and return the query result. Unified encapsulation of cache query errors and database query errors, returning a uniformly formatted error response to the caller.

7. The method according to any one of claims 1-6, characterized in that, The method also includes configuring a cache update strategy, specifically including: The cache update strategy is determined to be at least one of the write-back strategy, write-through strategy, or bypass caching strategy; When using a write-back strategy, write to the cache first and delay writing to the database. When using a write-through strategy, writes are made to both the cache and the database simultaneously. When using a bypass caching strategy, the cache is updated or invalidated after being written to the database.

8. A dual-channel access device for a cached database based on unified query parameters, characterized in that, include: The processing module is used to obtain the original query parameters from the query request; The processing module is also used to uniformly parse the original query parameters and construct a unified query parameter structure; The unified query parameter structure includes a query condition tree and meta-parameters; The processing module is also used to generate a cache index path based on the unified query parameter structure; The cache index path includes a set of filter tokens, a sorting rule, and a range. The processing module is further configured to access the cache index according to the cache index path, and when the data item set corresponding to the cache index path in the cache index contains a data item, return the cached data; The processing module is further configured to generate a database query statement based on the cache index path and execute the database query to obtain the query result when the number of data items in the data item set corresponding to the cache index path in the cache index is empty, and update the cache.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-7.

Images