A Netty-based car charging pile docking system, method and medium

Abstract

The present application discloses a Netty-based car charging pile docking system, method, and medium, which mainly relates to the field of car charging pile technology and is used to solve the problems of low connection management efficiency, redundant message processing processes, insufficient feedback link reliability, and limited resource utilization and scalability in existing solutions in high-concurrency scenarios. It includes: a charging pile client, which is used to establish a connection with the server via the TCP / IP protocol; a server, which constructs an Nginx gateway and several Netty servers, and is used to distribute the uploaded information to the Netty server via the Nginx gateway when receiving the uploaded information from the charging pile client; wherein the Netty server includes a preset data codec, a message processor, a message publishing component, a message monitoring component, and a connection mapper; a business processing system, which is used to monitor the json file of the distributed stream processing platform and return feedback information to the distributed stream processing platform.

Description

Technical Field

[0001] The present application relates to the technical field of automobile charging piles, and in particular to a Netty-based automobile charging pile docking system, method, and medium. Background Art

[0002] With the rapid development of new energy vehicles, the large-scale access of charging piles has put forward higher requirements for the real-time performance, stability and scalability of communication systems. Traditional charging pile and server connection solutions are mostly based on HTTP protocol or simple TCP long connection, which has the following technical bottlenecks:

[0003] 1. Inefficient connection management in high-concurrency scenarios: Existing systems typically employ single-point service architectures or static load balancing strategies, making them incapable of handling the dynamic fluctuations in charging pile access requests. Especially during peak hours, the server is prone to response delays or connection interruptions due to the surge in connection volume, and cannot dynamically scale computing resources to accommodate load fluctuations. 2. Redundant message processing: Data uploaded by charging piles typically undergoes multiple levels of protocol parsing (e.g., byte stream → binary → structured data). Traditional solutions fail to modularly separate encoding and decoding from business logic, resulting in low parsing efficiency, high resource utilization, and difficulty in compatibility with charging pile communication protocols from different vendors. 3. Inadequate feedback link reliability: Existing technologies often rely on fixed connections or polling mechanisms to issue control commands to charging piles, lacking real-time monitoring and dynamic mapping of connection status. If network fluctuations cause a connection interruption, commands cannot be accurately routed to the target charging pile, impacting business continuity. 4. Limited resource utilization and scalability: In traditional architectures, message processing, data forwarding, and business logic are tightly coupled, making it difficult to increase system throughput through horizontal scaling. In addition, the lack of a unified connection and message lifecycle management mechanism can easily lead to memory leaks or thread blocking problems.

[0004] Therefore, there is an urgent need for a Netty-based car charging pile docking system, method and medium to solve the above technical problems. Summary of the Invention

[0005] This application provides a Netty-based car charging pile docking system, method, and medium to address the problems of low connection management efficiency, redundant message processing processes, insufficient feedback link reliability, and limited resource utilization and scalability in existing solutions in high-concurrency scenarios.

[0006] In the first aspect, the present application provides a car charging pile docking system based on Netty, the system comprising:

[0007] The charging pile client is used to establish a connection with the server through the TCP / IP protocol; the server builds an Nginx gateway and several Netty servers, and is used to distribute the uploaded information to the Netty server that meets the current load balancing through the Nginx gateway when receiving the uploaded information from the charging pile client; among them, the Netty server includes a preset data codec, a message processor, a message publishing component, a message listening component, and a connection mapper; through the data codec, the data packet of the uploaded information is read; according to the message frame type of the message in the data packet, the corresponding message processor is determined, and then the bytecode of the message in the data packet is parsed into a json file through the message processor; through the connection mapper, the charging pile code is obtained; the json file is pushed to the distributed stream processing platform through the message publishing component; through the message listening component, the feedback information returned by the distributed stream processing platform is monitored, and the corresponding ChannelHandler is determined according to the charging pile code in the feedback information; through the connection mapper, the charging pile code and the ChannelHandler are associated; the feedback information is converted into bytecode and sent to the corresponding charging pile client through the ChannelHandler; the business processing system is used to monitor the json file of the distributed stream processing platform and return feedback information to the distributed stream processing platform.

[0008] In one implementation of the present application, the Netty server includes a data codec definition unit,

[0009] Used to define the data codec to inherit ByteToMessageDecoder and override the decode() method to convert the transmission information into a complete data packet;

[0010] And define the data block of the transmission information of preset fixed length intercepted by FixedLengthFrameDecoder, or use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

[0011] In one implementation of the present application, the connection mapper includes a login binding unit, which is used to perform login authentication and binding on the charging pile client of the current message to obtain the charging pile code.

[0012] In one implementation of the present application, the Netty server includes a configuration unit,

