Insurance policy system data migration method and device based on MQ message queue

Abstract

The invention relates to the technical field of data storage processing, and discloses an insurance policy system data migration method, device and equipment based on an MQ message queue, and a medium, and the method comprises the steps: carrying out the fragmentation of data according to the data characteristics of a health insurance policy system, the insurance policy type, the time range and the customer region, and carrying out the parallel processing of the fragmented data; performing format conversion on the processed data, and after the data format is determined to be consistent with the format supported by the message queue, packaging the converted data into a message and sending the message to the MQ message queue; parameters of the MQ message queue are configured according to actual requirements, and the MQ message queue is partitioned and copied. The method can be applied to development of business systems such as financial science and technology, medical health, old-age care and the like, massive insurance policy data are stored in a scattered mode through data fragmentation, and the stability and reliability of the system, the data processing efficiency and the throughput capacity are improved through a partitioning and duplicating mechanism of a message queue (MQ).

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data storage processing, and in particular to a policy system data migration method and device based on an MQ message queue, equipment and a medium. BACKGROUND

[0002] In the development of financial technology, medical health and pension business systems, health insurance policy systems have gradually become an important support for the core business of insurance companies. However, with the continuous expansion of business scale, the upgrading and optimization of system architecture, and the popularity of cloud computing environment, the health insurance policy system is facing frequent data migration needs. For example, in the scenarios of system upgrading, architecture adjustment, cloud environment migration or business integration, a large amount of historical policy data needs to be migrated from the old system to the new system or the target platform. However, the traditional data migration method has problems when processing health insurance policy system data: performance bottleneck: health insurance policy systems usually involve massive data, including policy information, customer information, claim records, etc. The data is large in size and complex in structure. Traditional data migration methods (such as direct data replication or database migration tools) may cause significant performance degradation of the system when processing large-scale data, and even affect the normal operation of the business. SUMMARY

[0003] The present application provides a policy system data migration method and device based on an MQ message queue, a computer device and a medium to solve the technical problem that the existing technology cannot cope with model failure under frequent policy changes, resulting in significant performance degradation of the system when processing large-scale data.

[0004] In a first aspect, a policy system data migration method based on an MQ message queue is provided, comprising:

[0005] According to the data characteristics of the health insurance policy system, the data is divided into shards according to the policy type, time range and customer area, and the divided data is processed in parallel;

[0006] The processed data is converted to a format consistent with the format supported by the message queue, and the converted data is encapsulated as a message and sent to the MQ message queue;

[0007] According to the actual demand, the parameters of the MQ message queue are configured, and the MQ message queue is partitioned and replicated;

[0008] Read the message in the MQ message queue, convert the data in the message to ensure that the data format is consistent with the requirements of the target system, and then write the converted data into the target system to complete the data migration.

[0009] In a second aspect, a policy system data migration device based on an MQ message queue is provided, comprising:

[0010] The slicing module is configured to slice the data according to the data characteristics of the health insurance policy system, slice the data according to the policy type, time range and customer area, and perform parallel processing on the sliced data.

[0011] The conversion module is configured to convert the processed data, encapsulate the converted data into a message after determining that the data format is consistent with the format supported by the message queue, and send the converted data to the MQ message queue.

[0012] The configuration module is configured to configure the parameters of the MQ message queue according to actual needs, and partition and replicate the MQ message queue.

[0013] The reading module is configured to read the message in the MQ message queue, convert the data in the message, write the converted data into the target system after ensuring that the data format is consistent with the requirements of the target system, and complete the data migration.

[0014] In a third aspect, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above-mentioned policy system data migration method based on the MQ message queue when executing the computer program.

[0015] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program implements the steps of the above-mentioned policy system data migration method based on the MQ message queue when executed by a processor.

[0016] The above-mentioned policy system data migration method based on the MQ message queue, the device, the computer device and the storage medium implement the scheme, which can slice the data according to the data characteristics of the health insurance policy system, slice the data according to the policy type, time range and customer area, and perform parallel processing on the sliced data; convert the processed data, encapsulate the converted data into a message after determining that the data format is consistent with the format supported by the message queue, and send the converted data to the MQ message queue; configure the parameters of the MQ message queue according to actual needs, and partition and replicate the MQ message queue; read the message in the MQ message queue, convert the data in the message, write the converted data into the target system after ensuring that the data format is consistent with the requirements of the target system, and complete the data migration. In the present application, the system stability and reliability are improved, the data processing efficiency and throughput are improved, the business adaptability and flexibility are enhanced, the data consistency and accuracy are ensured, the system maintenance cost and risk are reduced, and the sustainable development of the business is supported. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0018] Figure 1 is an application environment schematic diagram of the policy system data migration method based on the MQ message queue in an embodiment of the present application;

[0019] Figure 2 is a flow schematic diagram of the policy system data migration method based on the MQ message queue in an embodiment of the present application;

[0020] Figure 3 is a structure schematic diagram of the policy system data migration device based on the MQ message queue in an embodiment of the present application;

[0021] Figure 4 is a structure schematic diagram of the computer device in an embodiment of the present application;

[0022] Figure 5 is another structure schematic diagram of the computer device in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be described clearly and completely in the following with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by those skilled in the art without any creative effort belong to the protection scope of the present application.

[0024] The policy system data migration method based on the MQ message queue provided by the embodiments of the present application can be applied in, for example, Figure 1In the application environment, the client shards the data according to the data characteristics of the health insurance policy system, according to the policy type, time range and customer area, and performs parallel processing on the sharded data; the processed data is format-converted, and after the data format is determined to be consistent with the format supported by the message queue, the converted data is encapsulated as a message and sent to the MQ message queue; the parameters of the MQ message queue are configured according to actual needs, and the MQ message queue is partitioned and replicated; the messages in the MQ message queue are read, the data in the messages is format-converted, and after the data format is ensured to be consistent with the requirements of the target system, the converted data is written into the target system to complete the data migration. In the present application, the system stability and reliability are improved, the data processing efficiency and throughput are improved, the business adaptability and flexibility are enhanced, the data consistency and accuracy are ensured, the system maintenance cost and risk are reduced, and the sustainable development of the business is supported. The client can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of multiple servers. The present application will be described in detail below through specific embodiments.

[0025] Referring to Figure 2 , as shown in the drawings, Figure 2 A flowchart of a policy system data migration method based on an MQ message queue provided by an embodiment of the present application is shown, and includes the following steps:

[0026] S10: According to the data characteristics of the health insurance policy system, the data is sharded according to the policy type, time range and customer area, and the sharded data is processed in parallel;

[0027] Health insurance policy data has the characteristics of large quantity (tens of millions to hundreds of millions), strong time sequence (related to the time of insurance, the time of taking effect), various types (great differences in rules of different types of insurance), and regional correlation (the place of residence of the customer affects the underwriting and claim settlement). The core attributes and characteristics of health insurance policy data are as follows, which directly determine the selection of the sharding dimension: the policy type at least includes: medical insurance (medical insurance, outpatient insurance), critical illness insurance, and cancer insurance according to the scope of protection; individual insurance and group insurance according to the sales channel; the field structure (such as the number of insured persons in group insurance) and business rules (such as the need for underwriting of disease history in critical illness insurance) of different types of insurance are very different, and separate sharding can reduce the processing complexity. The time attribute at least includes the time of insurance, the time of taking effect, the payment period (annual payment / monthly payment), and the protection period (1 year / long-term). Policy operations (such as renewal reminders and expiration termination) and data analysis (such as quarterly premium statistics) rely on time ranges, and sharding by time can improve the efficiency of time-related tasks. The customer area at least includes: the place of residence of the customer (province / city), the insurance area, and the claim settlement service area (related to medical insurance policies and offline service networks); health insurance is affected by regional policies (such as local medical insurance directory and claim settlement process), and sharding by region can adapt to local business and facilitate the deployment of resources (such as regional claim settlement systems) nearby. The data size at least includes: a single policy contains basic information (insured person, insured person), protection responsibility, and payment records, and the annual increment can reach tens of millions; the data volume needs to be split by sharding to avoid excessive storage / processing pressure on a single node. The access frequency at least includes: recent effective policies (such as in the past year) are accessed frequently (claim settlement and policy maintenance); historical policies (such as 5 years ago) are mostly queried or archived; time sharding can combine access frequency to deploy hot data (recent) on high-performance nodes and cold data (historical) on low-cost storage.

[0028] The sharding design needs to define the sharding dimension, rule, and granularity in combination with the business scenario (such as underwriting, claim settlement, and report statistics) to ensure that the data after sharding can be processed independently and aggregated as needed.

[0029] Sharding by "Policy Type": Isolate data according to business rules, with the shard dimension defined as "Policy Type + Subtype" as the primary shard key. For example: Primary Type: Medical Insurance, Critical Illness Insurance, Cancer Insurance, Accident Insurance (related to health insurance); Subtype: Medical Insurance is divided into "Million Medical Insurance", "Outpatient Medical Insurance", "Tax-Optimized Health Insurance" (rules differ greatly, such as tax-optimized insurance related to individual tax deduction). Sharding rules, core logic: Policies of the same type are stored in the same shard (or shard cluster), and different types are physically isolated. Implementation: Through data table splitting (such as policy_medical (medical insurance table), policy_critical (critical illness insurance table)) or distributed storage "type routing" (such as column family isolation in HBase). Sharding granularity selection, granularity should not be too fine (avoid excessive number of shards, increase management cost): For example, do not subdivide by "sales channel + type", but distinguish by field (channel) within the type shard. Typical scenario adaptation: When the underwriting system handles critical illness insurance, it only needs to access the critical illness insurance shard, without the need to scan other type data, improving efficiency.

[0030] Sharding by "Time Range": Split hot and cold data by time sequence. Sharding dimension definition, with "policy effective time" or "policy application time" as the secondary shard key (usually combined with policy type to form "type + time" compound shard). Sharding rules, split by "time granularity": Choose granularity (year / quarter / month) according to data volume and access frequency: Hot data (last 1-2 years): shard by "month" (frequent access, fine granularity, easy to quickly locate); Warm data (2-5 years): shard by "quarter" (medium access frequency); Cold data (more than 5 years): shard by "year" (mostly for archival queries, coarse granularity, reduce storage cost). Example: In the medical insurance shard, further split by effective time into policy_medical_202401 (effective in January 2024), policy_medical_202402, etc. Sharding granularity selection, avoid too coarse granularity (such as only shard by year, single table data volume still reaches millions) or too fine granularity (such as monthly shard, 10 years is 120 shards, management is complex); Dynamic adjustment: If the data volume of a certain month increases sharply (such as during the opening red period), the month can be further split into "first half month / second half month".

[0031] Sharding by "customer area": Adapt to local needs by region. Sharding dimension definition, with "customer's permanent residence (province / city)" or "insurance area" as the three-level sharding key (usually combined with "type + time" to form a three-dimensional composite sharding). Sharding rules, split by administrative region level: first-level region: shard by "province" (such as Guangdong, Zhejiang, Jiangsu, applicable to provincial medical insurance policy correlation scenarios); second-level region: subdivide by "city" for large provinces (such as Guangdong) (Guangzhou, Shenzhen, due to economic level differences, insurance / case handling needs differ). Implementation: On the basis of "type + time" sharding, route storage by region (such as "regional sharding key" routing of distributed databases). Sharding granularity selection, combined with business coverage: If business is only conducted in first- and second-tier cities, shard by "city"; if covering the whole country, prefer to shard by "province"; avoid "data skew": For regions with few customers (such as Tibet, Qinghai), combine into "Northwest Region" shard to avoid wasting sharding resources.

[0032] In practical applications, sharding needs to combine multiple dimensions to form a "locatable and isolable" sharding unit. For example: Sharding identifier: [policy type]-[effective year quarter]-[customer province], specific sharding: medical insurance-2024Q1-Guangdong, critical illness insurance-2023Q4-Zhejiang. Data routing: A million medical insurance policy issued in March 2024 for a Guangdong customer will be routed to the "medical insurance-2024Q1-Guangdong" shard.

