Automobile charging pile docking system and method based on Netty and medium

Abstract

The invention discloses a Netty-based automobile charging pile docking system and method and a medium, mainly relates to the technical field of automobile charging piles, and is used for solving the problems of low connection management efficiency, redundant message processing flow, insufficient feedback link reliability and limited resource utilization rate and expansibility in a high-concurrency scene of an existing scheme. Comprising a charging pile client which is used for establishing connection with a server through a TCP / IP protocol; the server constructs an Nginx gateway and a plurality of Netty servers, and is used for distributing the uploaded information to the Netty servers through the Nginx gateway when the uploaded information of the charging pile client is received; wherein the Netty server comprises a preset data codec, a message processor, a message publishing component, a message monitoring component and a connection mapper; and the service processing system is used for monitoring the json file of the distributed stream processing platform and returning 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 docking system, method and medium for automobile charging piles based on Netty. 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, stability and scalability of the communication system. The traditional connection solution between charging piles and servers is mostly based on HTTP protocol or simple TCP long connection, which has the following technical bottlenecks: 1. Low connection management efficiency in high-concurrency scenarios: Existing systems usually adopt a single-point service architecture or a static load balancing strategy, which makes it difficult to cope with dynamically fluctuating charging pile access requests. Especially during peak hours, the server is prone to response delays or connection interruptions due to a surge in the number of connections, and it is impossible to dynamically expand computing resources to adapt to load changes. 2. Redundant message processing process: The data uploaded by the charging pile usually needs to go through multi-level protocol parsing (such as byte stream → binary → structured data). The traditional solution does not realize the modular separation of encoding and decoding and business logic, resulting in low parsing efficiency, high resource usage, and difficulty in compatibility with charging pile communication protocols of different manufacturers. 3. Insufficient reliability of the feedback link: In the existing technology, when the server sends control instructions to the charging pile, it often relies on a fixed connection or polling mechanism, lacking real-time monitoring and dynamic mapping of the connection status. Once the network fluctuation causes the connection to be interrupted, the instruction cannot be accurately routed to the target charging pile, affecting business continuity. 4. Limited resource utilization and scalability: In the traditional architecture, message processing, data forwarding and business logic are highly coupled, and it is difficult to improve system throughput through horizontal expansion. In addition, the lack of a unified connection and message lifecycle management mechanism can easily lead to memory leaks or thread blocking problems.

[0003] 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

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

[0005] In the first aspect, the present application provides a car charging pile docking system based on Netty, the system comprising: 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, which are 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; wherein 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 the 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; 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.

[0006] In one implementation of the present application, the Netty server includes a 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 to intercept the data block of the transmission information of preset fixed length through FixedLengthFrameDecoder, or to use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

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

[0008] In one implementation of the present application, the Netty server includes a configuration unit, Used to configure the correspondence between message frame types and message processors.

[0009] In one implementation of the present application, the business processing system includes a business processing component. Used to input json files into the preset business processing program to obtain feedback information.

[0010] In the 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: 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 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; 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.

[0011] 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: Define the data codec to inherit ByteToMessageDecoder and override the decode() method to convert the transmission information into a complete data packet; And define to intercept the data block of the transmission information of preset fixed length through FixedLengthFrameDecoder, or to use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

[0012] In one implementation of the present application, obtaining the charging pile code specifically includes: Login and authenticate the charging pile client of the current message to obtain the charging pile code.

[0013] In one implementation of the present application, 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.

[0014] In a third aspect, the present application provides a non-volatile computer storage medium on which computer instructions are stored. When the computer instructions are executed, a method for docking a car charging pile based on Netty as described above is implemented.

[0015] It can be seen from the above technical solutions that this application has the following advantages: The Netty-based car charging pile docking system, method and medium provided in this application effectively solve the problems of low efficiency of high-concurrency connection management, redundant message processing, insufficient reliability of feedback links and limited resource scalability in existing solutions through technical architecture and process innovation, which are specifically reflected as follows: 1. Dynamic load balancing and high concurrent connection management optimization: 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.

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

[0017] 2. Efficient decoupling of message processing flow: 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.

[0018] ‌Message publishing / listening components collaborate with distributed stream processing platforms‌: Adopt an asynchronous non-blocking message push mode to push JSON files to distributed stream platforms such as Kafka / RocketMQ, decoupling the business processing system from the communication layer, reducing system coupling and avoiding thread blocking caused by message accumulation.

