Drug identification information efficient query method and system based on distributed cache

Abstract

The invention provides a drug identification information efficient query method and system based on distributed cache. The method comprises the following steps: firstly, receiving and analyzing a drug identifier query request to generate a dynamic cache routing key, then positioning a target cache node, then matching a cache data block corresponding to a drug unique code in the target cache node, if matching succeeds, extracting a drug full life cycle record in the cache data block, and sending the drug full life cycle record to the target cache node; if the matching fails, initiating a cross-node retrieval request to the drug block chain database to return drug source data, splitting the drug source data into a core attribute set and an extended track set, and finally executing a dynamic combination operation on the core attribute set and the extended track set to generate a drug tracing result set and returning the drug tracing result set to the user terminal; according to the technical scheme provided by the invention, the query fluctuation defect of a single storage architecture is eliminated from the source, so that the whole system simultaneously meets three drug traceability core requirements of high concurrency, cross-mechanism and tamper-proofing.

Description

Technical Field

[0001] The present application relates to the field of pharmaceutical industry-specific information processing technology, and in particular to a method and system for efficiently querying pharmaceutical identification information based on distributed caching. Background Art

[0002] In the full lifecycle management of pharmaceuticals, manufacturers, logistics providers, and point-of-sale (POS) organizations require real-time verification of drug authenticity, traceability, and ingredient information. With the exponential growth of nodes in the global pharmaceutical distribution network, traditional centralized databases face high concurrent query pressure. They urgently need to meet millisecond-level response times to prevent supply chain disruptions, ensure reliable and tamper-proof data across organizations, and support dynamic, on-demand data combination (e.g., pharmacies require only basic authenticity information, while regulators require the full supply chain). These three rigid requirements have become core challenges for industry upgrades.

[0003] The current mainstream solution adopts a hybrid architecture of blockchain and centralized database to balance efficiency and credibility. The basic properties of drugs (ingredients, production batches, etc.) are stored in a centralized relational database, and the circulation trajectory (warehouse nodes, temperature control records, etc.) is written to the blockchain node; when the terminal initiates a query, the central processor first searches the local database. If trajectory data is required, it initiates a collaborative request to the blockchain network, and finally manually splices the two types of data into a result set through preset mapping rules.

[0004] However, this hybrid architecture suffers from fundamental flaws. The central database's microsecond response time severely conflicts with the blockchain's second-level consensus mechanism, causing single query times to fluctuate wildly between 10 milliseconds and 1 second, failing to meet the stability requirements of real-time verification scenarios. Furthermore, scaling the blockchain network requires reorganizing node consensus, while scaling the central database requires downtime and sharding. These two expansion processes mutually restrict dynamic resource coordination. More critically, due to the heterogeneous storage formats of core attributes (table structures) and trajectory data (chained blocks), they can only rely on static mapping table splicing results, unable to dynamically restructure data structures based on query scenarios. For example, when a pharmacy urgently needs to verify authenticity, it is still forced to load redundant logistics tracks, resulting in wasted bandwidth resources and delayed responses. Summary of the Invention

[0005] The present application provides an efficient query method and system for drug identification information based on distributed cache, which is used to solve the problems in the existing technology that the query time of the hybrid architecture fluctuates sharply due to the conflict of response mechanisms, the fragmentation of the storage system restricts the elastic expansion, and the heterogeneous data structure cannot support dynamic on-demand combination.

[0006] In a first aspect, the present application provides an efficient query method for drug identification information based on distributed cache, comprising: Receive a drug identification query request initiated by a user terminal, and parse the drug unique code and query type in the drug identification query request; Generate a dynamic cache routing key according to the batch characteristics of the unique code of the drug, and locate a target cache node in a preset distributed cache cluster based on the dynamic cache routing key; Match the cache data block corresponding to the unique code of the drug in the target cache node. If the match is successful, extract the drug life cycle record in the cache data block. If the match fails, initiate a cross-node search request to the preset drug blockchain database to return the drug source data; When a cross-node search request returns drug source data, the drug source data is split into a core attribute set and an extended trajectory set according to the circulation link; A dynamic combination operation is performed on the core attribute set and the extended trajectory set according to the query type to generate a drug traceability result set, and the drug traceability result set is returned to the user terminal.

[0007] Optionally, receiving a drug identification query request initiated by a user terminal and parsing the drug unique code and query type in the drug identification query request include: receiving, by a receiving device, a drug identification query request transmitted from a user terminal, and temporarily storing the drug identification query request in a temporary buffer; Extract the request body structure from the temporary buffer and disassemble the request body structure into multiple independent parts; In each independent part, positioning the drug unique code part and the query type part according to a predetermined position rule; A fixed-length character sequence is extracted from the drug unique code portion as the drug unique code, and a content value is extracted from the query type portion as the query type.

[0008] Optionally, generating a dynamic cache routing key according to the batch feature of the unique drug code, and locating a target cache node in a preset distributed cache cluster based on the dynamic cache routing key includes: Stripping the continuous subsequence containing batch characteristics from the drug's unique coding sequence; The last two digits of the current system millisecond value are appended to the batch feature subsequence as a distribution factor to form a dynamic cache routing key; Convert each character of the dynamic cache routing key into an ASCII code value in sequence and sum them up, perform a modulo operation on the sum result and the total number of preset virtual nodes to obtain a virtual node identifier; According to a preset node allocation table, a physical node address mapped to the virtual node identifier is determined, and the physical node is used as a target cache node.

[0009] Optionally, matching the cache data block corresponding to the unique code of the drug in the target cache node, and extracting the drug life cycle record in the cache data block if the match is successful, including: Calculate the location index of the target segment based on the batch characteristic segment of the unique code of the drug; Perform a scan operation on the mapping entry set of the target sharding area and obtain the corresponding storage location identifier by matching the encoding segments; Locating and reading a cache data block in a block storage area according to the storage location identifier; A hierarchical structure conversion operation is performed on the cached data block to generate a full life cycle record of the drug.

[0010] Optionally, if the match fails, a cross-node search request is initiated to the preset drug blockchain database to return the drug source data, including: When the target cache node does not match the cache data block corresponding to the drug's unique code, a blockchain search request body is generated based on the structural characteristics of the drug's unique code; Query the node location index table based on the predetermined segment content of the drug's unique code to determine the location identifier set of the target node group; Sending a search request body to the primary node and auxiliary nodes included in the target node group in parallel, and receiving the drug circulation data unit returned by each node; Add a continuity mark to each drug circulation data unit, and merge the associated identifiers within each drug circulation data unit into complete drug source data.

[0011] Optionally, when a cross-node search request returns drug source data, the drug source data is split into a core attribute set and an extended trajectory set according to the circulation link, including: Loading the drug source data returned by the cross-node search request into a serialized data block, wherein the serialized data block includes a plurality of fields arranged with a predetermined delimiter; Scan the starting identification prefix of each field, and when it is detected that the starting identification prefix of the field is a preset first-class identification prefix, treat it as a first-class field and assign the first-class field to the core attribute set; When it is detected that the starting identification prefix of the field is a preset second-category identification prefix, it is regarded as a second-category field and the second-category field is allocated to the extended track set.

