An insurance product process management method based on a multi-strategy hybrid mode

Abstract

The application discloses a kind of based on multi-strategy hybrid mode under insurance product process management method, it is related to computer technology field, the multi-strategy hybrid architecture of event-driven is as core in the present application, through lease main node and majority confirmation guarantee control plane single commit semantic, substantially reduce the risk of out-of-order and repeated execution in concurrent scene;With version unique identifier as anchor point, the environment and product domain information are included in the abstract context, combined with heartbeat reconciliation, standardized serialization and content definition block, the consistency check between channels is upgraded from coarse-grained version number comparison to fine-grained content check, and the missing commit can be replayed in order or the differential synchronization can be performed after deviation is found, less dependent on full coverage, shorten abnormal window;Under the condition of network jitter and node heterogeneity, timeout optimization strategy is based on robust statistical quantile threshold and hierarchical backoff, dynamically matches the delay distribution of each channel, reduces long tail waiting and cascading timeout.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for managing insurance product processes based on a multi-strategy hybrid model. Background Technology

[0002] Insurance products typically need to be released across multiple terminals, including online insurance platforms, agent channels, and third-party partners. To shorten the time to market, companies generally adopt a multi-environment (development, testing, pre-release, production) and multi-node collaborative release process, requiring that the product elements displayed on each channel (name, rate, liability terms, underwriting rules, listing status, etc.) remain consistent within a reasonable timeframe. Due to the dispersed release nodes, fluctuating network conditions, and heterogeneous channel connections, inconsistencies can easily occur between environments and between channels during the dissemination process. Typical manifestations include: some channels displaying older versions, rate changes not taking effect simultaneously, or historical configurations remaining after rollback. These issues affect user experience and increase compliance risks, often requiring manual spot checks or reviews in practice.

[0003] Existing technologies often employ a combination of distributed locks and state machines to reduce the risk of concurrency conflicts. For example, middleware such as Redis is used to lock critical steps, and the order of operations is constrained by explicit state transitions (such as pending release → testing and verification → canary release → full release), supplemented by transaction compensation and timeout control to alleviate inconsistencies to some extent.

[0004] However, in scenarios with high concurrency, network partitioning, or node failure, distributed locks may fail during master-slave switching, clock drift, or resource contention, leading to reentrancy or state rollback anomalies; fixed state machine timeouts and branches are difficult to adapt to real-time load and channel health status; some solutions lack a unified observation and recovery strategy for cross-environment product upgrades and channel-side eventual consistency, causing the system to still require manual intervention and making it difficult to achieve stable automated operation and maintenance. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] This invention provides a method for managing insurance product processes based on a multi-strategy hybrid model, which addresses the problems of disorder and drift in multi-channel and cross-environment releases, slow convergence, and reliance on manual verification and backtracking.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0008] In a first aspect, embodiments of the present invention provide a method for managing insurance product processes based on a multi-strategy hybrid model, comprising:

[0009] Step S1: When an insurance product experiences a status change event across multiple channels and environments, a status change request is generated. The status change request includes at least: product identifier, target environment, target channel set, target version number, change type, and serial number. The multiple environments include development, testing, pre-release, and production environments.

[0010] Step S2: Apply a multi-strategy hybrid mechanism to the state change request. The multi-strategy hybrid mechanism includes a priority broadcast protocol and a state verification algorithm, and the execution order and parallelism of the two are determined by the rule engine layer.

[0011] Step S3: Based on the processing result of the multi-strategy hybrid mechanism, submit the updated and synchronized status data of each channel node; if the verification fails within the threshold time, trigger the consistency repair process or roll back to the previous consistent version.

[0012] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the priority broadcast protocol includes:

[0013] The master node broadcasts the state change request to the target channel node in a priority queue. The state change request carries a monotonically increasing sequence number and a unique version identifier.

[0014] A submission record is generated after receiving confirmation responses of not less than a majority threshold. The confirmation responses are verified based on sequence number order and support idempotent processing.

[0015] Apply the changes to the committed changes and persist the commit record to the commit log.

[0016] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the master node is elected and renewed through a lease mechanism; when the master node is detected to be in failure during the lease period, the alternative node takes over according to the latest offset of the submission log and continues to broadcast the unfinished state change requests.

[0017] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the status verification algorithm includes:

[0018] The status data of each channel node is standardized and serialized to generate a unique identifier; the status data includes rate version, sales rule version, listing status and dependency configuration.

