Long text message splicing device based on long connection polling load

Abstract

The invention provides a long short message splicing device based on a long connection polling load, which belongs to the technical field of long short message splicing and comprises a TCP (Transmission Control Protocol) gateway layer module, a shared cache module, a long short message splicing engine module, a message queue module and a back-end service cluster module which are integrated on a processing terminal. The invention aims to solve the problems in the prior art that the content integrity of the long text message cannot be guaranteed, the TCP connection distribution is unbalanced, and the service is difficult to dynamically expand to meet the high throughput requirement, realize the adaptation of any load mode in a complex network environment, and improve the stability, expansibility and data processing accuracy of a service cluster.

Description

Technical Field

[0001] This invention belongs to the field of long SMS splicing technology, specifically relating to a long SMS splicing device based on long connection polling load. Background Technology

[0002] In today's digital communication era, SMS, as an important means of information transmission, is widely used in various scenarios, such as verification code sending, push notifications, and business information transmission. With the continuous growth of user needs, the use of long SMS messages is becoming increasingly frequent. Long SMS messages typically need to be split into multiple segments for transmission and then reassembled at the receiving or server end to reconstruct the complete content. However, existing long SMS transmission and processing technologies have many problems, making it difficult to meet the high reliability and high throughput requirements of services in complex network environments. Specific problems are as follows:

[0003] Firstly, regarding load balancing, the current mainstream load balancing method is IP hash-based load balancing. In complex network environments, the same IP address may correspond to multiple terminal devices, or the same terminal device may initiate multiple TCP connections due to network switching (such as switching from WiFi to mobile data network). The IP hash-based load balancing mechanism will occasionally distribute these multiple connections from the same IP to different backend service machines. Due to the lack of an effective data sharing mechanism between different machines, each machine can only obtain partial fragments of long SMS messages, and cannot collect all fragments for splicing, resulting in incomplete SMS content. This seriously affects user experience and the accuracy of business data. For example, in scenarios such as financial transaction notifications and the transmission of important business instructions, incomplete SMS messages may lead to user misunderstandings or business process interruptions.

[0004] Secondly, existing technologies lack effective connection scheduling and allocation mechanisms to ensure balanced TCP connection distribution. Some backend service machines may be assigned far more long-lived TCP connections than their capacity due to factors such as geographical location, network bandwidth, and hardware performance, while other machines remain idle. This uneven distribution of connections can lead to performance bottlenecks on high-load machines, such as excessively high CPU utilization, insufficient memory, and increased response latency, potentially even causing service outages. Furthermore, the hardware resources of idle machines cannot be fully utilized, resulting in resource waste and reducing the overall processing efficiency of the entire service cluster.

[0005] Finally, regarding service availability and scalability, when a backend service needs to be restarted (such as for version updates, fault repair, or hardware maintenance), all long-lived TCP connections on that service are forcibly disconnected. Due to the lack of effective connection migration and service discovery mechanisms in current technology, clients need to re-initiate connection requests, and new connections may be assigned to other normally functioning service machines. During this process, the restarted service machine, after resuming operation, cannot promptly receive new connection requests, leading to idle service and further exacerbating the problem of uneven connection distribution. Simultaneously, the existing service architecture struggles to support dynamic scaling. When business volume suddenly increases, it cannot quickly add service nodes and evenly distribute the load among the new nodes, resulting in service throughput failing to meet business demands and causing issues such as message backlog and sending delays.

[0006] In summary, existing long SMS transmission and processing technologies have significant shortcomings in terms of load balancing, connection distribution, and service scalability. A new technical solution is urgently needed to address these issues, ensuring the integrity of long SMS content, improving the load balancing capabilities and throughput of service clusters, and meeting business needs in complex network environments. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a long SMS splicing device based on long-connection polling load balancing. It aims to solve the problems of incomplete long SMS content, uneven TCP connection distribution, and difficulty in dynamically scaling services to meet high throughput requirements. The device adapts to any load balancing method in complex network environments, improving the stability, scalability, and data processing accuracy of the service cluster.

[0008] The present invention employs the following technical solution.

[0009] A long SMS splicing device based on long-connection polling load balancing includes:

[0010] The TCP gateway layer module, shared cache module, long SMS splicing engine module, message queue module, and backend service cluster module are integrated into the processing terminal.

[0011] TCP Gateway Layer Module: This module uses the Netty framework to build a high-performance TCP gateway layer service, serving as a communication bridge between the client and the backend service cluster.

[0012] Shared caching module: Redis is introduced as a shared caching system to store the data of each segment of a long SMS message, splicing progress status information, and connection mapping relationships;

[0013] Long SMS splicing engine module: Integrated into the backend service node, it serves as the core processing unit and is responsible for implementing the splicing logic of long SMS segments;

[0014] Message queue module: Kafka is used as the message queue system to implement asynchronous transmission and priority processing of long SMS segments;

[0015] Backend service cluster module: It consists of multiple backend service nodes with the same configuration, adopts a horizontal scaling architecture, and supports dynamically increasing or decreasing the number of nodes according to business needs.

[0016] Preferably, the Netty framework in the TCP gateway layer module supports connection establishment, maintenance, and disconnection management; the client initiates a TCP long connection request through the TCP gateway layer module, and after the TCP gateway layer module performs preliminary verification of the requested long connection, it distributes the long connection to different backend service nodes in the backend service cluster based on a round-robin load balancing algorithm.

[0017] Preferably, the round-robin load balancing algorithm distributes new connections to each backend service node in a preset order to ensure that the number of connections received by each backend service node is relatively balanced. At the same time, the TCP gateway layer module monitors the running status of the backend service nodes in real time. When a backend service node is abnormal, it is automatically removed from the load list and re-added after the backend service node recovers.

[0018] Preferably, the specific method for the round-robin load balancing algorithm to distribute new connections to each backend service node in a preset order, ensuring a relatively balanced number of connections received by each backend service node, includes:

[0019] With fixed-order traversal as the core logic, new connection requests are allocated sequentially according to the priority order of the pre-set backend service node list to ensure the balance of the number of connections of each node in the initial state.

[0020] A dynamic weighting mechanism is introduced to adjust the allocation ratio based on the real-time load of nodes, further optimizing connection balance.