[0013] Used to configure the correspondence between message frame types and message processors.

[0014] In one implementation of the present application, the business processing system includes a business processing component.

[0015] Used to input json files into the preset business processing program to obtain feedback information.

[0016] In a second aspect, the present application provides a method for docking a car charging pile based on Netty, which is applied to a docking system for a car charging pile based on Netty, and the method includes:

[0017] When receiving the upload information from the charging pile client, the uploaded information is distributed to the Netty server that meets the current load balancing requirements through the Nginx gateway;

[0018] The data packet of the uploaded information is read through the data codec in the Netty server; the corresponding message processor is determined according to the message frame type of the message in the data packet, and then the bytecode of the message in the data packet is parsed into a json file through the message processor in the Netty server; the charging pile code is obtained through the connection mapper in the Netty server; the json file is pushed to the distributed stream processing platform through the message publishing component in the Netty server; the feedback information returned by the distributed stream processing platform is monitored through the message listening component in the Netty server, and the corresponding ChannelHandler is determined according to the charging pile code in the feedback information; the charging pile code and ChannelHandler are associated through the connection mapper; the feedback information is converted into bytecode and sent to the corresponding charging pile client through the ChannelHandler;

[0019] The business processing system monitors the json file of the distributed stream processing platform and then returns feedback information to the distributed stream processing platform.

[0020] In one implementation of the present application, before reading the data packet of the uploaded information through the data codec in the Netty server, the method further includes:

[0021] Define the data codec to inherit ByteToMessageDecoder and override the decode() method to convert the transmission information into a complete data packet;

[0022] And define the data block of the transmission information of preset fixed length intercepted by FixedLengthFrameDecoder, or use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

[0023] In one implementation of the present application, obtaining the charging pile code specifically includes:

[0024] Log in and authenticate the charging pile client of the current message to obtain the charging pile code.

[0025] In one implementation of the present application, before returning feedback information to the distributed stream processing platform, the method further includes:

[0026] Input the json file into the preset business processing program to obtain feedback information.

[0027] In a third aspect, the present application provides a non-volatile computer storage medium having computer instructions stored thereon, which, when executed, implement a method for docking a car charging pile based on Netty as described above.

[0028] It can be seen from the above technical solutions that this application has the following advantages:

[0029] The Netty-based car charging pile docking system, method, and medium provided in this application effectively solve the problems of low efficiency in high-concurrency connection management, redundant message processing, insufficient feedback link reliability, and limited resource scalability in existing solutions through technical architecture and process innovation. The specific implementation is as follows:

[0030] 1. Dynamic load balancing and high-concurrency connection management optimization:

[0031] Intelligently distribute charging pile client requests through the Nginx gateway to achieve dynamic load balancing on the backend Netty server, significantly improving the response speed and stability in scenarios with tens of thousands of concurrent connections.

[0032] The Netty server is based on an event-driven thread model and non-blocking IO mechanism, supporting high-throughput processing on a single node and avoiding the thread resource waste and connection blocking problems under the traditional BIO model.

[0033] 2. Efficient decoupling of message processing processes:

[0034] Modular encoding and decoding and message processing: Through the preset data codec and message frame type matching mechanism, fast parsing of byte stream to structured JSON data is achieved, which improves data parsing efficiency compared to traditional multi-level protocol conversion solutions.

[0035] ‌Message publishing / listening components collaborate with distributed stream processing platforms‌: Using an asynchronous, non-blocking message push mode, JSON files are pushed to distributed stream platforms such as Kafka / RocketMQ. This decouples the business processing system from the communication layer, reduces system coupling, and avoids thread blocking caused by message accumulation.

[0036] 3. Enhanced reliability of the bidirectional feedback link:

[0037] By real-time association between charging pile codes and ChannelHandler, feedback from the business processing system can be accurately routed to the target charging pile client. The Netty server integrates IdleStateHandler to periodically detect connection activity and proactively reestablish abnormal channels, avoiding the resource waste of traditional polling mechanisms and ensuring the continuous availability of persistent connections.

[0038] 4. Improved resource utilization and horizontal scalability:

[0039] The Netty server handles only the communication layer protocol processing, while the business logic is handled by an independent distributed stream processing platform. This platform supports dynamic scaling on demand, improving resource utilization. Lightweight connection management: A connection mapper maintains a mapping table between charging pile codes and ChannelHandlers (based on memory or Redis). Compared to traditional database storage solutions, this reduces mapping query latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solution of the present invention, the following is a brief introduction to the drawings required for the description. 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 these drawings without paying any creative work.

[0041] Figure 1 This is a schematic diagram of the internal structure of a Netty-based car charging pile docking system provided in an embodiment of the present application.