[0019] Each channel node exchanges unique identifiers with the master node according to the set heartbeat cycle.

[0020] When an identifier inconsistency is detected, the consistency repair process is triggered, which includes replaying missing commits in sequence and / or performing incremental synchronization based on differential packets.

[0021] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the unique identifier is a hash value calculated based on standardized state data, and the hash value is combined with the version number to form a version unique identifier, which is used for cross-environment / cross-channel consistent reconciliation and rollback anchor point.

[0022] The normalization rules for hash calculation are as follows:

[0023] Step C1: Normalize and serialize the state data to obtain a stable byte stream for subsequent hashing.

[0024] ,

[0025] in, This represents the normalized byte sequence. Represents the original state data set. This represents the normalized mapping of the range. This indicates a stable sorting based on the lexicographical order of the field paths. This indicates the lexicographical order rule of the field paths used for sorting. This indicates the use of a deterministic serialization function based on UTF-8+NFC.

[0026] Step C2, for Divide into chunks based on content definition, and trigger partitioning using rolling hash:

[0027] ,

[0028] when and Then cut,

[0029] in, Indicates the starting point of the window is Rolling hash at time, Indicates the starting point of the window is Rolling hash at time, express No. A value in bytes, This indicates the new byte value that the window slides in. Represents a cardinal constant. Indicates the length of the scroll window. Represents the modulus of a prime number. This represents the modulo operation. Indicates the boundary determination modulus. Indicates the boundary trigger remainder. This represents the threshold value for the allowed block length closed interval;

[0030] Step C3 involves calculating a fast hash for each block and summing it using a collision-resistant hash, while simultaneously introducing domain-separated salts to bind the environment and product:

[0031] ,

[0032] ,

[0033] in, Indicates cascaded summary hash, Represents a collision-resistant hash function. Representation domain for separating salts, This indicates a byte-level concatenation operation. Indicates by to Sequential multi-segment splicing, Indicates the intra-block fast hash function. Indicates the first The normalized byte sequence of each block, Indicates the number of blocks. Indicates the environment code. Indicates product identification;

[0034] Step C4: Combine and encode the summary hash and version number:

[0035] ,

[0036] in, Indicates a unique identifier for the version. This represents the Base32 encoding function. Represents the version number string. Represents the constant separator byte. The function represents truncation by bit length. Indicates the length of the truncated bits.

[0037] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the multi-strategy hybrid mechanism further includes a timeout optimization strategy, which is used to adaptively calculate the waiting timeout time according to the historical response time distribution of each channel node, divide the node into multiple timeout levels according to preset rules, and configure differentiated retry and backoff parameters.

[0038] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the timeout optimization strategy uses a sliding time window to statistically analyze the response delay of each node, calculates the waiting threshold for each timeout level according to the quantile threshold, and dynamically updates the number of retries and the backoff interval when the node level changes.

[0039] The quantile threshold, smoothing, and backoff functions are defined as follows:

[0040] Step D1, at node Response delay sequence First, robust pruning is performed to reduce the perturbation of outliers on the threshold:

[0041] ,

[0042] in, This represents the cropped sample. Represents the original sample. This represents the median within the window. Indicates the cutting ratio. This represents a robust metric derived from the absolute deviation of the median. , These represent operations that take the smaller and larger values ​​of two numbers, respectively.

[0043] Step D2, in a length of On the sliding window, according to the set of quantiles Calculate empirical quantiles:

[0044] ,

[0045] in, Represents a node At any moment Corresponding timeout level empirical quantiles, Indicates the first Ordered statistical functions of sequence Indicates rounding up. Indicates the first quantiles, Indicates the number of samples within the window. Indicates the number of timeout levels. This represents the cropping sequence obtained in step D1;

[0046] Step D3: Perform an exponentially weighted update on the quantile sequence:

[0047] ,

[0048] in, Indicates the smoothed quantiles. Represents the smoothing factor. Indicates the previous moment;

[0049] Step D4: Rank is given based on smooth quantiles and robust scalars. The waiting threshold and the first The backoff time for the second retry:

[0050] ,

[0051] in, Indicates the first The waiting threshold for retrying This means taking the smaller of the two. This indicates the maximum cap. This represents the smooth quantile of step D3. This represents the scale bias coefficient. This represents the robustness metric for step D1. This represents the retreat baseline coefficient. Indicates the retry sequence number. Indicates the type of retreat. This represents the exponential growth factor.