[0033] The core of parallel processing is to break down "global tasks" into "shard-level sub-tasks", which are executed simultaneously by multiple nodes, and finally aggregate the results. The process needs to be designed in combination with distributed computing frameworks and business scenarios. The parallel processing architecture is based on the "sharding-task-execution-aggregation" four-step process, relying on distributed computing engines (such as Spark, Flink) or distributed task scheduling platforms (such as XXL-Job) for implementation: Sharding metadata management: Store sharding rules (such as type, time, and region division logic) and sharding locations (such as storage node addresses, table names) through "sharding center"; Task decomposition: After receiving a global task (such as "statistical 2024Q1 medical insurance premium of each province"), break it down into "medical insurance premium statistics of each province-2024Q1 shard" sub-tasks; Parallel execution: Schedule multiple computing nodes to handle different shard sub-tasks simultaneously (nodes can be allocated based on region to reduce data transmission); Result aggregation: Collect all sub-task results and aggregate them according to business rules (such as adding up the premiums of each province to generate total national data).

[0034] Automatic generation of sub-tasks based on shard metadata: For example, if the time range of a statistical task is "2023-2024", all time shards from "2023Q1 to 2024Q4" are automatically matched; sub-tasks are distributed through message queues (MQ): for example, "Guangdong shard task" is sent to the MQ queue of "South China regional computing nodes", and the nodes execute after consumption.

[0035] Localized reading: shard data is stored in nodes corresponding to the region (e.g., Guangdong shard exists in South China machine room), and the computing node reads nearby to reduce cross-regional network delay; shard index: a secondary index is established within the shard (e.g., by "policy number" and "insured ID"), which improves the query efficiency within a single shard.

[0036] The key to the shard and parallel processing of the health insurance policy system is to achieve "data isolation" and "task decomposition" based on business characteristics (type, time, region): different business rules are isolated by policy type, hot and cold data are split by time range, and local needs are adapted by customer region; then rely on distributed architecture to execute tasks in parallel, ultimately improve system processing efficiency and scalability. In actual implementation, the shard granularity needs to be dynamically optimized according to the data size and access mode, and technical means need to be used to solve the problems of skew and consistency, so as to achieve "efficient and stable" parallel processing.

[0037] Among them, step S10 includes: according to the data characteristics of the health insurance policy system, storing the same type of policy in the same shard, selecting granularity for splitting and sharding according to data volume and access frequency, and splitting according to administrative region level; store shard rules and shard location, and schedule multiple computing nodes to simultaneously and in parallel process sub-tasks of different shards; collect all sub-task results and aggregate them according to business rules.

[0038] In the health insurance policy system, the design of data sharding, parallel processing and result aggregation needs to closely fit the business characteristics. Health insurance policy data has characteristics such as diverse types (such as medical insurance, critical illness insurance, etc.), regional correlation (affected by provincial medical insurance policies), and uneven access (frequent recent policy inquiries), so a complete link needs to be built from shard rules, storage management, parallel scheduling to result aggregation.

[0039] Sharding by policy type to achieve business logic isolation: different types of health insurance policies (such as medical insurance, critical illness insurance, and cancer prevention insurance) have significant differences in underwriting rules, claims processing, and data fields. For example, medical insurance needs to record the number of outpatient / hospital visits and other high-frequency claims-related fields, while critical illness insurance needs to associate with specific disease categories and diagnosis times. Storing the same type of policy in the same shard can avoid the complexity of mixed storage of different business logic data - subsequent underwriting review or claims statistics can directly locate the corresponding shard without the need to scan irrelevant data.

[0040] Adjust the granularity of sharding dynamically according to data volume and access frequency. The growth and access frequency of policy data differ significantly: some types of insurance (such as million medical insurance) have a large number of policies, and a single type of policy may accumulate tens of millions of data. Among the same type, the policies of the past year are frequently accessed due to the need for renewal, claims, and other demands (hot data), while the policies of five years ago are mostly archived for queries (cold data). Therefore, the granularity needs to be split according to data volume and access frequency: when the data volume of a shard exceeds a preset threshold (such as 10 million), it is automatically split into smaller sub-shards; fine-grained sharding (such as splitting by month) is used for hot data to improve query efficiency; coarse-grained sharding (such as splitting by year) is used for cold data to reduce storage costs.