[0021] A node status awareness mechanism is added to the polling algorithm to remove abnormal nodes in real time and ensure the reliability of connection allocation.

[0022] The accuracy of the allocation process is ensured through a fault-tolerance mechanism.

[0023] Preferably, when the backend service node receives a long SMS segment, it stores the segment data in Redis and updates the SMS splicing progress status.

[0024] Preferably, Redis also stores the mapping relationship between client connections and backend service nodes. When a client initiates a request for the complete content of a long SMS message, any backend service node can retrieve all SMS fragments corresponding to that client by querying Redis.

[0025] Preferably, Redis supports data expiration policies, allowing you to set the storage timeout for long SMS segments. For long SMS messages that have not been collected within the preset time, the relevant segment data will be automatically deleted to release cache space.

[0026] Preferably, the long SMS splicing engine module performs a complete check on SMS messages that have not been spliced ​​by periodically polling the long SMS status information in Redis.

[0027] Preferably, during the complete check process, the long SMS splicing engine module queries the total number of SMS segments and the number of received segments based on the SMS identifier. When the number of received segments equals the total number of segments, it is determined that the SMS segments are complete. Then, all segment data is read from Redis and spliced ​​in the order of segment numbers to generate the complete long SMS content. After splicing, the long SMS splicing engine module stores the complete SMS content in a designated area of ​​Redis and updates the splicing status of the SMS to "completed".

[0028] Preferably, the long SMS splicing engine module is also responsible for timeout management. For SMS messages that have not been spliced ​​after the preset timeout period, they are marked as "sponging failed" and an alarm mechanism is triggered so that problems can be investigated in a timely manner.

[0029] Preferably, the long SMS splicing engine module supports a status query function, allowing the client to obtain the splicing progress and current status of a specified long SMS by sending a query request.

[0030] Preferably, when a backend service node receives a long SMS segment, it does not directly splice it. Instead, it encapsulates the segment data into a message and sends it to a designated topic in Kafka. The message queue system categorizes and stores messages according to their business priority, setting different message partitions. The long SMS splicing engine of the backend service node consumes messages from the corresponding partitions in priority order, prioritizing high-priority long SMS segments. At the same time, Kafka supports persistent message storage, so messages will not be lost when a backend service node fails, and messages can be consumed again after the node recovers.

[0031] Preferably, each backend service node is equipped with TCP connection processing and long SMS splicing engine modules. When the throughput of the existing cluster becomes insufficient due to increased business volume, new backend service nodes can be added and registered in the load list of the TCP gateway layer. The gateway layer will automatically allocate new connections to the new nodes, thereby achieving dynamic expansion of the service cluster. Conversely, when the business volume decreases, a set number of idle backend service nodes can be shut down. In addition, the nodes in the cluster achieve data synchronization and collaborative work through shared cache modules and message queue modules, ensuring consistency of business processing logic among the nodes.

[0032] The beneficial effects of the present invention are as follows, compared with the prior art:

[0033] Ensuring the integrity of long SMS messages: By introducing a shared Redis cache, data sharing of long SMS fragments is achieved in a distributed environment. Regardless of which node in the backend service cluster a client connection is assigned to, all SMS fragments corresponding to that client can be retrieved by querying Redis. Simultaneously, the long SMS splicing engine ensures timely splicing after all fragments are collected through a periodic polling and integrity check mechanism. This effectively solves the problem of incomplete long SMS content caused by multiple connections from the same IP being assigned to different machines under the existing IP hash load balancing method, thus improving the accuracy of data processing.

[0034] Optimizing TCP connection distribution balance: The TCP gateway layer employs a round-robin load balancing algorithm, combined with backend service node status monitoring, to evenly distribute client connections across all nodes, avoiding overload on any single node. Furthermore, when the service restarts, the gateway layer automatically reallocates connections to other healthy nodes, adding them back to the load list only after the restarted nodes have recovered. This resolves the issue of idle services caused by service restarts, fully utilizes the cluster's hardware resources, and improves overall service processing efficiency.

[0035] Supports dynamic service scaling and high throughput: The backend service cluster adopts a horizontally scalable architecture, allowing for flexible addition or removal of nodes based on changes in business volume. Newly added nodes only need to register with the gateway layer to receive connections and process business, achieving rapid scaling. Simultaneously, the TCP gateway layer built with the Netty framework efficiently handles concurrent connections, the Kafka message queue buffers instantaneous high-concurrency messages, and Redis caching improves data read and write speeds. The synergistic effect of these three elements significantly improves the throughput of the service cluster, meeting the demands of sudden business growth and ensuring service stability and reliability.

[0036] Adaptable to complex network environments and various load balancing methods: The round-robin load balancing algorithm of this invention does not rely on IP addresses and can adapt to any load balancing method in complex network environments (such as IP hashing, random load balancing, etc.). Switching between different load balancing strategies can be achieved simply by adjusting the load balancing algorithm at the TCP gateway layer, which enhances the flexibility and versatility of the technical solution and reduces the adaptation cost under different business scenarios. Attached Figure Description

[0037] Figure 1 This is a flowchart of the long SMS splicing device based on long connection polling load in this invention. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this invention. The embodiments described in this application are merely some embodiments of this invention, and not all embodiments. Based on the spirit of this invention, other embodiments obtained by those skilled in the art without creative effort are all within the protection scope of this invention.

[0039] like Figure 1 As shown, a long SMS splicing device based on long connection polling load includes:

[0040] The TCP gateway layer module, shared cache module, long SMS splicing engine module, message queue module, and backend service cluster module are integrated in the processing terminal (the processing terminal can be a client or backend service node such as a computer or server), and the modules work together.

[0041] TCP Gateway Layer Module: This module uses the Netty framework to build a high-performance TCP gateway layer service, serving as a communication bridge between the client and the backend service cluster.

[0042] In a preferred but non-limiting embodiment of the present invention, the Netty framework in the TCP gateway layer module has asynchronous and event-driven characteristics, which can efficiently handle a large number of concurrent TCP long connections and support connection establishment, maintenance and disconnection management. The client initiates a TCP long connection request through the TCP gateway layer module. After the TCP gateway layer module performs preliminary verification on the requested long connection (such as identity authentication and protocol version verification), it distributes the long connection to different backend service nodes in the backend service cluster based on a round-robin load balancing algorithm.

