A short link suffix high-strength random generation method and system for equity delivery

Abstract

The application provides a short link suffix high-strength random generation method and system for benefit delivery, relates to the technical field of data processing and benefit delivery, and comprises the following steps: acquiring a true random number sequence through a hardware physical entropy source, and generating a random string as a short link suffix according to a mapping rule of the true random number sequence and a preset character set; performing hash calculation on the short link suffix to obtain a corresponding first hash value; converting the first hash value into an integer value; acquiring a current available database shard identifier set based on a preset shard configuration strategy, and then calculating a corresponding combined weight value based on the integer value and each database shard identifier in the database shard identifier set. The application can solve the security defects of software pseudo-random generation of short link suffixes, realize storage load balancing and intelligent resource allocation, and guarantee the real-time nature of benefit cancellation.

Description

Technical Field

[0001] This invention relates to the field of data processing and rights delivery technologies, and in particular to a method and system for generating high-strength random short link suffixes for rights delivery. Background Technology

[0002] With the popularization of mobile internet and the deepening of digital transformation, digital benefits, due to their convenient access and usage, have been widely applied in e-commerce, finance, and lifestyle services. Short links, with their advantages of easy dissemination and storage, have gradually become the core carrier for delivering digital benefits, effectively improving user experience and efficiency by simplifying the access path.

[0003] However, existing short link technologies for rights delivery generally suffer from the following technical flaws: insufficient security in the short link suffix generation mechanism. For example, most current mainstream solutions rely on software pseudo-random algorithms to generate short link suffixes. The random sequences generated by such algorithms have low security entropy and strong regularity, making them vulnerable to attackers who can predict the short link suffix through brute-force attacks or pattern recognition, thereby obtaining associated rights information.

[0004] This flaw can lead to the following consequences: the predictability of short link suffixes exposes rights to the risk of unauthorized misuse. Attackers can crack short links and claim or use rights without authorization, causing direct economic losses to rights issuers and legitimate users. Furthermore, some solutions, in order to reduce the risk of cracking, adopt overly simplistic storage architecture designs without optimizing for the query characteristics of short links. This results in increased latency in the mapping query response between short links and rights information, seriously affecting the real-time performance of rights redemption scenarios and reducing the user's rights usage experience. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a method and system for generating high-strength random short link suffixes for rights delivery. This method can solve the security defects of pseudo-random generation of short link suffixes by software, achieve storage load balancing and intelligent resource allocation, and ensure the real-time performance of rights revocation.

[0006] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0007] Firstly, a method for generating high-intensity random short link suffixes oriented towards equity delivery, the method comprising:

[0008] Step 1: Obtain a true random number sequence through a hardware physical entropy source, and generate a random string as a short link suffix according to the mapping rules between the true random number sequence and the preset character set;

[0009] Step 2: Perform a hash calculation on the short link suffix to obtain the corresponding first hash value;

[0010] Step 3: Convert the first hash value into an integer value;

[0011] Step 4: Based on the preset sharding configuration strategy, obtain the set of currently available database sharding identifiers, and then calculate the corresponding combined weight value based on the integer value and each database sharding identifier in the set of database sharding identifiers.

[0012] Step 5: Compare all the calculated combined weight values, and determine the storage location identifier of the short link suffix as the database shard identifier and the associated data table shard identifier corresponding to the maximum value.

[0013] Step 6: Based on the storage location identifier, establish and store the mapping relationship between the short link suffix and the corresponding rights and interests information in the distributed database;

[0014] Step 7: Synchronously store the short link suffix and the established mapping relationship between the short link suffix and the corresponding rights information to a multi-level caching architecture to support efficient querying and access during rights redemption.

[0015] Secondly, a high-strength random generation system for short link suffixes oriented towards equity delivery includes:

[0016] The sequence acquisition and suffix generation module is used to acquire a true random number sequence through a hardware physical entropy source, and generate a random string as a short link suffix according to the mapping rules between the true random number sequence and a preset character set;

[0017] The hash value calculation and integer value conversion module is used to perform hash calculation on the short link suffix to obtain the corresponding first hash value; at the same time, the first hash value is converted into an integer value.

[0018] The weight value calculation module is used to obtain the currently available set of database shard identifiers according to the preset sharding configuration strategy, and then calculate the corresponding combined weight value based on the integer value and each database shard identifier in the set of database shard identifiers.

[0019] The weight value comparison and location identifier determination module is used to compare all calculated combined weight values ​​and determine the database shard identifier and associated data table shard identifier corresponding to the maximum value as the storage location identifier of the short link suffix.

[0020] The mapping relationship establishment module is used to establish and store the mapping relationship between short link suffixes and corresponding rights information in the distributed database based on the storage location identifier.

[0021] The synchronous storage module is used to synchronously store the short link suffix and the mapping relationship between the established short link suffix and the corresponding rights information to a multi-level cache architecture to support efficient querying and access during rights reimbursement.

[0022] The above-described solution of the present invention has at least the following beneficial effects:

[0023] Because it employs a hardware physical entropy source to obtain truly random number sequences to generate short link suffixes, it overcomes the security flaws of existing short link suffix software that uses pseudo-random generation, thus effectively preventing brute-force attacks and predictions, and ensuring that rights information is not illegally obtained. Because it uses intelligent weight allocation technology based on database shard health, it overcomes the problem of unbalanced storage load caused by fixed hash sharding not taking into account real-time health status, thus achieving intelligent optimization and allocation of storage resources and improving storage stability. Because it uses multi-level caching synchronous storage technology that maps short links to rights information, it overcomes the problems of inefficient mapping queries and high database pressure, thus ensuring the real-time nature of rights redemption and improving the user experience. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a method for generating high-strength random short link suffixes for benefit delivery, provided by an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of a short link suffix high-strength random generation system for rights delivery provided by an embodiment of the present invention. Detailed Implementation

[0026] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0027] like Figure 1 As shown, embodiments of the present invention propose a method for generating high-strength random short link suffixes for benefit delivery, the method comprising the following steps:

[0028] Step 1: Obtain a true random number sequence through a hardware physical entropy source, and generate a random string as a short link suffix according to the mapping rules between the true random number sequence and the preset character set;

[0029] Step 2: Perform a hash calculation on the short link suffix to obtain the corresponding first hash value;

[0030] Step 3: Convert the first hash value into an integer value;

[0031] Step 4: Based on the preset sharding configuration strategy, obtain the set of currently available database sharding identifiers, and then calculate the corresponding combined weight value based on the integer value and each database sharding identifier in the set of database sharding identifiers.

[0032] Step 5: Compare all the calculated combined weight values, and determine the storage location identifier of the short link suffix as the database shard identifier and the associated data table shard identifier corresponding to the maximum value.

[0033] Step 6: Based on the storage location identifier, establish and store the mapping relationship between the short link suffix and the corresponding rights and interests information in the distributed database;

[0034] Step 7: Synchronously store the short link suffix and the established mapping relationship between the short link suffix and the corresponding rights information to a multi-level caching architecture to support efficient querying and access during rights redemption.

[0035] In this embodiment of the invention, the truly random short link suffix generated by the hardware physical entropy source possesses high security and unpredictability, effectively preventing brute-force attacks and predictive attacks, thus strengthening the security defense line for rights and interests information. Combining the database sharding health status calculation with weighted allocation of storage locations balances storage load and improves resource utilization efficiency, making the storage architecture more stable. Multi-level caching synchronizes storage mapping relationships, not only quickly responding to rights and interests revocation queries but also effectively reducing database load, ensuring the real-time use of rights and interests, and further optimizing the user experience.

[0036] In a preferred embodiment of the present invention, step 1 above may include:

[0037] Step 1.1 involves acquiring raw random signals from hardware physical entropy sources. This includes: prioritizing hardware physical noise sources with high stability and naturally irregular characteristics, with selection criteria including the unpredictability of the noise signal, anti-interference ability, and output stability; simultaneously using at least two different types of auxiliary noise sources to form a multi-source complementary noise acquisition system to ensure the diversity of random signal sources; employing a time-series synchronous acquisition method to capture raw analog signals at fixed time intervals, blocking external electromagnetic interference paths during acquisition using signal isolation technology, and shielding the acquisition link to prevent environmental noise from mixing with the raw signal; and performing a standardization conversion on the acquired analog signals to transform physical quantities such as voltage fluctuations and delay differences into initial digital signals of a unified format, forming a continuous, irregular, and pure raw random signal stream.

[0038] Step 1.2 involves entropy estimation and mixing of the original random signal to obtain mixed random data. Specifically, this includes: determining a fixed-duration time window based on the generation frequency and data density of the original random signal to ensure that the amount of signal data within each window meets the requirements for randomness assessment; segmenting the original random signal stream according to the window so that the signal within each window constitutes an independent analysis unit; performing an entropy estimation process on the signal data of each unit: counting the frequency of occurrence of all unique values ​​within the unit, dividing the frequency of occurrence of each value by the total amount of data in the unit to obtain the probability of occurrence of the corresponding value; quantifying the uncertainty of the unit based on these probabilities to form the entropy value of the signal segment, which serves as the core indicator for measuring randomness quality; and combining the uniformity of numerical distribution, the correlation between adjacent data, and abrupt change characteristics to form a multi-dimensional randomness assessment result.

[0039] A clear entropy security threshold is set, referencing commonly used cryptographic standards, not less than 7.5 bits / byte. Valid signal segments with acceptable entropy values ​​and other random characteristics are selected, while low-quality signal segments with insufficient entropy, unbalanced distribution, or strong correlation are directly eliminated. Fusion weights are assigned based on the entropy results of each noise source signal segment: higher entropy values ​​represent better random quality, and correspondingly, a higher weight ratio. A reasonable weight range of 0.2 to 0.5 is first defined, and the noise source with the highest entropy value is assigned the highest weight within this range. The remaining noise sources are then assigned corresponding weights according to their entropy ratios. After allocation, the sum of the weights of all noise sources is uniformly calibrated to 1 to ensure the scientific and standardized nature of the weight allocation.

[0040] Timestamp calibration is performed on each effective signal segment: using the timestamp of the noise source signal with the highest entropy and strongest stability as a benchmark, the time deviation of other signal segments is corrected to ensure that the time granularity of all effective signal segments is completely consistent, achieving precise alignment at the same time node; during the weighted summation operation, the original signal values ​​of each effective signal segment at the same time node are first extracted, and then each value is multiplied by the assigned weight of its respective noise source to obtain the weighted value corresponding to each signal value; then, the weighted values ​​of all signals at the same time node are accumulated to obtain the single fused value at that time node; the weighted accumulation operation of all time nodes is completed sequentially in chronological order, and all fused values ​​are integrated to form a continuous data stream. Through the complementary fusion of multi-source signals, the implicit patterns that may exist in a single signal source are broken, ultimately forming mixed random data with more complex randomness and more uniform distribution.