[0042] Figure 2 This is a flow chart of a method for docking a car charging pile based on Netty provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0044] It should be understood by those skilled in the art that the embodiments described below are merely preferred embodiments of the present disclosure and do not imply that the present disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely intended to explain the technical principles of the present disclosure and are not intended to limit the scope of protection of the present disclosure. Based on the preferred embodiments provided by the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present disclosure.

[0045] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0046] The technical solutions proposed in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0047] This application Figure 1 The present invention provides a car charging pile docking system based on Netty. Figure 1 As shown, the system provided in the embodiment of the present application mainly includes:

[0048] The charging pile client 110 is used to establish a connection with the server 120 via the TCP / IP protocol.

[0049] It should be noted that the TCP / IP protocol provides a connection-oriented reliable communication mechanism, which ensures the integrity of data transmission between the charging pile client 110 and the server 120 through mechanisms such as three-way handshake to establish a connection and data packet confirmation and retransmission.

[0050] For example, in the scenario of real-time reporting of charging pile status, if network fluctuations cause data packet loss, the TCP protocol automatically triggers retransmission to avoid the loss of critical data (such as charging power and fault alarms) 57.

[0051] Use TCP persistent connection mode (such as the heartbeat packet mechanism) to reduce the overhead of frequent connection establishment / disconnection and improve resource utilization.

[0052] For example: The charging pile client 110 sends a heartbeat packet every 30 seconds to maintain the connection. The server 120 monitors the device's online status in real time through heartbeat detection, avoiding the frequent handshakes in the traditional short connection mode.

[0053] The TCP / IP protocol supports communication between the local area network and the Internet, and is suitable for the diverse deployment scenarios of charging piles (such as the weak network environment of underground parking lots).

[0054] For example: When the charging pile is connected through a wired network or wireless GPRS, it can communicate stably with the cloud platform through the TCP / IP protocol without the need for additional protocol stack adaptation.

[0055] The server 120 constructs an Nginx gateway 121 and several Netty servers 122, and is used to distribute the uploaded information to the Netty server 122 that meets the current load balancing through the Nginx gateway 121 when receiving the uploaded information from the charging pile client 110.

[0056] It should be noted that the Nginx gateway 121 dynamically adjusts traffic to the available Netty server 122 based on weight distribution and max_fails fault detection mechanism, thereby improving system throughput in high concurrency scenarios.

[0057] For example: When a Netty node experiences response delays due to excessive processing pressure, Nginx automatically distributes new requests to low-load nodes to avoid single-point bottlenecks.

[0058] Netty server 122 is based on an event-driven and non-blocking IO model. A single node can support 100,000+ QPS, which is significantly better than the traditional BIO thread pool model.

[0059] For example: During peak charging hours, Netty uses ChannelHandler to quickly parse and forward massive amounts of charging pile data to a distributed streaming platform (such as Kafka) to avoid thread blocking.

[0060] The combination of Nginx and Netty cluster supports dynamic expansion of server nodes and automatic fault elimination, which can improve the high availability of the guarantee system.

[0061] For example: When a Netty node goes down, Nginx removes it from the list of available nodes through the health_check mechanism, and requests are automatically switched to other healthy nodes without the business being aware of it.

[0062] The Netty server 122 focuses on communication layer protocol analysis (such as data encoding and decoding, heartbeat management), and the business logic is handled by the distributed streaming platform to achieve modular division of labor.

[0063] For example: Netty parses the charging pile's raw byte stream into JSON and pushes it to Kafka through the message publishing component. The business system independently consumes the data and generates billing orders, reducing system coupling.

[0064] ‌Collaborative work example:‌

[0065] Scenario: The charging station starts the charging process;

[0066] ‌Connection establishment‌: The charging pile client 110 establishes a persistent connection with the Nginx gateway 121 via TCP / IP‌.

[0067] Request distribution: Nginx distributes requests to the Netty server with the lowest load based on the current Netty node load.

[0068] Data processing: The Netty server 122 parses the charging request byte stream into JSON through the data codec and pushes it to Kafka.

[0069] Feedback delivery: After the business system completes processing, Netty matches the charging pile code with the ChannelHandler through the connection mapper and delivers the control instruction (such as "stop charging") to the corresponding client.

[0070] Among them, the Netty server 122 includes a preset data codec, a message processor, a message publishing component, a message listening component, and a connection mapper; through the data codec, the data packet of the uploaded information is read; according to the message frame type of the message in the data packet, the corresponding message processor is determined, and then the bytecode of the message in the data packet is parsed into a json file through the message processor; through the connection mapper, the charging pile code is obtained; the json file is pushed to the distributed stream processing platform 130 through the message publishing component; through the message listening component, the feedback information returned by the distributed stream processing platform 130 is monitored, and the corresponding ChannelHandler is determined according to the charging pile code in the feedback information; through the connection mapper, the charging pile code and the ChannelHandler are associated; the feedback information is converted into bytecode and sent to the corresponding charging pile client 110 through the ChannelHandler.