[0041] Sharding by administrative region level to adapt to regional needs. Health insurance business is highly dependent on regional policies: medical insurance directories, claim reimbursement ratios, and offline service network distribution vary by province (e.g., the scope of special medicine reimbursement in Guangdong Province differs from that in Zhejiang Province). Splitting shards by administrative region level (province → city → county) can store policies for a region together - for example, all policies in Guangdong Province are stored in a single large shard, and Guangzhou and Shenzhen are split into separate sub-shards due to their larger business volume. This design allows regional businesses (such as Guangdong Province's claim review) to directly access local shards, reducing cross-regional data transmission and facilitating integration with local medical insurance systems.

[0042] Sharded data needs to be managed and scheduled through standardized storage mechanisms to support subsequent parallel processing. The storage management of sharding rules and locations requires a special "shard metadata center" to record all core information of shards: including the splitting rules of shards (such as "Guangdong Province + medical insurance + 2024"), physical storage locations (such as the IP and disk path of the corresponding server), and shard status (whether available, whether in the process of splitting), etc. The metadata center needs to ensure high availability (multiple node backups) and real-time synchronization of shard changes - when new shards are added, existing shards are split, or storage locations are migrated, the metadata is automatically updated to ensure that computing nodes can always obtain the latest shard information.

[0043] Multiple computing nodes process sub-tasks in parallel. Based on the independence of shards, the global task can be divided into multiple sub-tasks, which are executed in parallel by different computing nodes. For example, the task of "statistical annual premium of national medical insurance" can be divided into sub-tasks such as "statistical annual premium of medical insurance in Guangdong Province" and "statistical annual premium of medical insurance in Zhejiang Province", each corresponding to a regional shard. The scheduling system assigns sub-tasks to the computing node closest to the shard storage location (such as the node deployed in the South China data center for Guangdong Province shard) based on the information from the metadata center, reducing data transmission delay. At the same time, the scheduling system monitors the load of each node and dynamically migrates some sub-tasks to idle nodes if a node is processing slowly to ensure overall efficiency.

[0044] Sub-task result aggregation and business rule integration: After each computing node completes the sub-task, it needs to aggregate the results according to the business logic to form the final output. The collection and verification of sub-task results: After each computing node processes the corresponding shard sub-task, it will send the results (such as the total premium of a certain area, the number of claims) to the aggregation node. The aggregation node first verifies the results: checks whether there is data missing (such as a shard not returning results due to node failure), whether it meets the business logic (such as a negative premium amount). If an exception is found, a retry mechanism (rescheduling the corresponding sub-task) or marking the abnormal shard will be triggered to ensure the accuracy of the input aggregation data.

[0045] Aggregating results according to business rules: The core of aggregation is to integrate sub-task results according to health insurance business needs. For example: simple aggregation: the total premium of the country = the sum of the provincial shard premiums; regional rule aggregation: the claim amount of some provinces needs to be multiplied by the adjustment coefficient according to local policies (such as an additional 5% subsidy for special medicine claims in Guangdong Province), which needs to be applied first and then accumulated during aggregation; hierarchical aggregation: first aggregate the municipal shard results (such as Guangzhou City, Shenzhen City), then combine them into the total result of Guangdong Province, and finally aggregate the national results. Through this hierarchical aggregation method, it can ensure that the results meet the regional and type business rules, and also improve the overall efficiency through parallel processing.

[0046] The shard design of the health insurance policy system is centered on business characteristics: through three-dimensional splitting of type, data volume, and region, logical isolation and load balancing of data are achieved; with the help of the metadata center to manage shard information, parallel scheduling of computing nodes is supported; finally, through rule-based aggregation, results that meet business needs are output. This architecture can not only handle the storage pressure of millions of policies, but also meet the efficient processing needs of scenarios such as underwriting and claims, while adapting to the core characteristics of health insurance regionalization and typization.

[0047] S20: Format conversion of processed data, after determining that the data format is consistent with the format supported by the message queue, the converted data is packaged as a message and sent to the MQ message queue;

[0048] In health insurance policy systems, after data is processed in parallel through sharding, it needs to be transferred to downstream systems (such as underwriting systems, claims systems, and data analysis platforms) via message queues (MQ). This ensures that the data format is compatible with the formats supported by MQ, and guarantees the accuracy and reliability of data transmission through standardized message encapsulation and sending mechanisms. Different MQ products (such as RabbitMQ, Kafka, and RocketMQ) have varying levels of native support for message formats, but all primarily use structured data formats (such as JSON and XML) (binary formats are mostly used in special scenarios). The goal of format conversion is to transform the processed raw data (which may be database table records, CSV files, internal objects, etc.) into a format that MQ can transmit and downstream systems can parse. JSON is preferred (as it has the strongest universality), with XML or binary formats chosen only in special scenarios (such as integration with legacy systems or high-performance requirements).

[0049] The processed data may be in various formats (such as database query results, Java objects, CSV row data), and needs to be converted to the target format in three steps: "field mapping → type adaptation → structure adjustment". For example: Database table records (Row) - extract fields from the table (such as policy_id, insured_name), map them to JSON key-value pairs - table field policy_type (value "medical insurance") → JSON field "policyType":"medical insurance"; Internal business objects (POJO) - directly convert the object to JSON using serialization tools (such as Jackson, FastJSON) - Java object Policy{id:

[0050] "P2024001",status:"Effective"}→{"id":"P2024001","status":"Effective"}; CSV file (row data) - Parse each row according to the CSV header (e.g., "Policy Number, Policyholder, Effective Date") and map it to JSON fields - CSV row "P2024001,Zhang San,2024-01-01"→{"policyId":"P2024001","insurer":"Zhang San",...}.

[0051] Convert database underscore naming (e.g. policy_id) to JSON camelCase (policyId) to match downstream system parsing conventions; convert date types (e.g. 2024-01-01) to strings to avoid JSON's default serialization differences; preserve numerical types (e.g. premium 1000.50) with original precision to avoid data loss from integer conversion; nest complex data (e.g. policyholder information including name, ID, phone) in JSON objects to avoid field redundancy; explicitly mark null for empty fields (e.g. beneficiary not filled) to avoid misjudgment of "field missing" during downstream parsing.

[0052] Ensure the converted data format is correct through "conversion tool + verification mechanism"; use tools like Jackson (Java), Pandas (Python) for automatic conversion; define custom conversion logic (e.g. use template engine Freemarker to define JSON output template); define format rules based on JSON Schema (e.g. policyId is a required string, premium is a positive number); check converted data with verification tools (e.g. JSON Schema Validator) and return errors and retry conversion if not qualified.

[0053] Converted JSON data needs to be further encapsulated as "MQ messages" - in addition to business data, message metadata (e.g. message ID, timestamp, topic) needs to be added for MQ routing, downstream system processing, and problem troubleshooting. A standard MQ message should include "metadata (Header)" and "business data (Body)", structure as follows:

[0054] Message metadata (Header) - messageId: unique message identifier (e.g. UUID, used for deduplication and tracking), - topic: message topic (e.g. "policy_apply", used for MQ routing), - timestamp: message generation time (millisecond level, convenient for time series analysis), - source: message source (e.g. "health insurance policy system", identifies the sender), - tags: message tags (e.g. "medical, 2024", used for fine-grained filtering), used for MQ routing (by topic / tags), message tracking (messageId), source identification (source). Business data (Body), business data after format conversion (e.g. policy application information, claim application data), the core processing object of downstream systems (e.g. underwriting system based on policy information in Body for review).

[0055] To ensure data consistency, we need to standardize the packaging. First, the metadata must be filled in: messageId (unique), topic (routing basis), and timestamp (timing basis) are mandatory, and others are optional. Business data integrity: Body must contain the necessary fields for downstream systems (such as the "insured person's ID number" and "policy type" for the underwriting system), to avoid errors caused by missing fields in downstream systems. Sensitive data processing: sensitive information such as ID numbers and mobile phone numbers should be encrypted (such as AES encryption) before being placed in Body to avoid leakage during transmission. Message size control: the size of a single message should not be too large (Kafka recommends no more than 1MB), and large data (such as policy attachments) should be stored in object storage (such as OSS) first, and only the file address should be stored in Body.

[0056] After the message is packaged, it needs to be sent to the MQ cluster through the MQ client SDK. The sending process needs to ensure "correct routing", "reliable transmission", and "monitoring", and the core process is as follows: load MQ connection parameters (such as Broker address, port, username and password); initialize the client instance (such as RabbitMQ's ConnectionFactory and Kafka's Producer); specify the topic corresponding to the message (such as "policy apply" for "policy apply"); if you need to fine-tune the routing (such as sending to different consumers by region), configure tags or keys (such as Kafka's partition key).

[0057] Different MQs provide multiple sending methods, which need to be selected based on the requirements of "reliability" and "real-time" of the business: synchronous sending, waiting for the Broker to return the result (success / failure) after sending, which is highly reliable but time-consuming (milliseconds). Asynchronous sending, which returns immediately after sending, and the Broker notifies the result through callback, which is short in time but requires handling asynchronous callback logic. One-way sending, which does not wait for the result after sending, is the most optimal in performance, but cannot confirm whether it has been delivered.

[0058] Message sending is not "one and done", and needs to be handled through retry mechanisms, persistence, monitoring, and other means to deal with abnormal scenarios such as network fluctuations and Broker failures. When the sending times out, the Broker returns "sending failed" (such as queue full), or the network is interrupted; retry times: core business (such as insurance) retries 3-5 times, non-core business retries 1-2 times; retry interval: use "exponential backoff" (such as 1s, 2s, 4s) to avoid frequent retries exacerbating Broker stress; retry upper limit: after exceeding the maximum number, store the message in the "local failed queue" (such as the database table failed_message), and resend it later through a scheduled task.

[0059] The configuration Broker will persist messages to disk (such as Kafka's log persistence, RocketMQ's CommitLog), ensuring that the Broker restarts without losing messages;

[0060] Business level: Before sending, temporarily store the message in the local (such as a database), and delete it after receiving the "send success" returned by the MQ, to avoid message loss caused by client crash ("local transaction table" solution).

[0061] Query message status (whether sent successfully, whether consumed) through messageId in MQ console; record key information of sending process (messageId, sending time, result, time consumption) for easy troubleshooting; send success rate (alarm below 99.9%), average time consumption (alarm over 100ms); abnormal alarm: trigger alarm (such as SMS, DingDing notification) when consecutive sending fails, local failure queue message accumulation (over 100). Network delay may cause "sender does not receive successful response and retries", but the Broker has actually received, causing message duplication; sender: based on messageId, send only once for the same messageId (local cache has sent messageId); consumer: downstream system needs to support "duplicate message idempotent processing" (such as through messageId or policyId to determine whether it has been processed).

[0062] The complete link for sending processed data to MQ is: raw data → format conversion (adapt to JSON format supported by MQ) → message packaging (add metadata and business data) → send through MQ client (choose synchronous / asynchronous mode) → ensure reliability through retry, persistence, monitoring. The core goal is to ensure that data can be sent, not lost, can be parsed, and can be traced, providing stable data input for downstream systems. In the health insurance scenario, special attention should be paid to the message reliability of core business (such as insurance, claims) (synchronous sending + retry + persistence), and the encryption processing of sensitive data, while reducing the parsing cost of downstream systems through standardized message structure.

[0063] S30: According to actual demand, configure parameters of MQ message queue, and partition and replicate MQ message queue;

[0064] Different MQ products (such as Kafka, RocketMQ, RabbitMQ) have different implementation logic, but the design idea needs to be combined with business needs (such as the "high reliability, high throughput, regionalization" needs of the health insurance policy system). The following are from the "parameter configuration principles and core parameters", "partition (queue) design", and "replica strategy" dimensions. MQ parameter configuration needs to focus on business priority (core / non-core), performance requirements (throughput / delay), and reliability requirements (whether to allow loss) of the three core dimensions, avoiding "default configuration" or "over configuration". Different MQ parameter systems are different, so first clarify the general configuration principles, and then explain the core parameters of the mainstream products (Kafka, RocketMQ).

[0065] Core business priority ensures reliability: Health insurance "policy application" and "claim application" are core businesses that require parameters such as "message persistence, synchronous flushing, and retry mechanism" to ensure that messages are not lost; non-core businesses (such as policy status SMS notifications) can be configured more loosely to prioritize performance. High-throughput scenarios (such as batch policy archiving) can allow for some delay (such as 100ms) to improve efficiency through "batch sending, asynchronous flushing"; low-latency scenarios (such as real-time underwriting notifications) require reducing batch waiting and configuring "immediate sending, synchronous flushing (low frequency)". Parameters need to match server hardware (such as memory, disk IO), for example, mechanical hard drives are not suitable for high-frequency synchronous flushing (IO bottleneck), and need to be adjusted to asynchronous flushing + timing synchronization.

[0066] Different MQ parameter names and implementation logic are different, and need to be adjusted according to product characteristics: Kafka (health insurance high-throughput scenarios, such as policy log synchronization), Broker parameters: log.dirs: set multiple disk directories (separated by commas), distribute disk IO pressure (health insurance mass policy data needs to avoid single disk IO bottleneck); num.io.threads: IO thread number (recommended to set to disk number x 2, such as 4 disks → 8 threads), improve read-write efficiency; log.flush.interval.messages: asynchronous flushing message quantity threshold (core business set to 1000, non-core set to 10000). Producer parameters: linger.ms: batch sending waiting time (core business set to 5ms, non-core set to 20ms, accumulate more messages before sending); acks: message confirmation level (core business set to all: only all replica write success before confirmation; non-core set to 1: only leader write success); retries: sending retry number (core business set to 5, non-core set to 2).

[0067] RocketMQ (health insurance core business, such as policy underwriting, claims), Broker parameters: flushDiskType: flush type (core business set SYNC_FLUSH: synchronous flush; non-core set ASYNC_FLUSH: asynchronous flush); waitTimeMillsInSendQueue: message waiting timeout in sending queue (core business set 3000ms, avoid fast failure); Producer parameters: retryTimesWhenSendFailed: synchronous sending retry times (core business set 3); compressMsgBodyOverHowmuch: message compression threshold (compress over 4KB, reduce the transmission volume of health insurance large policy data).

[0068] RabbitMQ (health insurance lightweight scenarios, such as notification push), Exchange / Queue parameters: durable: queue persistence (open, avoid queue loss); auto_delete: whether to automatically delete the queue after consumption (closed, core queue needs to exist for a long time); Consumer parameters: prefetch_count: pre-pull message number (set 50, avoid consumer pulling too many messages at a time causing accumulation).

[0069] “Partition” (Kafka / RocketMQ) or “Queue” (RabbitMQ) is the core mechanism for MQ to implement parallel processing - by distributing messages of a Topic to multiple partitions (queues), achieving “producer parallel writing, consumer parallel consumption”. Design needs to combine business traffic, data distribution, and consumption capacity to avoid “data skew” (too many messages in a partition).

[0070] Distribute massive messages to multiple partitions to avoid single partition becoming a performance bottleneck (e.g. 100,000 TPS policy messages, distributed to 10 partitions, each partition only needs to handle 10,000 TPS); parallel consumption means that multiple consumers in a consumer group can consume different partitions simultaneously (1 consumer corresponds to 1 or more partitions), improving overall consumption speed; assign partitions according to business rules (e.g. health insurance “region”

[0071] “Policy type”) to achieve logical isolation of messages (e.g. Guangdong region's policy messages are fixed in partitions 1-3).

[0072] The number of partitions must meet the "throughput requirements" and avoid "over-partitioning" (increasing management costs and resource consumption). The formula is: number of partitions = peak TPS ÷ single-partition maximum processing capacity. Peak TPS: health insurance scenarios need to calculate the maximum traffic of core business (such as 5000 policy messages per second during peak insurance); single-partition maximum processing capacity: depends on hardware and configuration (Kafka single-partition about 1000-2000 TPS, RocketMQ about 2000-3000 TPS); for example: health insurance policy peak 5000 TPS, RocketMQ single-partition processing 2000 TPS, then at least 3 partitions (5000 ÷ 2000 ≈ 2.5, rounded up to 3). Additional considerations: the number of partitions should be ≥ the number of consumers (if the consumer group has 5 consumers, the number of partitions should be at least 5 to ensure that each consumer is assigned a partition); reserve expansion space (such as design based on 1.5 times the peak to avoid the need for re-partitioning when traffic surges).

[0073] Partition (queue) routing strategy (health insurance scenario adaptation), the routing strategy determines "which partition the message enters", the core goal is to avoid data skew (such as a certain partition has 10 times the message volume of others), and adapt to business logic (such as messages for the same policy enter the same partition to ensure consumption order).

[0074] Health insurance example: Topic "policy_apply" (policy insurance), 4 partitions, routing strategy "hash by customer area": Guangdong and Guangxi policy messages → partitions 0, 1 (South China region); Zhejiang and Jiangsu policy messages → partitions 2, 3 (East China region); consumer groups are deployed by region (South China consumers consume partitions 0, 1, East China consumers consume partitions 2, 3) to achieve "local consumption".

[0075] Partition design considerations to avoid excessive number of partitions: too many Kafka partitions can lead to metadata expansion and increased election time (it is recommended that a single Topic not exceed 100 partitions); data skew monitoring: regularly statistics each partition's message volume and consumption delay (such as if a certain partition has more than 100,000 messages accumulated, the routing strategy needs to be adjusted); partition expansion: plan for scalability in advance (such as Kafka supports increasing partitions by "replicating data", RocketMQ supports dynamically increasing queues).

[0076] Replica is the core of MQ to achieve high availability - by keeping the same message in multiple nodes, when a node fails, it can switch to other replicas to provide services. The design needs to balance reliability (number of replicas) and resource consumption (storage, network). Replicas are mainly used to avoid data loss caused by single node failure (such as Broker node downtime, replica node still retains messages); through "master-slave replication", data is synchronized between replicas, and after the master node fails, the slave node can switch to the master node to continue providing services; some MQs support reading messages from replicas (such as Kafka), which can share the read pressure of the master node.

[0077] The number of replicas (replication-factor) needs to be selected according to "reliability requirements" and "resource costs", the general principle is: the minimum number of replicas in production environment is 3: 1 leader replica + 2 follower replicas, which can tolerate 1 node failure (still 2 replicas survive); core business replica number ≥ 3: health insurance policy data cannot be lost, at least 3 replicas are required; non-core business replica number = 2: such as log messages, which can tolerate a lower probability of loss and reduce resource consumption.

[0078] Replicas need to be deployed on different physical nodes (even different machine rooms) to avoid "all losses". The health insurance scenario recommends "cross-node + same machine room" deployment (balance reliability and synchronization efficiency): basic deployment: 3 replicas are distributed in 3 different Broker nodes (same machine room): Leader in node A, Follower1 in node B, Follower2 in node C; after node A fails, a new Leader is elected from B / C, and data is not lost.

[0079] Cross-machine room deployment (core financial scenario): the master replica is in machine room A, and the two follower replicas are in machine room A and machine room B (disaster recovery in different places); when machine room A fails, the follower replica in machine room B can switch to the master replica (suitable for health insurance headquarters and branch center disaster recovery architecture).

[0080] Replica synchronization determines "how the master replica message is synchronized to the follower replica", which directly affects reliability and delay: synchronous replication, after the master replica receives the message, it needs to wait for all follower replicas to synchronize before returning "send success"; core business (such as claim application): ensure that the message is 100% synchronized to all replicas, no loss but high delay (10-50ms). Semi-synchronous replication, after the master replica receives the message, it waits for at least one follower replica to synchronize before returning "send success"; recommended for core business: balance reliability (at least one replica synchronization) and delay (5-20ms), such as policy underwriting. Asynchronous replication, the master replica returns immediately after receiving the message, and the follower replica synchronizes asynchronously (there is a short period of data inconsistency); non-core business: such as policy notification, which allows a short period of data inconsistency, and prioritizes low latency.

[0081] RocketMQ default "asynchronous replication", the core business needs to open "synchronous disk + master-slave synchronization" (through SYNC_MASTER configuration); Kafka through acks = all to achieve synchronous replication (wait for all replicas to synchronize), acks = 1 to achieve half synchronization (only the main replica writes).

[0082] MQ needs to have an automatic mechanism of "fault detection → replica switching" to ensure uninterrupted service: fault detection: monitor the status of the main replica through the "heartbeat mechanism" (such as Kafka's Controller, RocketMQ's Namesrv); replica switching: after the main replica fails, the slave replica becomes the new main replica through the "election mechanism" (such as Kafka's ISR, RocketMQ's BrokerController); health insurance scenario requirements: switching time needs to be ≤30 seconds (to avoid long-term unavailability of core policy business), and messages are not lost after switching (dependent on synchronization mechanism).

[0083] Combined with the needs of health insurance "core business high reliability, regional processing, peak throughput", take RocketMQ as an example to design the scheme: Topic: policy_core (core policy message: insurance, claim); flush strategy: SYNC_FLUSH (synchronous flush); send retry: 3 times; message TTL: 7 days; consumption retry: 10 times (core business allows multiple retries). Number of partitions: 6 (peak TPS 10000, single partition processing 2000 TPS); routing strategy: hash by "customer area + policy type": South China (Guangdong, Guangxi) + medical insurance → partitions 0, 1; South China (Guangdong, Guangxi) + critical illness insurance → partitions 2, 3; East China (Zhejiang, Jiangsu) + all types → partitions 4, 5. Consumer deployment: South China consumer group consumes partitions 0-3, East China consumer group consumes partitions 4-5 (regional parallel processing). Number of replicas: 3 (1 master 2 slave); deployment: master replica in node 1 of machine room A, slave replica in node 2 of machine room A and node 1 of machine room B (cross-machine room disaster recovery); synchronization mechanism: half-synchronous replication (at least 1 slave replica synchronization success before returning).

[0084] The parameter configuration, partition and replica design of MQ need to be "cored on business needs": parameter configuration, core business priority reliability (synchronous flushing, retry, long TTL), non-core business priority performance (asynchronous flushing, short TTL); partition design, determine the number according to "peak TPS + business routing", avoid tilt through hash routing, adapt to the regionalization and typization needs of health insurance; replica strategy, at least 3 replicas in production environment, semi-synchronous replication, cross-node deployment, ensure that core policy data is not lost and service is not interrupted. The ultimate goal is to make MQ support both "insurance peak throughput" and "claim data reliability" in health insurance, while improving consumption efficiency through regional partitioning.

[0085] Step S30 includes: fine tuning of MQ message queue parameters based on actual needs; distributing massive messages according to business rules, and saving copies of the same message in multiple nodes, when a node fails, it can switch to other copies to provide services.

[0086] Based on the actual needs of MQ parameter fine tuning, the core of MQ parameter tuning is "on-demand configuration" - the needs of different businesses for "reliability, throughput and delay" are very different, and need to be adjusted accordingly to avoid "one size fits all". The core of the tuning is based on business priority and scenario characteristics. In the health insurance scenario, businesses can be divided into "core" and "non-core" two categories, and the tuning direction is completely different: core business (such as policy insurance, claim application): it is necessary to absolutely guarantee "message not lost, not repeated", delay can be tolerated but needs to be stable (such as <100ms); non-core business (such as policy status SMS notification, statistical log): can accept low probability loss, priority high throughput, low resource consumption. Parameter tuning needs to focus on these two scenarios, and make differentiated configuration in the three dimensions of "reliability", "performance" and "exception handling".

[0087] Reliability parameters determine whether a message will be lost, and core services must be strictly configured, while non-core services can be appropriately relaxed. Message persistence: Core services must be enabled (messages are written to disk rather than just memory), avoiding data loss caused by server power failure or restart. For example, health insurance policy application messages need to be configured with a persistent path to multiple disks (to distribute IO pressure) and ensure that the write is successful before returning "send complete"; non-core services can also enable persistence, but can use a single disk to reduce costs. The disk flushing strategy is mainly to control the timing of writing messages from memory to disk. Core services require "synchronous disk flushing" (message is written to disk before confirming successful sending), or "semi-synchronous disk flushing" (at least one copy node is written to disk before confirmation) - for example, health insurance claim messages must wait for disk writing to complete before notifying the upstream "message received" to prevent critical data loss; non-core services can use "asynchronous disk flushing" (messages are first stored in memory, and accumulated to a certain amount or time before being written to disk in batches), which reduces the number of disk IOs to improve throughput (such as SMS notification messages, which accumulate 1000 messages before flushing in batches). Send confirmation mechanism, after sending a message, the Broker needs to return an "acknowledgment signal". Core services require "full confirmation" (all copy nodes receive and store the message before confirmation), for example, health insurance policy payment messages must be saved in the master and all slave nodes before being considered "sent successfully"; non-core services can use "single confirmation" (only the master copy is received before confirmation), reducing waiting time.

[0088] Performance parameters affect the efficiency of message sending / consumption, and need to match the traffic characteristics of the business (such as peak TPS, message size). Batch sending / consumption accumulates a certain amount of messages before processing them in batches, reducing network requests and disk IOs. Core services can set "small batch + short wait" (such as accumulating 100 messages or waiting 5ms before sending), to avoid high latency (such as policy application messages requiring fast response); non-core services can set "large batch + long wait" (such as accumulating 1000 messages or waiting 20ms), to improve throughput (such as batch sending of log messages, which can reduce 50% network requests). Thread resources: The number of consumer threads determines the parallel processing capability. Core services need to be configured with more consumer threads (such as 32-64), to match the message volume at peak times (such as 5000 messages per second during the policy application peak, requiring sufficient threads to quickly process to avoid accumulation); non-core services can reduce the number of threads (such as 8-16), to reduce server CPU usage. Network and IO configuration, core services require larger network buffers (such as 1MB) and IO threads (such as 8), to avoid network or disk becoming a bottleneck (such as a million medical insurance policy application peak, requiring sufficient IO threads to handle a large number of message writes); non-core services can use default configurations to save resources.

[0089] Abnormal processing parameters determine the behavior when sending / consuming fails, avoiding "invalid retries" or "message loss". Retry mechanism when message sending fails (such as network fluctuations). Core business needs "multiple retries + exponential backoff" (such as 3 retries, interval 1s→2s→4s), to deal with temporary failures (such as sending insurance messages fails, may be due to Broker node temporary overload, retry can be restored); non-core business can "less retries" (such as 1-2 times), to avoid excessive resource occupation. The maximum time for messages to remain in MQ. Core business needs to set a long TTL (such as 7 days), to ensure that downstream systems can still be consumed after failure recovery (such as the claim system is down for 3 days, restart can read messages 3 days ago); non-core business sets a short TTL (such as 4 hours), to avoid invalid messages occupying storage space for a long time. After multiple consumption failures, messages enter the dead letter queue instead of infinite retries. Core business must enable dead letter queue, and dead letter must be persisted and trigger alarm (such as insurance message dead letter needs manual intervention to troubleshoot); non-core business can enable dead letter queue, but dead letter can be automatically cleaned up regularly (such as notification message dead letter does not need manual processing).

[0090] Parameters are not fixed and need to be dynamically adjusted according to business load: pre-peak warm-up: before the "open door red" of health insurance and other insurance peaks, temporarily increase the number of consumption threads and expand the batch sending threshold to improve processing capacity; monitoring linkage: through monitoring tools to track "message accumulation" and "sending delay" in real time, if the core business accumulation exceeds 10,000, automatically adjust the number of consumption threads; configuration center: parameters are managed through the configuration center (such as Nacos), no need to restart the service to take effect (such as suddenly appearing claim peak, can start more IO threads in real time).

[0091] Mass messages need to be balanced through "partitioning" and switched through "replication", both of which support high concurrency and high availability. Partitioning is the basis for parallel processing of MQ - messages of a "Topic" (message topic) are dispersed to multiple partitions, enabling "producer parallel writing and consumer parallel consumption", avoiding single partition becoming a bottleneck.

[0092] The number of partitions needs to be calculated according to "peak TPS" and "single partition processing capacity": single partition processing capacity: mainstream MQ (such as RocketMQ, Kafka) can handle 1000-3000 messages per second per partition; partition number = peak TPS ÷ single partition capacity (rounded up). For example, health insurance peak of 5000 messages per second, single partition processing 2000, at least 3 partitions (5000 ÷ 2000 ≈ 2.5 → 3). At the same time, redundancy needs to be reserved (such as 1.5 times the peak value), to avoid sudden traffic crushing the system.

[0093] Routing rules determine "which partition a message enters", the core is "grouping by business logic", to avoid too many messages in a partition (skew). There are two common routing strategies in health insurance scenarios: routing by business identifier, and distributing by business rules to avoid load skew: messages with the same business identifier are distributed to the same partition. For example, route by "policy ID" - messages such as insurance, renewal, and claim for the same policy enter the same partition to ensure the order of consumption (avoid "claim messages before insurance messages are consumed"); route by region / type: group by business attributes. For example, route by "customer region + policy type" - medical insurance messages in Guangdong Province enter partitions 0-1, and medical insurance messages in Zhejiang Province enter partitions 2-3, which not only realizes regional consumption (South China node handles South China partition), but also avoids single partition accumulation. Routing rules need to avoid "random allocation" (which may lead to skew) to ensure even distribution of messages among partitions.

[0094] Replicas are "redundant storage of the same message on multiple nodes", the primary replica (Leader) is responsible for reading and writing, and the secondary replica (Follower) synchronizes the primary replica data. When the primary replica fails, it automatically switches to a secondary replica to ensure uninterrupted service. For core business, the more replicas there are, the higher the reliability (there are still backups when a node fails), but the more storage and network consumption: 3 replicas (1 primary and 2 secondary) - can tolerate 2 node failures (e.g. if the primary node and one secondary node fail, the remaining one secondary node can still provide service), health insurance policy and claim messages must be configured in this way; for non-core business, you can configure 2 replicas (1 primary and 1 secondary) - tolerate 1 node failure, reduce storage costs (e.g. notification messages).

[0095] Replicas need to be deployed on "different physical nodes" (even in different machine rooms) to avoid "all or nothing" (e.g. the primary and secondary replicas cannot be on the same server to prevent all replicas being lost if the server loses power). Replica synchronization determines whether the secondary replica is consistent with the primary replica data, and core business requires "semi-synchronization", while non-core business can be "asynchronous". Semi-synchronous synchronization, the primary replica receives a message and waits for at least one secondary replica to synchronize before confirming that the sending is successful (core business is required). For example, health insurance claim messages, the primary replica needs to wait for one secondary replica to synchronize before notifying the upstream "sending success" to ensure that the secondary replica has complete data when the primary replica fails. Asynchronous synchronization, the primary replica confirms immediately after receiving the message, and the secondary replica synchronizes asynchronously in the background (optional for non-core business). For example, notification messages, the primary replica receives and returns immediately, and the secondary replica synchronizes slowly, sacrificing a small amount of consistency for performance.

[0096] When the primary copy fails, MQ needs to automatically complete "detection → election → switching" to ensure that the business is not aware: fault detection, monitor the status of the primary copy through the "heartbeat mechanism" - the primary copy sends a heartbeat to the slave copy and the management node regularly, and if it is not sent within a certain time, it is determined to be a failure; New master election, select a new master from "synchronized slave copies" (prefer the latest data). For example, after the primary copy of the health insurance policy message fails, select one with complete data from the two slave copies as the new master; Seamless switching, the client (producer / consumer) automatically connects to the new master through the MQ routing update mechanism without human intervention. The switching time needs to be controlled within 30 seconds (core business requirement) to avoid business interruption.

[0097] Taking the health insurance "policy insurance" Topic as an example, the coordinated configuration of parameters, partitions, and copies is as follows: Parameters: persistent enabled, 3-copy semi-synchronous disk flushing, 3 retries for sending, TTL 7 days; Partitions: 4 partitions, routed by "customer area + policy type" (South China medical insurance → partitions 0-1); Copies: 3 copies (master in Guangzhou machine room, slave in Shenzhen machine room and Shanghai machine room), semi-synchronous synchronization. Effect: zero loss of insurance messages, single-partition TPS stable at 1000-1500, 30 seconds switching within node failure, business unaware.

[0098] The core of MQ tuning and partition copy design is "business-driven": parameter tuning needs to distinguish between core and non-core, core to ensure reliability, and non-core to ensure performance; Partitions are routed according to business rules to avoid skew and support parallel processing; The number and synchronization method of copies are configured according to reliability requirements to achieve seamless switching in case of failure. This design has been verified in the health insurance scenario: it can support high-concurrency processing of millions of policy messages and ensure zero loss and high availability of core business.

[0099] S40: Read the messages in the MQ message queue, format convert the data in the messages, ensure that the data format is consistent with the requirements of the target system, and then write the converted data into the target system to complete the data migration.

[0100] In the data migration scenario of the health insurance policy system, the process of reading messages from MQ and writing them into the target system involves four links: message consumption, format conversion, data writing, and exception handling. This process needs to ensure that data is not lost, not duplicated, and format compliant, while taking into account performance and stability. Reading messages from MQ needs to solve three core problems: "how to efficiently consume", "how to avoid duplicate consumption", and "how to handle consumption failure". Different MQ products (such as Kafka, RocketMQ) have different consumption mechanisms, but the core logic is consistent.

[0101] According to business needs, choose "push mode" or "pull mode": Push mode (Push), MQ actively pushes messages to consumers, and consumers do not need to actively request; high real-time requirement, high consumer processing capacity (such as real-time underwriting notification); recommendation: health insurance core business (such as insurance, claim) needs fast response, push mode can reduce delay (usually <10ms). Pull mode (Pull), consumers actively pull messages from MQ, and can independently control the pull frequency and batch size; unstable consumption capacity, batch processing scenario (such as batch migration of historical insurance policies).

[0102] MQ records the position of messages processed by consumers through "consumption site (Offset)", and needs to be reasonably managed to avoid duplicate consumption: automatic submission, after the consumer processes the message, MQ automatically updates the consumption site (such as Kafka's enable.auto.commit=true); not recommended: health insurance core business needs to strictly guarantee "only submit after successful processing", automatic submission may cause the site to be updated in advance, and the message is not processed but lost. Manual submission, the consumer explicitly calls the API to submit the site (such as Kafka's consumer.commitSync()); recommended: health insurance core business must be manually submitted to ensure that the site is updated only after the message is successfully processed (such as submitting after the insurance message processing is completed). Site persistence, store the consumption site in an external system (such as a database) instead of relying on MQ internal storage; recommended: when migrating health insurance across environments (such as from old MQ to new MQ), the site needs to be persisted to ensure breakpoint resume.

[0103] Health insurance core business (such as insurance policy underwriting, claim) must ensure that the message is "processed at least once", and a perfect failure retry mechanism needs to be designed: immediate retry, after consumption fails, immediately retry a fixed number of times (such as 3 times), and each time with increasing interval (such as 1s, 2s, 4s). Dead letter queue (DLQ), after exceeding the maximum retry number, send the message to the dead letter queue for manual or scheduled task processing. Degradation processing, for non-critical messages, record logs and skip after failure (such as insurance browsing records).

[0104] Messages read from MQ need to be converted to the format supported by the target system (e.g. JSON -> database table structure, XML -> object), involving three core operations: field mapping, type conversion, and structure reorganization. Conversion logic for format conversion: field mapping: map the nested fields in the MQ message (e.g. body.applicant.name) to the flat fields of the target table (applicant.name); type conversion: convert the string type date (2024-08-01) to the DATE type of the database; structure reorganization: split the single JSON message of MQ into multiple records (e.g. the main table policy_base and the associated table applicant). Common conversion tools: simple mapping relationship, use built-in libraries of programming languages (e.g. Jackson, Gson); complex mapping relationship, use tools (e.g. MapStruct, Dozer) to define mapping rules; dynamic mapping (e.g. select different mapping rules according to field values), use SpEL, OGNL, etc.

[0105] If the MQ message is missing a required field of the target system (e.g. policyId), record an error log and reject processing (core data of health insurance cannot be missing); type mismatch: if the date format is incorrect (e.g. 2024-08-32), try to convert (e.g. extract the valid part) or reject processing; data validation: perform business validation on key fields (e.g. premium amount) (e.g. the amount must be > 0), and if the validation fails, enter the DLQ.

[0106] Writing the converted data into the target system (e.g. database, cache, file) needs to solve the three core problems of "transaction consistency", "idempotency", and "performance optimization". Write mode selection: choose "single write" or "batch write" according to the characteristics of the target system: single write, process one by one, and when it fails, you can pinpoint the problem, but the performance is low (e.g. 1000TPS). Batch write, accumulate multiple data and write at once, high performance (e.g. 100,000TPS), but when it fails, it needs to be retried as a whole.

[0107] Health insurance core business (e.g. policy underwriting) must ensure that "repeated consumption of the same message will not produce duplicate results", the implementation method is: unique key constraint, set a unique key (e.g. policy_id) in the database table, and when writing repeatedly, the database will automatically reject it. State machine validation, the business layer validates the data state (e.g. the policy has "taken effect", then refuse to process the "underwriting" message repeatedly). Distributed lock, through Redis, etc. distributed lock, to ensure that the same message will not be processed by multiple consumers at the same time.

[0108] The core business of health insurance (such as "deduct the inventory + generate the policy") needs to ensure the consistency of cross-resource operations. The implementation method is: local transaction, multiple operations under the same database connection, atomicity is guaranteed through commit / rollback. Distributed transaction, operation across services / resources, coordinated through TCC (Try-Confirm-Cancel) or SAGA mode. Eventual consistency, allows temporary inconsistency, but eventually reaches agreement through retry or compensation mechanism (such as sending compensation messages through MQ).

[0109] The data migration process needs to design a "fuse-downgrade-alarm" mechanism to ensure that the system can still run stably in abnormal conditions. MQ connection exception, automatic reconnection (such as 3 times), exceeding the retry number triggers an alarm (such as SMS notification to operation and maintenance). Target system unavailable, open fuse (such as Hystrix), temporarily store messages in local queue (such as file, local database), retry after recovery. Data conversion failure, record error log, store original message and error information in "exception record table", and send to DLQ.

[0110] The data migration of health insurance policy system needs to build a complete link of "reliable consumption → accurate conversion → safe writing → intelligent fault tolerance": manual commit bit is used, combined with retry mechanism and dead letter queue to ensure that messages are not lost; complex field mapping is achieved through mapping tools, strict data quality verification; use unique key constraint, state machine and transaction mechanism to ensure idempotency and consistency; design fuse degradation, local queue cache, alarm mechanism to deal with system failure. Achieve "zero loss, zero error, high performance" migration of health insurance core data (such as policy, claim), support smooth upgrade of business system.

[0111] After step S40, the method comprises: after the data migration is completed, the migrated data is verified; the data of the source system and the target system are compared piece by piece to ensure data consistency; if inconsistent data is found, start the data repair process and re-migrate the failed data.

[0112] Before checking, the scope, benchmark and tools of the check should be clearly defined to avoid missing key data or ambiguous logic. The core objects of health insurance data migration include policy basic information (such as policy number, policyholder, coverage), associated data (such as payment records, claims records), business status (such as "effective" "terminated"), etc. The check scope should be targeted: 100% check of core business data (such as basic information of all valid policies) to ensure no missing; sampling (such as 10%) of non-core data (such as archived records of policies terminated five years ago) to balance efficiency and accuracy; double-checking of high-frequency access and high-value data (such as million medical insurance policies, large claims records) to avoid key data errors. At the same time, data that do not need to be consistent (such as target system internal ID generated during migration) should be excluded to avoid invalid comparison.

[0113] The check should be based on "source system data" (default source system data is accurate) and the determination criteria for "consistency" should be clearly defined: first, field-level consistency, target system field values should match the source system completely (such as "policyholder name" "policy effective date" should be exactly the same); format-level consistency, the format of date, amount and other fields should be unified (such as source system "2024-01-01" and target system "2024 / 01 / 01" should be considered as format difference, which needs to be converted before comparison); logic-level consistency, associated data should meet business logic (such as "premium amount" should equal "coverage x rate", the calculation results of source system and target system should be consistent). For example, the "payment status" field of health insurance policy, stored as "1 (paid)" "0 (not paid)" in the source system, if stored as "Y" "N" in the target system, it needs to be converted through mapping rules (1→Y, 0→N) before judging consistency.

[0114] An independent check environment should be built (to avoid affecting the production system) and check tools should be prepared: read source system and target system data in batches through scripts or professional tools (such as data comparison tools), automatically compare according to rules; for data that pass the automated check, extract a portion (such as 1%) for manual checking (focus on checking fields with complex format and multiple associations); tools should record all check processes (such as comparison time, inconsistent fields, error types) to facilitate subsequent tracing and repair.

[0115] The core means to ensure data consistency is to compare each item, which needs to cover the three levels of "field value, association, business logic" to avoid "surface consistency but logic error". By using unique identifier (such as policy number, policyholder ID) to locate the same data in the source system and the target system, for example, taking "policy number" as the key, read the policy information of "P2024001" from the source system, and at the same time read the information of the same policy number from the target system, to ensure that the comparison object is "the same data". For the two data located, compare each field one by one. For example, the health insurance policy needs to compare all core fields such as "policyholder name, ID number, coverage, effective date, payment status", and for sensitive fields such as amount and date, the accuracy needs to be up to two decimal places or specific date (such as "100000.00 yuan" and "100000 yuan" need to be considered consistent, and "2024-01-01" and "2024-01-02" need to be considered inconsistent).

[0116] The association information of a single data (such as "payment record" and "beneficiary information" of a policy) needs to be compared synchronously. For example, a certain policy has 3 payment records in the source system, and the target system has only 2, even if the main policy information is consistent, it also needs to be marked as "associated data missing". Compare whether the data meets the business rules. For example, the "coverage period" of a health insurance policy needs to be longer than the "payment period", if the source system meets the rule but the target system does not (such as 1 year of coverage period and 2 years of payment period), even if the field values match individually, it also needs to be marked as "logic inconsistency".

[0117] After comparison, the results need to be classified into three categories: consistent, inconsistent, and missing. Consistent: all fields, associated data, and logic match, no need to process; Inconsistent: there are field value mismatches (such as incorrect name), associated data missing (such as one less payment record), logic errors (such as amount calculation error) and other issues, which need to record specific differences (such as "policyholder name: source system Zhang San, target system Zhang Shan"); Missing: the source system has a certain data (such as policy "P2024001"), but the target system has not migrated successfully (no record of this policy), which needs to be marked as "target system missing". The record needs to include unique identifier, difference type, specific field, comparison time and other information, forming an "inconsistent data list" as the basis for subsequent repair.

[0118] After finding inconsistent data, we need to solve it through the process of "locating the cause → repairing the data → secondary verification" to avoid "repeated errors" or "introducing new problems after repair". The cause of data inconsistency needs to be analyzed specifically. Common causes include: migration script logic vulnerabilities (such as field mapping errors, mapping "premium" to "premium" field), data format conversion failures (such as incompatible date formats leading to null values), network interruptions causing partial data migration; source system data itself has errors (such as the same policy having two duplicate records in the source system), migration exposes problems after synchronization; target system field length limit (such as source system "address" field 50 characters, target system only 30 characters, leading to truncation), business rule differences (such as target system has "ID number" verification, source system invalid ID number is migrated after being filtered). When locating, we need to combine migration logs (such as script execution logs, error logs) and comparison results: for example, the "ID number" of a certain policy is inconsistent, if the migration log shows "field length exceeds", the reason is that the target system field length is insufficient; if there is no exception in the log, it may be a migration script field mapping error.

[0119] According to the cause, develop a repair plan to repair the target system based on the source system, and if necessary, correct the source system error: when the migration process is wrong, the script has vulnerabilities: repair the script logic (such as correcting the field mapping relationship), re-migrate the data; format conversion fails: adjust the format conversion rules (such as converting dates to "YYYY-MM-DD" format), re-migrate; network interruption, re-execute the migration task, only migrate the missing or inconsistent data (avoid wasting resources by re-migrating the full amount); when the source system data is wrong, first correct the source system error (such as deleting duplicate records, filling in null values), then re-migrate to the target system; if the source system cannot be corrected immediately (such as production systems require approval), record the problem and synchronize it to the target system (such as marking "source system data to be corrected"), avoid target system repair leading to subsequent synchronization inconsistency again; when the target system configuration is wrong, adjust the target system configuration (such as expanding the field length, relaxing non-critical verification rules), then re-migrate the data; if the configuration cannot be adjusted (such as core rule restrictions), we need to preprocess the source system data before migration (such as truncating the address to 30 characters), to ensure compliance with the target system requirements. When repairing, we need to "handle each piece", to avoid introducing new problems by batch repair (such as batch updating mistakenly changing other correct data).

[0120] After repair, the repaired data needs to be re-executed through the comparison process (checked item by item according to the original rules) to ensure that the repaired data is consistent with the source system; if the same type of error (such as field mapping error) affects multiple data, the repaired data (not just a single one) needs to be checked to avoid omissions; after repair, the reasons for inconsistency need to be summarized to optimize the migration process (such as improving script logic and adding data cleaning steps before migration) to avoid the same problems from recurring in subsequent migration (such as incremental migration). For example, due to the "field length is insufficient", a "source system data and target system configuration compatibility check" step needs to be added before migration.

[0121] The verification, comparison and repair after data migration are the "last line of defense" to ensure the availability of the target system: through clear verification scope and rules, full or sample item-by-item comparison is achieved; for inconsistent data, the cause is located, targeted repair and secondary verification are performed to completely solve the problem; finally, the migration process is optimized through review to avoid recurring problems. In the health insurance scenario, this process is directly related to the accuracy of core businesses such as policies and claims, and needs to be strictly executed to ensure that the data after migration is "reliable and usable".

[0122] After step S40, the method further comprises: monitoring error information in real time during the data migration process, recording error types and occurrence times; when the detected error, automatically triggering a retry mechanism, configuring a retry number upper limit and a retry interval time; adjusting the retry strategy according to the error type and severity; monitoring the progress and performance indicators of data migration in real time; when the monitoring indicators exceed the threshold, triggering an alarm notification.

[0123] During the data migration process, errors may occur due to network fluctuations, data format inconsistencies, excessive target system load, etc. By monitoring error information in real time, errors can be detected and accurately recorded in a timely manner, facilitating subsequent retries and repairs. The core error types monitored need to capture the following types of errors, covering the entire migration link: data reading error, failure to read data from the source system (such as source system database connection interruption, data record damage); format conversion error, source data format does not meet the requirements of the target system (such as the "effective date" of the health insurance policy in the source system is a text "20240101", the target system requires date format "2024-01-01", conversion fails); write failure error, data cannot be written to the target system (such as target system disk full, field length exceeds the limit causing insertion failure); business verification error, target system fails to perform business rule verification on data (such as health insurance policy "premium" is negative, triggering the target system "amount must be positive" verification rule).

[0124] The monitoring system needs to record key error information in real time to ensure traceability: basic information, the precise time of the error (down to milliseconds), the unique identifier of the data involved (e.g., policy number "P2024001"), and the migration task ID (for locating the specific migration batch); error details, error type (e.g., "write failure"), error cause (e.g., "insufficient disk space on the target system"), and error stack (if it is a program error, record the specific error location); contextual information, the system state at the time of the error (e.g., source system CPU utilization, target system network latency), to help determine whether it was caused by environmental fluctuations. For example, if a "write failure" occurs during the migration of a health insurance policy, the monitoring system needs to record: "2024-07-25 10:15:30.123, policy number P2024001, error type: write failure, cause: insufficient length of the 'address' field in the target system table (source data 50 characters, target system limit 30 characters), source system CPU utilization 15%, target system disk utilization 90%." Real-time error monitoring is achieved through "migration tool instrumentation + log collection": the migration tool embeds monitoring logic at key nodes (read, transformation, write), and triggers reporting immediately once an error occurs; the monitoring system captures error logs output by the migration tool in real time through log collection tools (such as Fluentd), parses them according to rules, and stores them in the error database; the visualization panel (such as Grafana) displays error statistics in real time (such as "10 write failures in the last 5 minutes"), making it easy for operations and maintenance personnel to intuitively grasp the status.

[0125] For recoverable errors (such as temporary network fluctuations), automatic retries should be implemented to reduce manual intervention; for unrecoverable errors (such as permanent data format mismatches), retries should be stopped and the error flagged. Retry should initially only be triggered for "temporary errors," excluding "permanent errors": Retrievalable errors are temporary failures caused by environmental fluctuations (such as network timeouts or temporary overload of the target system) – for example, during health insurance policy migration, a write timeout may occur due to a momentary spike in CPU usage on the target system; retrying after the system load decreases will succeed. Non-retrieval errors are permanent failures caused by the data itself or configuration issues (such as empty fields in the source data or incorrect table structures in the target system) – for example, an empty "policyholder ID number" field on the policy will fail the non-empty check on the target system even after retries, requiring manual intervention. The migration tool should automatically determine the error type: if the error log contains "timeout" or "connection refused"...

[0126] If the error is network-related, a retry will be triggered; if the error includes "data format error" or "field is null" (data-related), no retry will be performed.

[0127] Retry parameters need to balance "success rate" and "resource consumption" to avoid wasting resources on invalid retries: upper limit of retry times, set according to error type - network type temporary error can be retried 3-5 times (such as a maximum of 5 retries, if still failed, mark as "need manual handling"); system overload type error can be retried 2-3 times (avoid frequent retries to aggravate target system load). For example, health insurance core policy migration, network timeout error can be retried a maximum of 5 times to ensure that critical data is automatically recovered as much as possible; retry interval time, use "exponential backoff" strategy (interval gradually increases) - first retry interval 1 second, second retry 2 seconds, third retry 4 seconds... to avoid intensive retries in a short time impacting the system. For example, after the first retry fails, wait 1 second and try again; if it still fails, wait 2 seconds (not immediately retry) to give the target system time to recover. Parameters need to be managed uniformly through the configuration center and can be dynamically adjusted according to the migration stage (such as in the early stage of migration, the target system load is low, the retry interval can be shortened; during peak period, the interval is extended).

[0128] Adjust retry strategy according to error type and severity, different errors have different impact range and recovery difficulty, need to configure different retry strategies to avoid "one size fits all" leading to low efficiency. Adjust the strategy according to the error type, optimize the retry parameters according to the characteristics of different error types: network type error, increase the number of retries (5 times), use exponential backoff for interval (1s→2s→4s) - network fluctuations usually have a short duration, multiple retries have a high success rate; target system overload error, reduce the number of retries (3 times), extend the interval (initial interval 3s) - avoid aggravating system load, give the system time to recover; data conversion error: only retry 1 time (confirm whether it is occasional), if failed, stop - conversion error is mostly due to rule configuration problems (such as date format conversion logic error), repeated retries are not meaningful. For example, in the health insurance "batch policy migration" task, network timeout error is retried 5 times (interval 1s→2s→4s→8s→16s); target system overload error is retried 3 times (interval 3s→6s→12s).

[0129] Adjust the strategy according to the severity of the error, the severity of the error depends on "impact range" and "data importance": high severity error, affecting core data (such as health insurance active policy) or batch data (such as 50% of a batch of data failing) - increase the number of retries (5-10 times), shorten the interval (initially 1s, quickly confirm whether it is recovered), and trigger an alarm in advance (such as the 3rd retry fails) ; low severity error, affecting non-core data (such as terminated policy) or single data (such as a single policy failure) - reduce the number of retries (2-3 times), normal interval (exponential backoff), no need for urgent alarm.

[0130] For example, "20 core policy migration failures in the last 10 minutes" (high severity), the retry count is increased to 10, and the operation and maintenance personnel are notified immediately after the third failure; "single terminated policy migration failure" (low severity), if it fails after 3 retries, it is recorded in the error table, but no active alarm is given.

[0131] Real-time monitoring of migration progress and performance indicators, in addition to errors, the overall progress and performance of the migration need to be tracked in real time to ensure that it is completed on schedule and that resource consumption is reasonable. Reflecting the "completion rate" of the migration, the core indicators include: the amount of data that has been migrated, the number of data items that have been successfully migrated (e.g. "100,000 migrated policies"); the remaining amount, the number of data items to be migrated (e.g. "50,000 remaining policies"); the completion rate, the amount of data that has been migrated divided by the total amount of data to be migrated (e.g. "66.7% completion rate"); the migration speed, the number of data items successfully migrated per unit of time (e.g. "200 items per second on average"). Progress monitoring needs to be combined with the migration plan (e.g. "20 million policies need to be migrated within 24 hours"), if the actual speed is lower than expected (e.g. "only 5 million policies migrated in 10 hours"), then a warning needs to be given and resources need to be adjusted (e.g. increase the number of migration nodes).

[0132] Reflecting the "resource consumption" and "efficiency" of the migration, the core indicators include: source system load, CPU usage, memory usage, and database query delay of the source system (to avoid the impact of migration on the normal business of the source system); target system load, CPU usage, disk IO, and write delay of the target system (to avoid the target system being overloaded due to migration); migration delay, the time taken for a single data item to be "migrated" to "successfully written to the target system" (e.g. "average delay 500ms"); throughput, the amount of data processed by the migration tool per unit of time (e.g. "peak throughput 500 items / second"). For example, during the health insurance migration process, if the target system disk IO usage rate is consistently above 90%, it may cause write delay to skyrocket, so the migration needs to be paused or the data needs to be shunted.

[0133] Alarm triggered when monitoring indicators exceed thresholds, when errors, progress, or performance indicators exceed pre-set thresholds, an alarm needs to be triggered immediately to ensure that the problem is handled in a timely manner. Set reasonable thresholds according to business priorities and system carrying capacity: error thresholds, such as "number of write failures ≥ 20 times in 5 minutes" (high-frequency errors), "core policy migration errors ≥ 5 times" (critical data errors); progress thresholds, such as "expected completion time exceeds planned time by 2 hours" (progress lag), "remaining amount / migration speed > remaining time" (unable to complete on schedule); performance thresholds, such as "source system CPU usage rate > 80%" (performance degradation), "target system disk IO usage rate > 90%" (performance degradation).

[0134] ≥80%” (affect normal business), “target system write delay ≥2 seconds” (performance degradation). Thresholds need to be configured differently: core business (such as valid policy migration) threshold is more stringent (such as 1 error alarm); non-core business (such as archived policy migration) threshold can be relaxed (such as 50 errors before alarm).

[0135] Different notification methods are used according to the alarm level (serious / general): serious alarm (such as 10 times of core policy migration failure, target system downtime): push through phone, SMS, instant messaging tool (such as Dingding group), notify core operation and maintenance personnel, require response within 15 minutes; general alarm (such as progress lag, non-core data error): push through email or instant messaging tool, notify ordinary operation and maintenance personnel, require response within 1 hour. Alarm information needs to include “index name, current value, threshold, impact range, recommended treatment plan”, for example: “

serious alarm

[0136] Alarm is not only a notification, but also needs to be linked to subsequent actions: automatically trigger flow limiting (such as when the target system load is too high, automatically reduce migration speed); automatically expand (such as when the migration speed is too slow, automatically increase the number of migration nodes); ticket system automatically creates repair tasks, assigns to corresponding responsible person, and tracks processing progress.

[0137] The monitoring, retry and alarm system of data migration needs to achieve “full link awareness, automatic processing, precise early warning”: through real-time monitoring of errors and performance, ensure early detection of problems; through differentiated retry strategy, automatically solve recoverable problems; through threshold alarm, respond to serious abnormalities in time. In the health insurance scenario, this system can guarantee the accuracy and efficiency of policy and other core data migration, and avoid the impact of migration failure on key businesses such as insurance and claims.

[0138] After step S40, the method further comprises: integrating the message queue into the existing system architecture; interfacing the test original system and the target system, and optimizing the adapter and the interface according to the test results.

[0139] The core of MQ integration is to "improve system flexibility by decoupling communication links without disrupting existing architecture", which needs to be promoted from three levels of architecture evaluation, component adaptation, and reliability design. Before integration, the existing system's communication mode (synchronous call / asynchronous notification), technology stack (development language, middleware), and business link (core process / non-core process) need to be sorted out to determine the integration boundary of MQ. Communication mode adaptation: if the existing system is a "synchronous call chain" (such as A system directly calling B system, and B system calling C system), the "non-core call" needs to be changed to MQ asynchronous communication - for example, in the health insurance system, "generate policy" (core) needs to be processed synchronously, while "send SMS of successful insurance" (non-core) can be changed to A system sending messages to MQ, and the SMS system consuming from MQ, avoiding SMS service failure blocking policy generation.

[0140] If there is already some asynchronous communication (such as based on file transfer), MQ needs to be used as a "standardized asynchronous channel" to replace the old mode, and the message format and communication rules need to be unified. According to the existing system technology stack, select the MQ product (such as Java system prefer RocketMQ / Kafka,.NET system can be compatible with RabbitMQ), and confirm the compatibility of MQ client with existing framework (such as Spring Boot system needs to integrate the corresponding MQ Starter component). At the same time, an adaptation layer (adapter) needs to be reserved to avoid affecting business code when changing MQ products - for example, by encapsulating MQ specific implementation through "message sending interface", business system can call the interface without directly depending on MQ client API.

[0141] Deployment architecture integration: MQ needs to be deployed in the "communication layer" of the existing architecture, and needs to be connected with the original system network (such as the same VPC, open necessary ports), and needs to adapt to the existing operation and maintenance system (such as monitoring access to Prometheus, log access to ELK). If the existing system is a distributed architecture (multi-machine room / multi-region), MQ needs to support cross-region communication (such as through mirror queue to synchronize cross-machine room messages) to avoid becoming a single point of bottleneck.

[0142] The core of MQ integration is to make the original system (producer) stable in sending messages and the target system (consumer) reliable in receiving messages, which needs to focus on the whole link of "message generation, sending, receiving, and processing". The "message sending logic" needs to be embedded in the business node of the original system (such as after the completion of policy generation), but needs to follow the principle of "separation of business code and communication logic" - through the adapter to convert business data into MQ message format (such as JSON), and then call the MQ client to send. For example, in the health insurance original system, after generating a policy, the adapter will automatically extract the policy number, policyholder, and other core fields, package them as "policy generation message" (including message header and business body), and send them to the specified topic (such as "policy_create") through the MQ client.

[0143] Meanwhile, "sending reliability guarantee" needs to be added: check the message format before sending (to avoid invalid messages), enable the confirmation mechanism during sending (such as waiting for the MQ to return "sending success"), and record the message log after sending (for easy tracing).

[0144] The target system needs to deploy the MQ consumer component to receive specified messages through "subscribe to topic + message filtering" (such as the health insurance claim system only subscribing to messages of "critical illness insurance" type in the "policy generation" topic). The consumption logic needs to be decoupled from the business logic: after the consumer receives the message, it first converts it into a business object recognizable by the target system through an adapter (such as converting the MQ message into a "policy DTO" of the claim system), and then calls the business interface for processing.

[0145] The consumer needs to guarantee "idempotency and fault tolerance": avoid duplicate processing through the unique message ID (such as MQ's messageId) (such as the claim system processing the same policy message only once); if the processing fails (such as the business interface being temporarily unavailable), the message will be returned to the MQ (triggering a retry) or sent to the dead letter queue (to avoid blocking consumption).

[0146] To reduce the direct dependence of the original system and the target system on MQ, an "intermediate adapter layer" needs to be designed to encapsulate the sending, consumption, retry, and other basic capabilities of MQ, and provide standardized interfaces (such as "message sending interface" and "message subscription interface") to the outside. The original system and the target system only need to call the adapter layer interface and do not need to concern about the specific implementation of MQ (such as switching from Kafka to RocketMQ, only the adapter layer code needs to be modified, and the business system is not aware).

[0147] After integrating MQ, "introducing new unstable factors" needs to be avoided, which needs to be strengthened from the following aspects: enabling MQ persistence (writing messages to disk), producer sending confirmation (ensuring successful reception by MQ), and consumer manually submitting offset (confirming consumption after processing) — for example, the core policy message of health insurance needs to ensure that the whole link from sending to consumption is not lost.

[0148] Set the upper limit of the sending rate on the producer side (to avoid sudden traffic pressure on MQ), and configure the consumer thread pool on the consumer side (set the number of concurrent threads according to the processing capacity) — for example, during the peak of health insurance application, limit the flow through MQ to avoid 100,000 messages per second impacting the downstream claim system.

[0149] Integrate the running status of MQ (message accumulation, sending success rate, consumption delay) into the existing monitoring system (such as Grafana), set alarm thresholds (such as triggering an alarm when the accumulation exceeds 10,000), and reserve MQ expansion channels (such as adding Broker nodes) to cope with business growth.

[0150] After the integration of MQ, conduct interface testing to verify whether the communication between the original system and the target system meets the business expectations. The test should simulate real business links, focusing on verifying whether the message can be correctly transmitted, processed, and fed back. Core scenarios include: for key interactions between the original system and the target system (such as health insurance "original system generates policy -> MQ -> target system synchronizes policy"), verify the correctness of the whole process: after the original system sends the message, check whether MQ correctly receives it, whether the target system successfully consumes it, and whether the consumption result meets the business rules (such as complete policy information and field matching). For example, test the "critical illness insurance policy" message: the "premium 500,000" and "effective date 2024-08-01" sent by the original system should be accurately displayed in the target system, and the associated "critical illness type" field should not be missing.

[0151] Simulate faults in the communication link to verify the system's fault tolerance: MQ is temporarily unavailable: test whether the original system can cache messages (such as local queues) and retry sending after MQ is restored; target system consumption failure: test whether the message will be rolled back to MQ and whether it will trigger a retry (such as entering the dead letter queue after 3 retries); message format error: test whether the target system can identify and reject (rather than crash) when the original system sends a message with illegal format (such as an empty date field).

[0152] Verify whether the throughput and delay of the system after integrating MQ meet the standards: stress test the producer: simulate the original system sending 1000 messages per second, check the success rate of MQ receiving (≥99.9%) and the sending delay (≤100ms); stress test the consumer: test the consumption delay of the target system when processing 1000 messages per second (≤200ms) and whether there is message accumulation; long-term running test: send messages continuously for 24 hours to verify the stability of MQ and the target system (no memory leakage, no message loss).

[0153] Build a mirror environment consistent with production (including original system, MQ, and target system), with the same network and hardware configuration (to avoid environmental differences leading to distorted test results). Use stress testing tools (such as JMeter) to simulate the original system sending messages, use MQ's own tools (such as Kafka Tool) to monitor message status, and use interface testing tools (such as Postman) to verify the target system's processing results. Prepare data covering all business scenarios (such as policies of different types of insurance, normal / abnormal format data), ensuring test coverage (such as at least 80% of fields and business rules).

[0154] After testing, a detailed report needs to be output, focusing on recording "unexpected scenarios" and locating the root cause: for example, if the "insured name" received by the target system is inconsistent with the original system, it may be due to the adapter field mapping error (such as the original system "name" corresponding to the target system "username", but the adapter mismaps as "nickname"); if the consumption delay exceeds the threshold, it may be due to the long processing logic of the target system (such as redundant verification), or the insufficient configuration of the MQ consumption thread; if the message is occasionally lost, it may be due to the producer not starting the sending confirmation (MQ does not receive success but judges "sending complete"), or the consumer does not manually submit offset (processing is completed without confirmation, MQ considers it not consumed).

[0155] Solve the problems found in the test, improve the efficiency and stability of communication, solve the format adaptation and conversion efficiency problem, the adapter is the "interpreter" of the original system and MQ, MQ and the target system, the optimization needs to focus on "format compatibility" and "conversion performance": if the test finds that the "field type does not match" (such as the original system "premium" is a string, and the target system needs a numerical type), you need to add type conversion logic in the adapter (such as string to BigDecimal); If the "nested structure parsing fails" (such as the original system message contains multiple layers of JSON objects, and the target system cannot parse), you need to optimize the serialization / deserialization rules of the adapter (such as using Jackson instead of FastJSON to improve the parsing ability of complex structures). Performance optimization: If the test finds that the adapter conversion takes too long (such as 50ms for a single message conversion), you need to simplify the conversion logic (such as removing redundant field mapping), introduce caching (such as caching frequently used dictionary mapping to memory), and batch conversion (such as accumulating 100 messages and processing them in batches to reduce repeated initialization overhead). For the problem of "format error message causing adapter crash", add validation logic in the adapter (such as null validation, format validation), and directly mark "invalid" and log for illegal messages (instead of throwing exceptions to interrupt the process). Improve the processing capacity and compatibility of the target system, the interface of the target system is the "terminal" of the consumed message, and the optimization needs to focus on "processing efficiency" and "fault tolerance": If the test finds that the target system interface processing takes too long (such as 300ms for a single policy processing), you need to optimize the interface logic (such as removing unnecessary checks, combining database operations), introduce asynchronous processing (such as receiving messages first, and then asynchronously executing time-consuming logic), and increase caching (such as caching frequently queried "insurance rules" to Redis). If the test finds that "repeated consumption causes data duplication" (such as the target system generates two identical policies), you need to add idempotent check in the interface layer (such as based on message ID, messages that have been processed are directly returned success). If the test finds that "the old version interface does not support new fields" (such as the original system adds a "policyholder occupation" field, and the target system interface is not adapted), you need to upgrade the interface to "compatibility mode" (add optional fields, which does not affect the old logic), or filter redundant fields through the adapter (temporarily do not pass the fields that the target system does not support).

[0156] Based on the performance test results, optimize the configuration parameters of MQ and the system to improve the overall throughput: If the test finds that the "sending delay is high", you can increase the sending buffer of MQ (such as "socket.send.buffer.bytes" of Kafka from 128KB to 512KB); If "consumption is accumulated", you can increase the number of threads of the consumer group (such as "consumeThreadMax" of RocketMQ from 20 to 50).

[0157] If the target system CPU usage is too high, the number of server cores needs to be increased; if the disk IO bottleneck causes the MQ persistence to be slow, the MQ storage path needs to be migrated to SSD. If the test finds that the "temporary error retry success rate is low", the retry interval needs to be adjusted (such as from fixed 1s to exponential backoff 1s→2s→4s); if "invalid retries are too many", the retry trigger condition needs to be refined (such as only network error retries, format errors do not retry).

[0158] MQ integration into existing systems needs to follow the principle of "minimum invasion" - encapsulate MQ capabilities through the adapter layer to avoid direct dependence on the business system; interface testing needs to cover all link scenarios, focusing on verifying functionality, performance, and reliability; optimization needs to address test problems in a targeted manner, improving from three levels: adapter (format and efficiency), interface (processing and compatibility), and configuration (resources and strategies). In core scenarios such as health insurance, the ultimate goal is to achieve "zero message loss, low communication latency, and high system stability".

[0159] Massive policy data is stored in scattered storage through data sharding to avoid single node overload; the partition and replica mechanism of message queue (MQ) realizes message load balancing and fault tolerance, and automatically switches to the replica when the node fails, with the interruption time of core business (such as insurance and claims) controlled within 30 seconds. At the same time, message persistence, synchronous disk flushing, and other mechanisms ensure zero loss of critical data, solving the problem of "single point failure leading to data loss" in traditional centralized storage.

[0160] The sharding design according to policy type and region, combined with parallel processing of multiple computing nodes, improves the efficiency of batch tasks (such as premium statistics and historical policy archiving) by 3-10 times - for example, the nationwide medical insurance policy statistics are shortened from 2 hours to 15 minutes after parallel processing. The parallel read and write capabilities of MQ support tens of thousands of message flows per second, and combined with batch processing mechanisms, it easily handles health insurance "opening red" and other insurance peaks.

[0161] The sharding strategy according to administrative region and policy type adapts to the differences in medical insurance policies of each province (such as special drug reimbursement in Guangdong and medical insurance interface in Shanghai), and regionalized business (such as local claims audit) can directly access the corresponding shard, reducing cross-regional data transmission. The decoupling characteristics of MQ allow new businesses (such as new "long-term care insurance") to be added without modifying the original system, only by adding a consumer to subscribe to the corresponding message, achieving "plug-in" expansion.

[0162] Real-time monitoring, error retry, and verification mechanisms during migration ensure data consistency from the source system to the target system - the comparison and repair process controls the data inconsistency rate to below 0.1%. The format conversion optimization of the adapter solves the field difference problem (such as date format, field naming) between the new and old systems, and business rule verification (such as premium calculation logic) further ensures that the data meets the health insurance business specifications.

[0163] The sharded metadata center centrally manages storage rules, reducing manual configuration costs; standardized message queue (MQ) communication replaces traditional file transfer and direct calls, reducing the complexity of cross-system integration. Monitoring, alerting, and automatic retry mechanisms reduce manual intervention by 80%, allowing operations personnel to focus on core issues (such as dead-letter queue handling) rather than repeatedly troubleshooting temporary faults.

[0164] Dynamic sharding and elastic computing nodes can be expanded as business grows (e.g., adding corresponding shards directly when adding new provincial businesses) without refactoring the system; the compatible design of MQ and the adaptation layer provides a smooth transition capability for future system upgrades (e.g., replacing MQ products or migrating to a cloud-native architecture), avoiding the high cost of "starting from scratch".

[0165] As can be seen, in the above solution, regarding the partitioning and replication mechanism of the Message Queue (MQ), the data is first partitioned according to the data characteristics of the health insurance policy system, based on policy type, time range, and customer region, and the partitioned data is processed in parallel. The processed data is then format-converted to ensure it matches the format supported by the message queue. The converted data is then encapsulated into messages and sent to the MQ message queue. The parameters of the MQ message queue are configured according to actual needs, and the MQ message queue is partitioned and replicated. Messages are read from the MQ message queue, and the data in the messages is format-converted to ensure it matches the requirements of the target system. Finally, the converted data is written to the target system, completing the data migration. This invention improves system stability and reliability, increases data processing efficiency and throughput, enhances business adaptability and flexibility, ensures data consistency and accuracy, reduces system maintenance costs and risks, and supports sustainable business development.

[0166] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0167] In one embodiment, a policy system data migration device based on MQ message queues is provided, which corresponds one-to-one with the policy system data migration method based on MQ message queues in the above embodiments. For example... Figure 3 As shown, the policy system data migration device based on MQ message queue includes a deconstruction module 101, a construction module 102, an evaluation module 103, and an optimization module 104. Detailed descriptions of each functional module are as follows:

[0168] The sharding module 101 is used to shard the data according to the data characteristics of the health insurance policy system, based on the policy type, time range and customer region, and to process the sharded data in parallel.

[0169] The conversion module 102 is configured to format the processed data, and after determining that the data format is consistent with the format supported by the message queue, encapsulate the converted data as a message and send the message to the MQ message queue.

[0170] The configuration module 103 is configured to configure parameters of the MQ message queue according to actual needs, and partition and replicate the MQ message queue.

[0171] The reading module 104 is configured to read the message in the MQ message queue, format the data in the message, ensure that the data format is consistent with the requirements of the target system, and then write the converted data into the target system to complete the data migration.

[0172] In an embodiment, the device specifically further comprises:

[0173] The verification module is configured to verify the migrated data after the data migration is completed, compare the data of the source system and the target system piece by piece to ensure data consistency, and if inconsistent data is found, start a data repair process to re-migrate the failed data.

[0174] In an embodiment, the device specifically further comprises:

[0175] The monitoring module is configured to monitor error information in the data migration process in real time, record error types and occurrence times, automatically trigger a retry mechanism when detecting errors, configure a retry upper limit and a retry interval time, and adjust the retry strategy according to the error type and severity.

[0176] The alarm module is configured to monitor the progress and performance indicators of the data migration in real time, and trigger an alarm notification when the monitoring indicators exceed the threshold.

[0177] In an embodiment, the device specifically further comprises:

[0178] The optimization module is configured to integrate the message queue into the existing system architecture, interface test the original system and the target system, and optimize the adapter and the interface according to the test results.

[0179] In an embodiment, the sharding module 101 is specifically further configured to:

[0180] According to the data characteristics of the health insurance policy system, the same type of policy is stored in the same shard, the granularity is selected according to the data volume and access frequency for splitting and sharding, and the shards are split according to the administrative region level;

[0181] The storage shard rule and the shard location are stored, and multiple computing nodes are scheduled to simultaneously and in parallel process subtasks of different shards;

[0182] All subtask results are collected and summarized according to business rules.

[0183] In an embodiment, the configuration module 103 is specifically configured to:

[0184] Fine-tuning the MQ message queue parameters based on actual needs;

[0185] According to the business rules, the massive messages are allocated to partitions, and the copies of the same message are saved in multiple nodes, so that when a node fails, the service can be switched to other copies.

[0186] The present application provides a kind of based on the data migration device of MQ message queue's policy system, according to the data characteristics of health insurance policy system, data is according to policy type, time range and customer area are fragmented, and the data after fragmentation is parallel processing;The data after processing is format conversion, after determining that data format is consistent with the format supported by message queue, the data after conversion is encapsulated as message and sent to MQ message queue;According to actual demand, the parameters of MQ message queue are configured, and MQ message queue is partitioned and copy;Read the message in MQ message queue, the data in message is format conversion, ensure that data format is consistent with the requirement of target system after conversion, the data after conversion is written into target system, complete data migration.In the present application, system stability and reliability are improved, data processing efficiency and throughput are improved, business adaptability and flexibility are enhanced, data consistency and accuracy are guaranteed, system maintenance cost and risk are reduced, and sustainable business development is supported.

[0187] The specific limitations of the policy system data migration device based on the MQ message queue can be referred to the limitations of the policy system data migration method based on the MQ message queue in the above, which will not be repeated here.Each module in the above policy system data migration device based on the MQ message queue can be realized by software, hardware and their combinations in whole or in part.The above each module can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to call and execute the operation corresponding to each module by the processor.

[0188] In one embodiment, a computer device is provided, which can be a server, and its internal structure diagram can be as shown in Figure 4As shown in the figure. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media, internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external client through the network connection. The computer program is executed by the processor to implement the functions or steps of the server side of the MQ message queue-based policy system data migration method.

[0189] In one embodiment, a computer device is provided, which can be a client, and its internal structure diagram can be as shown in the figure. Figure 5 As shown in the figure. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile storage media, internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external server through the network connection. The computer program is executed by the processor to implement the functions or steps of the client side of the MQ message queue-based policy system data migration method

[0190] In one embodiment, a computer device is provided, including a memory, a processor and a computer program stored on the memory and executable on the processor, and the processor executes the computer program to implement the following steps:

[0191] According to the data characteristics of the health insurance policy system, the data is divided according to the policy type, time range and customer area, and the divided data is processed in parallel;

[0192] The processed data is converted to a format consistent with the format supported by the message queue, and the converted data is packaged as a message and sent to the MQ message queue;

[0193] According to the actual demand, configure the parameters of the MQ message queue, and partition and replicate the MQ message queue;

[0194] Read the message in the MQ message queue, convert the data in the message to ensure that the data format is consistent with the requirements of the target system, and then write the converted data into the target system to complete the data migration.

[0195] In one embodiment, a computer readable storage medium is provided, and the computer program is stored on the computer readable storage medium, and the computer program is executed by a processor to implement the following steps:

[0196] According to the data characteristics of the health insurance policy system, the data is sharded according to the policy type, time range, and customer area, and the sharded data is processed in parallel;

[0197] The processed data is format-converted, and after determining that the data format is consistent with the format supported by the message queue, the converted data is encapsulated as a message and sent to the MQ message queue;

[0198] According to the actual demand, the parameters of the MQ message queue are configured, and the MQ message queue is partitioned and replicated;

[0199] The message in the MQ message queue is read, the data in the message is format-converted, and after ensuring that the data format is consistent with the requirements of the target system, the converted data is written into the target system to complete the data migration.

[0200] It should be noted that the functions or steps that the computer readable storage medium or the computer device can implement above can be referred to the related descriptions of the server side and the client side in the foregoing method embodiments, and will not be described here to avoid repetition.

[0201] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing related hardware, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. Any reference to memory, storage, database or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0202] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0203] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A data migration method for an insurance policy system based on an MQ message queue, characterized in that, include: Based on the data characteristics of the health insurance policy system, the data is segmented according to policy type, time range, and customer region, and the segmented data is processed in parallel. After processing the data, the data format is converted to ensure that it matches the format supported by the message queue. The converted data is then encapsulated into a message and sent to the MQ message queue. Configure the parameters of the MQ message queue according to actual needs, and partition and replicate the MQ message queue. Read messages from the MQ message queue, convert the data format in the messages to ensure that the data format is consistent with the requirements of the target system, and then write the converted data into the target system to complete the data migration.

2. The policy system data migration method based on MQ message queue as described in claim 1, characterized in that, After the steps of reading messages from the MQ message queue, converting the data format in the messages to ensure that the data format is consistent with the requirements of the target system, and writing the converted data into the target system to complete the data migration, the method further includes: After the data migration is completed, the migrated data is validated. The data from the source system and the target system are compared line by line to ensure data consistency; If data inconsistencies are found, initiate the data repair process and re-migrate the failed data.

3. The policy system data migration method based on MQ message queue as described in claim 1, characterized in that, After the steps of reading messages from the MQ message queue, converting the data format in the messages to ensure that the data format is consistent with the requirements of the target system, and writing the converted data into the target system to complete the data migration, the method further includes: Real-time monitoring of error information during data migration, recording error types and occurrence times; When an error is detected, the retry mechanism is automatically triggered, with a maximum number of retries and a retry interval configured. Adjust the retry policy configuration based on the error type and severity.

4. The policy system data migration method based on MQ message queue as described in claim 3, characterized in that, After the step of adjusting the retry policy configuration according to the error type and severity, the method further includes: Monitor the progress and performance metrics of data migration in real time; An alarm notification is triggered when the monitored metric exceeds the threshold.

5. The policy system data migration method based on MQ message queue as described in claim 1, characterized in that, After the steps of reading messages from the MQ message queue, converting the data format in the messages to ensure that the data format is consistent with the requirements of the target system, and writing the converted data into the target system to complete the data migration, the method further includes: Integrate message queues into the existing system architecture; Interconnect and test the original system and the target system, and optimize the adapter and interface based on the test results.

6. The policy system data migration method based on MQ message queue as described in claim 1, characterized in that, The steps of segmenting the data according to policy type, time range, and customer region based on the data characteristics of the health insurance policy system, and then processing the segmented data in parallel, include: Based on the data characteristics of the health insurance policy system, policies of the same type are stored in the same shard. The granularity of the shards is selected according to the data volume and access frequency, and the shards are split according to the administrative region level. Store sharding rules and sharding locations, and schedule multiple computing nodes to process subtasks of different shards in parallel. Collect all subtask results and summarize them according to business rules.

7. The data migration method for a policy system based on an MQ message queue as described in claim 1, characterized in that, The steps of configuring the parameters of the MQ message queue according to actual needs, and partitioning and replicating the MQ message queue include: Fine-tuning of MQ message queue parameters based on actual needs; According to business rules, massive messages are allocated to partitions and copies of the same message are saved to multiple nodes. When a node fails, the service can be switched to other copies.

8. A data migration device for an insurance policy system based on an MQ message queue, characterized in that, include: The data sharding module is used to shard the data according to the data characteristics of the health insurance policy system, based on policy type, time range and customer region, and to process the sharded data in parallel. The conversion module is used to convert the processed data into a format. After confirming that the data format is consistent with the format supported by the message queue, the converted data is encapsulated into a message and sent to the MQ message queue. The configuration module is used to configure the parameters of the MQ message queue according to actual needs, and to partition and replicate the MQ message queue. The read module is used to read messages from the MQ message queue, convert the data in the messages to ensure that the data format is consistent with the requirements of the target system, and then write the converted data into the target system to complete the data migration.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the policy system data migration method based on MQ message queue as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the policy system data migration method based on MQ message queue as described in any one of claims 1 to 7.

Images