[0041] Step 1.3 involves post-processing the mixed random data to generate a true random number sequence that meets cryptographic security requirements. This includes: performing refined frequency balancing on the mixed random data; first, dividing the data into reasonable intervals based on numerical values, grouping values ​​within the same interval into the same type to avoid bias caused by single-value statistics; then, statistically analyzing the occurrence frequency of values ​​in each interval, calculating the average frequency across all intervals based on the total data volume, and adjusting the average frequency to ensure the rationality of the statistical benchmark, considering the dispersion of data distribution in each interval; and finally, adjusting intervals whose occurrence frequency exceeds a multiple of the average frequency using a combination of equivalent replacement and random interpolation: first, selecting values ​​from low-frequency intervals that have similar characteristics to those from high-frequency intervals to replace some high-frequency values; then, based on the distribution patterns of values ​​in adjacent intervals, generating a small number of new values ​​that conform to overall randomness and inserting them into high-frequency intervals. This reduces the proportion of high-frequency values ​​without introducing new patterns, ultimately making the distribution of all types of values ​​more uniform and completely eliminating data bias.

[0042] A multi-round unidirectional iterative process is employed to enhance data randomness. The iteration rounds are determined based on the entropy value of the first round, ensuring that the final entropy value meets cryptographic security standards. The first round uses the debiased mixed data as input and performs a unidirectional transformation based on data position permutation and numerical nonlinear offset: first, the data arrangement is randomly shuffled, and then each value is slightly and irregularly offset to ensure that the transformed value cannot be used to deduce the original data, outputting the intermediate result of the first round. Subsequent rounds use the intermediate result of the previous round as input, focusing on enhancing the local irregularity of the data, such as randomly splitting consecutively repeating numerical segments and dispersing densely distributed numerical regions. After each iteration, a simple randomness check is performed, such as detecting the correlation between adjacent values, to avoid data regularity degradation. Through a multi-round iterative signal feature amplification mechanism, the unpredictability of the data is continuously enhanced, ultimately generating a true random number sequence that meets cryptographic security standards. This sequence not only cannot deduce subsequent data from known segments, but also does not have any repeatable regular patterns, and its entropy value is stable above the preset security threshold.

[0043] Step 1.4 converts the true random number sequence into the corresponding integer value. Specifically, this includes: first, performing a format feature check on the true random number sequence. By identifying the character composition, encoding identifier, and data delimiter of the sequence, it is determined whether its original format is binary stream or hexadecimal. If it is a binary stream, the sequence is equally divided into fixed byte lengths. After division, an integrity check is performed on each unit to ensure no data loss or misalignment. For each binary unit, the value is read bit by bit from high to low, and a corresponding bit weight is assigned to each value. By accumulating the product of each value and its bit weight, the binary to decimal integer conversion is completed. The numerical conversion process is as follows: If the format is hexadecimal, redundant characters such as spaces and newlines are first removed from the sequence by character feature identification, retaining only valid hexadecimal characters from 0 to 9 and AF (case-compatible). Then, the sequence is grouped according to a fixed number of characters. If the total number of characters is insufficient for the grouping standard, zeros are added to the end of the sequence to adapt. Each group of valid characters is converted into a corresponding 4-bit binary number, and the two groups are concatenated to form a complete binary sequence. The conversion is then completed according to the weighted summation rule for binary to decimal conversion. Finally, all the converted integer values ​​are concatenated in the order of the original true random number sequence to form a continuous and complete integer value sequence that retains the original randomness characteristics.

[0044] Step 1.5: Based on the total number of characters in the preset character set, perform a modulo operation on the integer value to obtain the target character index, and select the corresponding character from the preset character set according to the target character index. Specifically, this includes: designing the preset character set according to the dual principles of security and compatibility. For security, select character types that are difficult to guess and have no obvious patterns, covering uppercase letters, lowercase letters, numbers, and commonly used compliant symbols. For compatibility, remove easily confused characters (such as O and 0, I and 1) and characters that cannot be displayed correctly in special environments. After forming a standardized character set, count and record the total number of characters; for each obtained integer... For numerical values, first determine if they are negative. If negative, calculate a compensation value based on the total number of characters in the character set, and convert the value to a non-negative value by accumulating the compensation value. Perform a modulo operation on the non-negative value, and the result is the target character index. The index value is strictly limited to the legal range of 0 to the total number of characters in the character set minus 1. Construct an index mapping table for the preset character set in a fixed order. Query the mapping table through the target character index to accurately locate and extract the corresponding single character. During the extraction process, simultaneously verify the matching consistency between the index and the character to ensure that the character selection is completely synchronized with the randomness of the original true random number and does not destroy the original random characteristics.

[0045] Step 1.6 adds the selected corresponding characters to the temporary character sequence, specifically including: constructing a temporary character sequence container based on an ordered storage mechanism: adopting a linear storage structure with pre-allocated contiguous memory, reserving sufficient space in advance according to the preset length of the short link suffix, reducing the expansion overhead of subsequent append operations, and ensuring storage efficiency and order stability from the underlying structure; this container only allows operation permissions to append characters in the order of generation, strictly disabling intermediate insertion, deletion or modification functions, and preventing the sequence order from being disrupted from the permission level; after each character is extracted from the preset character set, an independent character storage unit is immediately created, which contains three core fields: first, the character body field, which stores the extracted original character; second, the traceability information field, which records the character's generation timestamp accurate to the millisecond level, the random signal batch number to which it belongs, and the sequence number; and third, the verification field, which generates a verification code through simple character encoding verification rules to verify the integrity of character storage.

[0046] A tail pointer positioning mechanism is maintained through atomic operations to ensure the accuracy of tail pointer updates in high-concurrency scenarios and avoid character appending anomalies caused by pointer errors. Before each append, the end position of the container is directly located through the tail pointer, without traversing the entire container, thus controlling the time complexity of the character appending operation to O(1). The newly created storage unit is directly mounted to the end position pointed to by the tail pointer, and the tail pointer is updated synchronously to the new end, completing the orderly appending of characters. Throughout the appending process, detailed operation logs are recorded synchronously, including operation time, operation thread identifier, character value, storage unit address, and check code, achieving full traceability. At the same time, through read and write permission separation control, only the generation thread is allowed to perform append operations, while other threads can only read data. Combined with the check code, the storage unit data is verified in real time to prevent characters from being illegally tampered with or replaced, ensuring that the temporary character sequence completely retains the order of character generation logic, does not change the character arrangement characteristics brought about by the original randomness, and guarantees the randomness and integrity of the sequence.

[0047] Step 1.7: Determine whether the length of the temporary character sequence has reached the preset length. If not, continue to collect the next set of original random signals from the hardware physical entropy source, and sequentially perform entropy estimation and mixing, post-processing, conversion to integer values, modulo operation, and character selection on the next set of original random signals. At the same time, add the obtained new characters to the temporary character sequence until the length of the temporary character sequence reaches the preset length. If it has reached the preset length, output the temporary character sequence as the final short link suffix. Specifically, this includes: adopting a dual-mode design of basic length + dynamic expansion, comprehensively evaluating the preset length of the short link suffix; at the security level, calculating the security entropy value corresponding to different lengths, and combining the brute-force attack protection level of the rights delivery scenario, determining the basic security length, such as 16 bits, to ensure that its security entropy value meets the minimum anti-cracking requirements; at the usage scenario level, limiting the upper limit of the basic length based on user propagation habits, input convenience, and network transmission efficiency; and reserving a dynamic expansion mechanism, automatically expanding the length according to a preset gradient, such as increasing by 2 bits each time, when the risk of short link duplication is detected to increase or the security level is improved, balancing security and user experience.

[0048] A real-time counting mechanism combining cache counting and periodic calibration is used to count the current number of characters in the temporary character sequence. An atomic counting field is maintained in the container. After each character appending, the count value is updated synchronously through atomic increment operations, allowing for quick acquisition of the current character count without traversing the container. Every 10 characters appended, a full calibration is performed, comparing the storage unit numbers of the container with the counting field to ensure counting accuracy and avoid counting deviations in concurrent scenarios. The real-time counting result is accurately compared with a preset length (basic length or expanded length). If the current character count has not reached the preset length, a random signal acquisition restart command is automatically triggered, and the complete process from steps 1.1 to 1.6 is re-executed. Newly generated characters are appended to the temporary character sequence in sequence, and the continuity of the new character's sequential number with the end number of the existing sequence is checked during appending to avoid numbering gaps.

[0049] If the current number of characters has reached the preset length, the termination process is initiated immediately: First, all write operations to the temporary character sequence container are frozen, prohibiting the appending of new characters; then, the temporary character sequence is traversed according to the order in which the characters were generated, and characters in each storage unit are extracted sequentially. During the extraction process, the checksum and sequential number of the characters are checked simultaneously to ensure that no characters are missing, out of order, or corrupted; all extracted characters are concatenated in order to generate a complete character sequence, and the overall checksum of the sequence is calculated and stored for integrity verification when the short link is used subsequently; finally, a resource release operation is performed, the random signal acquisition link is closed, the redundant memory occupied by the temporary character sequence container is released, the operation log and traceability information are archived, and the entire short link suffix generation process is completed; the final character sequence has high security, uniqueness, and unpredictability, and can be directly used as a short link suffix.

[0050] In this embodiment of the invention, to balance security and availability, the default preset length of the short link suffix is ​​16 characters. Unless otherwise specified, the short link suffix mentioned below refers to a random string generated by this preset length, which can be dynamically adjusted according to the actual security level and business needs.

[0051] In a preferred embodiment of the present invention, step 2 above may include:

[0052] Step 2.1: Receive the short link suffix as input data for hash calculation. Specifically, this includes: receiving the generated final short link suffix, which conforms to a preset character set, containing 24 uppercase letters, 24 lowercase letters, 10 numbers, and 8 compliant symbols, with easily confused characters such as O and l removed, and a random string that meets the length requirement; during the receiving process, first verify the validity of the suffix format by matching each character against the preset character set. If an illegal character outside the set is detected, the verification is directly determined to have failed; then verify the length integrity, confirming that the suffix length is completely consistent with the preset base length or the expanded length, with no missing or redundant characters; if both verifications pass, the suffix is ​​used as the sole input data for hash calculation; if the verification fails, an error message is returned and steps 1.1 to 1.7 are re-executed to ensure the validity and standardization of the input data.