[0071] It should be noted that

[0072] 1. A preset data codec is responsible for decoding the original byte stream (following a specific protocol) uploaded by the charging pile client 110 into structured data, or encoding the service feedback information into a byte stream that can be recognized by the client.

[0073] Through predefined codecs, it is compatible with the private protocols of charging piles from different manufacturers (such as DLT645 and Modbus-TCP). It can adapt to multiple protocols without modifying business logic, reducing development and maintenance costs.

[0074] Example: A charging station uses a custom binary protocol (frame header 0xA5 + length field + data field + CRC checksum). The codec automatically extracts the data field and verifies the CRC.

[0075] Use Netty's ByteToMessageDecoder to directly operate off-heap memory to avoid multiple data copies between the JVM heap and kernel buffer, reducing memory usage and parsing latency.

[0076] Example: When processing a 10KB charging pile data packet, the traditional solution requires three copies (kernel → JVM heap → business layer), while the Netty codec only requires one copy, reducing memory usage.

[0077] 2. The message processor selects the corresponding processor based on the message frame type (such as heartbeat packet, charging status, fault alarm) in the data packet to convert the bytecode into a JSON file.

[0078] Processors are divided by message type (such as HeartbeatHandler and ChargingDataHandler). When adding a new protocol type, only the new processor needs to be expanded without modifying the core logic.

[0079] Example: When adding the "Reservation Charging" feature, you only need to implement ReservationHandler and register it with the Netty pipeline (ChannelPipeline), which reduces the amount of code changes.

[0080] The @Sharable annotation is used to implement a stateless processor, allowing multiple threads to reuse the same instance, avoiding the throughput degradation caused by thread blocking in traditional solutions.

[0081] Example: When processing real-time power data from charging piles, the Netty message processor achieves a throughput of 80,000 QPS in a concurrent scenario with 100,000 messages, while traditional synchronous processing only supports 10,000 QPS.

[0082] 3. A message publishing component pushes the parsed JSON file to a distributed stream processing platform 130 (such as Kafka or RocketMQ).

[0083] The message publishing component is isolated from the business processing system 140. Even if the business system is temporarily down, the data can still be persisted to the message queue to avoid data loss.

[0084] Example: During peak charging hours, the Netty server 122 pushes 100,000 charging data records per second to Kafka. The business system processes data asynchronously based on consumption capacity to avoid service crashes caused by instantaneous pressure.

[0085] KafkaProducer batch submission (batch.size=16KB) and GZIP compression reduce network transmission overhead and storage costs.

[0086] Example: The original JSON data is 1MB, but after compression it is only 200KB, reducing network bandwidth usage.

[0087] 4. A message monitoring component monitors the feedback information (such as billing results and control instructions) from the distributed stream processing platform 130 and matches the corresponding ChannelHandler according to the charging pile code in the feedback.

[0088] By dynamically binding the charging pile code with the ChannelHandler, feedback information can be routed to the target client within milliseconds.

[0089] Example: After the business system generates a "stop charging" command, the message listening component consumes the command from Kafka and quickly searches for the associated ChannelHandler through ConcurrentHashMap, reducing latency throughout the process.

[0090] If the client reconnects after being disconnected, the message listening component automatically updates the ChannelHandler through the connection mapper to ensure that the command is reachable.

[0091] Example: After a charging station network is disconnected and then reconnected, the connection mapper records the new ChannelHandler, and the "resume charging" command issued by the business system can still be successfully delivered.

[0092] 5. Connect to the mapper to maintain the mapping relationship between the charging pile code and the ChannelHandler, and support two-way search (code → Handler, Handler → code).

[0093] Based on memory (ConcurrentHashMap) or Redis storage mapping table, query latency is as low as microseconds and supports management of millions of connections.

[0094] Example: In a scenario with 100,000 charging stations online, query time is reduced by storing mapping relationships in the Redis Hash structure.

[0095] When the client reconnects, historical sessions (such as unfinished charging transactions) are restored through the charging pile code to improve the user experience.

[0096] Example: The charging station's payment instruction is not confirmed due to a network interruption. After reconnection, the mapper automatically associates with the original ChannelHandler to continue the payment process.

[0097] ‌Full-link collaboration example:‌

[0098] Scenario: The charging station starts charging and receives billing results.