[0043] Meanwhile, in a preferred but non-limiting embodiment of the present invention, the round-robin load balancing algorithm distributes new connections to each backend service node in a preset order, ensuring a relatively balanced number of connections received by each backend service node and avoiding overload on a single node. Simultaneously, the TCP gateway layer module monitors the operating status of the backend service nodes in real time (such as CPU utilization, memory usage, and number of connections). When a backend service node experiences an anomaly (such as crashing or timeout), it is automatically removed from the load list and re-added after recovery, ensuring the reliability of connection allocation.

[0044] In long SMS splicing devices based on long-connection round-robin load balancing, the load list is a core data structure maintained by the TCP gateway layer. Essentially, it's a collection of backend service node information, recording key information about currently available backend nodes (such as node identifier, status, and load metrics). It forms the basis for the round-robin load balancing algorithm to achieve balanced connection allocation. Its core function is to allow the gateway layer to clearly define "which nodes to allocate connections to" and "which nodes to prioritize," while dynamically excluding abnormal nodes to ensure the reliability and balance of connection allocation.

[0045] In a preferred but non-limiting embodiment of the present invention, the specific method for the round-robin load balancing algorithm to distribute new connections to each backend service node in a preset order, ensuring a relatively balanced number of connections received by each backend service node, includes:

[0046] Round-robin load balancing is the core mechanism for ensuring a balanced distribution of connections across the backend service cluster. It distributes newly initiated TCP long connections from clients to different backend service nodes sequentially using pre-defined allocation rules, preventing overload on any single node. In the application scenario of a long SMS splicing device based on long-connection round-robin load balancing, its implementation can be divided into four core stages: "basic round-robin algorithm design," "dynamic weight optimization," "enhanced node state awareness," and "connection allocation fault tolerance guarantee." These stages work together to achieve a relatively balanced number of connections, as detailed below:

[0047] I. Basic Polling Algorithm Design: Ordered Allocation Based on Preset Order

[0048] The basic round-robin algorithm uses a fixed-order traversal as its core logic. It allocates new connection requests sequentially based on the priority order of a pre-defined list of backend service nodes, ensuring a balanced number of connections across nodes in the initial state. The specific implementation steps are as follows:

[0049] (I) Initialization and sorting of the node list

[0050] Node Registration and Information Storage: The TCP gateway layer maintains a "list of available nodes." After backend service nodes (such as node 1, node 2, and node 3) start, they submit node information to the gateway layer through service registration mechanisms (such as HTTP requests or the ZooKeeper registry), including node IP addresses, service ports, and node identifiers (such as NodeID). The gateway layer stores this information in an ordered set in local memory (such as a LinkedList in Java). The sorting order of the set is the preset connection allocation order (which can be set according to node deployment time and IP address ascending / descending order, for example, the preset order is node 1 → node 2 → node 3 → node 1...).

[0051] Allocation Counter Settings: The gateway layer initializes an "allocation counter" (initial value 0) to record the number of currently allocated connections and serves as an index pointer for the node list. The counter's value range is consistent with the length of the available node list. When the counter reaches the list length, it automatically resets to 0, enabling loop traversal.

[0052] (ii) Sequential allocation process for new connections

[0053] Connection request reception: The client initiates a TCP long connection request. After receiving the request, the gateway layer first completes basic verification (such as client identity validity and protocol version compatibility). After the verification is successful, it enters the load distribution stage.

[0054] Node selection and counter update: The gateway layer selects the node with the corresponding index from the list of available nodes based on the current value of the allocation counter (for example, select node 1 when counter = 0, select node 2 when counter = 1, and select node 3 when counter = 2). After the selection is completed, the allocation counter is automatically incremented by 1. If the counter is equal to the length of the node list (for example, when the list length is 3 and the counter = 3), it is reset to 0 and the next round of loop begins.

[0055] Connection forwarding and mapping records: The gateway layer forwards client connection requests to the selected backend nodes, and stores the "client-node" mapping relationship locally (e.g., using the client device ID as the key and the node identifier as the value), and synchronizes it to the "connection_mapping" hash table in the shared Redis cache, which facilitates subsequent connection status queries and business processing.

[0056] (III) Balance Verification of the Basic Algorithm

[0057] Suppose there are 1000 new connection requests within a certain time period, and the available node list contains 3 nodes (node ​​1, node 2, and node 3). The allocation result of the basic round-robin algorithm is as follows: node 1 is allocated 334 connections (for requests 1, 4, 7...997, and 1000), node 2 is allocated 333 connections (for requests 2, 5, 8...998), and node 3 is allocated 333 connections (for requests 3, 6, 9...999). The difference in the number of connections between nodes is only 1, and the relative deviation is less than 0.3%, which can effectively avoid overloading of a single node and meet the initial balanced allocation requirement.

[0058] II. Dynamic Weight Optimization: Distribution Adjustment Based on Node Load

[0059] The basic round-robin algorithm may encounter the problem of "balanced allocation but unbalanced actual load" in scenarios with differences in node performance or load fluctuations (such as excessively high CPU utilization or memory constraints on a certain node). Therefore, a dynamic weighting mechanism needs to be introduced to adjust the allocation ratio based on the real-time load of the nodes, further optimizing connection balance. The specific implementation method is as follows:

[0060] (I) Collection of Node Load Indicators

[0061] The TCP gateway layer collects core load metrics from each backend node in real time using a combination of periodic heartbeat checks and proactive query requests. The collection frequency is set to 100ms / time to ensure the timeliness of the load data. The collected metrics include:

[0062] Connection load: The total number of TCP long connections currently established by the node, reflecting the connection load pressure on the node;

[0063] CPU utilization: The real-time CPU utilization of the node (the average of 5 data collections is taken to avoid the impact of instantaneous fluctuations). The threshold is set to 80%. If the threshold is exceeded, it is judged as high load.

[0064] Memory utilization: Real-time memory usage of the node (including JVM heap memory and system memory). The threshold is set to 75%. If the threshold is exceeded, the allocation of new connections will be restricted.