[0053] Step 2.2 involves encoding the input data into a unified byte sequence format. Specifically, this includes: converting the received short link suffixes into a unified byte sequence format using the UTF-8 encoding standard. This encoding format is compatible with all character types in the suffix and has good cross-platform adaptability. During encoding, the short link suffixes are read character by character. First, the Unicode code point corresponding to each character is obtained, and then the number of bytes required for encoding is determined based on the code point range, ranging from 1 to 4 bytes. Characters with code points in the range U+0000 to U+007F are encoded using 1 byte, with the format being 0. Characters with code points in the range U+0080 to U+07FF are encoded using 2 bytes, with the format 110xxxxx, 10xxxxxx; characters with code points in the range U+0800 to U+FFFF are encoded using 3 bytes, with the format 1110xxxx, 10xxxxxx, 10xxxxxx; characters with code points in the range U+10000 to U+10FFFF are encoded using 4 bytes, with the format 11110xxx, 10xxxxxx, 10xxxxxx, 10xxxxxx. The binary bits of the code points are filled into the encoding template according to the corresponding format to generate the byte representation of each character. The byte data of all characters are then concatenated to form a complete byte sequence. After encoding, the integrity of the byte sequence is checked to ensure that multi-byte characters are not truncated and that the total number of bytes is consistent with the calculation result of the character encoding rules, avoiding data distortion due to encoding differences.

[0054] Step 2.3: Select a preset secure hash algorithm and perform a one-way hash calculation on the byte sequence. Specifically, this includes: selecting SHA-256 as the preset secure hash algorithm based on cryptographic security requirements. This algorithm has strong collision resistance and high security, which can effectively ensure the uniqueness and non-forgeability of the hash result, and is suitable for the core requirements of data integrity and anti-tampering in the rights delivery scenario. When performing a one-way hash calculation on the converted byte sequence, message padding is first performed: a 1-bit stop marker is added to the end of the byte sequence, and then 0 bits are continuously added until the remainder of the padded sequence length modulo 512 is 448. Finally, the total length of the original byte sequence is appended to the end of the sequence in the form of a 64-bit binary number to ensure that the final padded sequence length is an integer multiple of 512 bits, which meets the format requirements of the algorithm processing.

[0055] The completed sequence is divided into several independent groups of 512 bits each, and each group is further divided into 16 32-bit message words. Then, the message word expansion process is started to generate another 48 32-bit extended message words. For each extended message word to be generated, the 16th, 14th, 8th and 3rd existing message words before it are selected. Different preset bit shift operations are performed on these four message words, such as 7 bits, 18 bits, 9 bits and 14 bits. Then, the four shifted results are sequentially subjected to combined bit operations such as XOR, AND and OR. Finally, the operation result is added to a fixed constant, and the result is kept to 32 bits by overflow truncation mechanism to obtain a new extended message word. This logic is iterated until 48 extended message words are generated, which together with the original 16 message words form a complete processing set of 64 32-bit message words.

[0056] Eight 32-bit initial base values ​​were determined according to cryptographic standards, derived from the recognized prime number correlation properties in cryptography. These eight base values ​​were assigned to eight independent working variables as the initial state for iterative operations. Then, for each group of 64 message words, 64 consecutive rounds of iterative processing were performed: In each round, the message word and eight working variables corresponding to the current round were retrieved. Five of the working variables were then cyclically shifted by a preset number of bits. The shifted result was then combined with the remaining working variables, the current message word, and a fixed constant specific to the round through multiple rounds of XOR, AND, and OR operations. During the operations, modulo 2 operations were performed on the 32-bit length. 32 The addition process updates the values ​​of the eight working variables. After all grouping processes are completed, the eight working variables are concatenated in sequence to form a complete hash calculation result.

[0057] Step 2.4: Obtain the original hash value from the one-way hash calculation output. Specifically, this includes: after the hash calculation is completed, extracting the original hash value from the output result. This original hash value is a fixed-length binary array with a total length of 256 bits (32 bytes), composed of eight 32-bit hash segments H0 to H7 concatenated sequentially. During the extraction process, the complete binary data stream is directly obtained through the output interface to avoid data truncation or modification in the intermediate stages. After obtaining the data, an integrity check is immediately performed: first, check whether the length of the binary array is strictly equal to 32 bytes; if the length does not match, the data is considered abnormal. Then, calculate the byte checksum of the array, sum the values ​​of all bytes, and compare it with the preset check benchmark value to ensure that the data is not damaged or tampered with. After the check passes, the original hash value in binary array form is temporarily stored for subsequent format conversion. If the check fails, the hash calculation process in Step 2.3 is re-executed.

[0058] Step 2.5 converts the obtained original hash value into a fixed-length hexadecimal string, which serves as the first hash value. Specifically, this involves: converting the original hash value into a fixed-length hexadecimal string; before conversion, constructing a binary-to-hexadecimal mapping table to define the correspondence between 4-bit binary numbers and their corresponding hexadecimal characters, i.e., 0000 corresponds to 0, 0001 corresponds to 1…1010 corresponds to A, 1011 corresponds to B…1111 corresponds to F; during conversion, read each byte of the original hash value sequentially, splitting each byte into two half-words: the high 4 bits and the low 4 bits. Each byte is processed by querying the mapping table to obtain the corresponding hexadecimal character. For example, the binary representation of a byte is 10110010, which is split into 1011 and 0010, corresponding to the hexadecimal characters B and 2. All 32 bytes are processed sequentially, and the resulting 64 hexadecimal characters are concatenated in order and presented in uppercase to form a hexadecimal string of fixed length of 64 characters. After conversion, the string is validated to ensure that it contains only characters 0-9 and AF and has a length of 64 bits. This string is the first hash value used for subsequent storage sharding calculations.

[0059] In a preferred embodiment of the present invention, step 3 above may include:

[0060] Step 3.1, receiving the first hash value as the input string, specifically includes: receiving the first hash value, which is a 64-character uppercase hexadecimal string containing only legal characters 0-9 and AF, and having a unique mapping relationship with the short link suffix (16 characters in this embodiment) and the parent product's unique ID; upon receiving, a triple verification mechanism is initiated: first, format verification, comparing each character against the legal hexadecimal character set, eliminating illegal characters such as lowercase letters and special symbols; second, length verification, confirming through character counting that the string length is strictly equal to 64 characters, with no missing or redundant characters; third, association verification, querying whether the parent product ID corresponding to the hash value exists in the system's parent-child product model to ensure the validity of data binding; after passing the verification, the input string is stored in a read-only temporary cache area to prevent tampering; if the verification fails, a prompt message containing the error type, including format, length, and association errors, is returned, and the hash calculation process in step 2 is triggered to be re-executed to ensure that the input data is completely compliant.

[0061] Step 3.2 involves dividing the input string into multiple substrings of equal length and converting each substring into its corresponding integer component. Specifically, based on the correlation of equity data dimensions and the requirement for uniformity in subsequent sharding, the length of each substring is determined to be 16 characters. Following the principle of left-to-right, continuous, and non-overlapping substrings, the 64-character input string is evenly divided into four 16-character substrings of equal length, preserving the original character order of each substring and maintaining the randomness of the hash value. Before conversion, a standard hexadecimal-to-decimal mapping table is constructed, such as 0-9 corresponding to 0-9 and AF corresponding to 10-15. A precise digit-by-digit conversion is performed on each substring: starting from the leftmost high-order digit of the substring, the... k Bit( k The weights (counting from 0) are The decimal values ​​corresponding to the characters are multiplied by their weights and then summed to obtain the decimal integer component of each substring. The four substrings correspond to four independent components, which are sequentially associated with the parent product ID hash fragment, the sub-product set identifier, the rights status code, and the generated timestamp hash fragment, ensuring a strong binding between the components and the rights data. After conversion, the value range of each component is verified to be (0, 16). 16 -1), to avoid numerical overflow, and fully inherit the randomness and uniqueness of the first hash value.

[0062] Step 3.3 combines multiple integer components into a coordinate point in a multi-dimensional space. Specifically, this includes: accurately binding the four obtained integer components to the core business attributes of the rights and interests according to the left-to-right order of the substring segmentation, and defining them sequentially in the 4-dimensional space. x , y , z , w Coordinate components: x Each component corresponds to the last 16 bits of the SHA-256 hash of the parent product's unique ID, ensuring a unique association with the parent product ID in the parent-child product model. y Each component corresponds to a unique hash fragment representing a set of sub-products. This identifier is generated by hashing a list of sub-product IDs and uniquely maps to a set of sub-products. z The component corresponds to the hash mapping value of the equity status code. The equity status of unused, used, and expired is mapped to different basic values ​​and then hashed, which preserves the status characteristics and has randomness. w The hash fragment of the timestamp corresponding to the rights and benefits generation ensures that rights and benefits generated at different times under the same parent product can be distinguished.