[0099] Data Upload: The charging station sends a binary data packet (message type = 0x01, containing the charging station code, start time, current and voltage). The codec parses the packet, verifies the CRC, and extracts the message body. The message handler calls ChargingStartHandler based on the message type 0x01 and converts the bytecode into JSON (e.g., {"cmd":"start", "code":"CP001", "voltage":220}).

[0100] Business processing: The message publishing component pushes the JSON to the charging-start topic of Kafka.

[0101] The business system consumes the message, generates an order, calculates the fee, and writes the result (such as {"code":"CP001", "fee":30.5}) to the charging-feedback topic of Kafka.

[0102] Feedback Delivery: The message listener reads the results from the charging-feedback topic, queries the connection mapper based on code=CP001, and obtains the corresponding ChannelHandler. The codec encodes the JSON into binary instructions and sends them to the charging station through the ChannelHandler, completing the billing notification.

[0103] The Netty server 122 includes a data codec definition unit, which is used to define a data codec that inherits ByteToMessageDecoder and overrides the decode() method to convert the transmission information into a complete data packet; and define how to intercept a data block of the transmission information of a preset fixed length through FixedLengthFrameDecoder, or use DelimiterBasedFrameDecoder to split the transmission information according to a preset delimiter.

[0104] Data codec definition unit, inheriting ByteToMessageDecoder: custom decoders need to inherit this abstract class and override the decode() method to implement the conversion from byte stream to complete data packet.

[0105] ‌Use FixedLengthFrameDecoder‌: split the byte stream into a preset fixed length (such as 128 bytes per frame).

[0106] Use DelimiterBasedFrameDecoder: Splits data blocks by delimiters (such as 0x0D0A), suitable for variable-length messages.

[0107] The frame decoder accurately segments the data stream to avoid the concatenation of multiple data packets (sticky packets) or the splitting of a single data packet (unpacking) caused by network buffering during TCP transmission.

[0108] ‌Example‌:

[0109] Scenario: A charging station continuously uploads two pieces of current data (each fixed at 64 bytes), which are then merged into 128 bytes before arriving at the server due to network buffering.

[0110] ‌Processing‌: FixedLengthFrameDecoder(64) automatically splits the data into two complete packets to avoid the complexity of manual parsing.

[0111] Effect: Supports two mainstream protocol formats: fixed length and delimiter, covering common communication scenarios of charging piles.

[0112] ‌Example‌:

[0113] Fixed-length protocol: A charging pile protocol specifies that each frame contains a 16-byte header (including a length field) + a data field.

[0114] Delimiter protocol: A certain vendor's protocol uses 0xFFFF as the message terminator.

[0115] Effect: ByteToMessageDecoder directly operates on off-heap memory (ByteBuf), reducing the number of data copies.

[0116] The connection mapper includes a login binding unit, which is used to perform login authentication binding on the charging pile client 110 of the current message to obtain the charging pile code.

[0117] It should be noted that in the connection mapper's login and binding unit, the client sends authentication information (such as device ID and key) when it first connects. After the server verifies the information, it generates a unique charging pile code and binds it to the ChannelHandler. This mapping relationship can be stored using a thread-safe ConcurrentHashMap<charging pile code, ChannelHandler> or a distributed cache (such as Redis).

[0118] Secure identity authentication and session binding ensure that only legitimate charging piles can access the system, and each connection is associated with a unique code to prevent unauthorized access and message crosstalk.

[0119] ‌Example‌:

[0120] Scenario: When the charging pile client 110 connects for the first time, it sends an authentication message: {"deviceId":"CP-001", "signature":"a1b2c3"}.

[0121] ‌Processing‌: The server verifies the validity of the signature. If it passes, it generates the code CP-001-20231001 and records it in the mapping table.

[0122] If the client attempts to forge the deviceId, the server will reject the connection due to signature verification failure, preventing malicious devices from accessing.

[0123] The Netty server 122 includes a configuration unit for configuring the correspondence between message frame types and message processors.

[0124] The business processing system 140 is used to monitor the JSON file of the distributed stream processing platform 130 and return feedback information to the distributed stream processing platform 130.

[0125] The business processing system 140 includes a business processing component for inputting a json file into a preset business processing program to obtain feedback information.

[0126] Subscribe to a specified Topic (such as charging-data) through a consumer group (such as Kafka Consumer Group) to pull the charging pile data in JSON format pushed by the Netty server 122 in real time.

[0127] Input JSON data into preset business processing programs (such as billing engines, order generators, and fault diagnosis modules) to generate feedback information (such as billing results and control instructions).

[0128] The processing results (JSON format) are pushed to the feedback topic (such as charging-feedback) for consumption by the message monitoring component of the Netty server 122 and sent to the charging pile.