[0012] Optionally, performing a dynamic combination operation on the core attribute set and the extended trajectory set according to the query type to generate a drug traceability result set, and returning the drug traceability result set to the user terminal includes: Parse the code tag of the query type and determine the scope of the combined operation according to the code tag; Scanning a core attribute set and an extended trajectory set based on the operation scope, wherein the core attribute set includes a basic drug description unit, and the extended trajectory set includes a circulation node record unit; Extract all the basic description units of the drug in the core attribute set, and extract the circulation node record units of the extended trajectory set according to the relevance of the query type; Create a blank result container, place the basic drug description unit at the beginning of the blank result container, and place the circulation node record units at the end of the blank result container in ascending order of timestamps to obtain a result container, wherein each basic drug description unit and each circulation node record unit in the result container contains a corresponding type tag; Scan each drug basic description unit and each circulation node record unit and corresponding type mark in the result container, generate a character string unit according to the type mark as a separator, and append a check code to the end of the character string unit to form a linear sequence; Encapsulating the linear sequence into an initial response body, and appending a timestamp identifier and a sequence length identifier to the header of the initial response body to obtain a drug traceability result set; The drug traceability result set is pushed through the preset transmission channel and transmitted to the receiving interface of the user terminal.

[0013] In a second aspect, the present application provides an efficient drug identification information query system based on distributed cache, comprising: A receiving module, configured to receive a drug identification query request initiated by a user terminal and parse the drug unique code and query type in the drug identification query request; A positioning module, configured to generate a dynamic cache routing key according to the batch characteristics of the unique drug code, and locate a target cache node in a preset distributed cache cluster based on the dynamic cache routing key; A matching module is configured to match the cached data block corresponding to the unique drug code in the target cache node, extract the drug life cycle record in the cached data block if the match is successful, and initiate a cross-node search request to a preset drug blockchain database to return the drug source data if the match fails; A splitting module, configured to split the drug source data into a core attribute set and an extended trajectory set according to the circulation link when a cross-node search request returns the drug source data; A generation module is used to perform a dynamic combination operation on the core attribute set and the extended trajectory set according to the query type, generate a drug traceability result set, and return the drug traceability result set to the user terminal.

[0014] In a third aspect, an embodiment of the present application provides a computing device comprising a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement an efficient query method for drug identification information based on distributed cache as described in the first aspect above.

[0015] In a fourth aspect, an embodiment of the present application provides a computer storage medium storing a computer program. When the computer program is executed by a computer, it implements an efficient query method for drug identification information based on distributed cache as described in the first aspect.

[0016] This embodiment of the application first accurately calculates the location index of the target sharding area using the batch feature segment of the drug's unique code, performs a mapping entry scan within the specified area of the distributed cache node, and directly locates the cached data blocks in the block storage area, enabling the hierarchical structure conversion and extraction of drug lifecycle records to be completed within milliseconds. This method utilizes the principle of local continuity of batch features to transform traditional global search into partition-directed matching, avoiding the resource consumption caused by full node traversal in cache hit scenarios, and ensuring extremely fast response to high-frequency queries.

[0017] Secondly, when the distributed cache fails to match drug information, the query task is intelligently segmented based on the pre-positioned segments of the drug's unique code. A blockchain search request body is first generated based on structural features. The pre-positioned segments are then used to quickly locate the target node group, and search requests are initiated in parallel to the primary and secondary nodes. By adding continuity markers and merging associated identifiers to the returned drug circulation data units, the fragmented data returned asynchronously by multiple nodes is reconstructed into complete drug source data, avoiding the fragmented splicing delays associated with on-chain data retrieval.

[0018] Furthermore, by combining the rapid positioning capabilities of the local cache cluster with the distributed retrieval mechanism of the blockchain network, a two-level query architecture is formed: "batch features drive cache partition retrieval + pre-positioned segments guide on-chain parallel collection." While ensuring the integrity of drug data throughout its lifecycle, this architecture leverages the cache's shard mapping mechanism to achieve millisecond-level returns for high-frequency data, while intelligent node positioning addresses the inefficiency of cross-node on-chain data collection. This fundamentally eliminates the query fluctuation flaws inherent in a single storage architecture, enabling the overall system to simultaneously meet the three core requirements of drug traceability: high concurrency, cross-institutional integration, and tamper-proofing.

[0019] These and other aspects of the present application will become more readily apparent from the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 A flowchart of an efficient query method for drug identification information based on distributed cache provided by the present application is shown; Figure 2 The present invention provides a schematic diagram of a system for efficiently querying drug identification information based on distributed caching; Figure 3 A schematic structural diagram of a computing device provided by the present application is shown. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0023] In some of the processes described in the specification and claims of this application and the above-mentioned figures, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to being different types.

[0024] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts are within the scope of protection of this application.

[0025] Figure 1 The present invention provides a flowchart of an efficient query method for drug identification information based on distributed cache, such as Figure 1 As shown, the method includes: Step 101: Receive a drug identification query request initiated by a user terminal, and parse the drug unique code and query type in the drug identification query request.

[0026] In this step, the drug identification query request refers to the data query instruction encapsulation initiated by the user terminal to the system. The request contains a protocol control header and the actual query parameter body. The drug unique code is a 20-character sequence fixedly embedded in the request parameter body, which is used to accurately identify the identity of a single drug. For example, 864215973205 represents the unique identifier of a batch of drugs. The query type is a 4-digit enumeration code synchronously embedded in the request parameter body, which is used to declare the query scope category required by the user. For example, code 2 indicates that the full circulation trajectory data of the drug is required.

[0027] In this embodiment, the incoming data stream is continuously monitored through the TCP network port, and the original byte sequence of the drug identification query request is captured and temporarily stored in the ring buffer storage area. When performing the request body extraction operation on the data in the buffer, the system scans a specific blank line separator combination (hexadecimal 0x0D0A0D0A) as a cutting point to accurately separate the complete parameter body structure. In the parameter body parsing stage, the system implements a direct interception operation according to the predefined byte position rules: 20 bytes are continuously extracted from the starting position of the 3rd byte of the parameter body to generate the original string of the drug unique code; and 4 bytes of content are simultaneously obtained from the starting position of the 25th byte of the parameter body as the query type original code. Finally, the original code is converted into readable semantics through the preloaded enumeration mapping dictionary to form an unmodified drug unique code string and a clear query type semantic output group.

[0028] For example, when a pharmacy point-of-sale terminal initiates a drug traceability request, the byte sequence transmitted is [protocol header data]...[blank]ID=864215973205&QT=2. The system captures this data stream on port 8080 and stores it in a memory buffer. Using signature scanning, it locates the continuous blank identifier 0x0D0A0D0A at byte 40 and accurately extracts the valid parameter body "ID=864215973205&QT=2" after byte 44. During parameter parsing, the system automatically extracts the drug's unique code "864215973205" from the 3rd to 22nd characters based on positional rules. It also extracts the code "2" from the 25th to 28th characters. After enumeration and mapping in the dictionary, the query type is confirmed to be full-trace query mode. The resulting raw parameter set [drug unique code: "864215973205", query type: "full-trace query"] is then passed to the dynamic routing process.

[0029] Step 102: Generate a dynamic cache routing key according to the batch characteristics of the unique drug code, and locate a target cache node in a preset distributed cache cluster based on the dynamic cache routing key.