[0063] by( x , y , z , w The standardized structured format combines four components to form a unique coordinate point in four-dimensional space: on the one hand, xThe weight originates from the hash of the parent product ID, relying on the system's uniqueness of the parent product ID as its foundation; on the other hand, w The components are integrated with timestamp hashes to avoid duplicate coordinate points for different batches of benefits under the same parent product. Combined with the uniqueness of the hash value itself, this achieves triple uniqueness assurance: unique business attribute of the coordinate point + unique time dimension + unique random feature, ensuring no duplication is possible. During the combination process, dual association and verification are performed: first, dimension and attribute mapping verification, checking the binding relationship between each coordinate component and its corresponding benefit attribute, such as... x The component must match the hash rule of the parent product ID. z First, the components must conform to the rights and interests status coding mapping specification to avoid dimension misalignment; second, parent product association verification confirms that the associated parent product ID exists in the parent-child product model and that the status is valid, ensuring that the coordinate points are linked to real business data; simultaneously, a coordinate point association mapping table is generated to record... x Parent product ID hash fragment y Sub-product collection identifier, z Rights status code, w Generate a mapping relationship for timestamp hashes, and establish a bidirectional association between this mapping table and the parent product record; the parent product record stores summary information of the coordinate points, such as the first 8 characters of the coordinate points, and the coordinate point data stores the index identifier of the parent product ID, realizing bidirectional fast traceability.

[0064] Finally, the structured coordinate points are serialized in JSON format and stored in association with the parent product record of the parent-child product model. Simultaneously, auxiliary fields for database sharding and table partitioning queries are embedded in the coordinate point data, such as... x The first four characters of the component serve as the sharding pre-positioning identifier; the core association information of the coordinate point, including the coordinate point, parent product ID, and child product set identifier, is simultaneously written into the Redis cache, forming an association index with the cached data of the short link suffix. This provides efficient data support for quickly locating shards by dimension, filtering data by benefit status / time range, and tracing child products by parent product ID when sharding and partitioning the database and tables. It ensures that the coordinate point has both high randomness to adapt to the uniformity of sharding and deep binding to business attributes to meet the needs of full-link traceability of benefits.

[0065] Step 3.4: Based on a preset geometric mapping function, map the coordinate points onto a space-filling curve and obtain the curve parameters of the coordinate points on the space-filling curve. Specifically, the preset geometric mapping function adopts the Hilbert curve mapping function, which can uniquely map multi-dimensional spatial coordinate points to a one-dimensional curve, ensuring the uniqueness and continuity of the mapping results, and adapting to the uniform sharding requirements of database sharding and table partitioning. The specific formula is as follows:

[0066] ;

[0067] Explanation of each character in the formula: H It is a Hilbert curve mapping function, whose core function is to realize the conversion of multi-dimensional equity association coordinates to one-dimensional piecewise calculation parameters; n The spatial dimension has a value of 4, corresponding to the four core attribute dimensions of the rights and benefits, namely, parent product ID, child product set, rights and benefits status, and generation timestamp. m This is the resolution parameter for each dimension, with a value of 2^16, because each coordinate component originates from a 16-bit hexadecimal substring. 16 That is, 65536 can completely cover the range of values ​​after component standardization, ensuring uniform mapping;

[0068] The components of each dimension of a 4D spatial coordinate point are, in order: x Parent product ID hash fragment y Sub-product collection identifier, z Rights status code, w Generate timestamp hash fragments; t These are the curve parameters obtained after mapping, i.e., the one-dimensional position identifiers of the coordinate points on the Hilbert curve, which are used for subsequent sharding calculations for database and table partitioning.

[0069] Mapping implementation process: First, standardize the four coordinate components according to the following formula:

[0070] (component value / (16) 16 A scaling factor of -1))×(m-1) is applied to ensure all components fall within the [0, m-1] interval, preventing mapping offsets caused by differences in dimensional values. Then, the Hilbert curve iterative generation process is initiated, starting with the least significant bit of each component and sequentially reading the corresponding bits of the four components to form four-bit groups. Through cyclic shifting, XOR operations, and other bitwise operations, the interweaving and fusion of multi-dimensional equity attribute data are achieved while preserving the correlation between different dimensions. After processing each group of bits, the curve iteration state is updated, gradually constructing the position markers of the coordinate points on the curve until all 32 bits are processed (16 hexadecimal bits correspond to 32 binary bits). The final non-negative decimal value is the curve parameter. t By leveraging the uniqueness of the Hilbert curve, we ensure that different coordinate points correspond to different parameter values, thus meeting the unique sharding requirements of database sharding and table partitioning.

[0071] It should be noted that: HThe specific form of the Hilbert curve mapping function is a discretized iterative bitwise operation function. Since the Hilbert curve is essentially a recursively generated continuous space-filling curve, it lacks a concise closed mathematical formula. However, the database sharding and table partitioning scenario of this invention requires sharding calculations based on integers; therefore, discretization is necessary for engineering adaptation. Its core implementation logic is as follows: based on the 4-dimensional core rights attributes (parent product ID, child product set identifier, rights status, generation timestamp), each attribute is standardized to [0, 2]. 16 The discrete coordinates within the range of -1] are obtained; multi-dimensional data interweaving and fusion are achieved by reading the binary bits of the coordinates bit by bit, combined with cyclic shifting, XOR and other bit operations, while the mapping continuity is ensured by iteratively updating the state; finally, a unique one-dimensional integer t is output as the sharding calculation parameter for database sharding and table partitioning. This form can fully cover the value range of 16-bit resolution, ensuring the uniqueness of the coordinate mapping results of different rights and interests, and achieving mapping uniformity through the space filling characteristics of the Hilbert curve, effectively avoiding data skew in database sharding and table partitioning, and accurately adapting to the sharding storage and efficient query requirements of this invention.

[0072] Step 3.5, converting the curve parameters into an integer value, specifically includes: obtaining the curve parameters. t Then, perform a triple check: first, a range check to confirm... t The value is in [0, m n -1]( m =216, n =4) Within the valid range, avoid overflow caused by mapping anomalies; secondly, uniqueness verification, querying the Redis cache to confirm no duplicates. t If the value exists, step 3.4 of the mapping process will be re-executed, which is an extremely low-probability scenario; the third step is business verification. t Verify the validity of the association between the value and the corresponding parent product ID to ensure the integrity of the data chain; after successful verification, proceed with... t Value optimization was performed: Since subsequent database sharding and table partitioning calculations need to adapt to 64-bit unsigned integer types, a modulo compression + offset correction method was adopted to... t Values ​​compressed to [0, 2] 64 The interval [-1] is compressed by offset correction to maintain the randomness and uniqueness of the values, without disrupting their unique mapping relationship with the short link suffix and the first hash value; after optimization, the values ​​are directly... t The value is converted to a decimal integer and synchronously written to the Redis cache and local cache, following a multi-level caching architecture. It is also linked with the short link suffix and the parent product ID to create a composite index cache, improving the efficiency of subsequent database sharding and table sharding queries. This integer value fully inherits the high randomness of the original short link suffix and is also compatible with the hash sharding calculation requirements of database sharding and table sharding. It can be directly used for subsequent combined weight calculation of database sharding and table sharding.

[0073] In a preferred embodiment of the present invention, step 4 above may include:

[0074] Step 4.1: Periodically collect performance metrics data from the monitoring agents deployed on each database shard. Performance metrics include real-time response latency, CPU load, and memory usage. Specifically, a lightweight monitoring agent is deployed on each database shard node. This agent employs a low-intrusion design, consuming minimal CPU and memory resources to avoid impacting the shard's business processing capabilities. The collection cycle is dynamically adjusted based on system load, with a 10-second cycle during off-peak periods and automatically shortened to 5 seconds during peak periods to ensure real-time capture of performance fluctuations. Performance metrics collection focuses on core business processes related to short-chain connections, including real-time response latency. For core requests such as short-chain queries and rights redemption, the system collects the response time of all valid requests (excluding invalid requests that have timed out or been interrupted) within a collection period, and takes the average as the indicator value for that period. The CPU load rate is the actual percentage of CPU usage of the current shard node, which is related to the total number of CPU cores of the node. The memory usage rate is the ratio of the shard node's used memory capacity to the total memory capacity. An asynchronous retry mechanism is enabled during the collection process. After a single collection failure, a retry is performed after an interval of 1 second. If there are 3 failures in total, the shard is marked as a collection anomaly, and an early warning is triggered synchronously to ensure the integrity of the shard monitoring data corresponding to high-priority rights.

[0075] Step 4.2 involves cleaning and normalizing the collected performance index data to obtain standardized index vectors. Specifically, this includes: performing a stratified cleaning process on the collected performance index data; firstly, identifying outliers based on the 3σ principle, and removing index values ​​that exceed the mean ± 3 times the standard deviation; for single-point missing data, filling with the mean of the index values ​​from the previous two periods, and marking the performance data of the segment as abnormal if there are more than 3 consecutive missing periods, and temporarily excluding it from subsequent calculations; after cleaning, performing dynamic normalization, using the 99th percentile response time of the most recent 7 days as the maximum reasonable value, and mapping the value to the [0, 1] interval by (maximum reasonable delay - actual delay) / maximum reasonable delay, ensuring that the lower the delay, the better the standardized value; CPU load rate and memory utilization rate are directly converted by actual value / 100%, and the original data before and after the conversion are recorded for traceability. Finally, the index vector is formed by combining the [normalized response latency value, normalized CPU load value, normalized memory utilization value] in that order. After the vector is generated, it is verified whether the values ​​of each dimension are all in the range of [0, 1]. If there is an anomaly, normalization is re-executed to ensure the consistency and effectiveness of the model input.

[0076] Step 4.3: Input the standardized indicator vector into the pre-trained health prediction model to calculate the health score corresponding to each database shard. Specifically, the pre-trained health prediction model is based on the improved XGBoost gradient boosting tree architecture. The core optimization is customized for the database sharding characteristics, multi-level cache interaction logic, and rights redemption fluctuation characteristics in the short link rights delivery scenario of this invention. The native XGBoost has shortcomings in capturing time-series performance fluctuations and identifying the correlation between business load and shard performance. This model adds a time-series feature enhancement module and a business attribute fusion layer. The former enhances the sensitivity to performance mutations in scenarios such as peak redemption of e-commerce promotion rights and concentrated access to short links. The latter deeply integrates business correlation features such as shard concurrency and cache hit rate of database sharding, so that the model can fully adapt to the full-link performance monitoring needs of short link generation, database storage, and rights query. The advantages of this model are threefold: First, it has strong business adaptability, accurately distinguishing the normal load fluctuations unique to short-chain businesses, such as the load increase and abnormal failures caused by a 300% surge in short-chain query volume during promotional periods, or the sudden increase in response latency caused by sharding storage anomalies, reducing the false alarm rate by more than 60% compared to traditional models; second, it has outstanding real-time performance, with single-sample prediction time controlled within 1 millisecond, meeting the service level requirement of ≤50 milliseconds for short-chain query response time; and third, it has excellent generalization ability, adapting to sharding performance monitoring for different benefit types such as coupon codes, recharge, and services, without the need to train a separate model for a single benefit type.

[0077] The model building and training process strictly revolves around the technical solution and business scenarios of this invention. The specific process is as follows: The first stage is data preparation and scenario coverage, collecting performance data from all shard nodes over the past three months, covering multiple core scenarios such as off-peak hours, peak redemption periods for e-commerce promotional benefits, system expansion and upgrades, fault recovery, and multi-level cache failures, ensuring that the data covers the entire lifecycle of short-chain benefit delivery. The data dimensions not only include the three basic indicators of real-time response latency, CPU load rate, and memory utilization, but also supplement the unique business correlation features of this invention, including short-chain query QPS, benefit redemption frequency, Redis cache hit rate, database sharding query concurrency, and parent-child product model correlation query volume, etc., to achieve deep binding between performance indicators and business load, allowing the model to perceive the linkage between short-chain access volume, cache hit rate, and shard performance.