[0129] Business logic (such as billing rules) is separated from communication protocols (such as TCP / IP and data encoding and decoding), and business system iteration does not require modifying the communication layer code.

[0130] ‌Technology stack flexibility‌: Business processing programs can be implemented in different languages ​​such as Java / Python / Go, and are independent of the communication layer (Netty) technology stack.

[0131] ‌Example‌:

[0132] Scenario: After the charging station starts charging, the JSON data {"cmd":"start", "code":"CP001", "kwh":10} is pushed to Kafka.

[0133] Business Processing:

[0134] Billing program: Read the kwh field, combine it with the electricity price rule (such as 0.5 yuan / kWh), and generate an order {"code":"CP001", "fee":5.0, "orderId":"20231001120000"}.

[0135] ‌Control program‌: If the charging pile voltage is abnormal, the {"code":"CP001", "cmd":"emergency_stop"} command will be triggered.

[0136] Feedback push: The results are written to the charging-feedback topic, which is then monitored by Netty and sent to the charging station.

[0137] Asynchronous processing and peak shaving:

[0138] Business systems consume messages based on their own throughput capacity to avoid message backlogs caused by business processing delays on the Netty server 122. Message queues (such as Kafka) are used to temporarily store massive amounts of data to cope with business peaks (such as concentrated charging during holidays).

[0139] ‌Example‌:

[0140] Peak Scenario: During the morning rush hour, charging stations simultaneously report 10,000 pieces of data, and Kafka accumulates a backlog of 100,000 unprocessed messages.

[0141] Business Processing Strategy:

[0142] Dynamic Scaling: Automatically scale business processing nodes based on Kafka lag (accumulation), expanding from 10 nodes to 50 nodes, and increasing throughput from 10,000 QPS to 50,000 QPS.

[0143] Batch processing: The business program consumes 100 messages in batches, merges them and writes them to the database, reducing the number of IO operations (1 write instead of 100).

[0144] By defining a unified interface (such as BusinessProcessor), new business modules (such as battery health monitoring and coupon redemption) can be quickly integrated.

[0145] Rule Engine Integration: Supports dynamic configuration of business rules (such as tiered electricity prices and membership discounts), which take effect in real time without downtime.

[0146] ‌Example‌:

[0147] ‌New battery health analysis‌:

[0148] ‌Implementing the processor‌: Create a BatteryHealthProcessor, parse the voltage fluctuation data in JSON, and generate a health report.

[0149] ‌Register component‌: Add the processor to the business system and subscribe to the Topic battery-health-data.

[0150] ‌Processing Flow‌:

[0151] Dynamic rule adjustments:

[0152] Scenario: The electricity price during holidays is adjusted from 0.5 yuan / kWh to 0.3 yuan / kWh.

[0153] Implementation: The business system calls the rule engine API to update the electricity price, and subsequent billing automatically takes effect.

[0154] Full-link collaboration example:‌

[0155] Scenario: The user remotely stops charging pile CP001 through the App;

[0156] The app sends a stop command to the business system API, generating a message {"code":"CP001", "cmd":"stop"} and writing it to the charging-feedback topic.

[0157] The Netty message listening component pulls instructions from charging-feedback and searches for the ChannelHandler corresponding to CP001 through the connection mapper.

[0158] The Netty encoder converts JSON into a binary protocol (such as 0x02|CP001|0x00) and sends it to the charging station through ChannelHandler.

[0159] The charging station stops charging and returns a confirmation frame 0x02|CP001|SUCCESS. After decoding, Netty pushes it to the charging-response topic of Kafka.

[0160] The business system consumes the charging-response, updates the order status to "Stopped", and notifies the App user that the operation was successful.

[0161] The time from app click stop to charging pile response is ≤ 200ms (including network transmission, business processing, and message queue routing).

[0162] The Netty-based car charging pile docking system provided in this application effectively solves the problems of low efficiency in high-concurrency connection management, redundant message processing, insufficient feedback link reliability, and limited resource scalability in existing solutions through technical architecture and process innovation. The specific implementation is as follows:

[0163] Dynamic load balancing and high-concurrency connection management optimization: Intelligently distribute charging pile client 110 requests through the Nginx gateway 121 to achieve dynamic load balancing of the backend Netty server 122, significantly improving the response speed and stability in scenarios with tens of thousands of concurrent connections.

[0164] The Netty server 122 is based on an event-driven thread model and non-blocking IO mechanism, supporting high-throughput processing on a single node and avoiding the thread resource waste and connection blocking problems under the traditional BIO model.

[0165] Efficient decoupling of message processing: Modular encoding and decoding and message processing: Through the preset data codec and message frame type matching mechanism, fast parsing of byte stream → structured JSON data is achieved, which improves data parsing efficiency compared to traditional multi-level protocol conversion solutions.

