Insurance product process management method based on multi-strategy mixed mode

Abstract

The invention discloses an insurance product process management method based on a multi-strategy mixed mode, and relates to the technical field of computers. An event-driven multi-strategy mixed framework is taken as a core, and a single submission semantic meaning of a lease main node and a majority confirmation guarantee control plane is used for realizing the multi-strategy process management of an insurance product. Wrong sequence and repeated execution risks in a concurrent scene are substantially reduced; according to the method, environment and product domain information is incorporated into abstract context by taking a version unique identifier as an anchor point, and heartbeat reconciliation, normalized serialization and content definition partitioning are combined, so that consistency verification between channels is upgraded from coarse-grained version number comparison to fine-grained content verification, missing submission can be replayed in sequence or differential synchronization can be performed after deviation is found, and the consistency verification efficiency is improved. The dependence on full coverage is less, and an abnormal window is shortened; under the conditions of network jitter and node isomerism, the timeout optimization strategy dynamically matches the time delay distribution of each channel based on the quantile threshold and hierarchical backoff of robust statistics, and reduces long-tail waiting and cascade timeout.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a method for managing insurance product process based on multi-strategy hybrid mode. BACKGROUND

[0002] The insurance product usually needs to be published to online insurance platforms, agent channels and third-party cooperation institutions and the like multi-terminal; in order to shorten the listing cycle, enterprises generally adopt multi-environment (development, test, pre-release, production) and multi-node cooperative publishing processes, and require the product elements (name, rate, liability clause, underwriting rule, on-off shelf state and the like) displayed by each channel to be consistent within a reasonable time; due to the dispersion of publishing nodes, network condition fluctuation and channel docking heterogeneity, the states between the environments and the channel side are prone to appear inconsistent for a short time or persistently, and typical performances are that some channels display old versions, rate switching does not take effect at the same time, or residual historical configurations remain after rollback and the like; such problems will affect user experience and increase compliance risks, and in practice, manual sampling inspection or review is often required.

[0003] The prior art usually adopts a combination of distributed locks and state machines to reduce concurrent conflict risks; for example, Redis or the like middleware is used to lock critical steps, and an explicit state flow (such as to be published→test verification→gray→full amount) is used to constrain the operation sequence, supplemented by transaction compensation and timeout control to relieve inconsistency to a certain extent.

[0004] However, in high concurrency, network partition or node failure scenarios, the distributed lock may fail in master-slave switching, clock drift or resource competition, resulting in re-entry or state rollback exceptions; the fixed state machine timeout and branch are difficult to adapt to real-time load and channel health status; some schemes lack unified observation and recovery strategies for cross-environment product promotion and channel side final consistency, so that the system still needs manual intervention, and stable automated operation and maintenance is difficult to achieve. SUMMARY

[0005] In view of the above existing problems, the present application is proposed.

[0006] The present application provides a method for managing insurance product process based on multi-strategy hybrid mode, which solves the problems of loss of sequence and drift, slow convergence in multi-channel cross-environment publishing, and often relying on manual checking and backtracking.

[0007] To solve the above technical problems, the present application provides the following technical solutions:

[0008] In a first aspect, the present application embodiment provides a method for managing insurance product process based on multi-strategy hybrid mode, which includes:

[0009] Step S1, when the insurance product occurs a state change event in multiple channels and multiple environments, a state change request is generated, the state change request at least includes: product identification, target environment, target channel set, target version number, change type, sequence number; the multiple environments include development, test, pre-release and production;

[0010] Step S2, a multi-policy hybrid mechanism is applied to the state change request, the multi-policy hybrid mechanism includes a priority broadcast protocol and a state verification algorithm, and the execution order and parallelism of the two are determined by a rule engine layer;

[0011] Step S3, based on the processing result of the multi-policy hybrid mechanism, the state data of each channel node is submitted and synchronized; if the verification fails within a threshold time, a consistency repair process is triggered or rolled back to the last consistent version.

[0012] As a preferred scheme of the insurance product process management method based on the multi-policy hybrid mode, the priority broadcast protocol includes:

[0013] The state change request is broadcasted to the target channel node by the master node according to the priority queue, and the state change request carries a monotonically increasing sequence number and a version unique identifier;

[0014] The submission record is generated after receiving the confirmation response which is not less than the majority threshold, the confirmation response is verified based on the sequence number order and supports idempotent processing;

[0015] The committed change is executed and the submission record is persisted to the commit log.

[0016] As a preferred scheme of the insurance product process management method based on the multi-policy hybrid mode, the master node is elected and renewed through the lease mechanism; when the master node is detected to be invalid within the lease period, the standby node takes over and continues to broadcast the unfinished state change request according to the latest offset of the commit log.

[0017] As a preferred scheme of the insurance product process management method based on the multi-policy hybrid mode, the state verification algorithm includes:

[0018] The unique identifier is generated after the state data of each channel node is normalized and serialized; the state data includes the rate version, the sales rule version, the on-off shelf state and the dependent configuration;