[0078] The second stage involves data preprocessing and feature engineering. First, the raw data undergoes meticulous cleaning: short-chain query timeouts and extreme outliers caused by network jitter are removed; missing data during periods of failure are filled with the median of adjacent time periods; and normal high-load data during peak periods is labeled with business peak tags to avoid misjudgments. Next, a three-layer feature system is constructed. At the time-series feature level, the 5-minute sliding window mean, 10-minute trend difference, and volatility variance of core indicators are extracted to capture the continuous patterns of performance changes. At the business-related feature level, the correlation coefficient between short-chain query volume and CPU load, and the rate of change in memory usage when cache misses are calculated to enhance the model's ability to identify performance fluctuations driven by business load. At the sharding basic feature level, sharding storage capacity and the frequency of composite index queries are incorporated to adapt to the storage architecture characteristics of sharded databases and tables. Finally, all features are normalized to ensure consistent feature magnitudes input to the model and prevent any single type of feature from dominating the calculation results.

[0079] The third stage is model training and parameter optimization, which adopts a supervised training mode: the preprocessed feature data is divided into training, validation, and test sets in a 7:2:1 ratio, strictly following the time series order during the division to avoid future data leakage affecting the model's generalization ability and ensure that the trained model can adapt to the performance change trends in real-world scenarios. The tagging system is based on the Service Level Agreement (SLA) and sharding operation status definition of this invention, classifying sharding health status into four categories: normal, low-risk, high-risk, and fault. Normal status corresponds to short-chain query response ≤ 50 milliseconds, cache hit rate ≥ 99.9%, and no blocking of composite index queries; low-risk status corresponds to response latency 50 to 100 milliseconds, CPU load rate 60% to 80%, and cache hit rate 99% to 99.9%; high-risk status corresponds to response latency 100 to 200 milliseconds, CPU load rate 80% to 90%, memory utilization 85% to 95%, and slight blocking of some queries; fault status corresponds to response latency > 200 milliseconds, service interruption, or data query timeout. During training, core hyperparameters were tuned using grid search, with the learning rate set between 0.05 and 0.2, tree depth controlled between 3 and 8 layers, and the number of leaf nodes limited between 100 and 300. The objective function was to achieve the highest F1 score on the validation set. An early stopping mechanism was also enabled, which stopped training immediately when there was no performance improvement on the validation set for 5 consecutive rounds to avoid model overfitting and ensure good adaptability to unseen performance scenarios.

[0080] The fourth stage is model validation and scenario adaptation. Multi-dimensional evaluation is conducted on the test set, focusing on verifying that the recall rate for high-risk and fault states must be ≥98% and the precision rate must be ≥95%, ensuring that the model can accurately identify potential faults and reduce false alarms. By simulating real business scenarios such as a 300% surge in short link queries during e-commerce promotions and a sudden increase in shard query pressure due to cache failure, the model's ability to capture performance anomalies under sudden business loads is verified. The warning response time is required to be ≤3 seconds to meet the high availability requirements for the delivery of the rights and interests of this invention.

[0081] After deployment, the model employs a daily incremental fine-tuning mechanism, updating model parameters only with newly added valid performance data (excluding abnormally collected data) for the day. Simultaneously, new fault cases and business scenario data are periodically incorporated, such as changes in query logic due to added service-type benefits, and performance characteristic changes after database sharding and table expansion, continuously optimizing the model's adaptability to business changes. The model's output health score of 0 to 100 accurately quantifies the performance status of each shard, providing a reliable basis for subsequent candidate shard selection and ensuring shard stability and response efficiency during short-chain benefit queries and redemptions.

[0082] Step 4.4: Based on the preset health threshold, database shards with health scores higher than the threshold are selected and their identifiers are added to the candidate shard set. Specifically, the preset health threshold is dynamically adjusted based on the service level agreement, with a default threshold of 80 points, corresponding to a short-chain query response time of no more than 50 milliseconds and service availability of no less than 99.99%. During peak periods, the threshold can be lowered to 75 points to ensure that the size of the candidate shard set meets business needs. During the selection process, the health score of each shard is first compared with the current threshold to initially select compliant shards. Then, a secondary verification is performed on the initial selection results to check the network connectivity and database connection count of the shards in real time to see if they are within a reasonable range, and shards that are temporarily unavailable are removed. The final candidate shard set is stored in a structured form with shard identifiers, health scores, and remaining connection capacity, and is cached using Redis. The cache expiration time is dynamically adjusted according to the update frequency of the shard health status. The expiration time is extended when the health status is stable and shortened when there are large fluctuations, which ensures the timeliness of the set and reduces resource consumption.

[0083] Step 4.5, obtaining the integer value as the calculation input, specifically includes: obtaining the generated integer value according to the priority of local cache and Redis cache. The local cache adopts, for example, an LRU strategy, prioritizing the retention of integer values ​​corresponding to frequently accessed short links to improve hit efficiency; after obtaining, performing double validity checks, firstly, a value range check to confirm that it is within (0, 2... 64-1) within the valid range; secondly, business relevance verification, through the mapping relationship in the cache, verify whether the integer value matches the corresponding short link suffix, parent product ID, and rights status (unused, used, expired, etc.) to ensure that the value is strongly bound to the actual rights business; if the verification passes, the integer value is used as the calculation input; if the verification fails or the cache is not hit, the integer value generation process in step 3 is re-executed, and after generation, it is synchronously written to the multi-level cache to establish the association index between the integer value and the short link and parent product ID to ensure that subsequent queries are efficient and available.

[0084] Step 4.6: Traverse each database shard identifier in the candidate shard set. For the target shard identifier currently being traversed, perform the calculation process of the combined weight, which involves concatenating the integer value used as the calculation input with the target shard identifier to form a combined input string; perform a preset weight hash calculation on the combined input string to generate an intermediate hash result; convert the intermediate hash result into a numerical value as the combined weight value corresponding to the target shard identifier. Specifically, this includes: traversing the candidate shard set in descending order of health score, prioritizing the calculation of the combined weight of high-performance shards to lay the foundation for subsequent optimal shard selection; for the target shard identifier currently being traversed, the combined weight calculation process is as follows: first, concatenate using the fixed format of integer value # shard identifier, and then... The # symbol is used as a separator to avoid ambiguity between integer values ​​and shard identifiers, forming a conflict-free combined input string. The combined input string is then encoded in UTF-8 to ensure cross-platform character consistency. A one-way hash calculation is performed using the SHA-256 algorithm to generate a fixed-length binary hash result. The first 32 bits of the hash result are extracted from high to low order and converted to a decimal value. This value is the combined weight value corresponding to the target shard identifier, preserving randomness while avoiding excessively large values. A distributed lock is used during the calculation process to prevent simultaneous calculation of weights for multiple shards corresponding to the same short chain, which could lead to data inconsistency. A calculation log is also recorded, containing information such as the parent product ID associated with the short chain, the shard identifier, and the weight value, ensuring full traceability throughout the process.

[0085] Step 4.7: After traversing and calculating the combined weight values ​​corresponding to all fragment identifiers in the candidate fragment set, output the complete set of combined weight values. Specifically, this includes: after traversal, collecting key-value pairs of fragment identifiers and combined weight values ​​for all candidate fragments to form a set of combined weight values; performing dual integrity checks on the set: first, quantity check, confirming that the set size is consistent with the candidate fragment set, with no omissions or duplicates; second, validity check, checking whether each weight value is a non-negative integer and whether the corresponding fragment is currently available. Unavailable fragments are directly removed and other candidates are added. The shard weight calculation results are processed; after verification, the set is sorted in descending order of combined weight values, while the health score of the associated shard is used as an auxiliary sorting criterion to facilitate the subsequent routing module to quickly select the optimal shard; the sorted set of combined weight values ​​is stored in a local cache and synchronously updated to the routing-specific directory in Redis cache, with the cache expiration time consistent with the candidate shard set; finally, the set is synchronized to the database sharding and table routing module to establish a mapping relationship between weight values ​​and shard routes, providing efficient data support for shard selection in subsequent short-link queries, ensuring accurate and fast routing decisions.

[0086] In a preferred embodiment of the present invention, step 5 above may include:

[0087] Step 5.1: Receive the complete set of combined weight values. Specifically, this includes receiving the complete set of combined weight values ​​in a multi-level cache access order, prioritizing local cache and using Redis cache as a fallback. This set uses shard identifiers and combined weight values ​​as core key-value pairs, and is also associated with shard health scores, remaining connection capacity, and benefit type adaptation identifiers. It is strongly bound to the currently processed short link suffix and parent product ID through cache indexes. Upon receipt, a triple verification is performed: first, a set integrity verification to confirm that it includes all candidate shards that meet the health criteria, with no missing or duplicate values; second, a weight value validity verification to ensure that each value is a non-negative integer within a reasonable calculation range; and third, a rapid shard status verification to check whether each shard is still available through cache queries, avoiding receiving information about expired shards. After successful verification, the set is loaded into local memory. If verification fails, the combined weight calculation process in Step 4 is re-triggered to ensure the accuracy and timeliness of the input data.

[0088] Step 5.2: Traverse the set of combined weight values ​​and compare the size of each combined weight value in turn. Specifically, this includes: based on the traversal order in Step 4.6, start the traversal of the set of combined weight values ​​in descending order of health score to ensure that the weight values ​​of high-performance shards participate in the comparison first; the comparison process follows the rule of weight value priority and auxiliary indicators filling in the gaps: first, directly compare the size of each combined weight value and record the current maximum weight value and the corresponding shard information; if the weight values ​​are the same, prioritize the shard with the higher health score; if the scores are still the same, then the shard with the larger remaining connection capacity is preferred; after each round of comparison, remove the shards with the determined low weight values ​​to reduce the number of subsequent comparisons and improve traversal efficiency; if a shard's weight value is found to be outside the normal calculation range, mark it as invalid and remove it, and do not participate in subsequent comparisons to ensure the reliability of the results.

[0089] Step 5.3: Determine and record the largest combined weight value as the target weight value. This includes: after traversal, extracting the largest combined weight value from the recorded intermediate results and determining it as the target weight value; if multiple weight values ​​are the same and all are the maximum value, the uniqueness and optimality of the target weight value are ensured through multi-layered supplementary rules: first, compare the slice health scores and select the one with the higher score; if the scores are the same, prioritize the one with the larger remaining connection capacity; if the first two are the same, refer to the benefit type adaptation identifier and select the weight value corresponding to the slice with higher adaptation to the benefit type associated with the current short link, such as coupon code or service type; after determining the target weight value, synchronously record its corresponding slice identifier, health score, remaining connection capacity and benefit adaptation information to form a target weight association file, providing complete data support for subsequent reverse lookup and tracing.