[0166] The message publishing / listening component collaborates with the distributed stream processing platform 130: an asynchronous non-blocking message push mode is used to push JSON files to distributed stream platforms such as Kafka / RocketMQ, thereby decoupling the business processing system 140 from the communication layer, reducing system coupling, and avoiding thread blocking caused by message accumulation.

[0167] Enhanced reliability of the bidirectional feedback link: Real-time association between charging pile codes and ChannelHandler ensures that feedback information from the business processing system 140 can be accurately routed to the target charging pile client 110. The Netty server 122 integrates IdleStateHandler to periodically detect connection activity and proactively reestablish abnormal channels, avoiding the resource waste of traditional polling mechanisms and ensuring the continuous availability of persistent connections.

[0168] Improved resource utilization and horizontal scalability: The Netty server 122 is solely responsible for communication layer protocol processing, while the business logic is hosted by the independent distributed stream processing platform 130. This platform supports dynamic scaling on demand, improving resource utilization. Lightweight connection management: A connection mapper maintains a mapping table between charging pile codes and ChannelHandlers (based on memory or Redis). Compared to traditional database storage solutions, this reduces mapping query latency.

[0169] In addition, the embodiment provides a method for docking a car charging pile based on Netty, such as Figure 2 As shown, the method provided in the embodiment of the present application mainly includes the following steps:

[0170] Step 210: When the uploaded information of the charging pile client is received, the uploaded information is distributed to the Netty server that meets the current load balancing through the Nginx gateway.

[0171] Step 220: read the data packet of the uploaded information through the data codec in the Netty server; determine the corresponding message processor according to the message frame type of the message in the data packet, and then parse the bytecode of the message in the data packet into a json file through the message processor in the Netty server; obtain the charging pile code through the connection mapper in the Netty server; push the json file to the distributed stream processing platform through the message publishing component in the Netty server; monitor the feedback information returned by the distributed stream processing platform through the message listening component in the Netty server, and determine the corresponding ChannelHandler according to the charging pile code in the feedback information; associate the charging pile code and ChannelHandler through the connection mapper; convert the feedback information into bytecode, and send it to the corresponding charging pile client through the ChannelHandler.

[0172] Before reading the data packet of the uploaded information through the data codec in the Netty server, the method further includes:

[0173] Define the data codec to inherit ByteToMessageDecoder and override the decode() method to convert the transmission information into a complete data packet;

[0174] And define the data block of the transmission information of preset fixed length intercepted by FixedLengthFrameDecoder, or use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

[0175] Obtaining the charging pile code specifically includes:

[0176] Log in and authenticate the charging pile client of the current message to obtain the charging pile code.

[0177] Step 230: Monitor the json file of the distributed stream processing platform through the business processing system, and then return feedback information to the distributed stream processing platform.

[0178] In some embodiments, before returning feedback information to the distributed stream processing platform, the method further includes:

[0179] Input the json file into the preset business processing program to obtain feedback information.

[0180] The Netty-based car charging pile docking method provided in this application effectively solves the problems of low efficiency in high-concurrency connection management, redundant message processing, insufficient feedback link reliability, and limited resource scalability in existing solutions through technical architecture and process innovation. The specific implementation is as follows:

[0181] Dynamic load balancing and high-concurrency connection management optimization: Intelligently distribute charging pile client requests through the Nginx gateway. Combined with weight configuration and the max_fails fault detection mechanism, dynamic load balancing is achieved on the backend Netty server, significantly improving response speed and stability in scenarios with tens of thousands of concurrent connections.

[0182] The Netty server is based on an event-driven thread model and non-blocking IO mechanism, supporting high-throughput processing on a single node and avoiding the thread resource waste and connection blocking problems under the traditional BIO model.

[0183] Efficient decoupling of message processing: Modular encoding and decoding and message processing: Through the preset data codec and message frame type matching mechanism, fast parsing of byte stream → structured JSON data is achieved, which improves data parsing efficiency compared to traditional multi-level protocol conversion solutions.

[0184] ‌Message publishing / listening components collaborate with distributed stream processing platforms‌: Using an asynchronous, non-blocking message push mode, JSON files are pushed to distributed stream platforms such as Kafka / RocketMQ. This decouples the business processing system from the communication layer, reduces system coupling, and avoids thread blocking caused by message accumulation.

[0185] Enhanced reliability of the bidirectional feedback link: Real-time association between charging pile codes and ChannelHandler ensures that feedback information from the business processing system is accurately routed to the target charging pile client. The Netty server integrates IdleStateHandler to periodically detect connection activity and proactively reestablish abnormal channels, avoiding the resource waste of traditional polling mechanisms and ensuring the continuous availability of persistent connections.