[0030] In this step, the batch feature refers to the continuous character subsequence (such as fixed 7th to 10th digits) in the unique code of the drug used to identify the production batch. The dynamic cache routing key is a temporary routing identifier formed by concatenating the batch feature subsequence and the real-time distribution factor. The preset distributed cache cluster is a physical node network that adopts a virtual node mapping mechanism, and its address mapping relationship is determined by the preset node allocation table.

[0031] In this embodiment, the batch characteristic subsequence is first stripped from the predetermined bit segment (such as the 7th to 10th characters) of the unique drug code, and then the millisecond value of the current system time is obtained and the last two digits are extracted as the real-time distribution factor, and the factor is appended to the end of the batch characteristic subsequence to generate a complete dynamic cache routing key; then each character in the routing key is independently converted into an ASCII integer value and a cumulative sum is performed, and the obtained sum is modulo the total number of preset virtual nodes to generate a virtual node identifier; finally, the physical network address mapped to the virtual node identifier in the preset node allocation table is queried to determine the specific location of the target cache node.

[0032] For example, based on the unique drug code "864215973205" obtained in step 101, the 7th to 10th digits of the batch feature segment "1597" are extracted, and the current millisecond value of the monitoring system clock 1689243876925 is monitored, and the last two digits "25" are truncated to form the routing key "159725". The characters are converted one by one (1→49, 5→53, 9→57, 7→55, 2→50, 5→53), and the cumulative sum is 317. When the total number of virtual nodes is set to 200, the modulus operation 317%200=117 is performed to obtain the virtual node identifier. The node allocation table is queried to confirm that virtual node 117 is mapped to the physical address 192.168.5.22, thereby completing the location of the target cache node. This address will be directly used to trigger subsequent cache matching operations.

[0033] Step 103: Match the cache data block corresponding to the unique code of the drug in the target cache node. If the match is successful, extract the drug life cycle record in the cache data block. If the match fails, initiate a cross-node search request to the preset drug blockchain database to return the drug source data.

[0034] In this step, the target cache node refers to the physical storage node located in step 102 (such as 192.168.5.22). The cache data block is a fixed-size data unit stored in the node memory (such as a 128KB block). The drug life cycle record describes the structured data of the entire process from drug production to sales. The drug blockchain database is a decentralized drug traceability network composed of multiple nodes.