[0090] Step 5.4: Based on the target weight value, perform a reverse lookup to obtain the target database shard identifier corresponding to it in the set of combined weight values. Specifically, this includes: performing a precise reverse lookup in the set of combined weight values ​​using key-value pair mapping based on the target weight value to quickly locate the corresponding target database shard identifier; after the reverse lookup, initiate dual validity checks: first, shard status check, confirming that the shard is still in the candidate shard set, its health score is not lower than the preset threshold, and there are no temporary failures such as load surges or network interruptions; second, business adaptation check, combining the parent-child product model to verify whether the shard supports the storage rules of the current short link associated benefits, such as encrypted storage of sensitive fields and composite index queries; if the reverse lookup is successful and the dual checks pass, record the target database shard identifier; if the reverse lookup fails or the shard status has expired, re-determine the second largest weight value from the remaining weight values ​​as the new target weight value, and repeat the reverse lookup and check process until a valid target database shard identifier is obtained.

[0091] Step 5.5: Based on the preset sharding identifier mapping relationship, query the data table sharding identifier associated with the target database sharding identifier. Specifically, the preset sharding identifier mapping relationship is established based on the database sharding and table partitioning strategy of this invention, stored in a dedicated directory of Redis cache, and clarifies the mapping rules between each database sharding identifier and the corresponding data table sharding. It also associates the table sharding adaptation logic corresponding to different benefit types, such as the data table containing the encrypted coupon code field corresponding to coupon code benefits. During the query, the mapping relationship is first retrieved through the target database sharding identifier to obtain the preliminary matching data table sharding identifier. Then, two layers of verification are performed: first, the table sharding status verification confirms that its connection number and storage capacity are within a reasonable range, and there are no read / write blocking or index failures; second, the benefit storage adaptation verification checks whether the data table supports the AES-256 encrypted storage requirements of the sensitive fields of the current benefit, and whether the composite index suffix, coupon code number, and status are working properly. After the verification is passed, the final data table sharding identifier is determined. If the verification fails, other available data table sharding identifiers that meet the adaptation requirements under the same database sharding are selected according to the backup rules of the mapping relationship.

[0092] Step 5.6: Combine the target database shard identifier and the data table shard identifier to generate and output the storage location identifier of the short link suffix. Specifically, this includes: using a fixed format of database shard identifier - data table shard identifier, combining the target database shard identifier and the data table shard identifier with a hyphen as a separator to generate the storage location identifier of the short link suffix, ensuring that the identifier format is uniform, unambiguous, and easy for the system to parse; after generation, first verify the validity of the identifier, confirming that it only contains valid characters from the shard identifier and that its length conforms to system specifications; then establish the storage location identifier and the short link suffix, parent... The system associates product ID, benefit status, and encrypted coupon code with a cache duration set according to the short link's validity period. Expired benefits have a shorter cache duration, while unused benefits have the same validity period as the short link. This information is synchronously written to both the local cache and the Redis cache to ensure efficient hits in subsequent queries. Finally, the storage location identifier is output to the sharded database storage module, and detailed storage logs are recorded, including generation time, short link suffix, storage location identifier, shard status, and cache synchronization results. This ensures the traceability of short link data storage and provides accurate location guidance for subsequent benefit queries, redemptions, and data management.

[0093] In a preferred embodiment of the present invention, step 6 above may include:

[0094] Step 6.1: Based on the target database shard identifier and data table shard identifier contained in the storage location identifier, locate the corresponding target database table. Specifically, this includes: To ensure the timeliness and consistency of storage decisions, after locating the target database table, this step will re-acquire or verify the latest health status of the target shard to ensure that subsequent write strategies are optimized based on the current actual performance status; parse the output storage location identifier, extract key information according to the separation rule of database shard identifier - data table shard identifier, and ensure that the identifier resolution is unambiguous; obtain the connection configuration of the target database shard from the database sharding configuration center, including the encrypted storage database address, port, and access credentials. The password in the access credentials is encrypted using the AES-256 algorithm and needs to be decrypted through the set encryption / decryption module: first, obtain the pre-allocated decryption key from the security key management service KMS. This key is rotated periodically and only authorized to the decryption module. After loading the key, the decryption module executes the encryption password. The AES-256 decryption operation is performed entirely in memory, without storing intermediate results on the disk. A temporary plaintext password is generated upon successful decryption, and the plaintext data is immediately cleared from memory after use to prevent credential leakage. Connection pool management is enabled when establishing a database connection, dynamically allocating the number of connections based on the health of the target shard; higher health results in more connections. Simultaneously, connection connectivity testing is performed, verifying network link and database service availability by sending lightweight query commands to ensure smooth connections. After querying the physical table name and storage path based on the data table shard identifier, the data table structure is verified: confirming the inclusion of core fields such as parent product ID, child product set identifier, benefit status, encrypted coupon code, and generation timestamp, and that the field types match the encapsulated mapping records. The constraint relationships between parent and child product association fields are checked; the child product parent ID must be associated with an existing parent product ID, and the existence of encrypted storage fields for sensitive fields is verified, completing the accurate location and availability verification of the target database table.

[0095] Step 6.2 involves querying the real-time health score calculated by the pre-trained health prediction model for the target database shard identifier. Specifically, this includes: initiating a health score query request for the target database shard through the real-time data interface of the monitoring agent, specifying the query time range as within the last 30 seconds of the current time to ensure the score reflects the latest performance status of the shard; if the interface returns a real-time score, such as that generated instantly by the improved XGBoost model in step 4.3, extracting the score, calculation timestamp, and current load-related data, such as query concurrency and write queue length; if no real-time score within the last 30 seconds is found, triggering the model's instant calculation process, generating a real-time score based on the latest collected performance metrics of the shard, response latency, CPU load, and memory usage, avoiding decision bias caused by directly using old cached scores; after obtaining the score, performing a validity check to confirm that the value is within the range of 0 to 100 and contains complete calculation dimension information; after passing the check, recording the score and its source, and performing real-time calculation or triggering calculation immediately; if the score is abnormal or the calculation fails, only the most recently cached health score is used, while marking the non-real-time score and its reason for use, providing a reference for subsequent storage strategy adjustments.

[0096] Step 6.3: Input the real-time health score into the preset data persistence optimization model. The preset data persistence optimization model determines the storage strategy parameters for the current write operation. Specifically, the preset data persistence optimization model is based on a hybrid architecture of CART decision tree and logistic regression. Its core is to customize and optimize the "dynamic adaptation of sharding performance, differentiated storage for multiple equity types, and balance between data security and query efficiency" requirements of the present invention for short-link equity storage. The native CART decision tree lacks flexibility in the association mapping between business characteristics and storage strategies, and logistic regression has limited ability to make decisions on the combination of multi-dimensional parameters. This model adds a business and performance feature fusion layer and a storage strategy weight adjustment module, solving the problem that traditional models cannot accurately match the storage scenarios of short-chain equity sharding. The advantages of this model are threefold: First, it has strong real-time decision-making, with a single data decision time of ≤0.5 milliseconds, fully adapting to the low-latency requirements of high-frequency writes for short-chain equity; second, it has high strategy adaptation accuracy, dynamically adjusting storage parameters based on shard health and equity characteristics, increasing the write success rate to over 99.95%; and third, it has low resource consumption, with a lightweight design that can be deployed locally on database shard nodes without additional computing power, avoiding increasing the system burden.

[0097] The model construction and training process strictly revolves around the technical solution and business scenarios of this invention. The specific process is as follows: The first stage is data preparation and scenario coverage, collecting full data from sharded databases and tables over the past three months. This covers peak write periods for e-commerce promotional benefits, regular writes during off-peak hours, and fluctuations in shard health, such as high availability, medium availability, or low availability, and different benefit types, such as coupon codes, direct top-ups, or services. This ensures that the data covers the full scenario status of short-chain benefit storage. The data dimensions include three core categories: First, shard performance characteristics, namely the health score (0 to 100 points) output in step 4.3, real-time CPU load rate, memory usage rate, and write queue length; second, business characteristics, including benefit type, benefit data size in bytes, historical write frequency, and whether it is a high-frequency access benefit (those with an average of ≥100 queries per day are marked as high-frequency); and third, storage performance labels, namely the optimal storage strategy combination and corresponding storage performance indicators, including write time, disk flushing success rate, cache synchronization efficiency, and data security verification results, providing clear objectives for supervised training.

[0098] The second stage involves data preprocessing and feature engineering. First, the raw data undergoes refined cleaning: invalid data due to network interruptions or sharding failures is removed; missing health scores are filled with the average of adjacent shards within the same time period; and extreme high-load data during peak promotion periods is labeled with business peak tags to avoid misjudgments. Next, a multi-layered feature system is constructed. At the basic feature level, health scores are divided into low, medium, and high ranges [0-69, 70-89, 90-100] and encoded; one-hot encoding is performed on benefit types (coupons [1, 0, 0], direct top-ups [0, 1, 0], services [0, 0, 1]); and data size is normalized. At the business-related feature level, the correlation coefficient between benefit write frequency and sharding load, and the cache hit contribution value of high-frequency benefits are calculated to enhance the model's ability to identify the relationship between business load and storage strategy. At the storage adaptation feature level, derived features such as disk flushing latency and cache synchronization failure rate under different health ranges are extracted to provide data support for strategy decisions.

[0099] The third stage is model training and parameter optimization, which is carried out using a supervised training mode: the preprocessed feature data is divided into training set, validation set and test set in a ratio of 8:1:1, and the division follows the time series order to avoid future data leakage affecting the model's generalization ability. The tagging system, based on the storage requirements and performance targets defined in this invention, uses combinations of storage strategy parameters as tags, including write priority (e.g., high, medium, low); flushing strategy (e.g., real-time, 10-second batch, 30-second batch); cache synchronization strategy (e.g., Redis + local dual-write, Redis only, no synchronization); and encrypted write order (e.g., parallel, serial). Each tag combination corresponds to a set of optimal storage effects. During training, preliminary decision rules are first constructed using a CART decision tree, such as prioritizing high-priority writes when the health score is ≥90. Then, logistic regression is used to adjust the weights of the decision rules, optimizing the influence ratio of different features on strategy selection, such as giving higher weight to cache synchronization strategies for high-frequency equity than ordinary equity. Hyperparameters such as decision tree depth (3 to 5 layers) and logistic regression regularization coefficient (0.01 to 0.1) are optimized through grid search, with the objective function being a storage strategy adaptation accuracy of ≥98% and a write performance improvement rate of ≥15% on the validation set. At the same time, an early stopping mechanism is enabled, stopping training when there is no performance improvement on the validation set for 3 consecutive rounds to avoid model overfitting.