[0019] 3. Improved reliability of bidirectional feedback link: Through the real-time association between the charging pile coding and ChannelHandler, it is ensured that the feedback information of the business processing system can be accurately routed to the target charging pile client. The Netty server integrates IdleStateHandler to periodically detect the connection activity and actively rebuild the abnormal channel, avoiding the waste of resources of the traditional polling mechanism and ensuring the continuous availability of long connections.

[0020] 4. Improved resource utilization and horizontal expansion capabilities: The Netty server is only responsible for communication layer protocol processing, and the business logic is carried by an independent distributed stream processing platform, which supports dynamic expansion and contraction on demand and improves resource utilization. ‌Lightweight connection management‌: The mapping table between charging pile encoding and ChannelHandler is maintained through the ‌connection mapper‌ (based on memory or Redis). Compared with traditional database storage solutions, the mapping query latency has been reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solution of the present invention, the accompanying drawings required for use in the description will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0022] Figure 1 It 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.

[0023] 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

[0024] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. 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 creative work are within the scope of protection of the present invention.

[0025] It should be understood by those skilled in the art that the embodiments described below are only preferred embodiments of the present disclosure, and do not mean that the present disclosure can only be implemented through the preferred embodiments. The preferred embodiments are only used to explain the technical principles of the present disclosure, and are not used to limit the protection scope of the present disclosure. Based on the preferred embodiments provided by the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work should still fall within the protection scope of the present disclosure.

[0026] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0027] The technical solution proposed in the embodiments of the present application is described in detail below with reference to the accompanying drawings.

[0028] This application Figure 1 A car charging pile docking system based on Netty is provided in the embodiment of the present application. Figure 1 As shown, the system provided in the embodiment of the present application mainly includes: The charging pile client 110 is used to establish a connection with the server 120 via the TCP / IP protocol.

[0029] 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.

[0030] 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 key data (such as charging power and fault alarms) 57.

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

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

[0033] The TCP / IP protocol supports communication between the LAN and the Internet, and is adapted to the diversity of charging pile deployment scenarios (such as weak network environments in underground parking lots).

[0034] 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 adaptation of the protocol stack.

[0035] 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.

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

[0037] ‌Example‌: When a Netty node has a response delay due to excessive processing pressure, Nginx automatically distributes new requests to low-load nodes to avoid single-point bottlenecks.

[0038] Netty server 122 is based on 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.

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

[0040] 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 security system.

[0041] ‌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.

[0042] 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.

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

[0044] ‌Collaborative work example:‌ ‌Scenario‌: The charging pile starts the charging process; ‌Connection establishment‌: The charging pile client 110 establishes a long connection with the Nginx gateway 121 via TCP / IP‌.

[0045] Request distribution: Nginx distributes requests to the Netty server with the lowest load 122 according to the current Netty node load.

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

[0047] Feedback delivery: After the business system completes the 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.

[0048] 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 listened to, 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.

[0049] It should be noted that 1. The 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 recognizable by the client.

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

[0051] ‌Example‌: A charging pile uses a custom binary protocol (frame header 0xA5 + length field + data field + CRC check), and the codec automatically extracts the data field and verifies the CRC.

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

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

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

[0055] Processors are divided by message type (such as HeartbeatHandler, ChargingDataHandler). When adding a new protocol type, you only need to expand the new processor without modifying the core logic.

[0056] ‌Example‌: When adding the "Reservation Charging" feature, you only need to implement ReservationHandler and register it to the Netty pipeline (ChannelPipeline), and the amount of code changes is reduced.

[0057] The @Sharable annotation is used to implement a stateless processor, and multiple threads reuse the same instance to avoid the decrease in throughput caused by thread blocking in traditional solutions.

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

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

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

[0061] ‌Example‌: During the peak charging period, Netty server 122 pushes 100,000 charging data per second to Kafka. The business system processes asynchronously according to consumption capacity to avoid service crashes caused by instantaneous pressure.

[0062] Through KafkaProducer batch submission (batch.size=16KB) and GZIP compression, network transmission overhead and storage costs are reduced.

[0063] ‌Example‌: The original JSON data is 1MB, but after compression it is only 200KB, which reduces network bandwidth usage.

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

[0065] Through the dynamic binding of charging pile coding and ChannelHandler, feedback information can be routed to the target client in milliseconds.

[0066] Example: After the business system generates a "stop charging" instruction, the message listening component consumes the instruction from Kafka and quickly searches for the associated ChannelHandler through ConcurrentHashMap, reducing the overall delay.

[0067] 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.

[0068] Example: After the charging pile 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.

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

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