[0052] As a preferred embodiment of the insurance product process management method based on a multi-strategy hybrid mode described in this invention, the rule engine layer is used for:

[0053] Calculate priority weights for status change requests based on event type, channel weight, historical stability, and compliance requirements;

[0054] When there are multiple conflicting state change requests, they are sorted and preempted according to the aforementioned priority weights.

[0055] A conflict resolution log is recorded during conflict resolution. This conflict resolution log is associated with the commit log for subsequent auditing and playback.

[0056] In a second aspect, embodiments of the present invention provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements any step of the insurance product process management method based on a multi-strategy hybrid mode as described in the first aspect of the present invention.

[0057] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the insurance product process management method based on a multi-strategy hybrid mode as described in the first aspect of the present invention.

[0058] The beneficial effects of this invention are as follows: Based on an event-driven multi-strategy hybrid architecture, this invention substantially reduces the risk of out-of-order and duplicate execution in concurrent scenarios by ensuring the single commit semantics of the control plane through lease master nodes and majority confirmation. By using a unique version identifier as an anchor point to incorporate environment and product domain information into the summary context, and combining heartbeat reconciliation, normalized serialization, and content definition chunking, it upgrades consistency verification between channels from coarse-grained version number comparison to fine-grained content verification. This allows for the replay of missing commits or differential synchronization after discrepancies are detected, reducing reliance on full coverage and shortening the anomaly window. Under conditions of network jitter and node heterogeneity, the timeout optimization strategy, based on robust statistical quantile thresholds and tiered backoff, dynamically matches the latency distribution of each channel, reducing long-tail waiting and cascading timeouts. The rule engine prioritizes multiple changes and handles conflict preemption, ensuring the completion of high-weight channels and critical changes first, then advancing long-tail nodes, thereby improving overall throughput and convergence order. Commit logs and conflict resolution logs form a traceable chain of release evidence, facilitating auditing and compliance verification. When a fix fails, the system automatically rolls back to the most recent consistent version, ensuring consistency and predictability in external presentation. Thus, without relying on centralized locks and manual spot checks, it achieves enhanced consistency, accelerated recovery, and automated operation and maintenance across environments and channels. Attached Figure Description

[0059] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0060] Figure 1 This is a flowchart illustrating the insurance product process management method based on a multi-strategy hybrid mode in the embodiments. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0062] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0063] For example, the terms “first” and “second” used in this application are only used to distinguish and describe similar objects, to differentiate the first object from another object, and are not used to describe a specific order or sequence, nor should they be interpreted as indicating or implying relative importance.

[0064] This application proposes a method for insurance product process management based on a multi-strategy hybrid model, combining... Figure 1 As shown, the method includes:

[0065] Step S1: When an insurance product experiences a status change event across multiple channels and environments, a status change request is generated. The status change request includes at least: product identifier, target environment, target channel set, target version number, change type, and serial number; multiple environments include development, testing, pre-release, and production.

[0066] In this embodiment, a status change event refers to a systemic event that causes a change in the target version number or shelf status of a product, such as submission, approval, launch, delisting, or rollback. The target channel set is explicitly provided by the triggering party in the status change request. The sequence number is an integer value that increments by the product identifier and target environment dimension and remains monotonic within that dimension. The default event scanning and aggregation cycle is consistent with the heartbeat cycle, which can be relaxed or tightened as needed within the operation and maintenance window, based on the channel-side change frequency and historical congestion. The sequence number is generated atomically by the central side and written to the index field of the deduplication cache and submission log. For the same product identifier and target environment, requests with smaller sequence numbers are only treated as idempotent replays after requests with larger sequence numbers are submitted. Optionally, when the target channel set is empty, it is interpreted as a full-channel event. If the triggering party does not provide a target version number, it is generated by adding one to the latest version number of the current submission log. If necessary, if the product identifier does not exist or the target environment is inconsistent with the system configuration, the request is rejected and a verification failure event is recorded to avoid dirty writes.

[0067] Step S2: Apply a multi-strategy hybrid mechanism to the state change request. The multi-strategy hybrid mechanism includes a priority broadcast protocol and a state verification algorithm, and the execution order and parallelism of the two are determined by the rule engine layer.