[0100] The fourth phase involves model validation and scenario adaptation. Multi-dimensional evaluations are conducted on the test set, focusing on verifying the effectiveness of strategies under different scenarios: In scenarios with high availability and shard health scores ≥ 90, the model-recommended high-priority + real-time disk flushing + dual-write caching strategy should ensure write latency ≤ 10 milliseconds and cache hit rate ≥ 99.9%; In scenarios with low availability and shard health scores ≤ 69, the low-priority + 30-second batch disk flushing + Redis caching only strategy should reduce shard load by more than 20% without data loss; In scenarios involving coupon codes and other benefits, the choice of encrypted write order should ensure that sensitive fields are encrypted without omission, while not affecting write efficiency. By simulating a dynamic scenario during a major e-commerce promotion where 100,000 coupon codes and other benefits are written simultaneously, and shard health scores drop sharply from 95 to 75, the model's strategy switching response time is verified to be ≤ 1 millisecond, ensuring that the storage strategy can adapt to changes in shard performance in real time.

[0101] After deployment, the model employs a weekly incremental fine-tuning mechanism, updating model parameters only with newly added valid storage data (excluding outliers) within the current week. It also incorporates data such as new equity types (e.g., new service-type equity subclasses) and changes in storage characteristics after database sharding and table expansion, continuously optimizing the model's adaptability to business changes. By inputting real-time health scores into the model, it combines factors such as current equity type, data size, and write frequency to output targeted storage strategy parameters. This ensures that storage operations are adapted to sharding performance while also meeting the requirements for secure storage and high-frequency querying of short-chain equity data.

[0102] Step 6.4 involves structurally encapsulating the short link suffix and corresponding benefit information to generate a mapping record to be stored. Specifically, this includes: performing multi-layer encapsulation on the short link suffix and corresponding benefit information to generate a standardized mapping record; encapsulated fields include: short link suffix, unique query primary key, parent product unique ID, child product set identifier, a list of IDs associated with all child products, benefit status (unused, used, expired), encrypted coupon code, sensitive data encrypted with AES-256, benefit generation timestamp (uniformly in millisecond format), benefit validity period (standardized range from start to end time), and intermediary identifier; triple verification is performed during encapsulation: first, association verification, ensuring that all child product parent IDs in the child product set identifier are consistent with the parent product ID; second, status logic verification, expired benefits cannot be encapsulated as unused, and used benefits must be associated with the corresponding usage record ID; third, field format verification, ensuring that the timestamp, status field, and identifier field conform to the system's unified specifications to avoid format confusion; if verification passes, a structured mapping record is generated; if it fails, field error information is returned and the record is re-encapsulated.

[0103] Step 6.5: Based on the storage strategy parameters, write the mapping records to be stored into the target database table and obtain a successful write confirmation from the database. Specifically, this includes: executing the write operation according to the determined storage strategy parameters; high-priority writes use asynchronous parallel writing to improve writing efficiency; medium- and low-priority writes use synchronous writing to ensure data consistency; before writing, initiate an atomic transaction through the database transaction mechanism, writing the mapping records to be stored row by row according to the field mapping relationship of the target database table; sensitive fields are re-verified during the writing process to avoid decryption storage risks; after writing, receive confirmation information returned by the database, including the record's unique ID, write timestamp, and number of affected rows, verifying the consistency between the confirmation information and the record to be stored; if the write fails, repeat the write according to the preset retry mechanism, with a 100ms interval for the first retry, a 200ms interval for the second, and a 500ms interval for the third; after three failures, switch to a backup data table shard under the same database shard for rewriting, triggering an alert and recording failure logs, such as shard status and failure reason; after successful writing, commit the transaction and release the database connection to the connection pool.

[0104] Step 6.6: Based on the write success confirmation and storage strategy parameters, establish corresponding index entries for the mapped records in the target database table to support fast queries based on short link suffixes. Specifically, this includes: after obtaining the write success confirmation, establishing an index for the mapped records according to preset composite index rules. The index fields are fixed as a combination of short link suffix, encrypted coupon code, and benefit status, adapting to core business scenarios such as short link queries, benefit redemption, and status filtering. The index type uses a B+ tree index, and the index storage strategy is optimized based on the benefit access frequency: indexes for frequently accessed benefits, with a historical daily average of no less than 100 queries, are preferentially loaded into the database memory to improve query response speed; indexes for infrequently accessed benefits are stored normally to avoid wasting memory resources. During index creation, the progress is monitored to ensure there are no index conflicts or deadlocks. After creation, the index validity is verified by executing simulated queries to confirm that the query plan accurately hits the composite index without full table scans. Index information is simultaneously updated to multi-level caches: the Redis cache stores the mapping between short link suffixes and index positions, the local cache synchronously updates high-frequency index data, and the cache expiration time is consistent with the cache duration in the storage strategy parameters. Finally, index creation logs are recorded, including index ID, primary key of associated records, creation time, verification results, etc., providing data support for subsequent index maintenance and optimization, ensuring that queries based on short link suffixes can quickly locate data and meet the system's low-latency query requirements.

[0105] In a preferred embodiment of the present invention, step 7 above may include:

[0106] Step 7.1 involves obtaining the established mapping relationship between short link suffixes and corresponding benefit information. Specifically, this includes: based on the established composite index, using the short link suffix as the sole query condition, accurately retrieving the complete mapping relationship between the established short link suffixes and corresponding benefit information from the target database table. This mapping relationship strictly adheres to the structured specifications of the parent-child product model, covering core fields such as short link suffix, parent product unique ID, child product set identifier, benefit status, AES-256 encrypted coupon code, generation timestamp, and benefit validity period. During the query process, the composite index is used to avoid full table scans, ensuring efficient query response. Simultaneously, dual data verification is performed: first, field integrity verification to confirm no missing or null values ​​in core fields; second, association validity verification to ensure that the parent ID of all child products in the child product set is consistent with the parent product ID, and that sensitive fields have not been decrypted or leaked. If the database query times out or fails, a retry mechanism with a backoff strategy is triggered, with an initial interval of 1 second, and a warning is triggered after 3 consecutive failures, ensuring the reliability of the obtained mapping relationship.

[0107] Step 7.2: Based on the obtained mapping relationship, construct cache key-value pairs with short link suffixes as keys and structured benefit information as values. Specifically, this includes: constructing cache key-value pairs based on the obtained complete mapping relationship according to cache data standardization specifications; fixing the cache key to the short link suffix itself to ensure accurate matching via the suffix during queries, avoiding redundant key names; and storing standardized structured benefit information, organized hierarchically according to parent product basic information, child product set, sensitive data, and status attributes, including all fields required for redemption queries such as parent product ID, child product list, encrypted coupon code, benefit status, and validity period. Sensitive data remains AES-256 encrypted and is not decrypted. During construction, perform dual verification: first, key uniqueness verification, querying local and distributed caches to confirm that no cache key with the same short link suffix exists, avoiding data overwriting conflicts; second, value format verification to ensure that the structured data corresponds one-to-one with the parent and child product model fields, without format errors or missing fields, providing efficient support for subsequent cache query parsing.

[0108] Step 7.3 involves writing the constructed cache key-value pairs into the local application cache and setting a first-level lifecycle. This includes: using a thread-safe LRU cache container to write the constructed cache key-value pairs into the local application cache; the cache container has a preset capacity limit, for example, 100,000 entries. When the capacity threshold is reached, the least recently accessed cache entry is automatically evicted according to the LRU strategy to ensure reasonable allocation of local cache resources; the first-level lifecycle is dynamically adapted based on the benefit status and validity period. For unused benefits with a validity period exceeding 7 days, the TTL is consistent with the benefit validity period; for unused benefits with a validity period less than 7 days, the TTL is set to 1.5 times the benefit validity period to prevent premature expiration; for used or expired benefits, the TTL is uniformly set to 24 hours to reduce invalid cache usage; during writing, a distributed lock mechanism is used to prevent concurrent write conflicts; after writing, the existence of the cache entry and the completeness of the fields are immediately verified to ensure cache effectiveness; simultaneously, a local cache write log is recorded, including short link suffix, write time, TTL duration, cache location, and other information for easy traceability of subsequent issues.

[0109] Step 7.4: After successful local application cache writing, trigger an asynchronous synchronous task to push the cache key-value pairs to the distributed cache cluster for storage, and set a second-level lifecycle. Specifically, after successful local application cache writing, trigger an asynchronous synchronous task through the set task scheduling pool. The task is persisted to a distributed message queue in the form of messages to ensure no task loss. The message consumer thread is responsible for pushing the cache key-value pairs to the Redis distributed cache cluster. The asynchronous task executes independently of the main thread, does not block local business processes, and maintains complete consistency between the key-value pairs and the local cache during the push process, without modifying any field content. Second-level lifecycle... The cycle is uniformly set to the local cache TTL plus 30 minutes to ensure that the distributed cache can seamlessly handle query requests after the local cache expires, avoiding sudden increases in database pressure. For high-frequency access rights with a historical average of no less than 100 queries per day, a sharding storage strategy is adopted in the distributed cache to distribute cached data across multiple cluster nodes, improving query concurrency capabilities. The synchronization task has a built-in retry mechanism: the first push fails and retry is performed after 1 second, the second after 2 seconds, the third after 5 seconds, and the task is marked as failed after 3 failures, triggering an operation and maintenance alert and recording failure logs, including cluster node status, network conditions, etc., to ensure the reliability of distributed cache storage.

[0110] Step 7.5: Receive the storage confirmation response from the distributed cache cluster. This includes: listening to the response callback interface of the distributed cache cluster and receiving its storage confirmation response; the confirmation response must include key information such as the cache key, storage node identifier, data checksum, storage timestamp, and status code to verify the integrity and accuracy of the storage result; during the verification process, first check if the status code indicates successful storage, then verify the consistency between the stored data and the pushed data using the data checksum; if no response is received within 5 seconds, it is determined to be a synchronization timeout, triggering a retry process. If the received response indicates storage failure, analyze the failure reason in detail, such as cluster node unavailability, insufficient permissions, abnormal data format, etc., record it in the system log, and notify the operations and maintenance team; if all retries fail, switch to the backup distributed cache cluster for resynchronization to ensure that cached data is not lost.

