Cluster server and client busy trigger start flow control optimization method

Abstract

The invention discloses a cluster server and client busy trigger start flow control optimization method. The method comprises the following steps: S1, determining a flow control mode; s2, making a flow control strategy; s3, calculating the predicted flow after the flow control strategy is implemented; and S4, selecting an optimal flow control strategy for implementation. By reasonably limiting the sending rate, controlling the concurrent number, checking the message size and configuring parameters, the flow control can be effectively realized, the system problem caused by too fast message sending is avoided, and the stable operation of the message system is ensured while the performance is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software operation and maintenance research and development, and in particular to a method for optimizing flow control by busy triggering startup of a cluster server and a client. Background Art

[0002] On the Kubernetes (K8S container cloud) platform, the RocketMQ (message queue) service cluster is deployed. However, due to the containerized deployment and operation mode of the RocketMQ (message queue) service cluster in K8S (container cloud), when the cluster service faces a large amount of data usage scenarios, the producer will write the message to the Broker (service node component). The producer sends messages too quickly, causing the Broker to be overloaded, network congestion, or unable to process messages, which causes system instability or message accumulation. Summary of the invention

[0003] In order to solve the above problems, the present invention provides a cluster server and client busy trigger startup flow control optimization method, including the following steps: S1. Determine the flow control method; S2. Formulate a flow control strategy; S3. Calculate the expected flow size after the flow control strategy is implemented; S4. Select the optimal flow control strategy for implementation.

[0004] Furthermore, the traffic control method in step S1 specifically includes: preventing service node component overload, preventing network resource congestion, and preventing consumer end overload.

[0005] Furthermore, the flow control strategy formulated in the step S2 specifically includes: sending rate limitation, sending concurrency control, and message size limitation.

[0006] Furthermore, the sending concurrency control specifically includes the following methods: limiting the maximum allowed concurrent sending requests, packaging messages and sending them in batches, increasing asynchronous sending, and increasing concurrent threads.

[0007] Furthermore, the message size limitation specifically includes the following methods: setting the sending message size by default and compressing the size of a single message.

[0008] Furthermore, the default setting for sending a message size is specifically 4MB.

[0009] The present invention provides a cluster server and client busy triggering startup flow control optimization method, which has the following beneficial effects: The present invention can effectively implement flow control by reasonably limiting the sending rate, controlling the number of concurrent messages, checking the message size and configuring parameters, avoiding system problems caused by too fast message sending, improving performance and ensuring the stable operation of the message system. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying creative work.

[0011] Figure 1 The present invention provides a flow chart of the method. DETAILED DESCRIPTION

[0012] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0013] The following is a detailed description of the implementation method of the present invention in conjunction with the accompanying drawings. Only some embodiments are described, not all embodiments. For the purpose of clarity, representations and descriptions that are not related to the present invention are omitted in the drawings and descriptions.

[0014] In order to have a clearer understanding of the technical features, purposes and beneficial effects of the present invention, the technical solution of the present invention is now described in detail below. Obviously, the implementation cases described are part of the embodiments of the present invention, not all of the embodiments, and cannot be understood as limiting the scope of the implementation of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work belong to the protection scope of the present invention.

[0015] like Figure 1 As shown, the present invention provides a cluster server and client busy trigger start flow control optimization method, including the following steps: S1. Determine the flow control method; S2. Formulate a flow control strategy; S3. Calculate the expected flow size after the flow control strategy is implemented; S4. Select the optimal flow control strategy for implementation.

[0016] The traffic control method in step S1 specifically includes: preventing service node component overload, preventing network resource congestion, and preventing consumer end overload.

[0017] The flow control strategy formulated in step S2 specifically includes: sending rate limit, sending concurrency control, and message size limit.