[0068] Specifically, the rules engine layer calculates the priority weight for each state change request. The weight inputs include change type, channel weight, historical stability, and compliance constraints. The startup order of the priority broadcast protocol and state verification algorithm is arranged from highest to lowest weight. For a set of channels that can be parallelized, the system ensures that each channel node processes only one change related to that product at a time to maintain consistency within the node. The scheduling beat is aligned with the heartbeat cycle or its integer division, defaulting to a short beat to reduce queuing time, and is adjusted based on runtime monitoring data and auditing requirements. For example, when multiple requests for the same product have the same weight and potential conflicts exist, the rules engine layer uses a fixed winning rule to prioritize the earlier arriving sequence number and moves the unselected requests to the next scheduling cycle. Optionally, if the queue length continuously exceeds a threshold, the rules engine layer triggers short-term flow control to alleviate instantaneous congestion. In abnormal situations, if the necessary metadata cannot be obtained within the scheduling cycle, the original order is maintained and retried in the next cycle.

[0069] Step S3: Based on the processing result of the multi-strategy hybrid mechanism, submit the update and synchronize the status data of each channel node; if the verification fails within the threshold time, trigger the consistency repair process or roll back to the previous consistent version.

[0070] In one embodiment, the priority broadcast protocol includes:

[0071] The master node broadcasts a status change request to the target channel node in a priority queue. The status change request carries a monotonically increasing sequence number and a unique version identifier.

[0072] A submission record is generated after receiving confirmation responses of no less than a majority threshold. The confirmation responses are verified based on sequence number order and idempotent processing is supported.

[0073] Apply the changes to the committed changes and persist the commit record to the commit log;

[0074] Similarly, most thresholds are determined by adding one to half the number of online target channel nodes. Online status is based on the heartbeat being valid within a specified continuous window and the corresponding lease not having expired. The order of confirmation responses is verified using the sequence number, combined with deduplication caching to avoid duplicate submissions. The submission log is an append-written ordered structure, recording basic fields such as product identifier, target environment, sequence number, version unique identifier, submission time, and offset, used for subsequent consistency checks and differential replay. By default, log flushing uses synchronous writing to ensure consistency after a crash; batch submissions and periodic flushing can be configured based on media capacity and throughput requirements. Optionally, the log retention policy is executed based on both time and offset thresholds to balance auditing and storage usage. When a confirmation response does not reach most thresholds before the waiting period expires, in this embodiment, the submission is marked as incomplete and enters the retry sequence. If the maximum retry limit is exceeded, the rule engine layer decides whether to roll back or postpone.

[0075] In one embodiment, the master node is elected and renewed through a lease mechanism; when the master node failure is detected during the lease period, the standby node takes over based on the latest offset in the commit log and continues to broadcast the unfinished state change requests.

[0076] Optionally, the lease mechanism uses a time window plus renewal method to maintain master node ownership. Alternate nodes only enter the takeover process after detecting lease expiration or a heartbeat absence reaching the agreed window. During takeover, the latest offset in the commit log is used as the baseline, comparing it with the local offset and filling in any missing records to avoid skipped commits. To reduce jitter, a minimum hold time is set for the takeover action, during which no re-election request is responded to. When multiple alternative nodes exist, the node with the latest offset and the closest distance to the target channel topology is prioritized to shorten the recovery path. Furthermore, if two nodes simultaneously believe they are qualified to be master nodes during the takeover process, the decision is made based on the lexicographical order of the lease timestamp and the commit log offset; the losing node is immediately demoted to an alternative and its temporary state is cleared.

[0077] In one embodiment, the state verification algorithm includes:

[0078] The status data of each channel node is standardized and serialized to generate a unique identifier; the status data includes rate version, sales rule version, listing status and dependency configuration;

[0079] In this embodiment, when a channel node reads status data, it primarily uses the local snapshot of the configuration to be implemented. If the snapshot does not exist, it reverts to the currently implemented configuration. Each field read is expanded according to the key path agreed upon within the domain to ensure stable comparisons between different implementations. The default collection cycle is consistent with the heartbeat cycle. If necessary, encrypted sampling is performed within the publishing window to reflect changes more quickly. References to dependent configurations are represented by immutable reference identifiers to avoid misjudgments caused by different contents with the same name. Optionally, redundant fields that do not affect the external display are uniformly set to null during normalization to reduce hash input differences. In the event of insufficient permissions or a temporary failure, the current verification skips that node and retryes in the next heartbeat cycle, recording the reason for the missed test in the verification log.

[0080] Each channel node exchanges unique identifiers with the master node according to the set heartbeat cycle.