[0071] ‌Example‌: In a scenario with 100,000 charging piles online, the query time is reduced by storing the mapping relationship through the Redis Hash structure.

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

[0073] ‌Example‌: The payment instruction of the charging pile was not confirmed due to network interruption. After reconnection, the mapper automatically associated with the original ChannelHandler to continue the payment process.

[0074] ‌Full-link collaboration example:‌ Scenario: The charging station starts charging and receives the billing result.

[0075] ‌Data upload‌: The charging pile sends a binary data packet (message type = 0x01, including the charging pile code, start time, current and voltage). The ‌codec‌ parses the data packet and extracts the message body after verifying the CRC. The ‌message processor‌ calls ChargingStartHandler according to the type 0x01 and converts the bytecode into JSON (such as {"cmd":"start", "code":"CP001", "voltage":220}).

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

[0077] 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.

[0078] Feedback delivery: The message monitoring component reads the result from the charging-feedback topic, queries the connection mapper according to code=CP001, and obtains the corresponding ChannelHandler. The codec encodes JSON into binary instructions and delivers them to the charging pile through ChannelHandler to complete the billing notification.

[0079] 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 to define a data block of the transmission information of a preset fixed length to be intercepted by FixedLengthFrameDecoder, or to use DelimiterBasedFrameDecoder to split the transmission information according to a preset delimiter.

[0080] Data codec definition unit, ‌inherits 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.

[0081] ‌Use FixedLengthFrameDecoder‌: cut the byte stream according to a preset fixed length (such as 128 bytes per frame).

[0082] ‌Use DelimiterBasedFrameDecoder‌: Split the data blocks by delimiters (such as 0x0D0A), which is suitable for variable-length messages.

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

[0084] ‌Example‌: Scenario: The charging pile continuously uploads two pieces of current data (each with a fixed size of 64 bytes), which are merged into 128 bytes and arrive at the server due to network buffering.

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

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

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

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

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

[0090] 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.

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

[0092] ‌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.

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

[0094] ‌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.

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

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

[0097] 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.

[0098] 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.

[0099] 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.

[0100] Input JSON data into preset business processing programs (such as billing engine, order generator, fault diagnosis module) to generate feedback information (such as billing results, control instructions).

[0101] The processing result (JSON format) is 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.

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

[0103] ‌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.

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

[0105] ‌Business Processing‌: ‌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"}.

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

[0107] Feedback push: The result is written to the charging-feedback Topic, and Netty monitors it and sends it to the charging station.

[0108] Asynchronous processing and peak load shaving: The business system consumes messages according to its own throughput capacity to avoid message backlogs caused by business processing delays on the Netty server 122. Massive data is temporarily stored through message queues (such as Kafka) to cope with business peaks (such as centralized charging during holidays).

[0109] ‌Example‌: Peak scenario: Charging piles report 10,000 data items at the same time during the morning peak, and Kafka has a backlog of 100,000 unprocessed messages.

[0110] ‌Business processing strategy‌: Dynamic scaling: Automatically scale business processing nodes based on Kafka Lag (accumulation), from 10 nodes to 50 nodes, and increase throughput from 10,000 QPS to 50,000 QPS.

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

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

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

[0114] ‌Example‌: ‌New battery health analysis‌: ‌Implement the processor‌: Create a BatteryHealthProcessor, parse the voltage fluctuation data in JSON, and generate a health report.

[0115] ‌Register component‌: Add the processor to the business system and subscribe to the Topicbattery-health-data.

[0116] ‌Processing Flow‌: Dynamic rule adjustment: Scenario: The electricity price during holidays is adjusted from 0.5 yuan / kWh to 0.3 yuan / kWh.

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

[0118] Full-link collaboration example: ‌Scenario‌: The user stops charging pile CP001 remotely through the App; 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.

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

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

[0121] The charging pile stops charging and returns a confirmation frame 0x02|CP001|SUCCESS, which Netty decodes and pushes to Kafka's charging-response Topic.

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

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

[0124] The Netty-based car charging pile docking system provided in this application effectively solves the problems of low efficiency of high-concurrency connection management, redundant message processing, insufficient reliability of feedback links, and limited resource scalability in existing solutions through technical architecture and process innovation. The specific manifestations are as follows: Dynamic load balancing and high-concurrency connection management optimization: Intelligently distribute the 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 the scenario of tens of thousands of concurrent connections.

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

[0126] Efficient decoupling of message processing flow: 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.

[0127] ‌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 the system coupling and avoiding thread blocking caused by message accumulation.