[0035] In this embodiment, the sharding location index is calculated within the target cache node using the batch feature segment (digits 7-10 of the drug's unique code): the ASCII values of the subsequence of characters are summed and then modulo the total number of shards. A sequential scan is performed within the target sharding area's hash map. When a match is found with an entry that exactly matches the drug's unique code, a storage location identifier is obtained. Based on this identifier, the complete cached data block is read from the block storage area. A hierarchical structure conversion operation is performed on the data block: the binary stream is reorganized into a tree-structured record of the drug's entire life cycle, using predetermined hierarchical markers (e.g., 0x01 for the production layer, 0x02 for the logistics layer). If the map scan fails to find a match, a blockchain search request is generated based on the structural features of the drug's unique code (e.g., the first 6 digits of the manufacturer code). The node location index table is queried to determine the target node group (e.g., the node group corresponding to manufacturer A). The request is then sent concurrently to the primary and secondary nodes. Upon receiving drug circulation data units returned by multiple nodes, a continuity marker (e.g., a timestamp sequence number) is added and merged into the complete drug source data based on associated identifiers (e.g., the drug batch number).

[0036] For example, following step 102, the target node 192.168.5.22 is located. When the unique drug code is "864215973205", the batch feature segment "1597" is extracted to calculate the ASCII total value 214 (49+53+57+55). The total number of shards 50 is modulo to obtain shard area No. 14. After matching the code entry in the shard hash table, the storage address 0x7FE2A1 is obtained, and the 128KB data block at the address is read and parsed into a tree structure according to the tag: the production layer (0x01) contains the drug name and batch number, and the logistics layer (0x02) contains the warehouse temperature record and timestamp. If no match is successful, the manufacturer code "864215" is extracted to generate a blockchain search request body, and the target node group [192.168.8.11, 192.168.8.15], the primary node returns the production data unit of sequence number 1, and the secondary node returns the transportation data unit of sequence number 2, which are merged according to the sequence number to form continuous source data.

[0037] Step 104: When the cross-node search request returns drug source data, the drug source data is split into a core attribute set and an extended trajectory set according to the circulation link.

[0038] In this step, drug source data refers to the complete dataset returned from the drug blockchain database, consisting of a sequence of fields connected by predetermined delimiters (e.g., semicolons). The core attribute set stores the static characteristics inherent in the drug (consisting only of fields beginning with "PROD_" after removing the prefix). The extended track set stores dynamic records of the drug's distribution process (consisting only of fields beginning with "LOG_" after removing the prefix).

[0039] In this embodiment, the received drug source data is first segmented into a sequence of discrete field units using pre-defined delimiters. Next, the initial character sequence of each field unit is scanned. If a character sequence is detected that fully matches a preset static attribute identifier (fixed prefix "PROD_"), the original content of the field unit, after removing the identifier, is stored in a memory block dedicated to the core attribute set. If a character sequence is detected that fully matches a dynamic track identifier (fixed prefix "LOG_"), the original content of the field unit, after removing the identifier, is stored in a memory block dedicated to the extended track set. After all fields are processed, the core attribute set memory block contains only the basic drug parameter data, while the extended track set memory block retains only the circulation link record data.

[0040] For example, consider the drug source data returned by the blockchain in step 103: "PROD_Drug Name XX; LOG_20240520 Warehouse Temperature 25°C; LOG_20240522 Waybill Number 789." First, perform a field split operation to obtain three field units: Unit 1="PROD_Drug Name XX", Unit 2="LOG_20240520 Warehouse Temperature 25°C", and Unit 3="LOG_20240522 Waybill Number 789." Scan the starting character sequence: Unit 1's "PROD_" matches the static attribute identifier. After removing the prefix, "Drug Name XX" is written to the core attribute set memory block. Units 2 and 3's "LOG_" match the dynamic trajectory identifier. After removing the prefix, "20240520 Warehouse Temperature 25°C" and "20240522 Waybill Number 789" are written to the extended trajectory set memory block. The final core attribute set is ["drug name XX"], and the extended trajectory set is ["20240520 warehouse temperature 25°C", "20240522 waybill number 789"]. This output is used as a direct input parameter for the dynamic combination operation in step 105.

[0041] Step 105 : Perform a dynamic combination operation on the core attribute set and the extended trajectory set according to the query type to generate a drug traceability result set, and return the drug traceability result set to the user terminal.

[0042] In this step, dynamic combination refers to the process of intelligently reorganizing the existing core attribute set and extended trajectory set based on the query type semantics. The reorganization logic includes data selection rules (e.g., full trajectory queries must include all data units) and sorting rules (core data first, trajectory order by time). The drug traceability result set is a linearly sequenced data structure formed after reorganization, consisting of units separated by type tags and a chain of fields with a verifiable checksum at the end.

[0043] In this embodiment, the query type's semantic code is first parsed to determine the scope of the combined operation (e.g., a full trajectory query requires the entire attribute set and trajectory set). Next, the drug basic description units (e.g., ingredient data) in the core attribute set and the circulation node record units (e.g., storage records) in the extended trajectory set are scanned, extracting all basic description units and associated node record units within the query type range. Next, a blank result container is created, with the basic description units sequentially placed at the beginning of the container and the circulation node record units arranged in ascending timestamp order at the end. A type tag ("B_" for basic descriptions and "T_" for trajectory records) is appended to each unit. The container contents are then converted into a linear sequence: each unit is scanned and the type tag is used as a delimiter to generate a string unit (e.g., "B_Ingredient Glucose"), with the checksum appended to the end of the unit. Finally, the sequence is encapsulated into an initial response body, with a timestamp and sequence length identifier added to the header to generate the drug traceability result set. The result is then pushed to the receiving interface of the user terminal via a dedicated transmission channel.

[0044] For example, following the split result in step 104, the core attribute set includes the unit ["ingredient glucose"], and the extended trajectory set includes the unit ["20240520 warehouse temperature 25°C"]. If the query type is a full trajectory query, all units are scanned and extracted, and a result container is created. The basic unit "ingredient glucose" is placed at the beginning (with a "B_" marker), and the trajectory unit "20240520 warehouse temperature 25°C" is placed at the end (with a "T_" marker). When converting the container content, the "B_" marker is captured to generate the string unit "B_ingredient glucose", and the checksum "KJ8" is appended to the end to form "B_ingredient glucose KJ8". Similarly, "T_20240520 warehouse temperature 25°C KX3" is generated. These are concatenated to form the linear sequence "B_ingredient glucose KJ8; T_20240520 warehouse temperature 25°C KX3". After encapsulating the initial response body, the header identifier is added: [Timestamp: 202405280835, Sequence length: 58 bytes], and pushed to the pharmacy terminal display interface via the HTTPS channel.

[0045] In order to solve the problem of low positioning efficiency caused by the non-fixed field position in the query request parsing in the prior art and to improve the accuracy of extracting the drug unique code and query type, in some embodiments, according to step 101, receiving a drug identification query request initiated by a user terminal and parsing the drug unique code and query type in the drug identification query request include: In step 201 , a drug identification query request transmitted from a user terminal is received by a receiving device, and the drug identification query request is temporarily stored in a temporary buffer.

[0046] In this step, the receiving device refers to the network protocol processing module deployed at the front end of the server, which supports TCP / UDP protocol packet parsing; the temporary buffer is a pre-allocated memory area that can be written cyclically, and uses a circular queue storage structure to prevent data overflow.

[0047] In this embodiment, the Ethernet data frame is first captured through the physical network card port of the receiving device, and the network layer data packet is obtained after stripping the data link layer header. Then, the IP data packet is reassembled: the transport layer protocol type (such as TCP protocol) is identified, and the fragmented data packets are sorted and reassembled into a complete and ordered byte stream according to the sequence number field. The reassembled byte stream is written to the circular storage queue of the temporary buffer: the byte data is stored sequentially by the self-increment operation of the queue tail pointer, and the queue tail pointer is automatically reset to the starting position when it reaches the queue upper limit. The difference between the queue head and queue tail pointer is monitored throughout the process to ensure that the buffer occupancy rate does not exceed the safety threshold.

[0048] Step 202: extract the request body structure from the temporary buffer and decompose the request body structure into multiple independent parts.

[0049] In this step, the request body structure refers to the valid parameter data segment after the specific starting identifier in the drug identification query request; the independent part is the data sub-unit divided according to the predetermined separation rule, and each unit corresponds to an independent parameter category.

[0050] The embodiment of the present application first scans the circular queue data in the temporary buffer, locates the continuous blank line identifier 0x0D0A0D0A and copies the subsequent bytes to a new memory block to form a request body structure; then scans the request body byte by byte to detect predefined delimiters (such as the & symbol ASCII 38), and creates a new independent partial block each time a delimiter is identified.

[0051] Step 203: In each independent part, the drug unique code part and the query type part are located according to a predetermined location rule.

[0052] In this step, the predetermined position rule refers to a byte offset table pre-stored in the system memory, which records the absolute position range of different parameter blocks in the request body (e.g., the unique drug code occupies bytes 3-22, and the query type occupies bytes 25-28); the positioning operation is the process of confirming the target data domain by comparing the offset table with the independent part memory address.

[0053] In this embodiment, the byte offset table in the memory is first loaded, and the independent part memory blocks generated in step 202 are traversed. The global offset of the starting address in the request body is calculated for each block: the relative position is obtained by subtracting the starting address of the request body structure from the base address of the independent part. The relative position of each block is then interval-matched with the predetermined position rule: if the starting offset of the current block is within the predetermined byte range of the drug unique code (such as bytes 3-22), it is marked as a drug unique code block; if it is within the predetermined byte range of the query type (such as bytes 25-28), it is marked as a query type block. All blocks that fail to match will be ignored and will not participate in subsequent extraction.

[0054] Step 204: extract a fixed-length character sequence from the drug unique code portion as the drug unique code, and extract a content value from the query type portion as the query type.

[0055] In this step, the fixed-length character sequence refers to a continuous string of predetermined length (20 characters) in the drug's unique code block; the content value is the original data bytes in the query type block with the prefix removed; and the extraction operation is the physical process of accurately copying the target data from the tag block.

[0056] In this embodiment, substring extraction is first performed on the marked drug unique code block. A predetermined length (20 characters) is copied from a predefined starting position (e.g., the third character) in the block content to a new memory area, forming the original drug unique code string. Prefix stripping is then performed on the query type block: the block content is scanned for the first equal sign delimiter and all bytes following it are copied as the query type value. All extraction operations are based on raw byte copying, without any transcoding or calculation.

[0057] In order to solve the load imbalance and hotspot access problems caused by static routing keys in the distributed cache cluster in the prior art, in some embodiments, according to step 102, a dynamic cache routing key is generated according to the batch characteristics of the unique drug code, and a target cache node in the preset distributed cache cluster is located based on the dynamic cache routing key, including: Step 301: strip the continuous subsequence containing the batch characteristics in the unique coding sequence of the drug.

[0058] In this step, the continuous subsequence of the drug identification query request refers to a physically continuous character segment extracted from the drug's unique encoding string. Its starting position and length are determined by preset rules and stored in a separate memory block. The drug identification query request stripping operation is a memory byte copy process based on fixed offset and length values, without involving transcoding or calculation.

[0059] This example first loads the preset batch feature location parameters (starting index and length) and calculates the physical starting address of the drug's unique encoding string based on the starting index. It then performs a byte-level copy, continuously reading a byte stream of the specified length from the starting address and writing it into a newly allocated independent memory block. This entire process involves no character conversion or logical calculations; the physical separation of subsequences is achieved solely through memory address operations.

[0060] Step 302: append the last two digits of the current system millisecond value to the batch feature subsequence as a distribution factor to form a dynamic cache routing key.

[0061] In this step, the current system millisecond value drug identification query request is a complete timestamp value (accurate to milliseconds) obtained through the operating system clock interface; the distribution factor drug identification query request is the last two digits (such as "25") extracted from the decimal representation of the millisecond value; the combined operation drug identification query request is a process of sequentially splicing byte streams through the memory buffer.

[0062] In this example, the system clock interface is first called to obtain the current millisecond timestamp. After converting the value to a decimal string, the last two characters of the string are truncated as the distribution factor. A new memory buffer is allocated, and the batch feature subsequence byte stream is first written in its entirety. Subsequently, the distribution factor byte stream is continuously written, generating a continuous memory byte sequence that serves as the dynamic cache routing key output.

[0063] Step 303: Convert each character of the dynamic cache routing key into an ASCII code value in sequence and sum them up, perform a modulo operation on the sum result and the total number of preset virtual nodes to obtain a virtual node identifier.

[0064] In this step, the ASCII code value conversion of the drug identification query request refers to the operation of converting the routing key character into the corresponding ASCII standard code value (such as "A"→65); the summation operation of the drug identification query request is the process of performing integer accumulation on the ASCII code values of all characters; the preset total number of virtual nodes of the drug identification query request is the number of logical nodes predefined in the distributed cache cluster (such as 200); the modulus operation of the drug identification query request refers to the mathematical operation of dividing the sum value by the total number of virtual nodes and taking the remainder; the virtual node identifier of the drug identification query request is the integer result obtained after the modulus operation (range 0 to the number of nodes-1).

[0065] This embodiment first reads each character in the dynamic cache routing key and retrieves the corresponding integer value (e.g., "1" → 49) by looking up the ASCII encoding table. It then initializes an accumulator and sequentially iterates through all characters: the ASCII value of the current character is added to the accumulator and the accumulator state is updated. After the traversal is complete, the final sum is obtained, which is used as the dividend. Using the preset total number of virtual nodes as the divisor, an integer division operation is performed to obtain the remainder. The remainder is the virtual node identifier (e.g., 317 ÷ 200 = 117).

[0066] Step 304: Determine the physical node address mapped to the virtual node identifier according to a preset node allocation table, and use the physical node as a target cache node.

[0067] In this step, the preset node allocation table drug identification query request is a mapping structure (hash table form) stored in the memory, which records the correspondence between the virtual node identifier and the physical node network address; the physical node address drug identification query request is the network location identifier of the target cache node (such as IP+port number).

[0068] This embodiment first loads the node allocation table data structure from memory. Using the virtual node identifier output in step 303 as the query key, an exact match is performed within the allocation table's hash buckets. The bucket index corresponding to the key value is calculated using a hash function, and the key-value pair entries within that bucket are traversed until a complete match is found. The physical address field (e.g., "192.168.5.22:11211") in the matching entry is extracted and parsed into a network address structure. This address is then output as the target cache node.

[0069] In order to solve the retrieval delay problem caused by global scanning of cached data in the prior art, in some embodiments, according to step 103, it is characterized in that the cached data block corresponding to the unique code of the drug is matched in the target cache node, and if the match is successful, the drug life cycle record in the cached data block is extracted, including: Step 401: Calculate the location index of the target segment based on the batch feature segment of the unique code of the drug.

[0070] In this step, the batch feature segment of the drug identification query request refers to the character subsequence (such as the 7th to 10th characters) in the drug unique code used to identify the drug production batch; the position index drug identification query request is to convert the batch feature segment into an integer value through a specific algorithm to locate the storage location of the target shard area; the target shard area drug identification query request is a logical data partition unit of the distributed cache node.

[0071] This implementation first converts each character in the batch feature segment into an ASCII integer value, initializes an accumulator, and iterates through all characters. The ASCII value of the current character is added to the accumulator, and the accumulator state is updated. The final accumulated value is then modulo-calculated with the total number of shards. The remainder is the position index. This index ranges from 0 to the total number of shards - 1, directly corresponding to the logical storage area of the node.

[0072] Step 402: Perform a scan operation on the mapping entry set of the target sharding area, and obtain the corresponding storage location identifier by comparing the coding segments.

[0073] In this step, the mapping entry set drug identification query request is a key-value pair data structure stored in the target shard area, which contains the mapping relationship between the complete drug code and the storage address; the coding segment drug identification query request refers to the complete unique code string of the drug stored in the mapping entry; the storage location identifier drug identification query request is the memory address identifier of the physical storage block; the scanning operation drug identification query request refers to the query process of traversing the mapping entry set for precise comparison.

[0074] This example first accesses the target shard's mapping entry set based on the location index. A character-by-character comparison is performed on each entry in the set, comparing the drug's unique code bit-by-bit with the complete code segment stored in the entry. A match is considered successful when all characters match. Upon a successful match, the storage location identifier associated with the entry is immediately returned. If no match is found after traversing all entries, an empty identifier is returned, indicating a cache miss.

[0075] Step 403: Locate and read the cache data block in the block storage area according to the storage location identifier.

[0076] In this step, the drug identification query request block storage area drug identification query request refers to a fixed-size storage unit set (such as 128KB / block) divided by the cache node memory, which is managed by the starting address base address; the cache data block drug identification query request is a physical unit for storing specific drug data in the block storage area, and its location is precisely described by the storage location identifier (such as the memory address value).

[0077] This embodiment first parses the storage location identifier to obtain a physical address value and maps this address value to the block storage area management table: the target block offset is calculated as (identifier address - storage area base address) / block size. The starting address of the target block is located based on the offset, and the direct memory access interface is called to read the complete data block byte stream into the processing buffer. The read process uses an unaligned byte copy technique to ensure complete data transfer across memory boundaries.

[0078] Step 404: perform a hierarchical structure conversion operation on the cached data block to generate a drug life cycle record.

[0079] In this step, the hierarchical structure conversion operation of the drug identification query request refers to the process of reorganizing the linearly stored cache data blocks into a tree structure according to preset separation marks (such as 0x01 / 0x02); the drug identification query request for the entire life cycle record of the drug is a tree data structure that includes multi-level relationships of production, logistics, and quality inspection.

[0080] This embodiment first scans the cached data block byte by byte, and creates a new hierarchical node when a hierarchical separation marker (such as the production layer marker 0x01) is detected; reads the length field after the marker to determine the data segment size, extracts the corresponding byte stream and mounts it to the current hierarchical node; recursively processes each hierarchical marker in turn: the production layer is used as the root node, the logistics layer as the child node chain, and the quality inspection layer as the leaf node; establishes a parent-child relationship between nodes through pointers, and finally forms a complete tree data structure.

[0081] In order to solve the problems of fragmented collection and inefficient asynchronous splicing during cross-node retrieval of on-chain data in the prior art, in some embodiments, according to step 103, if a match fails, a cross-node retrieval request is initiated to a preset drug blockchain database to return the drug source data, including: Step 501: When the target cache node does not match the cache data block corresponding to the drug's unique code, a blockchain search request body is generated based on the structural characteristics of the drug's unique code.

[0082] In this step, the structural feature refers to the predefined manufacturer identification segment (such as the first 6 characters) in the unique drug code; the blockchain search request body is a structured query data packet that complies with the blockchain node communication protocol and includes a search key and a check field.

[0083] In this embodiment, when a cache miss occurs, a predefined manufacturer identification segment (such as the 1st to 6th characters) is intercepted from the unique drug code, a request body buffer is constructed, and the following are written in the order of the protocol format: protocol header (fixed bytes), manufacturer identification segment (original characters), complete drug code (verification backup), checksum field (byte arithmetic sum of the manufacturer identification segment), and the entire request body is terminated with a terminator to form a network data packet that can be sent directly.

[0084] Step 502: query the node location index table based on the predetermined segment content of the drug unique code to determine the location identifier set of the target node group.

[0085] In this step, the node location index table is a memory-resident key-value mapping structure (vendor code → node group address); the target node group refers to the cluster of primary nodes and secondary nodes responsible for a specific vendor's data; the location identifier set contains a list of network addresses of the primary nodes and secondary nodes.

[0086] This embodiment extracts the vendor identification segment from the request body as the query key. The node location index table hash structure is loaded, and the hash value of the vendor identification segment is calculated to locate the bucket index. The hash bucket is traversed to match entries: the key values are compared byte by byte. If a complete match is found, the corresponding node address list (primary node first address + auxiliary node address list) is read. A copy of the address list is returned for use in parallel requests.

[0087] Step 503: Send the search request body to the primary node and the auxiliary node included in the target node group in parallel, and receive the drug circulation data unit returned by each node.

[0088] In this step, the drug circulation data unit refers to the discrete data fragment returned by the blockchain node (such as a single circulation link record); parallel sending refers to initiating network requests to multiple targets at the same time rather than executing them sequentially.

[0089] This embodiment creates an independent thread to send a retrieval request body to each address in the target node group. Each thread is assigned a timeout threshold and retry counter, and a response cache queue is established. When a thread receives a node response, it verifies the protocol header validity, checks the magic number flag and length identifier, and stores the payload in the corresponding queue slot if it passes. The main thread then polls all cache slots and immediately extracts data units when data is ready in any slot. A node is marked as failed if a timeout or retry count is exhausted.

[0090] Step 504: Add a continuity mark to each drug circulation data unit, and merge the associated identifiers in each drug circulation data unit into complete drug source data.

[0091] In this step, the continuity mark is a time stamp number (such as 0001) attached to the front of the data unit; the association identifier is a key field in the data unit that can be used as a basis for merging (such as batch number).

[0092] This embodiment adds a continuity marker to each valid data unit: a globally incremented sequence number (starting at 0001 and incrementing thereafter) is generated based on the reception timestamp. The scanning unit extracts associated identification fields (such as the batch number) and, through an identification value matching algorithm, creates an identification index table, marking units with the same batch number as a similar group. Units in each group are sorted in ascending order based on the continuity marker, and the original byte stream is directly concatenated to form the drug source data, preserving the original field delimiters.

[0093] In order to solve the problem of difficulty in extracting key information caused by the mixed structure of traditional Chinese medicine source data in the prior art, in some embodiments, according to step 104, when the cross-node search request returns drug source data, the drug source data is split into a core attribute set and an extended trajectory set according to the circulation link, including: Step 601: Load the drug source data returned by the cross-node search request into a serialized data block, wherein the serialized data block includes a plurality of fields arranged with predetermined delimiters.

[0094] In this step, serialized data blocks refer to the conversion of drug source data into continuous byte sequence storage units in a specific encoding format; the predetermined delimiter is the physical separation identifier between fields (such as the ASCII value of the semicolon character); and multiple fields contain fragments of information about the entire life cycle of the drug (such as manufacturer and logistics records).

[0095] This embodiment applies for contiguous memory space and writes the drug source data string into the buffer in its original order, inserting a predetermined delimiter byte value at each field boundary. After writing, a terminator is added to form a serialized block. The method scans the source data for natural segmentation points (such as vertical bars in the content) and appends the delimiter after these points. Finally, a terminator is appended to the end of the data block to complete the serialized data block.

[0096] Step 602 : Scan the starting identification prefix of each field. When it is detected that the starting identification prefix of the field is a preset first-category identification prefix, it is regarded as a first-category field and the first-category field is assigned to the core attribute set.

[0097] In this step, the starting identifier prefix refers to a character combination with specific semantics at the beginning of a field (such as "production" representing product information); the first type of identifier prefix is a preset set of core attribute tags (such as {"production", "batch number", "ingredients"}); the core attribute set is a container data structure that stores key product information.

[0098] This embodiment first performs field segmentation on the serialized data block: a new field unit is created each time a delimiter character is encountered. The starting character sequence of each field unit is scanned and checked for a complete match against a pre-stored dictionary of first-category identifier prefixes. If the starting character sequence matches a dictionary entry (e.g., "production"), the complete content of the field is added to the core attribute set memory pool; otherwise, processing continues with subsequent fields. A dictionary tree is used throughout this process to accelerate match detection.

[0099] Step 603: When it is detected that the starting identification prefix of the field is a preset second-category identification prefix, the field is treated as a second-category field and the second-category field is allocated to the extended trace set.

[0100] In this step, the field start character sequence refers to the first N consecutive characters of the field (N is the maximum prefix length).

[0101] This implementation loads a prebuilt second-type prefix trie and truncates the starting character sequence for each field (length = maximum depth of the trie). Starting from the root node of the trie, the process traverses downward character by character. If a character path exists and the termination flag is true, the match is considered successful and the entire field content is immediately appended to the extended trajectory buffer. If the path is interrupted, processing is abandoned. A short-circuit return mechanism is used throughout to avoid scanning invalid characters.

[0102] In order to solve the problem that fixed result templates in the prior art cannot adapt to dynamic query requirements, in some embodiments, according to step 105, a dynamic combination operation is performed on the core attribute set and the extended trajectory set according to the query type to generate a drug traceability result set, and the drug traceability result set is returned to the user terminal, including: Step 701: parse the code tag of the query type and determine the combined operation range according to the code tag.

[0103] In this step, the code tag of the query type refers to a predefined query semantic identifier (e.g., "FULL" represents a full trajectory query); the combined operation scope is a set of scanning constraints determined by the code tag (e.g., "FULL" must include all units in the core attribute set and all valid units in the extended trajectory set).

[0104] This embodiment converts code tags (such as "QT_FULL" entered by the user) into semantic operation rules by querying a preset tag mapping dictionary. These include constraints such as whether the core attribute set must be included and whether the time range of the extended trajectory set must be matched. A dynamic scan path is also generated. When the trajectory set needs to be extended, a bidirectional data channel is established. Otherwise, only the core attribute set reading channel is activated. The final output is an operation range object (including the path switch status and filtering conditions).

[0105] Step 702 : Scan the core attribute set and the extended trajectory set based on the operation scope, wherein the core attribute set includes a basic drug description unit, and the extended trajectory set includes a circulation node record unit.

[0106] In this step, the basic drug description unit is the record entry in the core attribute set that records the static characteristics of the drug (such as ingredients and production date); the circulation node record unit is the entry in the extended trajectory set that records logistics operations (such as warehousing records and delivery timestamps).

[0107] This embodiment first performs a full scan on the core attribute set based on the status mark of the operation scope object, sequentially reads each basic description unit and loads it into the processing queue; then performs a conditional scan on the extended trace set. When the trace mark is activated, all circulation node record units are traversed in timestamp order; if there is a time range constraint, the records that do not meet the requirements are skipped; after the scan is completed, the dataset pointer list (core set pointer queue and extended set pointer queue) is returned for use in subsequent combination operations.

[0108] Step 703: extract all the basic description units of the drug in the core attribute set, and extract the circulation node record units of the extended trajectory set according to the relevance of the query type.

[0109] In this step, association extraction refers to the process of selectively obtaining extended trajectory data based on the matching rules between query type and drug attributes (e.g., associating temperature records based on ingredients).

[0110] This implementation first activates the data flow channel for the core attribute set and uses pointer batch copying technology to capture all basic drug description units at once, importing them directly into a temporary processing area without altering the existing storage structure. Dynamic association analysis is then performed to parse key attribute fields (such as ingredient names) in the current basic drug description unit and generate attribute matching fingerprints. Concurrent scanning threads are then launched within the extended trajectory set. Each thread calculates the similarity between the event type field of the circulation node record unit and the attribute fingerprint. When the similarity exceeds a predefined threshold, the matching circulation node record unit is marked as an associated unit. Finally, all core units and the marked associated trajectory units are merged into the final extraction result set.

[0111] Step 704, create a blank result container, place the basic drug description unit at the starting position of the blank result container, and place the circulation node record unit at the end of the blank result container in ascending order of timestamps to obtain a result container, wherein each basic drug description unit and each circulation node record unit in the result container contains a corresponding type tag.

[0112] In this step, the blank result container is a pre-allocated expandable memory structure (including the start area and the end area); the type tag is a prefix identifier attached to the head of the data unit ("C_" indicates the basic attribute, and "T_" indicates the circulation track) for fast type identification.

[0113] This embodiment first applies for a dynamically expandable memory block as a blank result container (starting at address 0x8000). It then reads the core unit set (e.g., ["ingredient|glucose"]) output in step 703 and writes them sequentially into the container's starting area (starting at address 0x8000) in their original order. It then synchronously sorts the circulation node record units by timestamp, extracting each unit's time field (e.g., "20240520") and converting it into a timestamp value. After sorting in ascending order, the units are written sequentially into the container's tail area (starting at address 0x8080). Each unit is then prepended with a type tag: "C_" for core units and "T_" for track units. After the container is filled, a partition address index table is generated to record the core / track area boundaries.

[0114] Step 705 , scan each drug basic description unit and each circulation node record unit and corresponding type tag in the result container, generate a string unit based on the type tag as a separator, and append a check code to the end of the string unit to form a linear sequence.

[0115] In this step, a string unit is a data segment encapsulation with a type tag (such as "C_ingredient|glucose"); a checksum is a 3-digit verification character generated based on the unit content (such as "KJ8"); and a linear sequence is a chain of string units separated by semicolons (such as "C_...KJ8;T_...X3Q").

[0116] The embodiment of the present application first traverses the memory area of each unit in the result container, scans the type tag prefix ("C_" or "T_") of each unit as a delimiter identifier, and copies the tag and subsequent content to a new buffer to form a basic string unit; then performs a check code calculation on each basic unit, takes the ASCII last digit of the first character of the unit content and concatenates the length value to generate a 3-bit code (zeros are added to any missing digits); then, after appending the check code to the end of the unit, all units are connected with a semicolon to form a continuous linear sequence.

[0117] Board 706 encapsulates the linear sequence into an initial response body, and appends a timestamp identifier and a sequence length identifier to the head of the initial response body to obtain a drug traceability result set.

[0118] In this step, the initial response body is the basic transmission data packet containing the linear sequence; the timestamp identifier is the precise time code of the moment the response is generated; and the sequence length identifier is a statement of the total number of bytes in the linear sequence.

[0119] This embodiment first allocates a network transmission buffer and writes the linear sequence as the data body into the middle of the buffer; then obtains the high-precision system time to generate a timestamp identifier (in the format YYYYMMDDHHMMSS), calculates the number of bytes in the linear sequence to generate a length identifier; then writes the protocol header to the starting area of the buffer, first writing a fixed 16-byte timestamp identifier, then writing an 8-byte sequence length identifier, and finally adding a protocol terminator. The resulting complete buffer is the drug traceability result set.

[0120] Step 707: The drug traceability result set is pushed to the user terminal's receiving interface via a pre-defined transmission channel. In this step, the pre-defined transmission channel refers to a dedicated network link (e.g., MQTT over TLS 1.3) established for the drug traceability service, whose connection parameters (topic path / encryption certificate) are pre-stored in the system; the receiving interface is a pre-defined network socket (IP+port+protocol) on the user terminal.

[0121] This embodiment first loads the pre-stored transmission channel configuration, reads the target subject path, encryption public key and QoS level; then establishes a unidirectional data flow pipeline, initializes the socket connection, loads the digital certificate to verify the terminal identity, negotiates the TLS session key, and then performs frame encapsulation on the drug traceability result set, splits it into equal-sized data frames according to the maximum unit of the transport layer, adds a sequence identifier and terminator to each frame, and then starts the asynchronous push engine. After sending the first frame through the pipeline, the subsequent frame streaming transmission is immediately triggered without waiting for confirmation; when the terminal returns an ACK signal, the pipeline is closed to release resources; if there is no response after the timeout, the exponential backoff retransmission mechanism is triggered.

[0122] Figure 2 The present invention provides a schematic diagram of a system for efficiently querying drug identification information based on a distributed cache. Figure 2 As shown, the system includes: The receiving module 21 is configured to receive a drug identification query request initiated by a user terminal and parse the drug unique code and query type in the drug identification query request; A positioning module 22 is configured to generate a dynamic cache routing key according to the batch characteristics of the unique drug code, and locate a target cache node in a preset distributed cache cluster based on the dynamic cache routing key; A matching module 23 is configured to match the cached data block corresponding to the unique drug code in the target cache node, extract the drug life cycle record in the cached data block if the match is successful, and initiate a cross-node search request to a preset drug blockchain database to return the drug source data if the match fails; A splitting module 24 is configured to split the drug source data into a core attribute set and an extended trajectory set according to the circulation link when the cross-node search request returns the drug source data; The generating module 25 is configured to perform a dynamic combination operation on the core attribute set and the extended trajectory set according to the query type, generate a drug traceability result set, and return the drug traceability result set to the user terminal.

[0123] Figure 2 The drug identification information efficient query system based on distributed cache can be executed Figure 1 The implementation principle and technical effects of the method for efficiently querying drug identification information based on distributed cache described in the illustrated embodiment will not be elaborated on here. The specific manner in which each module and unit performs operations in the above-mentioned embodiment of the system for efficiently querying drug identification information based on distributed cache has been described in detail in the embodiments of the method and will not be elaborated on here.

[0124] In one possible design, Figure 2 The embodiment shown is a drug identification information efficient query system based on distributed cache that can be implemented as a computing device, such as Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32; The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are called and executed by the processing component 32 .

[0125] The processing component 32 is used for the above Figure 1 The embodiment provides an efficient query method for drug identification information based on distributed cache.

[0126] The processing component 32 may include one or more processors to execute computer instructions to complete all or part of the steps in the above method. Of course, the processing component may also be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above method.

[0127] The storage component 31 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0128] Of course, a computing device may also include other components, such as input / output interfaces, display components, communication components, etc.