[0081] When an identifier inconsistency is detected, a consistency repair process is triggered, which includes replaying missing commits in sequence and / or performing incremental synchronization based on differential packets.

[0082] For example, in case of inconsistency, the master node determines the cause based on the version unique identifier and commit log offset, and prioritizes recovery using sequential replay. After replay, the identifier is compared again. If differences still exist, differential packet synchronization is initiated. The generation of differential packets is based on the block results of the normalized byte stream, and only the changed blocks are transmitted to reduce bandwidth consumption. By default, replay and differential synchronization are executed serially within the same recovery session. Depending on the channel-side load, they can be parallelized to several non-conflicting nodes as instructed by the rule engine layer. Similarly, to avoid oscillations caused by back-and-forth switching, a minimum duration is set for the same node within the recovery session, during which no new recovery type switch is triggered. If multiple consecutive recovery failures occur, a rollback process is triggered and a root cause summary is recorded.

[0083] In one embodiment, the unique identifier is a hash value calculated based on normalized state data, and the hash value is combined with the version number to form a version unique identifier, which is used for cross-environment / cross-channel consistent reconciliation and rollback anchor.

[0084] The normalization rules for hash calculation are as follows:

[0085] Step C1: To eliminate cross-channel / cross-environment differences, the status data is normalized and serialized to obtain a stable byte stream for subsequent hashing.

[0086] ,

[0087] in, This represents the normalized byte sequence. Represents the original state data set. This indicates a normalized mapping of the value range (explicit notation for null values, uniform decimal representation of numerical values, lowercase Boolean values, and time uniformity to UTC ISO-8601, etc.). This indicates a stable sorting based on the lexicographical order of the field paths. This indicates the lexicographical order rule of the field paths used for sorting. This indicates the use of a deterministic serialization function based on UTF-8+NFC.

[0088] Step C2, to balance incremental synchronization and replay efficiency, for Divide into chunks based on content definition, and trigger partitioning using rolling hash:

[0089] ,

[0090] when and Then cut,

[0091] in, Indicates the starting point of the window is Rolling hash at time, Indicates the starting point of the window is Rolling hash at time, express No. A value in bytes, This indicates the new byte value that the window slides in. Represents a cardinal constant. Indicates the length of the scroll window (in bytes). Represents the modulus of a prime number. This represents the modulo operation. Indicates the boundary determination modulus. Indicates the boundary trigger remainder. This represents the threshold value for the allowed block length closed interval;

[0092] Step C3 involves calculating a fast hash for each block and summing it using a collision-resistant hash, while simultaneously introducing domain-separated salts to bind the environment and product:

[0093] ,

[0094] ,

[0095] in, Indicates cascaded summary hash, This represents a collision-resistant hash function (summary layer). Representation domain for separating salts, This indicates a byte-level concatenation operation. Indicates by to Sequential multi-segment splicing, Indicates the intra-block fast hash function. Indicates the first The normalized byte sequence of each block, Indicates the number of blocks. Indicates the environment code (development / testing / pre-release / production). Indicates product identification;

[0096] Step C4, to form a cross-system readable anchor identifier, combines and encodes the summary hash and version number:

[0097] ,

[0098] in, Indicates a unique identifier for the version. This represents the Base32 encoding function. Represents the version number string. Represents the constant separator byte. The function represents truncation by bit length. Indicates the truncated bit length;

[0099] Furthermore, the version unique identifier uses an uppercase character set and removes easily confused characters during encoding to reduce manual verification errors. The generated identifier is written to the commit log and also attached to the request header along with the priority broadcast protocol for end-to-end verification. By default, the most recent few version unique identifiers and their corresponding offsets are stored in the database of each channel node for quick backtracking and breakpoint resumption. In the same product identifier and target environment, if two different identifiers correspond to the same version number, this embodiment uses the record with the larger offset in the commit log. Optionally, to facilitate cross-system troubleshooting, the version number and version unique identifier are displayed simultaneously in the operation and maintenance interface, and copying capability is provided to reduce manual input errors. If encoding fails or the target medium is not writable, the original state is maintained and retried in the next scheduling cycle, while recording the reason for failure.

[0100] Without changing the semantics of the algorithm, it is advisable to byte, , can be set To obtain the expected average block length, take , To facilitate constant-time scrolling, BLAKE3 is optional. SHA-256 is optional. A length of 128mm is preferable to balance length and collision risk. Enter Then participate in the aggregation to achieve domain separation;