[0018] Sending rate limit: implemented through code, for example, you can use the token (Token Bucket) algorithm to limit the sending rate, such as a simple implementation example: RateLimiter rateLimter = new RateLimiter(100); / / The maximum time for sending messages is 100 seconds for (int i = 0; i<1000; i++) { if (rateLimiter.tryAcquire()) { / / Send a message producer.send(message); } else { / / Wait or handle rate limiting System.out.println("Rate limit reached, waiting ..."); TimeUnit.MILLISECONDS.sleep(100);.

[0019] The specific methods of sending concurrency control include: limiting the maximum number of concurrent sending requests allowed, batch sending of messages: packaging multiple messages into one message for batch sending, which can also reduce the number of network interactions and improve the sending efficiency, and increasing asynchronous sending: using asynchronous sending (sendAsync) or one-way sending (sendOneway) to improve message sending efficiency, reduce latency, and increase concurrent threads.

[0020] The message size limit specifically includes the following methods: Default setting of sending message size: The default setting of sending message size is specifically 4MB, Single message size compression: If a single message is too large, it will also affect the overall TPS of the cluster. You can consider optimizing the content of the message, or compressing the message to reduce the message size.

[0021] According to the business usage scenario, the RocketMQ (message queue) Broker server broker.conf appropriately adjusts the configuration parameters.

[0022] When the message size exceeds 4k, it will be automatically compressed. Messages exceeding 128k are not allowed to be sent. The compression is done on the Producer side and the verification is done through Validators.checkMessage(msg,this.defaultMQProducer); in this way, the Broker (the service node) saves the compressed message.

[0023] After the client (Consumer) pulls the message, it will process the message. If the message has been compressed, it will be decompressed (UtilAll.uncompress) to ensure that the message is correctly decoded before subsequent logical processing. When sending a message, you can use the setBody method of the Message object to set the compressed message body.

[0024] public static void main(String[] args) throws Exception { / / Create a producer and specify the group name DefaultMQProducer producer = new DefaultMQProducer("compressed_producer_group"); / / Specify Namesrv address producer.setNamesrvAddr("localhost:9876"); / / Start the producer producer.start(); try { / / Create a message object, specifying the subject and tags Message msg = new Message("CompressedTopic", "TagA", "Hello RocketMQ".getBytes()); / / Compress the message body byte[] gzipped = compress(msg.getBody()); msg.setBody(gzipped); / / Send a message producer.send(msg); } catch (Exception e) { e.printStackTrace(); } finally { / / Close the producer producer.shutdown(); } } private static byte[] compress(byte[]data) throws IOException { ByteArrayOutputStream out = new ByteArrayOutputStream(); GZIPOutputStream gzip = new GZIPOutputStream(out); gzip.write(data); gzip.close(); return out.toByteArray(); }.

[0025] In the example, the compress method uses GZIPOutputStream to compress the message body. When sending a message, you need to replace the original message body with the compressed message body.

[0026] Because messages may use compression algorithms to reduce the amount of data transmitted over the network when they are sent and received, if the client needs to manually decompress the message, in the example, the decompressMessage method is a hypothetical decompression function, which needs to be replaced with appropriate decompression code based on the actual compression algorithm. If the message is not compressed, the original message body can be returned directly.

[0027] public class Consumer { public static void main(String[] args) throws Exception { / / Create a consumer DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumer_group"); consumer.subscribe("TopicTest", "*"); / / Register message listener consumer.registerMessageListener((MessageListenerConcurrently)(msgs, context) ->{ for (MessageExt msg : msgs) { String messageBody = new String(msg.getBody()); / / Get the message body / / If the message may be compressed, you can decompress it here / / NOTE: The actual decompression method depends on how the message was compressed String uncompressedMessageBody = decompressMessage(messageBody); System.out.println("Received message: " +uncompressedMessageBody); } return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; }); / / Start the consumer consumer.start(); System.out.printf("Consumer Started.%n"); } / / Assumption decompression method, in actual use, you need to replace it with appropriate decompression logic private static String decompressMessage(String compressedMessage){ / / This should be the decompression code, such as using GZIPInputStream, etc. / / The decompressed string will be returned return compressedMessage; / / Assuming no decompression, return the original string directly }.

[0028] By default, messages larger than 4k are compressed (configurable). The compression algorithm is zip. The default level is 5 (configurable). RocketMQ's compression mechanism is Producer compression, Broker transmission, and Consumer decompression.

[0029] The present invention can effectively implement flow control by reasonably limiting the sending rate, controlling the number of concurrent messages, checking the message size and configuring parameters, avoiding system problems caused by too fast message sending, improving performance and ensuring the stable operation of the message system.

[0030] The above is only a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the form disclosed herein, and should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications and environments, and can be modified within the scope of the concept described herein through the above teachings or the technology or knowledge of the relevant field. The changes and modifications made by those skilled in the art shall not deviate from the spirit and scope of the present invention, and shall be within the scope of protection of the claims attached to the present invention.

Claims

1. A cluster server and client busy triggering start flow control optimization method, characterized in that: The following steps are involved: S1. Determine the flow control method; S2. Formulate traffic control strategy; S3. Calculate the expected flow size after the flow control strategy is implemented; S4. Select the optimal flow control strategy and implement it.

2. The cluster server and client busy triggering start flow control optimization method according to claim 1, characterized in that: The flow control method in the step S1 specifically includes: preventing service node component overload, preventing network resource congestion, and preventing consumer end overload.

3. The cluster server and client busy triggering start flow control optimization method according to claim 1, characterized in that: The flow control strategy formulated in the step S2 specifically includes: sending rate limitation, sending concurrency control, and message size limitation.

4. The cluster server and client busy triggering start flow control optimization method according to claim 3, characterized in that: The sending concurrency control specifically includes the following methods: limiting the maximum number of concurrent sending requests allowed, sending messages in batches, increasing asynchronous sending, and increasing concurrent threads.

5. The cluster server and client busy triggering start flow control optimization method according to claim 3, characterized in that: The message size limitation specifically includes the following methods: setting the message size to be sent by default and compressing the size of a single message.

6. The cluster server and client busy triggering start flow control optimization method according to claim 5, characterized in that: The default setting for sending a message size is specifically 4MB.

Images