[0129] The input / output interface provides an interface between the processing component and the peripheral interface module, which can be an output device, an input device, etc.

[0130] The communication component is configured to facilitate, among other things, wired or wireless communications between the computing device and other devices.

[0131] Among them, the computing device can be a physical device or an elastic computing host provided by a cloud computing platform, etc. In this case, the computing device can refer to a cloud server, and the above-mentioned processing components, storage components, etc. can be basic server resources rented or purchased from the cloud computing platform.

[0132] The present application also provides a computer storage medium storing a computer program, wherein the computer program can achieve the above-mentioned Figure 1 The illustrated embodiment provides an efficient query method for drug identification information based on distributed cache.

[0133] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0134] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0135] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the essence of the above technical solution, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for causing a computer device (such as a personal computer, server, or network device) to execute the methods described in each embodiment or certain portions of the embodiments.

[0136] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. An efficient query method for drug identification information based on distributed cache, characterized in that: include: Receive a drug identification query request initiated by a user terminal, and parse the drug unique code and query type in the drug identification query request; Generate a dynamic cache routing key according to the batch characteristics of the unique code of the drug, and locate a target cache node in a preset distributed cache cluster based on the dynamic cache routing key; Match the cache data block corresponding to the unique code of the drug in the target cache node. If the match is successful, extract the drug life cycle record in the cache data block. If the match fails, initiate a cross-node search request to the preset drug blockchain database to return the drug source data; When a cross-node search request returns drug source data, the drug source data is split into a core attribute set and an extended trajectory set according to the circulation link; A dynamic combination operation is performed on the core attribute set and the extended trajectory set according to the query type to generate a drug traceability result set, and the drug traceability result set is returned to the user terminal.