[0101] Will The latest offset from the commit log is recorded together for reconciliation. When inconsistencies are found during reconciliation, the missing commits are replayed block by block. If the replay results in... If they still don't match, then revert to the previous rule. Consistent version and logging of fixes;

[0102] In this embodiment, the reconciliation process uses the commit log as a timeline, checking each log entry sequentially from smallest to largest offset. If a missing log entry is encountered, it is replayed according to the missing range, and the version unique identifier is compared immediately after each replay to narrow down the fault location. By default, reconciliation is performed at a higher frequency during the release window, and then returns to the normal frequency after release to reduce resource consumption. Optionally, to avoid mutual interference with new commits during reconciliation, short-term write protection is set for the product and environment combination being reconciled. New commits are then merged after the protection ends. If the target node still cannot be written to after a rollback is triggered, the rollback intention is retained and executed first when writability is restored, while the impact scope is included in the repair log.

[0103] Specifically, the chunking strategy adopts content-defined segmentation, which is not only suitable for incremental synchronization, but also beneficial to the replay efficiency during anomaly repair; the cascading stage introduces domain separation salt to incorporate environmental and product information into the summary context, avoiding confusion caused by hash reuse between different domains; finally, cross-system consistent identifiers are generated through truncation and readable encoding, which are easy to use in log, audit and rollback processes.

[0104] In one embodiment, the multi-strategy hybrid mechanism also includes a timeout optimization strategy, which is used to adaptively calculate the waiting timeout based on the historical response time distribution of each channel node, divide the nodes into multiple timeout levels according to preset rules, and configure differentiated retry and backoff parameters.

[0105] In one embodiment, the timeout optimization strategy uses a sliding time window to statistically analyze the response delay of each node, calculates the waiting threshold for each timeout level based on the quantile threshold or the abnormal deviation threshold, and dynamically updates the number of retries and the backoff interval when the node level changes.

[0106] Specifically, the rank mapping is defined by the quantile set and incorporated into the rule engine layer reference along with channel importance. The update frequency is kept on the same order of magnitude as the sliding window length to avoid oversensitivity. Within a single update cycle, the same node undergoes at most one rank migration, with the migration direction consistent with the new quantile position. By default, the effective dates of the waiting threshold and backoff parameters are aligned to the scheduling cycle boundary to ensure consistent timing strategies for requests in the same batch. Optionally, when a node is consistently in a better quantile range across multiple consecutive windows, the rank can be gradually lowered to recover throughput; conversely, if significant deterioration occurs in a short period, the rank is quickly raised with a one-time protection period. In exceptional circumstances, if the sample size is insufficient to calculate quantiles, the previous valid result is used, and the node is marked as low confidence to prompt subsequent auditing.

[0107] The quantile threshold, smoothing, and backoff functions are defined as follows:

[0108] Step D1, at node Response delay sequence First, robust pruning is performed to reduce the perturbation of outliers on the threshold:

[0109] ,

[0110] in, This represents the cropped sample. Represents the original sample. This represents the median within the window. Indicates the cutting ratio. This represents a robust metric derived from the absolute deviation of the median. , These represent operations that take the smaller and larger values ​​of two numbers, respectively.

[0111] Step D2, in a length of On the sliding window, according to the set of quantiles Calculate empirical quantiles:

[0112] ,

[0113] in, Represents a node At any moment Corresponding timeout level empirical quantiles, Indicates the first Ordered statistical functions of sequence Indicates rounding up. Indicates the first quantiles (range of values) ), Indicates the number of samples within the window. Indicates the number of timeout levels. This represents the cropping sequence obtained in step D1;

[0114] Step D3: To suppress short-term oscillations, the quantile sequence is updated using an exponential weighting method.

[0115] ,

[0116] in, Indicates the smoothed quantiles. Smoothing factor (range of values) ), Represents the previous time step; initialization is possible. ;

[0117] Step D4: Rank is given based on smooth quantiles and robust scalars. The waiting threshold and the first The backoff time for the second retry:

[0118] ,

[0119] in, Indicates the first The waiting threshold for retrying This means taking the smaller of the two. This indicates the maximum cap. This represents the smooth quantile of step D3. This represents the scale bias coefficient. This represents the robustness metric for step D1. This represents the retreat baseline coefficient. Indicates the retry sequence number ( ), Indicates the backoff type (linear lin or exponential exp). Indicates the exponential growth factor;

