Network reconnection method and device based on connection pool, and storage medium
By obtaining the connection pool indicator parameters in real time and triggering the recovery strategy, the database connection abnormality caused by fiber network jitter is solved, and the connection pool is automatically reconnected and self-healed, improving the stability and high availability of the system.
Patent Information
- Application Number
- CN202510983191.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-17
- Publication Date
- 2025-08-15
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
In the case of abnormal database connection caused by fiber network jitter, the existing technology fails to identify and trigger automatic reconnection of the database connection pool in time, resulting in continuous downtime of the application system and lacks fault tolerance mechanism under network jitter, which affects system continuity and stability.
By obtaining the network connection indicator parameters of the connection pool in real time, using multi-dimensional threshold comparison and combination conditions to determine, triggering corresponding recovery strategies, such as adjusting the connection pool parameters, optimizing SQL, enabling redundant architecture or recording logs, to achieve automatic recovery of the connection pool.
It realizes the rapid identification of abnormal status of the connection pool after network jitter and automatically restores the connection pool, which improves the system's robustness and self-healing ability, reduces manual intervention, and reduces operation and maintenance costs.
Smart Images

Figure CN120498967A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to an application network reconnection technology based on a connection pool, and in particular to a network reconnection method, device, and storage medium based on a connection pool. Background Art
[0002] Unified alarming refers to a technical approach that centrally collects, standardizes, correlates, analyzes, and uniformly displays alarm information from different sources and types within an information system or network environment. This approach aims to improve fault detection accuracy and response efficiency, reduce false alarms and missed alarms, and achieve comprehensive monitoring of system operating status and intelligent early warning. It is widely used in multiple industries, including communications, electricity, finance, and cloud computing. A search revealed that existing technologies in the unified alarm field include centralized alarm information collection methods, standardized alarm data processing technologies, rule-based correlation analysis methods, machine learning-based anomaly detection technologies, visual alarm display information technologies, multi-source heterogeneous data fusion technologies, real-time streaming alarm data processing technologies, and time series-based fault prediction technologies.
[0003] In the event that fiber optic network jitter causes database connection anomalies, the existing system fails to promptly identify and trigger the automatic reconnection mechanism of the database connection pool after the network is restored, causing some applications to remain in a downtime state and requiring manual intervention to resume normal operation. Specifically, the current application system using the Hikari connection pool lacks the ability to actively detect and intelligently recover the status of the connection pool when facing network fluctuations, and is unable to automatically complete the connection reconstruction after the network is restored, thus affecting the continuity and stability of the system. In addition, the existing connection pool configuration strategy does not fully consider the fault tolerance mechanism in network jitter scenarios, resulting in residual or failed connections in the connection pool in extreme network environments, further weakening the system's automatic recovery capabilities after abnormal recovery. Therefore, there is an urgent need for a technical solution that can automatically sense the status of the connection pool after network jitter and trigger intelligent reconnection and health check mechanisms to improve the robustness and self-healing capabilities of the system in complex network environments. Summary of the Invention
[0004] The present application provides a network reconnection method and device based on a connection pool, and a storage medium, which can at least solve the aforementioned technical problems.
[0005] According to a first aspect of an embodiment of the present application, a network reconnection method based on a connection pool is provided, wherein each application connects to a related database through a connection pool; the connection pool is configured to preset at least connection timeout parameters, a maximum waiting time for available connections, and database communication parameters; the method includes: The network connection indicator parameters of the connection pool are obtained in real time. Multi-dimensional threshold comparison and combined condition judgment are performed based on the dynamic alarm rule library. When the alarm condition is triggered, the corresponding recovery strategy of the connection pool is executed: if the alarm is insufficient connection or thread blocking, the connection pool parameters are adjusted or the structured query language SQL is optimized; if the alarm is abnormal connection pool downtime, one-click start and stop or switching to redundant architecture is performed; if the alarm is slow SQL, the abnormal query is terminated and the log is recorded; For new systems, deploy standardized monitoring and recovery configurations.
[0006] As an implementation method, the network connection indicator parameters include connection usage rate, number of waiting connection threads, connection time, connection creation time, and number of connection timeouts; Correspondingly, the method also includes: presetting threshold judgment logic and combined alarm conditions for each monitoring indicator, including: when the connection usage rate exceeds a first threshold, triggering a connection shortage alarm; when the number of waiting connection threads exceeds a second threshold, triggering a thread blocking alarm; when the connection usage rate is 0, or the current total number of connections reaches the maximum threshold, and the number of idle connections is 0, the number of waiting connection threads is not 0, and the connection timeout period exceeds a third threshold, it is determined that the connection pool has crashed abnormally, and the connection pool expansion or reduction operation is performed; when a slow SQL problem is detected, the long-running SQL query is automatically terminated and the log is recorded.
[0007] As an implementation mode, the method further includes: When the current number of connections reaches the fourth threshold and the number of waiting connection threads is not 0, it is determined that the connection pool is overloaded; When the number of connection timeouts continues to increase and the time it takes to obtain a connection increases, it is determined to be a database access anomaly; When the time taken to obtain a connection exceeds the first preset threshold, a slow query alarm is triggered; When the time taken to create a connection exceeds a second preset threshold, a database connection abnormality alarm is triggered.
[0008] As an implementation method, the corresponding recovery strategy of the execution connection pool includes: For existing systems, configure connection timeout parameters and socket timeout parameters for the connection pool and optimize slow SQL performance; Automatically restart the system with low priority. For systems whose priority weight exceeds the fourth threshold, a redundant architecture is enabled to ensure uninterrupted connection and service.
[0009] As an implementation mode, the method further includes: For existing systems, parameter optimization and SQL tuning are prioritized; For newly built systems, the preset standardized recovery process is directly triggered.
[0010] As an implementation mode, the method further includes: Create an independent connection pool for each database and load the connection parameters of each database; initialize multiple database connections and form key-value pairs for multiple database connections, and store the database name and the corresponding connection pool in a key-value pair data structure in memory; where the database name is the key and the database connection pool is the key value; Register the corresponding monitoring indicators for the connection pool and associate the monitoring indicators with the alarm rule library.
[0011] According to a second aspect of an embodiment of the present application, a network reconnection device based on a connection pool is provided, wherein each application connects to a related database through the connection pool; the connection pool is configured to preset at least connection timeout parameters, a maximum waiting time for available connections, and database communication parameters; the device includes: The execution unit is used to obtain the network connection indicator parameters of the connection pool in real time, perform multi-dimensional threshold comparison and combined condition judgment based on the dynamic alarm rule library, and execute the corresponding recovery strategy of the connection pool when the alarm condition is triggered: if it is an alarm of insufficient connection or thread blocking, adjust the connection pool parameters or optimize the structured query language SQL; if it is an alarm of abnormal connection pool downtime, perform one-click start and stop or switch to redundant architecture; if it is a slow SQL, terminate the abnormal query and record the log; Deployment unit, used to deploy standardized monitoring and recovery configurations for new systems.
[0012] As an implementation method, the network connection indicator parameters include connection usage rate, number of waiting connection threads, connection time, connection creation time, and number of connection timeouts; Correspondingly, the execution unit is also used to: set the threshold judgment logic and combined alarm conditions for each monitoring indicator: when the connection usage rate exceeds the first threshold, the connection shortage alarm is triggered; when the number of waiting connection threads exceeds the second threshold, the thread blocking alarm is triggered; when the connection usage rate is 0, or the current total number of connections reaches the maximum threshold, and the number of idle connections is 0, the number of waiting connection threads is not 0, and the connection timeout period exceeds the third threshold, it is determined that the connection pool has crashed abnormally, and the connection pool expansion or reduction operation is executed; when a slow SQL problem is detected, the long-running SQL query is automatically terminated and the log is recorded.
[0013] As an implementation method, the execution unit is also used to: when the current number of connections reaches a fourth threshold and the number of waiting connection threads is not 0, determine that the connection pool is overloaded; when the number of connection timeouts continues to increase and the time taken to obtain a connection increases, determine that a database access abnormality occurs; when the time taken to obtain a connection exceeds a first preset threshold, trigger a slow query alarm; when the time taken to create a connection exceeds a second preset threshold, trigger a database connection abnormality alarm.
[0014] As an implementation manner, the execution unit is further configured to: For existing systems, configure connection timeout parameters and socket timeout parameters for the connection pool and optimize slow SQL performance; Automatically restart the system with low priority. For systems whose priority weight exceeds the fourth threshold, a redundant architecture is enabled to ensure uninterrupted connection and service.
[0015] As an implementation manner, the deployment unit is further configured to: For existing systems, parameter optimization and SQL tuning are prioritized; For newly built systems, the preset standardized recovery process is directly triggered.
[0016] As an implementation method, the device further includes: A creation unit is used to create an independent connection pool for each database and load the connection parameters of each database; initialize multiple database connections and form key-value pairs for multiple database connections, and store the database name and the corresponding connection pool in a key-value pair data structure in memory; wherein the database name is used as the key and the database connection pool is used as the key value; The association unit is used to register corresponding monitoring indicators for the connection pool and associate the monitoring indicators with the alarm rule library.
[0017] According to a third aspect of an embodiment of the present application, a non-temporary computer-readable storage medium is provided. When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the steps of the connection pool-based network reconnection method.
[0018] The technical solutions provided by the embodiments of the present application may have the following beneficial effects: This application's technical solution utilizes a Prometheus monitoring system to collect and analyze key Hikari connection pool metrics (such as active / max, pending, acquire, creation, and timeout) in real time. This allows for rapid detection of connection pool anomalies, preventing application downtime caused by network jitter or connection failures. Compared to traditional manual inspections or simple log monitoring, this application offers a higher degree of automation and responsiveness. This application implements automatic recovery and self-healing capabilities for connection pool anomalies. For severe anomalies like connection pool downtime, combined parameter alert rules are configured. When specific conditions are met (e.g., active is 0 or equal to the maximum value, idle is 0, pending is greater than 0, and timeout is greater than 10), the system automatically triggers a one-click start, stop, or restart, enabling fault recovery without manual intervention, significantly improving the system's high availability and fault tolerance. By uniformly configuring the connection-timeout and socketTimeout parameters and combining them with slow SQL optimization strategies, this application effectively reduces the probability of connection failures caused by timeouts or network fluctuations, thereby reducing unplanned application downtime due to connection pool issues. For non-critical systems, this application uses an automatic restart mechanism to achieve rapid recovery; for critical systems, it requires the design of a redundant architecture to ensure that the service can still operate normally during the self-healing process to avoid single point failures affecting the core business. All applications must be connected to the Prometheus monitoring platform in accordance with unified standards, including dependency introduction, configuration item settings, monitoring indicator exposure, etc., to form a standardized process to facilitate subsequent maintenance and expansion, while improving the observability and controllability of the overall system. This application allows customized alarm thresholds based on actual business scenarios, such as adjusting the active / max threshold range, the upper limit of pending, etc., to make the monitoring system more flexible and adaptable, and avoid false alarms or missed alarms. From data collection, alarm judgment, automatic recovery to recovery verification, a complete closed-loop process is formed, which not only improves the efficiency of problem handling, but also reduces the frequency of manual intervention and reduces operation and maintenance costs.
[0019] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0021] Figure 1 A schematic diagram of a flow chart of a network reconnection method based on a connection pool according to an embodiment of the present application; Figure 2A schematic diagram of the structure of a network reconnection device based on a connection pool according to an embodiment of the present application; Figure 3 It is a block diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION
[0022] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
[0023] The embodiment of the present application adopts a unified monitoring and application recovery system architecture, aiming to improve the monitoring efficiency and fault self-healing capabilities of enterprise-level applications during the use of connection pools. It is based on the Java backend application of the Hikari connection pool and, by introducing the Prometheus monitoring system, realizes centralized collection, alarm configuration, and automated processing of the connection pool status. First, in the unified monitoring solution, all applications must be connected to the Prometheus monitoring platform according to standard procedures. Specifically, it includes: introducing Prometheus client dependencies and opening the monitoring interface of the Hikari connection pool for Prometheus to collect data; at the same time, uniformly configuring the monitoring indicators and alarm rules related to the Hikari connection pool. The monitoring indicators cover key parameters such as connection usage rate (active / max), number of waiting connection threads (pending), time to obtain connection (acquire), time to create connection (creation), and number of connection timeouts (timeout), and set reasonable threshold ranges and abnormal judgment logic for each indicator. For example, when the active / max ratio exceeds 90%, it indicates insufficient available connections, necessitating adjustment of the connection pool size and investigation of slow SQL. When the pending value exceeds 5, it indicates a large number of threads waiting for connections, potentially impacting business response speed. Furthermore, a combined parameter alert mechanism is implemented. For example, when (active = 0 || active = maximumPoolSize) and idle = 0, pending > 0, and timeout > 10, the connection pool is considered abnormally down, triggering a one-click start / stop operation for rapid self-healing.
[0024] In terms of application recovery solutions, for existing systems, it is required to uniformly configure the connection-timeout and socketTimeout parameters and optimize the performance of slow SQL; for systems that cannot be optimized, non-important systems can automatically restart and self-heal, while for important systems, a redundant architecture must be designed to ensure that services are not interrupted during the self-healing process. New systems will integrate the above configurations by default and will be uniformly managed by the Mercury platform scaffolding to ensure that the new system complies with monitoring and recovery specifications from the development stage. In summary, the embodiments of the present application have built an efficient and reliable connection pool monitoring and recovery system through standardized monitoring access, refined indicator configuration and intelligent alarm processing, which significantly improves system stability and operation and maintenance efficiency.
[0025] The essence of the technical solution of the embodiment of the present application is further explained below through specific examples.
[0026] Figure 1 This is a flow chart of a network reconnection method based on a connection pool according to an embodiment of the present application. Figure 1 As shown, the network reconnection method based on the connection pool in the embodiment of the present application may include the following processing steps: Step 101: obtain the network connection indicator parameters of the connection pool in real time, perform multi-dimensional threshold comparison and combination condition judgment according to the dynamic alarm rule library, and execute the corresponding recovery strategy of the connection pool when the alarm condition is triggered.
[0027] In an embodiment of the present application, each application connects to a related database through a connection pool. The connection pool is configured to pre-set at least connection timeout parameters, the maximum waiting time for available connections, and database communication parameters. Specifically, the network connection indicator parameters include connection utilization rate, number of threads waiting for connection, connection time, connection creation time, and number of connection timeouts. The corresponding recovery strategy of the connection pool includes: adjusting connection pool parameters or optimizing structured query language (SQL) in the event of insufficient connections or thread blocking alarms; executing one-click start / stop or switching to a redundant architecture in the event of abnormal connection pool downtime alarms; and terminating the abnormal query and logging in the event of slow SQL. In an embodiment of the present application, threshold judgment logic and combined alarm conditions are preset for each monitoring indicator. Specifically: when the connection usage rate exceeds the first threshold, a connection shortage alarm is triggered; when the number of waiting connection threads exceeds the second threshold, a thread blocking alarm is triggered; when the connection usage rate is 0, or the current total number of connections reaches the maximum threshold, and the number of idle connections is 0, the number of waiting connection threads is not 0, and the connection timeout period exceeds the third threshold, it is determined that the connection pool is abnormally down, and the connection pool expansion or reduction operation is performed; when a slow SQL problem is detected, the long-running SQL query is automatically terminated and the log is recorded. As an example, the first threshold can be 90%, 85%, etc. The second threshold can be 5, 7, or 9, etc. The maximum threshold for the total number of connections can be 15, 17, or 18, etc. The third threshold can be 3 seconds, 2 seconds, 5 seconds, etc.
[0028] When the current number of connections reaches the fourth threshold and the number of waiting connection threads is not zero, the connection pool is considered overloaded. When the number of connection timeouts continues to increase and the time it takes to obtain a connection increases, a database access anomaly is determined. When the time it takes to obtain a connection exceeds the first preset threshold, a slow query alarm is triggered. When the time it takes to create a connection exceeds the second preset threshold, a database connection anomaly alarm is triggered. The fourth threshold can be 21, 15, or 10, for example. The first preset threshold can be 2 seconds, and the second preset threshold can be 5 seconds, for example.
[0029] This application embodiment adopts a unified monitoring solution. All applications need to follow the following steps to access the bank's unified monitoring and alarm system to improve the efficiency of such problem investigation. The application introduces Prometheus monitoring dependency, opens the Hikari connection pool Prometheus monitoring interface, and uses the unified monitoring platform Prometheus for data collection; uniformly configure Hikari connection pool related alarms; Mercury application access method is as follows: Introduce Prometheus monitoring and collection dependency: <dependency> <groupid> io.micrometer< / groupid> <artifactid> micrometer-registry-prometheus< / artifactid> < / dependency> Add the following configuration: management: endpoints: web: exposure: include: 'info,health,prometheus' The monitoring indicators are shown in Table 1 below: Table 1: Monitoring indicator related parameters
[0030] Step 102: Deploy standardized monitoring and recovery configuration for the newly built system.
[0031] In this embodiment, for existing systems, connection timeout parameters and socket timeout parameters are configured for the connection pool, and slow SQL performance is optimized. For systems with low priority, automatic restarts are performed. For systems with priority exceeding the fourth threshold, redundant architectures are enabled to ensure uninterrupted connections and services. For existing systems, parameter optimization and SQL tuning are prioritized. For newly built systems, a pre-set standardized recovery process is directly triggered.
[0032] In the embodiments of this application, data processing primarily revolves around the collection, transmission, and storage of monitoring metrics. All application systems must connect to a unified Prometheus monitoring platform, exposing Hikari connection pool operational status information through standard interfaces, including but not limited to key performance indicators (KPIs) such as connection utilization, number of waiting threads, and connection acquisition time. This data serves as the basis for subsequent alarm assessment and self-healing operations. Data Source and Collection Method: Data is derived from the runtime status of the Hikari connection pool in the Java backend application and is exposed through the Metrics interface provided by HikariCP. This interface supports the output of metric data in the Prometheus Exporter format, facilitating scheduled pull-based collection by the Prometheus Server. The collection frequency can be configured to every 30 seconds, ensuring real-time and accurate data. Collected data uses the standard Prometheus text format, including the metric name, label, value, and timestamp. Each metric is labeled with the application name (app) and connection pool name (pool) to distinguish monitoring data from different systems. After collecting raw data, the Prometheus server performs preliminary filtering and aggregation, such as deduplication, outlier removal, and unit normalization. For example, millisecond-level acquisition and creation times are converted to seconds to facilitate subsequent analysis and matching alert rules. Furthermore, some metrics, such as activemax, require normalization, converting them into percentages to facilitate threshold determination.
[0033] The core of the embodiment of the present application is to build a unified monitoring and recovery system architecture, covering multiple modules such as monitoring data collection, alarm triggering, and automatic recovery, forming a closed-loop feedback mechanism. The system architecture consists of a monitoring and acquisition layer: Prometheus Server is responsible for pulling the monitoring indicators of the Hikari connection pool from each application instance through HTTP Pull. The technical solution of the embodiment of the present application can be implemented based on Prometheus Alertmanager, which judges the collected indicators according to the preset alarm rules and triggers alarm notifications. By integrating automated operation and maintenance tools (such as Ansible, Kubernetes Operator, etc.), when specific alarm conditions are detected, one-click start and stop, restart of services and other operations are performed. The embodiment of the present application can also use the Mercury platform as a unified configuration center, which is responsible for managing the connection pool parameters of each system and providing scaffolding templates for new systems.
[0034] For example, when activemax exceeds 90%, a "connection pool high load" alarm is triggered; when (active=0||active=max)&&pending>0&&timeout>10, it is considered a "connection pool down," triggering a one-click start / stop operation. Users can customize alarm thresholds based on business characteristics, such as setting the activemax threshold to 85% or the pending threshold to 3, to meet performance requirements in different scenarios. Critical systems are required to have redundant deployment capabilities, such as active / standby failover and load balancing, to ensure unimpeded business continuity during self-healing. When an alarm is triggered, the system executes recovery actions according to pre-set policies. 1. Alarm Triggering: Upon receiving the alarm signal, the AlertManager sends a notification to operations personnel or the automated recovery system. 2. Alarm Classification: Based on the alarm type (e.g., "High Load" or "Downtime"), automatic recovery is determined. 3. Recovery Action: For non-critical systems, the corresponding pod or service is restarted by directly calling the Kubernetes API or Ansible Playbook. For critical systems, first check whether the redundant node is available. If so, switch traffic to the redundant node, and then restart the primary node. 4. Recovery Confirmation: After recovery is complete, the system recollects indicators to verify whether it has returned to normal. If not, enter the manual intervention process.
[0035] In the embodiment of the present application, all applications are connected to the connection pool monitoring to configure the connection pool alarm; connection-timeout=30000ms is used as the configuration baseline, and all applications need to be configured; each system self-checks the slow SQL situation in the application and tries to optimize the super-slow SQL to within 30 seconds; for systems that do not have super-slow SQL after optimization, socketTimeout=60000ms is uniformly configured; for systems that cannot be optimized, there are two situations: Non-important systems: When the connection pool monitoring alarm is issued, the application is automatically restarted or the application start and stop function is connected to automatically trigger the application to restart and self-heal. Important systems: It is necessary to design an application redundancy solution by yourself to ensure that other redundant services can operate normally during the manual or automatic application self-healing restart phase in extreme cases. The embodiment of the present application is suitable for enterprise-level Java back-end applications, especially microservice architecture systems based on the Spring Boot framework and using the Hikari connection pool.
[0036] Figure 2 This is a schematic diagram of the composition structure of a network reconnection device based on a connection pool according to an embodiment of the present application. Figure 2 As shown, each application is connected to the relevant database through a connection pool; the connection pool is configured to preset at least connection timeout parameters, maximum waiting time for available connections, and database communication parameters; the network reconnection device based on the connection pool of the embodiment of the present application includes: The execution unit 20 is used to obtain the network connection indicator parameters of the connection pool in real time, perform multi-dimensional threshold comparison and combined condition judgment based on the dynamic alarm rule library, and execute the corresponding recovery strategy of the connection pool when the alarm condition is triggered: if it is an alarm of insufficient connection or thread blocking, adjust the connection pool parameters or optimize the structured query language SQL; if it is an alarm of abnormal connection pool downtime, perform one-click start and stop or switch to redundant architecture; if it is a slow SQL, terminate the abnormal query and record the log; The deployment unit 21 is used to deploy standardized monitoring and recovery configuration for the newly built system.
[0037] As an implementation method, the network connection indicator parameters include connection usage rate, number of waiting connection threads, connection time, connection creation time, and number of connection timeouts; Correspondingly, the execution unit 20 is also used to: preset the threshold judgment logic and combined alarm conditions for each monitoring indicator: when the connection usage rate exceeds the first threshold, the connection shortage alarm is triggered; when the number of waiting connection threads exceeds the second threshold, the thread blocking alarm is triggered; when the connection usage rate is 0, or the current total number of connections reaches the maximum threshold, and the number of idle connections is 0, the number of waiting connection threads is not 0, and the connection timeout period exceeds the third threshold, it is determined that the connection pool is abnormally down, and the connection pool expansion or reduction operation is executed; when a slow SQL problem is detected, the long-running SQL query is automatically terminated and the log is recorded.
[0038] As an implementation method, the execution unit 20 is also used to: when the current number of connections reaches a fourth threshold and the number of waiting connection threads is not 0, determine that the connection pool is overloaded; when the number of connection timeouts continues to increase and the time taken to obtain a connection increases, determine that a database access abnormality occurs; when the time taken to obtain a connection exceeds a first preset threshold, trigger a slow query alarm; when the time taken to create a connection exceeds a second preset threshold, trigger a database connection abnormality alarm.
[0039] As an implementation manner, the execution unit 20 is further configured to: For existing systems, configure connection timeout parameters and socket timeout parameters for the connection pool and optimize slow SQL performance; Automatically restart the system with low priority. For systems whose priority weight exceeds the fourth threshold, a redundant architecture is enabled to ensure uninterrupted connection and service.
[0040] As an implementation manner, the deployment unit 21 is further configured to: For existing systems, parameter optimization and SQL tuning are prioritized; For newly built systems, the preset standardized recovery process is directly triggered.
[0041] As an implementation method, the device further includes: Create a cell ( Figure 2 (not shown) for creating an independent connection pool for each database and loading the connection parameters of each database; initializing multiple database connections and forming key-value pairs for multiple database connections, storing the database name and the corresponding connection pool in a key-value pair data structure in memory; wherein the database name is used as the key and the database connection pool is used as the key value; Association unit ( Figure 2 (not shown in the figure) is used to register corresponding monitoring indicators for the connection pool and associate the monitoring indicators with the alarm rule library.
[0042] In an exemplary embodiment, the above-mentioned processing units may be implemented by one or more central processing units (CPU), graphics processing units (GPU), baseband processors (BP), application-specific integrated circuits (ASIC), digital signal processors (DSP), programmable logic devices (PLD), complex programmable logic devices (CPLD), field-programmable gate arrays (FPGA), general-purpose processors, controllers, microcontrollers (MCU), microprocessors, or other electronic components.
[0043] In the embodiments of this application, Figure 2 The specific manner in which each unit in the illustrated connection pool-based network reconnection device performs operations has been described in detail in the embodiment of the method and will not be elaborated on here.
[0044] Figure 3 8 is a block diagram of an electronic device according to an exemplary embodiment. The electronic device 800 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.
[0045] like Figure 3As shown, electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of electronic device 800. Computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to bus 804.
[0046] Multiple components in the electronic device 800 are connected to the I / O interface 805, including an input unit 806, such as a keyboard, a mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a magnetic disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.
[0047] The computing unit 801 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the connection pool-based network reconnection method. For example, in some embodiments, the connection pool-based network reconnection method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the computing unit 801, one or more steps of the connection pool-based network reconnection method described above can be performed. Alternatively, in other embodiments, the computing unit 801 may be configured as a network reconnection method based on a connection pool in any other appropriate manner (for example, by means of firmware).
[0048] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0049] The program code for implementing the methods of the present application can be written in any combination of one or more programming languages. Such program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the program code is executed by the processor or controller, the functions / operations specified in the flow charts and / or block diagrams are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.
[0050] In the context of this application, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or apparatus. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of machine-readable storage media may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fibers, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0051] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).
[0052] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.
[0053] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises through computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.
[0054] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this application can be achieved. This is not a limitation herein.
[0055] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the description of this application, "plurality" means two or more, unless otherwise specifically defined.
[0056] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.
Claims
1. A network reconnection method based on a connection pool, characterized in that: Each application is connected to a related database through a connection pool; the connection pool is configured to preset at least connection timeout parameters, maximum waiting time for available connections, and database communication parameters; the method includes: The network connection indicator parameters of the connection pool are obtained in real time. Multi-dimensional threshold comparison and combined condition judgment are performed based on the dynamic alarm rule library. When the alarm condition is triggered, the corresponding recovery strategy of the connection pool is executed: if the alarm is insufficient connection or thread blocking, the connection pool parameters are adjusted or the structured query language SQL is optimized; if the alarm is abnormal connection pool downtime, one-click start and stop or switching to redundant architecture is performed; if the alarm is slow SQL, the abnormal query is terminated and the log is recorded; For new systems, deploy standardized monitoring and recovery configurations.
2. The method according to claim 1, characterized in that The network connection indicator parameters include connection usage rate, number of waiting connection threads, connection time, connection creation time, and number of connection timeouts; Correspondingly, the method also includes: presetting threshold judgment logic and combined alarm conditions for each monitoring indicator, including: when the connection usage rate exceeds a first threshold, triggering a connection shortage alarm; when the number of waiting connection threads exceeds a second threshold, triggering a thread blocking alarm; when the connection usage rate is 0, or the current total number of connections reaches the maximum threshold, and the number of idle connections is 0, the number of waiting connection threads is not 0, and the connection timeout period exceeds a third threshold, it is determined that the connection pool has crashed abnormally, and the connection pool expansion or reduction operation is performed; when a slow SQL problem is detected, the long-running SQL query is automatically terminated and the log is recorded.
3. The method according to claim 2, characterized in that The method further comprises: When the current number of connections reaches the fourth threshold and the number of waiting connection threads is not 0, it is determined that the connection pool is overloaded; When the number of connection timeouts continues to increase and the time it takes to obtain a connection increases, it is determined to be a database access anomaly; When the time taken to obtain a connection exceeds the first preset threshold, a slow query alarm is triggered; When the time taken to create a connection exceeds a second preset threshold, a database connection abnormality alarm is triggered.
4. The method according to claim 1, wherein The corresponding recovery strategy of the execution connection pool includes: For existing systems, configure connection timeout parameters and socket timeout parameters for the connection pool and optimize slow SQL performance; Automatically restart the system with low priority. For systems whose priority weight exceeds the fourth threshold, a redundant architecture is enabled to ensure uninterrupted connection and service.
5. The method according to claim 1, wherein The method further comprises: For existing systems, parameter optimization and SQL tuning are prioritized; For newly built systems, the preset standardized recovery process is directly triggered.
6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Create an independent connection pool for each database and load the connection parameters of each database; initialize multiple database connections and form key-value pairs for multiple database connections, and store the database name and the corresponding connection pool in a key-value pair data structure in memory; where the database name is the key and the database connection pool is the key value; Register the corresponding monitoring indicators for the connection pool and associate the monitoring indicators with the alarm rule library.
7. A network reconnection device based on a connection pool, characterized in that: Each application is connected to a related database through a connection pool; the connection pool is configured to preset at least connection timeout parameters, maximum waiting time for available connections, and database communication parameters; the device includes: The execution unit is used to obtain the network connection indicator parameters of the connection pool in real time, perform multi-dimensional threshold comparison and combined condition judgment based on the dynamic alarm rule library, and execute the corresponding recovery strategy of the connection pool when the alarm condition is triggered: if it is an alarm of insufficient connection or thread blocking, adjust the connection pool parameters or optimize the structured query language SQL; if it is an alarm of abnormal connection pool downtime, perform one-click start and stop or switch to redundant architecture; if it is a slow SQL, terminate the abnormal query and record the log; Deployment unit, used to deploy standardized monitoring and recovery configurations for new systems.
8. The device according to claim 7, characterized in that The network connection indicator parameters include connection usage rate, number of waiting connection threads, connection time, connection creation time, and number of connection timeouts; Correspondingly, the execution unit is also used to: preset the threshold judgment logic and combined alarm conditions for each monitoring indicator: when the connection usage rate exceeds the first threshold, the connection shortage alarm is triggered; when the number of waiting connection threads exceeds the second threshold, the thread blocking alarm is triggered; when the connection usage rate is 0, or the current total number of connections reaches the maximum threshold, and the number of idle connections is 0, the number of waiting connection threads is not 0, and the connection timeout period exceeds the third threshold, it is determined that the connection pool has crashed abnormally, and the connection pool expansion or reduction operation is executed; when a slow SQL problem is detected, the long-running SQL query is automatically terminated and the log is recorded.
9. The device according to claim 8, characterized in that The execution unit is further configured to: determine that the connection pool is overloaded when the current number of connections reaches a fourth threshold and the number of threads waiting for connection is not 0; determine that a database access is abnormal when the number of connection timeouts continues to increase and the time taken to obtain a connection increases; trigger a slow query alarm when the time taken to obtain a connection exceeds a first preset threshold; and trigger a database connection abnormality alarm when the time taken to create a connection exceeds a second preset threshold.
10. A non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the steps of the network reconnection method based on the connection pool according to any one of claims 1 to 6.
Citation Information
Patent Citations
Method for monitoring failure of weblogic connection pool
CN104980524A
Database overload protection processing method and device and storage medium
CN112988435A
Connection thread monitoring method and device for connection pool, medium and equipment
CN113760656A
Fault self-recovery system and method based on MySQL database
CN117632651A