2. The method according to claim 1, characterized in that Receive a drug identification query request initiated by a user terminal, and parse the drug unique code and query type in the drug identification query request, including: receiving, by a receiving device, a drug identification query request transmitted from a user terminal, and temporarily storing the drug identification query request in a temporary buffer; Extract the request body structure from the temporary buffer and disassemble the request body structure into multiple independent parts; In each independent part, positioning the drug unique code part and the query type part according to a predetermined position rule; A fixed-length character sequence is extracted from the drug unique code portion as the drug unique code, and a content value is extracted from the query type portion as the query type.

3. The method according to claim 1, characterized in that Generating a dynamic cache routing key according to the batch characteristics of the unique drug code, and locating a target cache node in a preset distributed cache cluster based on the dynamic cache routing key, including: Stripping the continuous subsequence containing batch characteristics from the drug's unique coding sequence; The last two digits of the current system millisecond value are appended to the batch feature subsequence as a distribution factor to form a dynamic cache routing key; Convert each character of the dynamic cache routing key into an ASCII code value in sequence and sum them up, perform a modulo operation on the sum result and the total number of preset virtual nodes to obtain a virtual node identifier; According to a preset node allocation table, a physical node address mapped to the virtual node identifier is determined, and the physical node is used as a target cache node.

4. The method according to claim 1, wherein Match the cache data block corresponding to the unique code of the drug in the target cache node. If the match is successful, extract the drug life cycle record in the cache data block, including: Calculate the location index of the target segment based on the batch characteristic segment of the unique code of the drug; Perform a scan operation on the mapping entry set of the target sharding area and obtain the corresponding storage location identifier by matching the encoding segments; Locating and reading a cache data block in a block storage area according to the storage location identifier; A hierarchical structure conversion operation is performed on the cached data block to generate a full life cycle record of the drug.