[0128] ‌ Enhanced reliability of the two-way feedback link: Through the real-time association between the charging pile coding and the ChannelHandler, it is ensured that the feedback information of the business processing system 140 can be accurately routed to the target charging pile client 110. The Netty server 122 integrates the IdleStateHandler, periodically detects the connection activity and actively rebuilds the abnormal channel, avoiding the waste of resources in the traditional polling mechanism and ensuring the continuous availability of the long connection.

[0129] ‌ Improved resource utilization and horizontal expansion capability: Netty server 122 is only responsible for communication layer protocol processing, and the business logic is carried by the independent distributed stream processing platform 130, which supports dynamic expansion and contraction on demand and improves resource utilization. ‌ Lightweight connection management ‌: The mapping table of charging pile encoding and ChannelHandler is maintained through the ‌ connection mapper ‌ (based on memory or Redis). Compared with traditional database storage solutions, the mapping query latency has been reduced.

[0130] 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: Step 210: When the upload information of the charging pile client is received, the upload information is distributed to the Netty server that meets the current load balancing through the Nginx gateway.

[0131] 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; listen to 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 ChannelHandler.

[0132] 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 to intercept the data block of the transmission information of preset fixed length through FixedLengthFrameDecoder, or to use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

[0133] Among them, obtaining the charging pile code specifically includes: Login and authenticate the charging pile client of the current message to obtain the charging pile code.

[0134] 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.

[0135] In some embodiments, 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.

[0136] The Netty-based car charging pile docking method provided in this application effectively solves the problems of low efficiency of high-concurrency connection management, redundant message processing, insufficient reliability of feedback links, and limited resource scalability in existing solutions through technical architecture and process innovation, which are specifically reflected as follows: Dynamic load balancing and high-concurrency connection management optimization: Intelligently distribute charging pile client requests through the Nginx gateway, combine weight configuration and max_fails fault detection mechanism to achieve dynamic load balancing of the backend Netty server, and significantly improve the response speed and stability in the scenario of tens of thousands of concurrent connections.

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

[0138] Efficient decoupling of message processing flow: 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.

[0139] ‌Message publishing / listening components collaborate with distributed stream processing platforms‌: Adopt an asynchronous non-blocking message push mode to push JSON files to distributed stream platforms such as Kafka / RocketMQ, decoupling the business processing system from the communication layer, reducing system coupling and avoiding thread blocking caused by message accumulation.

[0140] ‌ Enhanced reliability of two-way feedback link: Through the real-time association between charging pile coding and ChannelHandler, it is ensured that the feedback information of 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 actively rebuild abnormal channels, avoiding the waste of resources in the traditional polling mechanism and ensuring the continuous availability of long connections.

[0141] Improved resource utilization and horizontal expansion capabilities: The Netty server is only responsible for communication layer protocol processing, and the business logic is carried by an independent distributed stream processing platform, which supports dynamic expansion and contraction on demand, and improves resource utilization. Lightweight connection management: The mapping table between charging pile encoding and ChannelHandler is maintained through the connection mapper (based on memory or Redis). Compared with traditional database storage solutions, the mapping query latency has been reduced.

[0142] 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.

[0143] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be 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 will not be limited to the embodiments shown herein, but rather 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 connection with the server through TCP / IP protocol; The server builds an Nginx gateway and several Netty servers 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, read the data packet of the uploaded information; according to the message frame type of the message in the data packet, determine the corresponding message processor, and then parse the bytecode of the message in the data packet into a json file through the message processor; through the connection mapper, obtain the charging pile code; push the json file to the distributed stream processing platform through the message publishing component; through the message listening component, listen to the feedback information returned by the distributed stream processing platform, and determine the corresponding ChannelHandler according to the charging pile code in the feedback information; through the connection mapper, associate the charging pile code and ChannelHandler; convert the feedback information into bytecode and send it to the corresponding charging pile client through ChannelHandler; 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. According to the Netty-based car charging pile docking system of claim 1, it is characterized in that: 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 to intercept the data block of the transmission information of preset fixed length through FixedLengthFrameDecoder, or to use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

3. 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 binding on the charging pile client of the current message to obtain the charging pile code.

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

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

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

7. The method for docking a car charging pile based on Netty according to claim 6, characterized in that: 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 to intercept the data block of the transmission information of preset fixed length through FixedLengthFrameDecoder, or to use DelimiterBasedFrameDecoder to split the transmission information according to the preset delimiter.

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

9. The method for docking a car charging pile based on Netty according to claim 6, 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.

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

Images