[0065] Response latency: The average response time of a node in processing a client request (the time from receiving a request to returning a response). The threshold is set to 200ms. If the threshold is exceeded, the assigned weight will be reduced.

[0066] (II) Rules for Calculating Dynamic Weights

[0067] The gateway layer calculates a real-time weight value for each node based on the collected load metrics (the weight ranges from 1 to 10; the higher the weight, the greater the probability of obtaining a new connection). The calculation logic is as follows:

[0068] Basic weight setting: All nodes have an initial basic weight of 5, which serves as the benchmark value for weight calculation;

[0069] Load indicator adjustment:

[0070] Connection load: If the current number of connections of a node is lower than "average number of connections in the cluster × 0.8", the weight is increased by 2; if it is higher than "average number of connections in the cluster × 1.2", the weight is decreased by 2.

[0071] CPU utilization: If CPU utilization is below 60%, weight +1; if it is above 80%, weight -3.

[0072] Memory utilization: If memory utilization is below 60%, weight +1; if it is above 75%, weight -2.

[0073] Response latency: If the response latency is less than 100ms, the weight increases by 1; if it is greater than 200ms, the weight decreases by 2.

[0074] Weight boundary constraints: If the calculated weight value is lower than 1, it will be forcibly set to 1 (to ensure the minimum allocation of rights for nodes); if it is higher than 10, it will be forcibly set to 10 (to avoid the allocation bias caused by an excessively high weight of a single node).

[0075] (III) Connection Allocation Process Based on Weighted Round Robin

[0076] Weight sum calculation: The gateway layer calculates the sum of the weights of all nodes in the available node list in real time (e.g., node 1 weight = 6, node 2 weight = 3, node 3 weight = 5, sum = 14).

[0077] Allocation pointer and step size settings: Initialize the "weighted allocation pointer" (initial value is 0) and the "step size" (step size = 1, pointer is incremented by 1 after each allocation);

[0078] Node selection logic: Each time a new connection request is received, the weighted allocation pointer is incremented starting from 0. If the pointer value is greater than the sum of weights, it is reset to 0. Nodes are selected based on the "weight interval" where the pointer value falls, for example:

[0079] Weighted interval division: Node 1 (0-5), Node 2 (6-8), Node 3 (9-13);

[0080] Pointer = 0 → Select node 1, Pointer = 5 → Select node 1, Pointer = 6 → Select node 2, Pointer = 9 → Select node 3, Pointer = 13 → Select node 3, Pointer = 14 → Reset to 0 → Select node 1;

[0081] Dynamic adjustment effect: When node 2's weight drops to 1 due to excessive CPU utilization (90%), its weight range shrinks (e.g., it only occupies 1 value), and the proportion of new connection allocation decreases from "3 / 14≈21.4%" to "1 / 12≈8.3%", effectively reducing the connection pressure on high-load nodes and achieving dynamic balance of "the higher the load, the less allocation".

[0082] III. Enhanced Node Status Awareness: Avoiding Connection Allocation for Abnormal Nodes

[0083] Backend service nodes may enter an abnormal state due to downtime, network interruption, service failure, or other reasons. Continuing to allocate connections to abnormal nodes will lead to connection failures or service interruptions. Therefore, a node state awareness mechanism needs to be added to the polling algorithm to remove abnormal nodes in real time, ensuring the reliability of connection allocation. The specific implementation method is as follows:

[0084] (I) Node Status Classification and Judgment Criteria

[0085] The gateway layer categorizes backend nodes into three states: "normal," "sub-healthy," and "abnormal," and determines the state through multi-dimensional detection, as shown in Table 1 below:

[0086] Table 1

[0087]

[0088] (II) Abnormal Node Removal and Recovery Process

[0089] Exception removal: When a node is determined to be "abnormal", the gateway layer performs the following operations:

[0090] Remove the node from the list of available nodes, and update the polling order and weight sum;

[0091] Send a "reconnection notification" (based on a custom TCP protocol, carrying the instruction "node abnormal, please reconnect") to all clients already established on this node.

[0092] Record the time and cause of node anomalies (e.g., "2024-05-20 14:30:00, Node 2 heartbeat timeout") for subsequent maintenance and troubleshooting.

[0093] Recovery Detection: Initiate "Periodic Recovery Detection" for abnormal nodes (the detection interval is gradually increased from 10 seconds to 5 minutes to avoid frequent detection consuming resources):

[0094] Detections 1-5: Every 10 seconds, the gateway layer sends a heartbeat request and connection test to the abnormal node;

[0095] If the "normal" status criteria are met for three consecutive tests, the node will be added back to the list of available nodes with an initial weight of 3 (lower than the average weight to avoid allocating too many connections at once).

[0096] If the detection is still abnormal, the detection interval will be extended to 30 seconds, 1 minute, and 5 minutes until the node recovers.

[0097] Example effect: When node 3 is marked as abnormal due to network interruption, the gateway layer immediately stops allocating new connections to it and notifies the 200 already connected clients to reconnect; after 5 minutes, node 3's network is restored, and it is re-added to the available list through recovery detection, with an initial weight of 3, and gradually takes on new connections to avoid the node becoming abnormal again due to a sudden increase in connections after recovery.

[0098] IV. Fault Tolerance Guarantee for Connection Allocation: Avoiding Data Inconsistency During Allocation

[0099] In high-concurrency scenarios, issues such as "delayed update of the gateway layer node list" and "concurrent modification of the allocation counter" may occur, leading to connection allocation errors (e.g., duplicate allocation to the same node or allocation to an already removed abnormal node). A fault-tolerance mechanism is needed to ensure the accuracy of the allocation process. The specific implementation method is as follows:

[0100] (I) Distributed Locks and Concurrency Control

[0101] When multiple gateway layer instances (such as primary / standby gateways or cluster gateways) process connection requests simultaneously, a "concurrent modification of allocation counters" issue may occur (e.g., two instances simultaneously modify the counter from 2 to 3, resulting in duplicate allocation to node 3). The solution is as follows:

[0102] Redis-based distributed lock: Before modifying the allocation counter and updating the node list, the gateway layer first requests a distributed lock from Redis (key="load_balance_lock", expiration time=500ms).

[0103] Lock contention handling: If the lock acquisition fails (indicating that other instances are modifying it), wait 10ms and retry. If it still fails after 3 retries, switch to the backup lock (key="load_balance_lock_backup").

[0104] Atomic operation update: Modify allocated data through Redis atomic commands (such as INCR to increment the counter, HSETNX to set the node status) to avoid inconsistencies in counter values ​​caused by concurrent modifications;

[0105] Example scenario: The gateway primary instance (A) and standby instance (B) process new connection requests simultaneously. Instance A first acquires the distributed lock, modifies the counter from 5 to 6, and selects node 2. Instance B fails to acquire the lock, waits 10ms, and retryes. After acquiring the lock, it modifies the counter from 6 to 7 and selects node 3 to avoid allocation errors caused by concurrent modification of the counter.

[0106] (ii) Verification and rollback of allocation results

[0107] After the gateway layer completes the node selection, it needs to perform a final verification before forwarding connection requests to ensure that the selected node is still in a "normal" state. The specific verification steps are as follows:

[0108] Secondary node status query: The status of the selected node is queried twice from the "list of available nodes" in local memory and the "node_status" hash table in Redis. If both are "normal", the connection request is forwarded.

[0109] Handling inconsistent states: If the local list shows a node as "normal" but Redis shows "abnormal" (indicating a delay in node status update), then the node is abandoned and the round-robin allocation is re-executed (the counter is not rolled back to avoid duplicate calculations).

[0110] Connection establishment confirmation: After the gateway layer forwards the connection request, it waits for the backend node to return a "connection established successfully" response (timeout = 1000ms); if no response is received within the timeout period, the node is determined to be abnormal, the connection is reassigned, and the node is marked as "sub-healthy".

[0111] Example effect: After selecting node 1 in the gateway layer, a second query finds that node 1 has been marked as "abnormal" in Redis (the local list has not been updated in time). Node 1 is immediately abandoned, and the polling is re-executed to select node 2, so as to avoid assigning the connection to the abnormal node and causing the connection to fail.

[0112] (III) Log Allocation and Traceability

[0113] The gateway layer records detailed logs for each connection allocation, facilitating subsequent troubleshooting of allocation errors. The log content includes:

[0114] Basic information: connection request time, client device ID, client IP, allocation node identifier;

[0115] Process information: Counter value before allocation, weight of selected node, node status (normal / sub-healthy / abnormal), whether secondary verification is triggered;

[0116] Result information: Connection established successfully / failed, reason for failure (node ​​error / timeout / verification failure);

[0117] Log storage: Logs are written to the ELK log system in real time and retained for 30 days. It supports searching by dimensions such as "assigned node" and "failure reason" to quickly locate allocation problems (e.g., the allocation failure rate of node 2 is as high as 30% during a certain period, and the log shows that its CPU utilization rate has been continuously exceeding 90%).

[0118] Shared caching module: Redis is introduced as a shared caching system to store the data of each segment of a long SMS message, splicing progress status information, and connection mapping relationships;

[0119] In a preferred but non-limiting embodiment of the present invention, Redis features high performance, high availability, and support for multiple data structures, thus meeting the data sharing needs in a distributed environment. When a backend service node receives a long SMS segment, it stores the segment data (including SMS identifier, segment sequence number, segment content, reception time, etc.) in Redis and updates the SMS splicing progress status (such as the number of segments received and whether it is complete).

[0120] In a preferred but non-limiting embodiment of the present invention, Redis also stores the mapping relationship between client connections and backend service nodes. When a client initiates a request for the complete content of a long SMS message, any backend service node can obtain all SMS fragments corresponding to that client by querying Redis, thus avoiding data isolation problems caused by connections being allocated to different nodes.

[0121] In a preferred but non-limiting embodiment of the present invention, Redis also supports a data expiration policy, which allows setting a storage timeout for long SMS segments. For long SMS messages that have not collected all segments after a preset time, the relevant segment data is automatically deleted to release cache space and avoid data redundancy.

[0122] Long SMS splicing engine module: Integrated into the backend service node, it serves as the core processing unit and is responsible for implementing the splicing logic of long SMS segments;

[0123] In a preferred but non-limiting embodiment of the present invention, the long SMS splicing engine module performs a complete check on SMS messages that have not been spliced ​​by periodically polling the long SMS status information in Redis.

[0124] In a preferred but non-limiting embodiment of the present invention, during the complete check process, the long SMS splicing engine module queries the total number of SMS segments and the number of received segments based on the SMS identifier. When the number of received segments equals the total number of segments, it is determined that the SMS segments are complete. Then, all segment data is read from Redis and spliced ​​in the order of segment numbers to generate complete long SMS content. After splicing, the long SMS splicing engine module stores the complete SMS content in a designated area of ​​Redis and updates the splicing status of the SMS to "completed".

[0125] In a preferred but non-limiting embodiment of the present invention, the long SMS splicing engine module is also responsible for timeout management. For SMS messages that have not been spliced ​​after exceeding the preset timeout period (which can be configured according to business needs, such as 5 minutes), they are marked as "sponging failed" and an alarm mechanism is triggered (such as sending a notification to the operation and maintenance personnel) so as to troubleshoot problems in a timely manner (such as fragment loss, network latency, etc.).

[0126] In a preferred but non-limiting embodiment of the present invention, the long SMS splicing engine module further supports a status query function. The client can obtain the splicing progress (such as the number of received segments and the number of remaining segments) and the current status (such as "sponging in progress", "completed", "sponging failed") of a specified long SMS by sending a query request.

[0127] Message queue module: Kafka is used as the message queue system to implement asynchronous transmission and priority processing of long SMS segments;