[0111] Step 7.6: Based on the storage confirmation response, update the status of the short link suffix in the cache metadata to the ready state to indicate that its corresponding equity mapping relationship can be used for revocation query. Specifically, this includes: if the distributed cache cluster returns a confirmation response indicating successful storage, perform an atomic status update on the cache metadata corresponding to the short link suffix, updating the status from the pending synchronization state to the ready state; the cache metadata is stored in a dedicated metadata partition of the Redis distributed cache, using key-value pairs, with the key name in the format meta_short link suffix, and the value containing detailed information such as cache status, local cache TTL, distributed cache TTL, storage node, creation time, and update time; the status update is atomically guaranteed by CAS (Compare and Swap) operation to avoid state conflicts caused by concurrent updates; after the update is completed, the cache entries of the metadata are synchronously refreshed to ensure that all application nodes can obtain the latest status when querying the metadata; at the same time, a status update log is recorded, including information such as the short link suffix, previous status, current status, update time, and operation node. The ready state clearly indicates that the equity mapping relationship of the short link has been dually implemented in the local and distributed caches, and can directly support subsequent core business scenarios such as equity revocation and query.

[0112] like Figure 2 As shown, embodiments of the present invention also provide a high-strength random generation system for short link suffixes oriented towards rights delivery, comprising:

[0113] The sequence acquisition and suffix generation module is used to acquire a true random number sequence through a hardware physical entropy source, and generate a random string as a short link suffix according to the mapping rules between the true random number sequence and a preset character set;

[0114] The hash value calculation and integer value conversion module is used to perform hash calculation on the short link suffix to obtain the corresponding first hash value; at the same time, the first hash value is converted into an integer value.

[0115] The weight value calculation module is used to obtain the currently available set of database shard identifiers according to the preset sharding configuration strategy, and then calculate the corresponding combined weight value based on the integer value and each database shard identifier in the set of database shard identifiers.

[0116] The weight value comparison and location identifier determination module is used to compare all calculated combined weight values ​​and determine the database shard identifier and associated data table shard identifier corresponding to the maximum value as the storage location identifier of the short link suffix.

[0117] The mapping relationship establishment module is used to establish and store the mapping relationship between short link suffixes and corresponding rights information in the distributed database based on the storage location identifier.

[0118] The synchronous storage module is used to synchronously store the short link suffix and the mapping relationship between the established short link suffix and the corresponding rights information to a multi-level cache architecture to support efficient querying and access during rights reimbursement.

[0119] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for generating high-strength random short link suffixes for equity delivery, characterized in that, The method includes: A true random number sequence is obtained through a hardware physical entropy source, and a random string is generated as a short link suffix according to the mapping rules between the true random number sequence and a preset character set. Perform a hash calculation on the short link suffix to obtain the corresponding first hash value; Convert the first hash value to an integer value; Based on a preset sharding configuration strategy, a set of currently available database shard identifiers is obtained. Then, based on an integer value and each database shard identifier in the set, a corresponding combined weight value is calculated. This includes: periodically collecting performance indicator data from monitoring agents deployed on each database shard; performance indicator data includes real-time response latency, CPU load rate, and memory utilization; cleaning and normalizing the collected performance indicator data to obtain standardized indicator vectors; inputting the standardized indicator vectors into a pre-trained health prediction model to calculate the health score for each database shard; and filtering out healthy shards according to a preset health threshold. Database shards with a degree score higher than the threshold are added to the candidate shard set; the integer value is obtained as the calculation input; each database shard identifier in the candidate shard set is traversed, and for the currently traversed target shard identifier, the combined weight calculation process is performed, that is, the integer value used as the calculation input is concatenated with the target shard identifier to form a combined input string; a preset weight hash calculation is performed on the combined input string to generate an intermediate hash result; the intermediate hash result is converted into a numerical value as the combined weight value corresponding to the target shard identifier; after traversing and calculating the combined weight values ​​corresponding to all shard identifiers in the candidate shard set, the complete set of combined weight values ​​is output; Compare all the calculated combined weight values, and determine the storage location identifier of the short link suffix by the database shard identifier corresponding to the maximum value and the associated data table shard identifier. Based on the storage location identifier, a mapping relationship between short link suffixes and corresponding rights information is established and stored in the distributed database; The short link suffix and the mapping relationship between the established short link suffix and the corresponding rights information are synchronously stored in a multi-level cache architecture to support efficient querying and access during rights redemption.

2. The method for high-strength random generation of short link suffixes oriented towards benefit delivery as described in claim 1, characterized in that, A true random number sequence is obtained through a hardware physical entropy source, and a random string is generated as a short link suffix according to the mapping rules between the true random number sequence and a preset character set, including: Raw random signals are collected from hardware physical entropy sources; Entropy estimation and mixing are performed on the original random signal to obtain mixed random data; Post-process the mixed random data to generate a sequence of truly random numbers that meets the cryptographic security requirements; Convert the true random number sequence into the corresponding integer value; Based on the total number of characters in the preset character set, perform a modulo operation on the integer value to obtain the target character index, and select the corresponding character from the preset character set according to the target character index; Add the selected corresponding character to the temporary character sequence; Determine whether the length of the temporary character sequence has reached the preset length. If not, continue to collect the next set of original random signals from the hardware physical entropy source, and sequentially perform entropy estimation and mixing, post-processing, conversion to integer values, modulo operation and character selection on the next set of original random signals. At the same time, add the new characters obtained to the temporary character sequence until the length of the temporary character sequence reaches the preset length. If it has reached the preset length, output the temporary character sequence as the final short link suffix.

3. The method for high-strength random generation of short link suffixes oriented towards benefit delivery according to claim 2, characterized in that, Perform a hash calculation on the short link suffix to obtain the corresponding first hash value, including: Receive the final short link suffix as input data for hash calculation; Encode the input data into a uniform byte sequence format; Select a preset secure hash algorithm and perform a one-way hash calculation on the byte sequence; Obtain the raw hash value output by the one-way hash calculation; The obtained raw hash value is converted into a fixed-length hexadecimal string, which is used as the first hash value.

4. The method for high-strength random generation of short link suffixes oriented towards benefit delivery as described in claim 3, characterized in that, Convert the first hash value to an integer value, including: Receive the first hash value as the input string; The input string is split into multiple substrings of equal length, and each substring of equal length is converted into a corresponding integer component; Combine multiple integer components into a coordinate point in a multidimensional space; Based on a preset geometric mapping function, the coordinate point is mapped onto a space-filling curve, and the curve parameters of the coordinate point on the space-filling curve are obtained. Convert the curve parameters into an integer value, which will be used as the integer value.

5. A method for generating high-strength random short link suffixes oriented towards benefit delivery, as described in claim 4, is characterized in that... Compare all calculated combined weight values, and determine the storage location identifier for the short link suffix based on the database shard identifier corresponding to the maximum value and the associated data table shard identifier, including: Receive the complete set of combined weight values ​​from the output; Iterate through the set of combined weight values ​​and compare the magnitudes of each combined weight value in turn. Identify and record the combination weight value with the largest value, and use it as the target weight value; Based on the target weight value, reverse lookup and obtain the target database shard identifier corresponding to it in the set of combined weight values; Based on the preset sharding identifier mapping relationship, query the sharding identifier of the data table associated with the target database sharding identifier; The target database shard identifier and the data table shard identifier are combined to generate and output the storage location identifier of the short link suffix.

6. The method for high-strength random generation of short link suffixes oriented towards benefit delivery as described in claim 5, characterized in that, Based on the storage location identifier, a mapping relationship between short link suffixes and corresponding rights information is established and stored in the distributed database, including: Based on the target database shard identifier and data table shard identifier contained in the storage location identifier, locate the corresponding target database table; Query the real-time health score calculated by the pre-trained health prediction model using the target database shard identifiers; The real-time health score is input into the preset data persistence optimization model, which then determines the storage strategy parameters for the current write operation. The short link suffix and the corresponding rights and interests information are structured and encapsulated to generate a mapping record to be stored; Based on the storage strategy parameters, the mapping record to be stored is written to the target database table, and the database returns a confirmation of successful write. Based on the successful write confirmation and storage strategy parameters, corresponding index entries are created for the mapped records in the target database table to support fast queries based on short link suffixes.

7. A method for generating high-strength random short link suffixes oriented towards benefit delivery, as described in claim 6, is characterized in that... The short link suffixes and the mapping relationship between the established short link suffixes and the corresponding rights information are synchronously stored in a multi-level caching architecture to support efficient querying and access during rights redemption, including: Obtain the mapping relationship between the established short link suffixes and the corresponding rights and interests information; Based on the obtained mapping relationship, construct cache key-value pairs with short link suffixes as keys and structured rights information as values; Write the constructed cache key-value pairs to the local application cache and set the first-level lifecycle. After the local application cache is successfully written, an asynchronous synchronous task is triggered to push the cache key-value pair to the distributed cache cluster for storage and set a second-level lifecycle. Receive storage confirmation response from the distributed cache cluster; Based on the storage confirmation response, the status of the short link suffix in the cached metadata is updated to ready, indicating that its corresponding rights mapping relationship can be used for reimbursement queries.

8. A short link suffix high-strength random generation system for equity delivery, the system implementing the method as described in any one of claims 1 to 7, characterized in that, include: The sequence acquisition and suffix generation module is used to acquire a true random number sequence through a hardware physical entropy source, and generate a random string as a short link suffix according to the mapping rules between the true random number sequence and a preset character set; The hash value calculation and integer value conversion module is used to perform hash calculation on the short link suffix to obtain the corresponding first hash value; at the same time, the first hash value is converted into an integer value. The weight value calculation module is used to obtain the currently available set of database shard identifiers according to the preset sharding configuration strategy, and then calculate the corresponding combined weight value based on the integer value and each database shard identifier in the set of database shard identifiers. The weight value comparison and location identifier determination module is used to compare all calculated combined weight values ​​and determine the database shard identifier and associated data table shard identifier corresponding to the maximum value as the storage location identifier of the short link suffix. The mapping relationship establishment module is used to establish and store the mapping relationship between short link suffixes and corresponding rights information in the distributed database based on the storage location identifier. The synchronous storage module is used to synchronously store the short link suffix and the mapping relationship between the established short link suffix and the corresponding rights information to a multi-level cache architecture to support efficient querying and access during rights reimbursement.

Images