[0120] Desirable The most recent sample size matching the heartbeat cycle. Set the levels in ascending order. The adjustment is increased as the level increases to improve stability. and Configure channels based on stability, with linear backoff for short links and exponential backoff for long links. The SLA sets a hard upper limit; when a node's statistical characteristics cross adjacent quantile intervals, its rank is updated. And adjust simultaneously , , , The maximum number of retries is set, and the switching event is written to the conflict resolution log for auditing and playback.

[0121] Specifically, based on robust statistics, outlier suppression, quantile estimation, exponential weighting, and backoff strategies are integrated to form a timeout classification method that can be transferred across different channels and nodes. Preprocessing uses the median and robust scale to prune extreme samples, reducing threshold shifts caused by short-term fluctuations. Sliding window quantiles provide historical distribution positions, which are further smoothed using exponential weighting, making the threshold change gradually over time without becoming overly sensitive. On this basis, a graded backoff is introduced: first, a base wait is constructed using quantiles and robust scales, and then incremental delays are added according to linear or exponential rules, while setting a cap to avoid excessively long waits from dragging down throughput. Grade switching and parameter linkage are recorded in the log, providing a basis for auditing and playback.

[0122] Optionally, when resource constraints prevent statistical or smoothing calculations from being completed within a scheduling cycle, the system retains the parameters effective in the previous cycle and postpones updates to the next cycle, while conservatively limiting the concurrency of that node to avoid further congestion. Furthermore, for nodes temporarily missing data, the waiting threshold is applied according to the baseline value of its level, and a linear backoff strategy is adopted until sufficient samples are recovered before switching to the predetermined strategy. When data is missing for multiple consecutive cycles, the node is downgraded to unavailable to exit most threshold statistics, and automatically reinstated into the statistical set via heartbeat upon recovery.

[0123] In one embodiment, the rules engine layer is used for:

[0124] Calculate priority weights for status change requests based on event type, channel weight, historical stability, and compliance requirements;

[0125] When there are multiple conflicting state change requests, they are sorted and preempted according to their priority weights.

[0126] A conflict resolution log is recorded during conflict resolution. The conflict resolution log is associated with the commit log for subsequent auditing and playback.

[0127] This embodiment also provides a computer device, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement an insurance product process management method based on a multi-strategy hybrid mode as proposed in the above embodiment.

[0128] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0129] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements an insurance product process management method based on a multi-strategy hybrid mode as proposed in the above embodiment. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0131] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A method for managing insurance product processes based on a multi-strategy hybrid model, characterized in that, include: Step S1: When an insurance product experiences a status change event across multiple channels and environments, a status change request is generated. The status change request includes at least: product identifier, target environment, target channel set, target version number, change type, and serial number. The multiple environments include development, testing, pre-release, and production environments. Step S2: Apply a multi-strategy hybrid mechanism to the state change request. The multi-strategy hybrid mechanism includes a priority broadcast protocol and a state verification algorithm, and the execution order and parallelism of the two are determined by the rule engine layer. Step S3: Based on the processing result of the multi-strategy hybrid mechanism, submit and update the status data of each channel node; If the verification fails within the threshold time, the consistency repair process will be triggered or the system will be rolled back to the previous consistent version. The priority broadcast protocol includes: The master node broadcasts the state change request to the target channel node in a priority queue. The state change request carries a monotonically increasing sequence number and a unique version identifier. A submission record is generated after receiving confirmation responses of not less than a majority threshold. The confirmation responses are verified based on sequence number order and support idempotent processing. Apply the changes to the committed changes and persist the commit record to the commit log; The state verification algorithm includes: The status data of each channel node is standardized and serialized to generate a unique identifier; the status data includes rate version, sales rule version, listing status and dependency configuration. Each channel node exchanges unique identifiers with the master node according to the set heartbeat cycle. When an identifier inconsistency is detected, the consistency repair process is triggered, which includes replaying missing commits in sequence and / or performing incremental synchronization based on differential packets. The rule engine layer is used for: Calculate priority weights for status change requests based on event type, channel weight, historical stability, and compliance requirements; The state change requests are sorted based on the priority weights, and the execution order of the priority broadcast protocol and the state verification algorithm is determined. For a set of target channels that can be parallelized, concurrency control is implemented for each channel node so that each channel node can process only one state change request related to the same product at any given time. When there are multiple conflicting state change requests, they are sorted and preempted according to the aforementioned priority weights. A conflict resolution log is recorded during conflict resolution. This conflict resolution log is associated with the commit log for subsequent auditing and playback.

2. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 1, characterized in that, The master node is elected and renewed through a lease mechanism; When a primary node failure is detected during the lease term, the backup node takes over based on the latest offset in the commit log and continues to broadcast any unfinished state change requests.

3. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 1, characterized in that, The unique identifier is a hash value calculated based on normalized state data, and the hash value is combined with the version number to form a version unique identifier, which is used for cross-environment / cross-channel consistent reconciliation and rollback anchor. The normalization rules for hash calculation are as follows: Step C1: Normalize and serialize the state data to obtain a stable byte stream for subsequent hashing. ， in, This represents the normalized byte sequence. Represents the original state data set. This represents the normalized mapping of the range. This indicates a stable sorting based on the lexicographical order of the field paths. This indicates the lexicographical order rule of the field paths used for sorting. This indicates the use of a deterministic serialization function based on UTF-8+NFC. Step C2, for Divide into chunks based on content definition, and trigger partitioning using rolling hash: ， when and Then cut, in, Indicates the starting point of the window is Rolling hash at time, Indicates the starting point of the window is Rolling hash at time, express No. A value in bytes, This indicates the new byte value that the window slides in. Represents a cardinal constant. Indicates the length of the scroll window. Represents the modulus of a prime number. This represents the modulo operation. Indicates the boundary determination modulus. Indicates the boundary trigger remainder. This represents the threshold value for the allowed block length closed interval; Step C3 involves calculating a fast hash for each block and summing it using a collision-resistant hash, while simultaneously introducing domain-separated salts to bind the environment and product: ， ， in, Indicates cascaded summary hash, Represents a collision-resistant hash function. Representation domain for separating salts, This indicates a byte-level concatenation operation. Indicates by to Sequential multi-segment splicing, Indicates the intra-block fast hash function. Indicates the first The normalized byte sequence of each block, Indicates the number of blocks. Indicates the environment code. Indicates product identification; Step C4: Combine and encode the summary hash and version number: ， in, Indicates a unique identifier for the version. This represents the Base32 encoding function. Represents the version number string. Represents the constant separator byte. The function represents truncation by bit length. Indicates the length of the truncated bits.

4. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 1, characterized in that, The multi-strategy hybrid mechanism also includes a timeout optimization strategy, which is used to adaptively calculate the waiting timeout based on the historical response time distribution of each channel node, divide the nodes into multiple timeout levels according to preset rules, and configure differentiated retry and backoff parameters.

5. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 4, characterized in that, The timeout optimization strategy uses a sliding time window to statistically analyze the response delay of each node, calculates the waiting threshold for each timeout level based on the quantile threshold, and dynamically updates the number of retries and the backoff interval when the node level changes. The quantile threshold, smoothing, and backoff functions are defined as follows: Step D1, at node Response delay sequence First, robust pruning is performed to reduce the perturbation of outliers on the threshold: ， in, This represents the cropped sample. Represents the original sample. This represents the median within the window. Indicates the cutting ratio. This represents a robust metric derived from the absolute deviation of the median. , These represent operations that take the smaller and larger values ​​of two numbers, respectively. Step D2, in a length of On the sliding window, according to the set of quantiles Calculate empirical quantiles: ， in, Represents a node At any moment Corresponding timeout level empirical quantiles, Indicates the first Ordered statistical functions of sequence Indicates rounding up. Indicates the first quantiles, Indicates the number of samples within the window. Indicates the number of timeout levels. This represents the cropping sequence obtained in step D1; Step D3: Perform an exponentially weighted update on the quantile sequence: ， in, Indicates the smoothed quantiles. Represents the smoothing factor. Indicates the previous moment; Step D4: Rank is given based on smooth quantiles and robust scalars. The waiting threshold and the first The backoff time for the second retry: ， in, Indicates the first The waiting threshold for retrying This means taking the smaller of the two. This indicates the maximum cap. This represents the smooth quantile of step D3. This represents the scale bias coefficient. This represents the robustness metric for step D1. This represents the retreat baseline coefficient. Indicates the retry sequence number. Indicates the type of retreat. This represents the exponential growth factor.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the insurance product process management method based on a multi-strategy hybrid mode as described in any one of claims 1 to 5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the insurance product process management method based on a multi-strategy hybrid mode as described in any one of claims 1 to 5.

Images