[0186] Improved resource utilization and horizontal scalability: The Netty server is solely responsible for communication layer protocol processing, while the business logic is hosted by an independent distributed stream processing platform. This platform supports dynamic scaling on demand, improving resource utilization. Lightweight connection management: A connection mapper maintains a mapping table between charging station codes and ChannelHandlers (based on memory or Redis). Compared to traditional database storage solutions, this reduces mapping query latency.

[0187] In addition, an embodiment of the present application further provides a non-volatile computer storage medium on which executable instructions are stored. When the executable instructions are executed, a method for docking a car charging pile based on Netty as described above is implemented.

[0188] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A car charging pile docking system based on Netty, characterized in that: The system comprises: Charging pile client, used to establish a connection with the server through TCP / IP protocol; The server builds an Nginx gateway and several Netty servers. When receiving the uploaded information from the charging pile client, it distributes the uploaded information to the Netty server that meets the current load balancing requirements through the Nginx gateway. Among them, the Netty server includes a preset data codec, a message processor, a message publishing component, a message listening component, and a connection mapper; the data packet of the uploaded information is read through the data codec; the corresponding message processor is determined according to the message frame type of the message in the data packet, and then the bytecode of the message in the data packet is parsed into a json file through the message processor; the charging pile code is obtained through the connection mapper; the json file is pushed to the distributed stream processing platform through the message publishing component; the feedback information returned by the distributed stream processing platform is monitored through the message listening component, and the corresponding ChannelHandler is determined according to the charging pile code in the feedback information; the charging pile code and ChannelHandler are associated through the connection mapper; the feedback information is converted into bytecode and sent to the corresponding charging pile client through the ChannelHandler; Among them, the Netty server contains the data codec definition unit, Used to define the data codec to inherit ByteToMessageDecoder and override the decode() method to convert the transmission information into a complete data packet; And define the data block of the transmission information of preset fixed length intercepted by FixedLengthFrameDecoder, or use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter; The business processing system is used to monitor the JSON files of the distributed stream processing platform and return feedback information to the distributed stream processing platform.

2. The Netty-based car charging pile docking system according to claim 1 is characterized in that: The connection mapper includes a login binding unit, which is used to perform login authentication and binding on the charging pile client of the current message to obtain the charging pile code.

3. The Netty-based car charging pile docking system according to claim 1 is characterized in that: The Netty server contains configuration units, Used to configure the correspondence between message frame types and message processors.

4. The Netty-based car charging pile docking system according to claim 1 is characterized in that: The business processing system includes business processing components. Used to input json files into the preset business processing program to obtain feedback information.

5. A method for docking a car charging pile based on Netty, applied to the docking system for a car charging pile based on Netty according to claim 1, characterized in that: The method comprises: When receiving the upload information from the charging pile client, the uploaded information is distributed to the Netty server that meets the current load balancing requirements through the Nginx gateway; The data packet of the uploaded information is read through the data codec in the Netty server; the corresponding message processor is determined according to the message frame type of the message in the data packet, and then the bytecode of the message in the data packet is parsed into a json file through the message processor in the Netty server; the charging pile code is obtained through the connection mapper in the Netty server; the json file is pushed to the distributed stream processing platform through the message publishing component in the Netty server; the feedback information returned by the distributed stream processing platform is monitored through the message listening component in the Netty server, and the corresponding ChannelHandler is determined according to the charging pile code in the feedback information; the charging pile code and ChannelHandler are associated through the connection mapper; the feedback information is converted into bytecode and sent to the corresponding charging pile client through the ChannelHandler; Before reading the data packet of the uploaded information through the data codec in the Netty server, the method further includes: Define the data codec to inherit ByteToMessageDecoder and override the decode() method to convert the transmission information into a complete data packet; and define the use of FixedLengthFrameDecoder to intercept the data block of the transmission information of a preset fixed length, or use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter; The business processing system monitors the json file of the distributed stream processing platform and then returns feedback information to the distributed stream processing platform.

6. The method for docking a car charging pile based on Netty according to claim 5, characterized in that: Obtain the charging pile code, including: Log in and authenticate the charging pile client of the current message to obtain the charging pile code.

7. The method for docking a car charging pile based on Netty according to claim 5, characterized in that: Before returning feedback information to the distributed stream processing platform, the method further includes: Input the json file into the preset business processing program to obtain feedback information.

8. A non-volatile computer storage medium, characterized in that Computer instructions are stored thereon, and when the computer instructions are executed, the method for docking a car charging pile based on Netty is implemented as described in any one of claims 5 to 7.

Images