[0128] In a preferred but non-limiting embodiment of the present invention, when a backend service node receives a long SMS segment, it does not directly splice it. Instead, it encapsulates the segment data into a message and sends it to a specified topic in Kafka. Kafka, with its high throughput and low latency, can buffer a large number of messages, preventing backend service nodes from experiencing processing bottlenecks due to sudden high concurrency. The message queue system categorizes and stores messages according to their business priority (e.g., emergency notification SMS messages have higher priority than ordinary advertising SMS messages), setting different message partitions. The long SMS splicing engine of the backend service node consumes messages from the corresponding partitions according to priority, prioritizing high-priority long SMS segments to ensure the timeliness of important business. Simultaneously, Kafka supports persistent message storage; when a backend service node fails, messages are not lost and can be consumed again after the node recovers, ensuring the integrity of data processing.

[0129] Backend service cluster module: It consists of multiple backend service nodes with the same configuration, adopts a horizontal scaling architecture, and supports dynamically increasing or decreasing the number of nodes according to business needs.

[0130] In a preferred but non-limiting embodiment of the present invention, each backend service node is equipped with functional modules such as TCP connection processing and a long SMS splicing engine, enabling it to independently complete the reception, storage, splicing, and response of long SMS segments. When the throughput of the existing cluster becomes insufficient due to increased business volume, new backend service nodes can be added and registered in the load list of the TCP gateway layer. The gateway layer will automatically allocate new connections to the new nodes, thereby achieving dynamic expansion of the service cluster. Conversely, when the business volume decreases, a set number of idle backend service nodes can be shut down to reduce hardware resource consumption. In addition, the nodes in the cluster achieve data synchronization and collaborative work through a shared cache module (Redis) and a message queue module (Kafka), ensuring that the business processing logic between each node is consistent and avoiding data conflicts and inconsistencies.

[0131] A specific example of the present invention is as follows:

[0132] (I) Example 1: Device Deployment and Operation in Basic Business Scenarios

[0133] Device deployment architecture

[0134] In this embodiment, the long SMS splicing device based on long connection polling load is deployed on the SMS service platform of an Internet company, and its specific architecture includes:

[0135] TCP Gateway Layer: Deploy two physical servers (configuration: 32 CPU cores, 64GB memory, gigabit network card), using the Netty 4.x framework to build the TCP gateway service. The two gateway servers use Keepalived for primary / backup redundancy to avoid single points of failure. The gateway layer is configured with a round-robin load balancing algorithm, and the load list initially contains three backend service nodes.

[0136] Backend service cluster: Deploy 3 backend service nodes (configuration: 16 CPU cores, 32GB memory), each node deploys a Java-developed backend service program, integrates a long SMS splicing engine module, and the service port is 8080.

[0137] Shared caching: A Redis cluster (3 master, 3 slave architecture) is deployed. The master nodes are responsible for data writing, and the slave nodes are responsible for data reading. A sentinel mechanism is used to achieve master-slave failover, ensuring high availability of the Redis service. The timeout for storing long SMS fragments is set to 5 minutes, and the storage time for complete SMS content is set to 24 hours.

[0138] Message queue: Deploy a Kafka cluster (3 broker nodes), create the topic "sms_fragment_topic", which is divided into 2 partitions, corresponding to "normal priority" and "high priority" respectively. Each partition is set up with 2 replicas to ensure message reliability.

[0139] Device operation process