[0019] Each channel node exchanges the unique identifier with each other and accounts with the master node according to the set heartbeat period;

[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 scheme of the insurance product process management method based on multi-strategy hybrid mode, wherein: the timeout optimization strategy adopts a sliding time window to statistically process the response time delay of each node, calculates the waiting threshold of each timeout level according to the quantile threshold, and dynamically updates the retry number and the backoff interval when the node level changes;

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

[0040] Step D1, on the response time delay sequence of the node First, robust clipping is performed to reduce the disturbance of abnormal values to the threshold:

[0041] ,

[0042] Wherein, represents the clipped sample, represents the original sample, represents the median in the window, represents the clipping multiple, represents the robust scale based on the absolute deviation of the median, , respectively represent the minimum value and the maximum value operation;

[0043] Step D2, on the sliding window with a length of , the empirical quantile is calculated according to the quantile set :

[0044] ,

[0045] Wherein, represents the empirical quantile of the node at time corresponding to the timeout level , represents the ordinal statistical function of the th order, represents the upward rounding, represents the th quantile, represents the number of samples in the window, represents the number of timeout levels, represents the clipping sequence obtained in step D1;

[0046] Step D3, the quantile sequence is updated by exponential weighting:

[0047] ,

[0048] Wherein, ​denotes the smoothed quantile, denotes the smoothing factor, denotes the last time point;

[0049] Step D4, the ranking is given based on the smoothed quantile and the robust scale the waiting threshold and the back-off time of the retry:

[0050] ,

[0051] wherein, denotes the waiting threshold of the retry, denotes the minimum of the two, denotes the cap, denotes the smoothed quantile of step D3, denotes the scale bias coefficient, denotes the robust scale of step D1, denotes the back-off reference coefficient, denotes the retry serial number, denotes the back-off type, denotes the exponential growth factor.

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

[0053] calculating a priority weight for a state change request according to a change event type, a channel weight, historical stability, and compliance requirements;

[0054] when there are multiple conflicting state change requests, sorting and preempting the multiple conflicting state change requests according to the priority weights;

[0055] recording a conflict resolution log when performing conflict resolution, and the conflict resolution log is associated with a commit log for subsequent auditing and playback.

[0056] In a second aspect, an embodiment of the present application provides a computer device, including a memory and a processor, and the memory stores a computer program, wherein the computer program is executed by the processor to implement any step of the insurance product process management method based on the multi-strategy hybrid mode according to the first aspect of the present application.

[0057] In a third aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, wherein the computer program is executed by a processor to implement any step of the insurance product process management method based on the multi-strategy hybrid mode according to the first aspect of the present application.

[0058] The application has the advantages that: the application takes an event-driven multi-strategy hybrid architecture as the core, substantially reduces the out-of-order and repeated execution risks in the concurrent scene through the single commit semantics of the control plane guaranteed by the lease master node and the majority confirmation, and upgrades the consistency check between channels from the coarse-grained version number comparison to the fine-grained content check by taking the version unique identifier as an anchor point to incorporate the environment and product domain information into the abstract context, combining heartbeat reconciliation, normalized serialization, and content definition blocking, so that the missing commit can be replayed in order or the differential synchronization can be performed after the deviation is found, less relying on full coverage and shortening the abnormal window; under the conditions of network jitter and node heterogeneity, the timeout optimization strategy dynamically matches the latency distribution of each channel based on the quantile threshold and hierarchical backoff of robust statistics, reduces the long-tail waiting and cascading timeout; the rule engine calculates the priority and conflict preemption of multiple changes, first guarantees the achievement of high-weight channels and key changes, and then promotes long-tail nodes, thereby improving the overall throughput and convergence order; the commit log and conflict resolution log form a traceable release evidence chain, facilitating audit and compliance verification; when the repair fails, the system automatically rolls back to the latest consistent version, ensuring the consistency and predictability of external display. Thus, without relying on centralized locks and manual sampling, the consistency enhancement, recovery acceleration, and operation and maintenance automation of cross-environment and cross-channel release are realized. BRIEF DESCRIPTION OF DRAWINGS

[0059] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as limiting the scope of the present application.

[0060] Figure 1 The flowchart of the insurance product process management method based on the multi-strategy hybrid mode in the embodiments. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solutions and advantages of the present application more clear, the following will further illustrate the present application in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and should not be regarded as limiting the present application.

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

[0063] For example, the terms "first", "second", etc. used in the present application are only used to distinguish the description of similar objects, to distinguish the first object from another object, and are not used to describe a specific order or sequence, nor can be understood 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. 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 roll back to the previous consistent version.

2. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 1, characterized in that, 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.

3. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 2, characterized in that, The master node is elected and renewed through a lease mechanism; when the master node fails 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.

4. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 1, characterized in that, 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.

5. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 4, 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.

6. 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.

7. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 6, 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.

8. The insurance product process management method based on a multi-strategy hybrid mode as described in claim 1, characterized in that, 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; 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.

9. 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 8.

10. 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 8.

Images