5. The method according to claim 1, wherein If the match fails, a cross-node search request is initiated to the preset drug blockchain database to return the drug source data, including: When the target cache node does not match the cache data block corresponding to the drug's unique code, a blockchain search request body is generated based on the structural characteristics of the drug's unique code; Query the node location index table based on the predetermined segment content of the drug's unique code to determine the location identifier set of the target node group; Sending a search request body to the primary node and auxiliary nodes included in the target node group in parallel, and receiving the drug circulation data unit returned by each node; Add a continuity mark to each drug circulation data unit, and merge the associated identifiers within each drug circulation data unit into complete drug source data.

6. The method according to claim 1, characterized in that When a cross-node search request returns drug source data, the drug source data is split into a core attribute set and an extended trajectory set according to the circulation link, including: Loading the drug source data returned by the cross-node search request into a serialized data block, wherein the serialized data block includes a plurality of fields arranged with a predetermined delimiter; Scan the starting identification prefix of each field, and when it is detected that the starting identification prefix of the field is a preset first-class identification prefix, treat it as a first-class field and assign the first-class field to the core attribute set; When it is detected that the starting identification prefix of the field is a preset second-category identification prefix, it is regarded as a second-category field and the second-category field is allocated to the extended track set.

7. The method according to claim 1, characterized in that Performing a dynamic combination operation on the core attribute set and the extended trajectory set according to the query type to generate a drug traceability result set, and returning the drug traceability result set to the user terminal, including: Parse the code tag of the query type and determine the scope of the combined operation according to the code tag; Scanning a core attribute set and an extended trajectory set based on the operation scope, wherein the core attribute set includes a basic drug description unit, and the extended trajectory set includes a circulation node record unit; Extract all the basic description units of the drug in the core attribute set, and extract the circulation node record units of the extended trajectory set according to the relevance of the query type; Create a blank result container, place the basic drug description unit at the beginning of the blank result container, and place the circulation node record units at the end of the blank result container in ascending order of timestamps to obtain a result container, wherein each basic drug description unit and each circulation node record unit in the result container contains a corresponding type tag; Scan each drug basic description unit and each circulation node record unit and corresponding type mark in the result container, generate a character string unit according to the type mark as a separator, and append a check code to the end of the character string unit to form a linear sequence; Encapsulating the linear sequence into an initial response body, and appending a timestamp identifier and a sequence length identifier to the header of the initial response body to obtain a drug traceability result set; The drug traceability result set is pushed through the preset transmission channel and transmitted to the receiving interface of the user terminal.

8. An efficient drug identification information query system based on distributed cache, characterized in that: include: A receiving module, configured to receive a drug identification query request initiated by a user terminal and parse the drug unique code and query type in the drug identification query request; A positioning module, configured to generate a dynamic cache routing key according to the batch characteristics of the unique drug code, and locate a target cache node in a preset distributed cache cluster based on the dynamic cache routing key; A matching module is configured to match the cached data block corresponding to the unique drug code in the target cache node, extract the drug life cycle record in the cached data block if the match is successful, and initiate a cross-node search request to a preset drug blockchain database to return the drug source data if the match fails; A splitting module, configured to split the drug source data into a core attribute set and an extended trajectory set according to the circulation link when a cross-node search request returns the drug source data; A generation module is used to perform a dynamic combination operation on the core attribute set and the extended trajectory set according to the query type, generate a drug traceability result set, and return the drug traceability result set to the user terminal.

9. A computing device, characterized in that It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement an efficient query method for drug identification information based on distributed cache as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that A computer program is stored, and when the computer program is executed by a computer, an efficient query method for drug identification information based on distributed cache as described in any one of claims 1 to 7 is implemented.

Images