[0140] Step 1: Connection Establishment. The client (e.g., a text messaging app on a user's phone) initiates a TCP long connection request to the TCP gateway layer via the mobile data network. The request carries the client identifier (e.g., device ID) and protocol version number. Upon receiving the request, the gateway master node verifies the client identifier's validity (by querying a pre-defined device whitelist). If the verification passes, the connection is allocated to backend service node 1 based on a round-robin load balancing algorithm (the load list order is node 1 → node 2 → node 3 → node 1...). The gateway layer records the mapping relationship between this connection and node 1 and synchronizes it to the "connection_mapping" hash table in Redis (key: client identifier, value: node 1 IP: port).

[0141] Step 2: Long SMS Segment Receiving and Storage The client needs to send a long SMS message containing 5 segments (SMS ID: SMS20240520001, total number of segments: 5), and send the 5 SMS segments to the server in sequence.

[0142] The client sends the first fragment (fragment number: 1, content: "Your account on May 20, 2024"), which is transmitted to the backend service node 1 through the established TCP connection.

[0143] After receiving the fragment, Node 1 encapsulates the fragment data into a Kafka message (message format: {"smsId":"SMS20240520001","fragmentNo":1,"content":"Your account on May 20, 2024","priority":"high","receiveTime":"2024-05-2010:00:00"}), and sends it to the high-priority partition of the topic "sms_fragment_topic" according to the priority "high".

[0144] The Kafka cluster receives and persists the message. The long SMS splicing engine of backend service node 1 consumes the message from the high-priority partition and stores the fragment data in the "sms_fragment" hash table in Redis (key: SMS20240520001:1, value: fragment content and receiving time). At the same time, it updates the SMS status in the "sms_status" hash table in Redis (key: SMS20240520001, value: {"totalFragments":5, "receivedFragments":1, "status":"sponging", "lastUpdateTime":"2024-05-2010:00:00"}).

[0145] Repeat the above process, the client sends fragments 2-5 in sequence, which are received and processed by node 1 respectively. The "receivedFragments" field of the "sms_status" hash table in Redis is updated to 2, 3, 4 and 5 in sequence.

[0146] Step 3: Long SMS Concatenation and Status Update. The long SMS concatenation engine polls the "sms_status" hash table in Redis at 100ms intervals. When it polls the SMS identifier SMS20240520001, it finds that "receivedFragments" (5) equals "totalFragments" (5), determines that the fragments are complete, and begins concatenation.

[0147] The engine reads all fragments of the SMS message (SMS20240520001:1 to SMS20240520001:5) from the “sms_fragment” hash table in Redis.

[0148] The fragments are concatenated in the order of fragment numbers 1-5 to generate a complete long text message: "Your account had a transfer transaction of 1000.00 yuan on May 20, 2024. Transaction status: successful. If you have any questions, please contact customer service at 400-XXX-XXXX."

[0149] The engine stores the complete SMS content in the Redis hash table “sms_complete” (key: SMS20240520001, value: complete content), updates the status of the SMS in the hash table “sms_status” to “complete”, and updates “lastUpdateTime” to the current time.

[0150] Step 4: Client Retrieves Complete SMS Message The client sends a request to retrieve the complete content of SMS message SMS20240520001. This request is transmitted to backend service node 1 via a TCP connection. Node 1 queries the "sms_status" hash table in Redis and finds that the SMS message status is "completed". It then reads the complete content from the "sms_complete" hash table and sends it back to the client via the TCP connection. The client receives and displays the complete long SMS message.

[0151] (II) Example 2: Device operation in a scenario of dynamic service expansion

[0152] Scenario: During the "618" shopping festival, an e-commerce platform experienced a surge in SMS sending volume. The CPU utilization of the original three backend service nodes all exceeded 80%, and the response latency increased from the normal 50ms to 200ms, resulting in processing delays for some SMS segments. To resolve this issue, dynamic scaling of the backend service cluster is required.

[0153] Expansion and Operation Process

[0154] Step 1: Adding Backend Service Nodes. The operations and maintenance personnel add two new backend service nodes (Node 4 and Node 5, with configurations identical to the existing nodes). Deploy the same backend service program on these nodes, integrating the long SMS splicing engine module. Register the IP addresses and ports of Node 4 and Node 5 to the load balancer list of the TCP gateway layer. The gateway layer detects that the new nodes are in normal status (CPU utilization below 30%, memory utilization below 40%) and adds them to the round-robin load sequence. At this point, the load balancer list is updated in the following order: Node 1 → Node 2 → Node 3 → Node 4 → Node 5 → Node 1...

[0155] Step 2: New Connection Allocation and Business Processing After the newly added nodes complete registration, newly initiated TCP long connections from the client are allocated to each node according to the updated round-robin order. Nodes 4 and 5 begin receiving new connections and processing long SMS segments.

[0156] A client initiates a connection request, which is assigned to node 4 by the gateway layer. Node 4 receives a long SMS segment (SMS ID: SMS20240618001, segment number: 1) sent by the client, encapsulates it into a Kafka message, and sends it to the corresponding partition.

[0157] Node 4's splicing engine consumes the message, stores the fragment data in Redis, and updates the SMS status. Since Redis is a shared cache, other nodes (such as Node 1 and Node 2) can query the SMS fragment data and status at any time, achieving data sharing.

[0158] Step 3: Verification of Expansion Effect After expansion, the average CPU utilization of the backend service cluster decreased from 80% to 45%, the response latency recovered from 200ms to less than 60ms, the message backlog in the Kafka message queue gradually decreased, and the long SMS splicing completion rate increased from 95% to 99.8%, effectively meeting the high throughput demand during the "618" shopping festival and ensuring the stable operation of the SMS service.

[0159] (III) Example 3: Fault-tolerant operation of device in service restart scenario

[0160] Scenario Background: Backend service node 2 needs to be updated and restarted. At this time, there are 100 active TCP long connections on node 2, and some long SMS messages are in the "assembling" state (e.g., SMS identifier: SMS20240521002, 3 fragments have been received, total number of fragments: 5).

[0161] Restart and Fault Tolerance Process

[0162] Step 1: Node Status Monitoring and Connection Migration. The TCP gateway layer monitors the status of backend service nodes by periodically sending heartbeat packets (every 100ms interval). When node 2 starts restarting, the heartbeat response times out, the gateway layer determines that node 2 is abnormal, removes it from the load list, and marks it as "unavailable". For the 100 established TCP long connections on node 2, the gateway layer sends a reconnection notification to the client. After receiving the notification, the client re-initiates the TCP connection request.

[0163] Step 2: New Connection Allocation and Service Recovery. The gateway layer allocates newly initiated connections from clients to nodes 1, 3, 4, and 5 in a round-robin order (node ​​2 is not included in the load list at this time). Among these, a client originally connected to node 2 is reassigned to node 3 after reconnecting. This client continues to send incomplete long SMS segments (SMS20240521002, segment numbers: 4 and 5):

[0164] Node 3 receives segments 4 and 5 and stores them in Redis. At this time, the number of received segments of this SMS message in Redis is updated to 5 (equal to the total number of segments).

[0165] Node 3's splicing engine polls the SMS status, reads all fragments, splices them together, stores the complete content in Redis, and updates the status to "completed." The client retrieves the complete SMS content through Node 3, and the business process remains uninterrupted.

[0166] Step 3: Node Recovery and Load Reset. After Node 2 completes the version update and restarts, it automatically sends a registration request to the gateway layer. The gateway layer detects that Node 2 is in a normal state (CPU, memory, and port are all normal), adds it back to the load list, and restores the round-robin load order (Node 1 → Node 2 → Node 3 → Node 4 → Node 5 → Node 1...). Node 2 starts receiving new connection requests. No idle service issues occurred during the entire process, and service availability was guaranteed.

[0167] The beneficial effects of the present invention are as follows, compared with the prior art:

[0168] Ensuring the integrity of long SMS messages: By introducing a shared Redis cache, data sharing of long SMS fragments is achieved in a distributed environment. Regardless of which node in the backend service cluster a client connection is assigned to, all SMS fragments corresponding to that client can be retrieved by querying Redis. Simultaneously, the long SMS splicing engine ensures timely splicing after all fragments are collected through a periodic polling and integrity check mechanism. This effectively solves the problem of incomplete long SMS content caused by multiple connections from the same IP being assigned to different machines under the existing IP hash load balancing method, thus improving the accuracy of data processing.

[0169] Optimizing TCP connection distribution balance: The TCP gateway layer employs a round-robin load balancing algorithm, combined with backend service node status monitoring, to evenly distribute client connections across all nodes, avoiding overload on any single node. Furthermore, when the service restarts, the gateway layer automatically reallocates connections to other healthy nodes, adding them back to the load list only after the restarted nodes have recovered. This resolves the issue of idle services caused by service restarts, fully utilizes the cluster's hardware resources, and improves overall service processing efficiency.

[0170] Supports dynamic service scaling and high throughput: The backend service cluster adopts a horizontally scalable architecture, allowing for flexible addition or removal of nodes based on changes in business volume. Newly added nodes only need to register with the gateway layer to receive connections and process business, achieving rapid scaling. Simultaneously, the TCP gateway layer built with the Netty framework efficiently handles concurrent connections, the Kafka message queue buffers instantaneous high-concurrency messages, and Redis caching improves data read and write speeds. The synergistic effect of these three elements significantly improves the throughput of the service cluster, meeting the demands of sudden business growth and ensuring service stability and reliability.

[0171] Adaptable to complex network environments and various load balancing methods: The round-robin load balancing algorithm of this invention does not rely on IP addresses and can adapt to any load balancing method in complex network environments (such as IP hashing, random load balancing, etc.). Switching between different load balancing strategies can be achieved simply by adjusting the load balancing algorithm at the TCP gateway layer, which enhances the flexibility and versatility of the technical solution and reduces the adaptation cost under different business scenarios.

[0172] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention without departing from the spirit and scope of the present invention. Any modifications or equivalent substitutions should be covered within the scope of protection of the claims of the present invention.

Claims

1. A long SMS splicing device based on long-connection polling load, characterized in that, include: The TCP gateway layer module, shared cache module, long SMS splicing engine module, message queue module, and backend service cluster module are integrated into the processing terminal. TCP Gateway Layer Module: This module uses the Netty framework to build a high-performance TCP gateway layer service, serving as a communication bridge between the client and the backend service cluster. Shared caching module: Redis is introduced as a shared caching system to store the data of each segment of a long SMS message, splicing progress status information, and connection mapping relationships; Long SMS splicing engine module: Integrated into the backend service node, it serves as the core processing unit and is responsible for implementing the splicing logic of long SMS segments; Message queue module: Kafka is used as the message queue system to implement asynchronous transmission and priority processing of long SMS segments; Backend service cluster module: It consists of multiple backend service nodes with the same configuration, adopts a horizontal scaling architecture, and supports dynamically increasing or decreasing the number of nodes according to business needs.

2. The long SMS splicing device based on long connection polling load as described in claim 1, characterized in that, The Netty framework in the TCP gateway layer module supports connection establishment, maintenance, and disconnection management. Clients initiate TCP long connection requests through this TCP gateway layer module. After performing preliminary verification of the requested long connection, the TCP gateway layer module distributes the long connection to different backend service nodes in the backend service cluster based on a round-robin load balancing algorithm. The round-robin load balancing algorithm distributes new connections to each backend service node in a preset order, ensuring that the number of connections received by each backend service node is relatively balanced. At the same time, the TCP gateway layer module monitors the running status of the backend service nodes in real time. When a backend service node malfunctions, it is automatically removed from the load list and re-added after it recovers.

3. The long SMS splicing device based on long connection polling load according to claim 2, characterized in that, When the backend service node receives a long SMS segment, it stores the segment data in Redis and updates the SMS splicing progress status. Redis also stores the mapping relationship between client connections and backend service nodes. When a client initiates a request for the complete content of a long SMS message, any backend service node can retrieve all SMS fragments corresponding to that client by querying Redis. Redis supports data expiration policies, allowing you to set the storage timeout for long SMS messages. For long SMS messages that have not been fully collected within the preset time, the relevant segment data will be automatically deleted to free up cache space.

4. The long SMS splicing device based on long connection polling load according to claim 3, characterized in that, The long SMS splicing engine module periodically polls the long SMS status information in Redis to perform a complete check on SMS messages that have not been spliced.

5. The long SMS splicing device based on long connection polling load according to claim 4, characterized in that, During the complete inspection process, the long SMS splicing engine module queries the total number of SMS segments and the number of received segments based on the SMS identifier. When the number of received segments equals the total number of segments, it is determined that the SMS segments are complete. Then, all segment data is read from Redis and spliced ​​in the order of segment sequence numbers to generate the complete long SMS content. After the concatenation is completed, the long SMS concatenation engine module stores the complete SMS content in a designated area of ​​Redis and updates the concatenation status of the SMS to "completed".

6. The long SMS splicing device based on long connection polling load according to claim 5, characterized in that, The long SMS splicing engine module is also responsible for timeout management. For SMS messages that have not been spliced ​​after the preset timeout period, they are marked as "sponging failed" and an alarm mechanism is triggered so that problems can be investigated in a timely manner.

7. The long SMS splicing device based on long connection polling load as described in claim 6, characterized in that, The long SMS splicing engine module supports a status query function. Clients can send a query request to obtain the splicing progress and current status of a specified long SMS.

8. The long SMS splicing device based on long connection polling load according to claim 7, characterized in that, When the backend service node receives a long SMS segment, it does not directly splice it together, but encapsulates the segment data into a message and sends it to the specified topic in Kafka. The message queue system categorizes and stores messages according to their business priority for long SMS messages, setting up different message partitions. The long SMS splicing engine of the backend service node consumes messages from the corresponding partitions in priority order, prioritizing the processing of high-priority long SMS segments. At the same time, Kafka supports persistent message storage, so messages will not be lost when the backend service node fails, and messages can be consumed again after the node recovers.

9. The long SMS splicing device based on long connection polling load according to claim 8, characterized in that, Each backend service node is equipped with TCP connection processing and long SMS splicing engine modules. When the throughput of the existing cluster is insufficient due to the increase in business volume, new backend service nodes can be added and registered to the load list of the TCP gateway layer. The gateway layer will automatically allocate new connections to the new nodes, thereby realizing the dynamic expansion of the service cluster. Conversely, when business volume decreases, a set number of idle backend service nodes can be shut down. In addition, nodes in the cluster achieve data synchronization and collaborative work through shared cache modules and message queue modules, ensuring that the business processing logic between each node is consistent.

10. The long SMS splicing device based on long connection polling load according to claim 9, characterized in that, The round-robin load balancing algorithm distributes new connections to each backend service node in a preset order, ensuring a relatively balanced number of connections received by each backend service node. Specific methods include: With fixed-order traversal as the core logic, new connection requests are allocated sequentially according to the priority order of the pre-set backend service node list to ensure the balance of the number of connections of each node in the initial state. A dynamic weighting mechanism is introduced to adjust the allocation ratio based on the real-time load of nodes, further optimizing connection balance. A node status awareness mechanism is added to the polling algorithm to remove abnormal nodes in real time and ensure the reliability of connection allocation. The accuracy of the allocation process is ensured through a fault-tolerance mechanism.

Images