High-availability solution method and device for database exception in high-frequency query scene, equipment and medium

Abstract

The invention discloses a high-availability solution method and device for database exception in a high-frequency query scene, equipment and a medium, and relates to the technical field of computers, and the method comprises the steps of obtaining a running log of a query access request through a quasi-real-time link; distributing the query access request to a plurality of sliding windows of a sliding window mechanism according to the running log, and calculating an aggregation statistical result of a target database in the sliding windows according to a preset rule; when it is judged that the target database is abnormal according to the aggregation statistical result, the target database is automatically isolated, and a database switching instruction is sent to the current operation instance, so that the current operation instance is connected to a healthy database. The accuracy of the high-frequency query result can be ensured.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a high-availability solution, device, equipment and medium for database anomalies in high-frequency query scenarios. Background Art

[0002] In high-frequency query scenarios, in order to meet the high requirements for real-time and accuracy of data queries, a database architecture with read-write separation and multi-read database routing is usually adopted. Oracle Database supports automatic switching to the standby database in sequence by configuring multiple database IP addresses in the connection string and enabling FAILOVER=ON mode to improve the availability of the system in high-frequency query scenarios. However, actual measurements have found that database switching takes a long time, and in some cases the database will "fake death", that is, the database can neither provide enough connections nor completely crash, which will cause the automatic switching mechanism to fail to trigger, thereby affecting the results of high-frequency queries.

[0003] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0004] The main purpose of this application is to provide a high-availability solution, device, equipment and medium for database anomalies in high-frequency query scenarios, aiming to solve the technical problem that the automatic switching mechanism cannot be triggered due to database pseudo-death in high-frequency query scenarios, thus affecting the high-frequency query results.

[0005] To achieve the above objectives, the present application proposes a high-availability solution to database anomalies in high-frequency query scenarios, and the high-availability solution to database anomalies in high-frequency query scenarios includes:

[0006] Obtain the operation log of the query access request through the quasi-real-time link;

[0007] Allocating the query access request to multiple sliding windows of a sliding window mechanism according to the operation log, and calculating aggregated statistical results of the target database within the sliding window according to preset rules;

[0008] When the target database is determined to be abnormal according to the aggregated statistical result, the target database is automatically isolated, and a database switching instruction is sent to the current running instance so that the current running instance is connected to a healthy database.

[0009] In one embodiment, the step of allocating the query access request to a plurality of sliding windows of a sliding window mechanism according to the operation log comprises:

[0010] Set the window length and sliding step size of the sliding window mechanism;

[0011] A plurality of sliding windows are established according to the window length and the sliding step, so as to distribute the query access request to the plurality of sliding windows of the sliding window mechanism according to the operation log, wherein each sliding window is associated with a trigger, and the trigger is used to trigger the aggregation calculation and window clearing within the sliding window.

[0012] In one embodiment, the step of calculating the aggregated statistical results of the target database in the sliding window according to the preset rules includes:

[0013] Determine all running instances connected to the target database under the sliding window;

[0014] Count the number of error code requests and total traffic in the sliding window for each running instance;

[0015] According to the number of error code requests and the total traffic, a proportion value of all running instances connected to the target database under a sliding window is determined.

[0016] In one embodiment, when the target database is determined to be abnormal according to the aggregated statistical result, the step of automatically isolating the target database includes:

[0017] Determine whether the proportion values ​​of all running instances of the target database in the sliding window are greater than the database abnormality threshold;

[0018] When the proportion values ​​of all running instances of the target database under the sliding window are greater than the database abnormality threshold, the target database is determined to be abnormal;

[0019] After determining that the target database is abnormal, the target database is automatically isolated and a database abnormality warning notification is sent.

[0020] In one embodiment, after the step of determining whether the proportion values ​​of all running instances of the target database in the sliding window are greater than the database abnormality threshold, the step further includes:

[0021] When the proportion values ​​of all running instances of the target database in the sliding window are not all greater than the database abnormality threshold, determining the total error quantity of the target database in the sliding window according to the number of error code requests;

[0022] When the total error amount is greater than other abnormal thresholds, a database early warning notification is sent.

[0023] In one embodiment, when the target database is determined to be abnormal according to the aggregated statistical result, the step of sending a database switching instruction to the current running instance so that the current running instance is connected to the healthy database includes:

[0024] When the target database is determined to be abnormal according to the aggregated statistical results, the target database is automatically isolated and the health status of the database stored in the redis cluster is modified;

[0025] When the health status of the database in the Redis cluster is monitored to change, the current healthy database list is obtained and a database switching instruction is sent to all currently running instances;

[0026] After all currently running instances receive the database switching instruction, the loads of all currently running instances are rebalanced so that each running instance is balanced to a healthy database in the current healthy database list.

[0027] In one embodiment, the step of modifying the health status of the database stored in the redis cluster includes:

[0028] Based on the distributed lock of redis cluster, read the health status of the database in the redis cluster;

[0029] Determining the number of healthy databases according to the health status of the databases;

[0030] When the number of healthy databases is greater than a preset number, the health status of the databases stored in the redis cluster is modified.

[0031] In addition, to achieve the above purpose, the present application also proposes a high-availability solution to database anomalies in high-frequency query scenarios, and the high-availability solution to database anomalies in high-frequency query scenarios includes:

[0032] An acquisition module, used to acquire the operation log of the query access request through a quasi-real-time link;

[0033] An allocation module, configured to allocate the query access request to a sliding window of a sliding window mechanism according to the operation log, and calculate an aggregated statistical result of a target database within the sliding window according to a preset rule;

[0034] The start module is used to automatically isolate the target database when it is determined that the target database is abnormal according to the aggregate statistical result, and send a database switching instruction to the current running instance so that the current running instance is connected to a healthy database.

[0035] In addition, to achieve the above-mentioned objectives, the present application also proposes a high-availability solution device for database anomalies in high-frequency query scenarios, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the high-availability solution method for database anomalies in high-frequency query scenarios as described above.

[0036] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the high-availability solution for database anomalies in high-frequency query scenarios as described above are implemented.

[0037] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the high-availability solution for database anomalies in high-frequency query scenarios as described above.

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] The high-availability solution, device, equipment and medium for database anomalies in high-frequency query scenarios proposed in the present application obtain the operation log of the query access request through a quasi-real-time link; distribute the query access request to multiple sliding windows of the sliding window mechanism according to the operation log, and calculate the aggregated statistical results of the target database in the sliding window according to preset rules; when the target database is determined to be abnormal according to the aggregated statistical results, the target database is automatically isolated, and a database switching instruction is sent to the current running instance to connect the current running instance to a healthy database, which solves the technical problem that the automatic switching mechanism cannot be triggered due to the pseudo-death of the database in the high-frequency query scenario, thereby affecting the high-frequency query results. Compared with the prior art, the present application uses the Flink window sliding mechanism to aggregate and calculate the response results of high-frequency query requests according to specified rules, and timely and accurately judges the health status of the database according to the response results, quickly isolates the database when the database is determined to be abnormal, and connects the current running instance to the healthy database to avoid traffic loss, thereby ensuring the accuracy of the high-frequency query results. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0042] Figure 1 A flowchart diagram of the first embodiment of a high-availability solution to database anomalies in high-frequency query scenarios of this application;

[0043] Figure 2 A schematic diagram of a window sliding mechanism provided in Embodiment 1 of the high-availability solution to database anomalies in high-frequency query scenarios of this application;

[0044] Figure 3 A schematic diagram of the statistical result structure provided in Example 1 of the high-availability solution to database anomalies in high-frequency query scenarios of this application;

[0045] Figure 4 A flow chart of exception handling rules provided for the first embodiment of a high-availability solution to database exceptions in high-frequency query scenarios of this application;

[0046] Figure 5 A schematic diagram of an abnormal fault-tolerant mechanism for a high-frequency query system provided in Embodiment 1 of the high-availability solution to database abnormalities in a high-frequency query scenario of the present application;

[0047] Figure 6 A flow chart of the second embodiment of the high-availability solution to database anomalies in high-frequency query scenarios provided in this application;

[0048] Figure 7 A schematic diagram of a distributed lock provided in Embodiment 2 of the high-availability solution to database anomalies in high-frequency query scenarios of this application;

[0049] Figure 8 A load balancing diagram provided for Embodiment 2 of the high-availability solution to database anomalies in high-frequency query scenarios of this application;

[0050] Fig. 9 This is a schematic diagram of the module structure of a high-availability solution to database anomalies in a high-frequency query scenario according to an embodiment of the present application;

[0051] Fig.10 This is a schematic diagram of the device structure of the hardware operating environment involved in a high-availability solution to database anomalies in high-frequency query scenarios in an embodiment of the present application.

[0052] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0053] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0054] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0055] The main solution of the embodiment of the present application is: obtaining the operation log of the query access request through a quasi-real-time link; allocating the query access request to multiple sliding windows of the sliding window mechanism according to the operation log, and calculating the aggregated statistical results of the target database in the sliding window according to preset rules; when the target database is determined to be abnormal according to the aggregated statistical results, the target database is automatically isolated, and a database switching instruction is sent to the current running instance to connect the current running instance to a healthy database.

[0056] It can be seen from the above embodiments that the present application obtains the operation log of the query access request through a quasi-real-time link; according to the operation log, the query access request is allocated to multiple sliding windows of the sliding window mechanism, and the aggregated statistical results of the target database in the sliding window are calculated according to preset rules; when the target database is judged to be abnormal according to the aggregated statistical results, the target database is automatically isolated, and a database switching instruction is sent to the current running instance to connect the current running instance to a healthy database, which solves the technical problem that the automatic switching mechanism cannot be triggered due to the pseudo-death of the database in high-frequency query scenarios, thereby affecting the high-frequency query results. Compared with the prior art, the present application uses the Flink window sliding mechanism to aggregate and calculate the response results of high-frequency query requests according to specified rules, and promptly and accurately judges the health status of the database according to the response results. When the database is judged to be abnormal, the database is quickly isolated, and the current running instance is connected to the healthy database to avoid traffic loss, thereby ensuring the accuracy of high-frequency query results.

[0057] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a high-availability solution device for database anomalies in high-frequency query scenarios, etc. The following takes a high-availability solution device for database anomalies in high-frequency query scenarios as an example to illustrate this embodiment and the following embodiments.

[0058] Based on this, the embodiment of the present application provides a high-availability solution to database abnormalities in high-frequency query scenarios. Figure 1 , Figure 1 This is a flow chart of the first embodiment of the high-availability solution to database anomalies in high-frequency query scenarios of the present application.

[0059] In this embodiment, the high-availability solution to database abnormality in the high-frequency query scenario includes steps S10 to S40:

[0060] Step S10, obtaining the operation log of the query access request through the quasi-real-time link;

[0061] It should be noted that the running log of the application query access request is obtained through the quasi-real-time link and forwarded to the subsystem running log kafka topic.

[0062] Step S20, allocating the query access request to multiple sliding windows of a sliding window mechanism according to the operation log, and calculating the aggregated statistical results of the target database in the sliding window according to a preset rule;

[0063] In a feasible implementation, the step of allocating the query access request to multiple sliding windows of a sliding window mechanism according to the operation log includes: setting the window length and the sliding step of the sliding window mechanism; establishing multiple sliding windows according to the window length and the sliding step, so as to allocate the query access request to multiple sliding windows of the sliding window mechanism according to the operation log, wherein each sliding window is associated with a trigger, and the trigger is used to trigger the aggregation calculation within the sliding window and the clearing of the sliding window.

[0064] It should be noted that for continuous high-frequency query request data streams, the sliding window in the Flink window mechanism is selected, where the sliding step size and window length of the sliding window can be defined in advance by the user, and finally the query requests are allocated to multiple sliding windows of the window sliding mechanism according to the running log.

[0065] (1) Window length (size): user-defined. Preferably, the window length can be set to size=1min, that is, the query request data flow within the last 1 minute is counted each time.

[0066] (2) Slide step size (slide): user-defined. Considering the maximum timeout for accessing the database, preferably, it can be set to slide=30s.

[0067] (3) Window Assignment (WindowAssigner): WindowAssigner assigns the arriving elements (i.e., query request data streams) to the corresponding sliding windows. Some query request data streams are assigned to size / slide windows (two in this system). Figure 2 As shown in the figure, when message 3 arrives at the processing system, according to the event time calculation of message 3, message 3 belongs to two sliding windows, Window1: [0s, 1min), Window2: [30s, 1min30s). Since Window2 has not been established at this time, the arrival of message 3 triggers the establishment of Window2.

[0068] (4) Trigger: Each sliding window is associated with a Trigger, and a timer is registered on the Trigger, which determines the time (endtime + allowedLateness) when each sliding window is calculated and cleared (FIRE_AND_PURGE). Figure 2 As shown, water level 1 triggers the aggregation calculation of Window 1 and clears the window, and water level 2 triggers the aggregation statistics of Window 2 and clears the window.

[0069] (5) Data statistics: When the Trigger triggers the processing of window data, the elements in the sliding window will be handed over to the "Evictor", which traverses the list of elements in the sliding window being counted and sends the filtered (duplicate data filtered) window elements to the calculation function. The calculation function calculates the result value of the window (that is, the number of error code requests and total traffic of all running instances connected to the target database) and finally sends it to the downstream.

[0070] In a feasible implementation, the step of calculating the aggregated statistical results of the target database in the sliding window according to preset rules includes: determining all running instances connected to the target database under the sliding window; counting the number of error code requests and the total traffic of each running instance under the sliding window; and determining the proportion value of all running instances connected to the target database under the sliding window based on the number of error code requests and the total traffic.

[0071] In the specific implementation, Figure 3 As shown, under the sliding window, all running instances connected to the target database can be counted, and the number of requests that the target database connection cannot obtain can be calculated (that is, the number of error code requests for each running instance under the sliding window is counted, and the error code is FDBE202), which accounts for the proportion of the total traffic count of the running instance in the corresponding sliding window.

[0072] Step S30, when it is determined that the target database is abnormal according to the aggregated statistical result, the target database is automatically isolated, and a database switching instruction is sent to the current running instance so that the current running instance is connected to a healthy database.

[0073] It should be noted that automatic isolation of the database refers to the use of automatic methods to isolate the database. When the target database is determined to be abnormal, the problem database is automatically isolated when the automatic isolation switch is in the on state, and an early warning notification of the database abnormality is sent to notify the relevant person in charge; when the target database is determined to be abnormal and isolated, but the automatic isolation switch is in the off state, a notification needs to be sent to the relevant person in charge, and manual intervention is required to investigate.

[0074] In a feasible implementation, when the target database is determined to be abnormal according to the aggregated statistical results, the step of automatically isolating the target database includes: determining whether the proportion values ​​of all running instances of the target database under the sliding window are greater than the database abnormality threshold; when the proportion values ​​of all running instances of the target database under the sliding window are greater than the database abnormality threshold, determining that the target database is abnormal; after determining that the target database is abnormal, automatically isolating the target database and sending a database abnormality warning notification.

[0075] In the specific implementation, Figure 4 As shown, if the probability (i.e., the ratio value) of all running instances (POD) connected to the target database in the corresponding sliding window is greater than the "database anomaly threshold" (preferably, the database anomaly threshold can be set to 0.05), the anomaly level of the target database in the corresponding sliding window is determined to be "database anomaly (DBError)", and the problem database (i.e., the target database) is automatically isolated when the automatic isolation switch is in the on state, and a notification is sent to warn the relevant person in charge; if the automatic isolation switch is in the off state at this time, a notification needs to be sent to the relevant person in charge for manual intervention and investigation; the purpose of setting the automatic isolation switch is to decide whether to use an automatic method to isolate the problem database.

[0076] In a feasible implementation, the step of determining whether the proportion values ​​of all running instances of the target database under the sliding window are greater than the database abnormality threshold further includes: when the proportion values ​​of all running instances of the target database under the sliding window are greater than the database abnormality threshold, determining the total error amount of the target database under the sliding window according to the number of error code requests; when the total error amount is greater than other abnormality thresholds, sending a database warning notification.

[0077] In the specific implementation, if the probability (proportion value) of all running instances (POD) connected to the target database in the corresponding sliding window is not all greater than the "database anomaly threshold", but the total error amount in the corresponding time window is greater than the "other anomaly threshold" (this system is set to 10), it is determined that the corresponding time window has not reached the "database anomaly", but the "database warning" is triggered. At this time, a database warning notification is sent to relevant personnel for manual intervention and investigation.

[0078] In the specific implementation, Figure 5 As shown in the figure, the database abnormal fault tolerance automatic isolation mechanism is mainly divided into the following parts:

[0079] (1) Obtain the operation log of the application query access request through the quasi-real-time link and forward it to the subsystem operation log Kafka topic;

[0080] (2) Use the Flink window sliding mechanism, with a window length of 1 minute, to aggregate and calculate the response results of high-frequency query requests according to specified rules;

[0081] (3) Setting up a separate monitoring application to parse and process the results of sliding window aggregation statistics;

[0082] (4) Set the automatic isolation switch to decide whether to use automatic isolation of the problem database;

[0083] (5) Set strict threshold conditions to determine whether the database is abnormal. If the database abnormality conditions are not met, but the warning level conditions are met, the relevant person in charge will be notified through the warning system and manual intervention will be carried out;

[0084] (6) Use redis cluster to store database health status, and monitor the real-time status of the database in redis through caching technology in high-frequency query applications;

[0085] (7) In high-frequency query applications, a flexible load balancing mechanism is used to re-load balance all instances when the database status changes, so that each instance can balance the load to the current healthy read database.

[0086] This embodiment obtains the operation log of the query access request through a quasi-real-time link; distributes the query access request to multiple sliding windows of the sliding window mechanism according to the operation log, and calculates the aggregated statistical results of the target database in the sliding window according to preset rules; when the target database is determined to be abnormal according to the aggregated statistical results, the target database is automatically isolated, and a database switching instruction is sent to the current running instance to connect the current running instance to a healthy database, which solves the technical problem that the automatic switching mechanism cannot be triggered due to the pseudo-death of the database in high-frequency query scenarios, thereby affecting the high-frequency query results. Compared with the prior art, this application uses the Flink window sliding mechanism to aggregate and calculate the response results of high-frequency query requests according to specified rules, and promptly and accurately judges the health status of the database according to the response results. When the database is determined to be abnormal, the database is quickly isolated, and the current running instance is connected to the healthy database to avoid traffic loss, thereby ensuring the accuracy of high-frequency query results.

[0087] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 6 , step S30 also includes steps S301 to S303:

[0088] Step S301, when the target database is determined to be abnormal according to the aggregated statistical result, the target database is automatically isolated, and the database health status stored in the redis cluster is modified;

[0089] In a feasible implementation, the step of modifying the health status of the database stored in the redis cluster includes: reading the health status of the database in the redis cluster based on the distributed lock of the redis cluster; determining the number of healthy databases based on the database health status; when the number of healthy databases is greater than a preset number, modifying the health status of the database stored in the redis cluster.

[0090] It should be noted that the high-frequency query system is clustered and deployed on the cloud platform. In order to control the shared variable "database health status", a redis-based distributed lock is used, and a cross-machine mutual exclusion mechanism is used to control access to shared resources. "Acquiring a lock" in a Redis-based distributed lock means that in a distributed system, when different processes or services need to operate on shared resources, they need to obtain a lock first to ensure the atomicity and consistency of the operation. The function of this lock is to ensure that at any time, only one process or service can operate on shared resources. After the operation is completed, the process or service needs to delete the lock flag in the Redis cluster by sending a release lock command, which usually involves checking whether the lock flag is consistent with the one you set to ensure that only the lock holder can release it.

[0091] In the specific implementation, Figure 7 As shown, under the Redis-based distributed lock, after the lock is successfully acquired, the database health status is read. If the number of healthy databases determined according to the database health status is greater than the preset number, the database health status can be modified and the lock can be released. If the number of healthy databases determined according to the database health status is not greater than the preset number, the lock is directly released at this time (that is, the database health status cannot be modified).

[0092] It is understandable that the preset number of healthy databases can just maintain the minimum availability of the database. Therefore, when the number of healthy databases is not greater than the preset number, there is no need to modify the number of databases. For example, the high-frequency query system has 3 databases and the preset number is 1. Two of the databases have been isolated. In order to maintain the minimum availability of the database, the last database will not be isolated (there is no need to modify the database health status at this time), and a notification will be sent to the relevant person in charge for manual intervention and investigation.

[0093] Step S302: when the health status of the database in the redis cluster is monitored to change, a list of currently healthy databases is obtained, and a database switching instruction is sent to all currently running instances;

[0094] It should be noted that when the health status of the database in the redis cluster is monitored to change (the "change" here means that the database is isolated), all currently running instances connected to the healthy database or the unhealthy database need to be re-load balanced.

[0095] In the specific implementation, changes in the "database health status" are divided into database isolation and database recovery. Both situations mean that the databases used by high-frequency query components need to be readjusted. That is, when the database health status monitored in the redis cluster is database recovery, all currently running instances connected to the healthy database need to be re-load balanced (database recovery means that the database is restored from an isolated state to normal use. Since the database will not be connected to the running instance when it is in an isolated state, when the "database health status" is database recovery, it is only necessary to re-load balance all running instances currently connected to the database).

[0096] Step S303: after all currently running instances receive the database switching instruction, re-balance the load of all currently running instances so that each running instance is balanced to a healthy database in the current healthy database list.

[0097] It should be noted that in high-frequency query applications, a flexible load balancing mechanism can be used to re-load balance all currently running instances when the database status changes, so that each currently running instance is evenly loaded to the healthy database.

[0098] In the specific implementation, Figure 8 As shown in the figure, changes in the "database health status" are divided into database isolation and database recovery. Both cases mean that the database used by the high-frequency query component needs to be readjusted. For each running instance (POD) of the application, no matter the currently connected database is in an unhealthy state or a healthy state, it is necessary to re-implement load balancing with other running instances within the current "healthy database list". The specific steps are as follows:

[0099] (1) The "database health status" is stored in the redis cluster. The high-frequency query component accesses the redis cluster through the proxy application, caches the "database health status" in the memory, and refreshes the cache periodically. The cache refresh frequency is configurable.

[0100] (2) After the cache is refreshed, if the "database health status" is monitored to have changed, the latest "healthy database list" is obtained, and the "switch database" instruction of the current running instance is triggered.

[0101] (3) After the current running instance receives the "switch database" instruction, it needs to determine which database in the "healthy database list" it should connect to. Here, a permanent auto-increment variable key is maintained in redis to assist in the calculation. Each time the running instance needs to switch the database, the incrby command is used to obtain the auto-incremented value index of the auto-increment variable. The corresponding database rule is: dbId = ids [index% ids.length], index is the auto-increment variable stored in redis, ids is the "healthy database list", and dbId is the calculated read database ID of the instance connection. Since the incrby auto-increment command is an atomic operation, there is no concurrency conflict problem.

[0102] (4) After the currently running instance obtains the database to which it belongs, it changes the instance-held DB to the latest healthy database.

[0103] This embodiment automatically isolates the target database and modifies the health status of the database stored in the redis cluster when the target database is determined to be abnormal according to the aggregated statistical results; when the health status of the database in the redis cluster is monitored to change, the current healthy database list is obtained, and a database switching instruction is sent to all currently running instances; after all currently running instances receive the database switching instruction, the load of all currently running instances is rebalanced so that each running instance is balanced to a healthy database in the current healthy database list. In the above manner, after isolating the unhealthy database, all currently running instances connected to the unhealthy database and the healthy database can be load balanced again, so that all currently running instances can be connected to the healthy database, ensuring the number of running instances connected to the healthy database, thereby meeting high-frequency query requests.

[0104] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the high-availability solution to database anomalies in high-frequency query scenarios of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0105] This application also provides a high-availability solution to database anomalies in high-frequency query scenarios. Fig. 9 , the high-availability solution for database anomalies in the high-frequency query scenario includes:

[0106] An acquisition module 10 is used to acquire a running log of a query access request through a quasi-real-time link;

[0107] An allocation module 20, configured to allocate the query access request to a sliding window of a sliding window mechanism according to the operation log, and calculate an aggregated statistical result of a target database in the sliding window according to a preset rule;

[0108] The start module 30 is used to automatically isolate the target database when it is determined that the target database is abnormal according to the aggregate statistical result, and send a database switching instruction to the current running instance so that the current running instance is connected to a healthy database.

[0109] The high-availability solution device for database anomalies in high-frequency query scenarios provided by the present application adopts the high-availability solution method for database anomalies in high-frequency query scenarios in the above-mentioned embodiments, and can solve the technical problem that the automatic switching mechanism cannot be triggered due to pseudo-death of the database in high-frequency query scenarios, thus affecting the high-frequency query results. Compared with the prior art, the beneficial effects of the high-availability solution device for database anomalies in high-frequency query scenarios provided by the present application are the same as the beneficial effects of the high-availability solution method for database anomalies in high-frequency query scenarios provided by the above-mentioned embodiments, and the other technical features of the high-availability solution device for database anomalies in high-frequency query scenarios are the same as the features disclosed in the above-mentioned embodiments, and are not described in detail here.

[0110] The present application provides a high-availability solution device for database anomalies in high-frequency query scenarios, and the high-availability solution device for database anomalies in high-frequency query scenarios includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the high-availability solution method for database anomalies in high-frequency query scenarios in the above-mentioned embodiment one.

[0111] Reference below Fig.10 , which shows a schematic diagram of the structure of a high-availability solution device for database anomalies in high-frequency query scenarios suitable for implementing the embodiment of the present application. The high-availability solution device for database anomalies in high-frequency query scenarios in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.10 The high-availability solution device for database anomalies in high-frequency query scenarios shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0112] like Fig.10As shown, the high-availability solution device for database anomalies in high-frequency query scenarios may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. Various programs and data required for the operation of the high-availability solution device for database anomalies in high-frequency query scenarios are also stored in RAM1004. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the high-availability solution device for database anomalies in high-frequency query scenarios to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a high-availability solution device for database anomalies in high-frequency query scenarios with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0113] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0114] The high-availability solution device for database anomalies in high-frequency query scenarios provided by the present application adopts the high-availability solution method for database anomalies in high-frequency query scenarios in the above-mentioned embodiments, which can solve the technical problem that the automatic switching mechanism cannot be triggered due to pseudo-death of the database in high-frequency query scenarios, thus affecting the high-frequency query results. Compared with the prior art, the beneficial effects of the high-availability solution device for database anomalies in high-frequency query scenarios provided by the present application are the same as the beneficial effects of the high-availability solution method for database anomalies in high-frequency query scenarios provided by the above-mentioned embodiments, and the other technical features of the high-availability solution device for database anomalies in high-frequency query scenarios are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0115] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0116] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0117] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, the computer-readable program instructions being used to execute a high-availability solution to database anomalies in high-frequency query scenarios in the above-mentioned embodiments.

[0118] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with 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), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0119] The computer-readable storage medium may be included in a high-availability solution device for database anomalies in high-frequency query scenarios; or may exist independently without being assembled into a high-availability solution device for database anomalies in high-frequency query scenarios.

[0120] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by a high-availability solution device for database anomalies in high-frequency query scenarios, the high-availability solution device for database anomalies in high-frequency query scenarios: obtains the operation log of the query access request through a quasi-real-time link; distributes the query access request to multiple sliding windows of the sliding window mechanism according to the operation log, and calculates the aggregated statistical results of the target database in the sliding window according to preset rules; when the target database is determined to be abnormal according to the aggregated statistical results, the target database is automatically isolated, and a database switching instruction is sent to the current running instance to connect the current running instance to a healthy database.

[0121] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0122] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0123] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0124] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned high-availability solution to database anomalies in high-frequency query scenarios, and can solve the technical problem that the automatic switching mechanism cannot be triggered due to the pseudo-death of the database in high-frequency query scenarios, thus affecting the high-frequency query results. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the high-availability solution to database anomalies in high-frequency query scenarios provided by the above-mentioned embodiments, and will not be elaborated here.

[0125] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the high-availability solution to database anomalies in the high-frequency query scenario as described above.

[0126] The computer program product provided by the present application can solve the technical problem that the automatic switching mechanism cannot be triggered due to the pseudo-death of the database in high-frequency query scenarios, thus affecting the high-frequency query results. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the high-availability solution to database anomalies in high-frequency query scenarios provided by the above-mentioned embodiments, and will not be elaborated here.

[0127] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A high-availability solution to database anomalies in high-frequency query scenarios, characterized in that: The method comprises: Obtain the operation log of the query access request through the quasi-real-time link; Allocating the query access request to multiple sliding windows of a sliding window mechanism according to the operation log, and calculating aggregated statistical results of the target database within the sliding window according to preset rules; When the target database is determined to be abnormal according to the aggregated statistical result, the target database is automatically isolated, and a database switching instruction is sent to the current running instance so that the current running instance is connected to a healthy database.

2. The method according to claim 1, characterized in that The step of allocating the query access request to a plurality of sliding windows of a sliding window mechanism according to the operation log comprises: Set the window length and sliding step size of the sliding window mechanism; Multiple sliding windows are established according to the window length and the sliding step size to distribute the query access request to the multiple sliding windows of the sliding window mechanism according to the operation log, wherein each sliding window is associated with a trigger, and the trigger is used to trigger the aggregation calculation and window clearing within the sliding window.

3. The method according to claim 1, characterized in that The step of calculating the aggregated statistical results of the target database in the sliding window according to the preset rules includes: Determine all running instances connected to the target database under the sliding window; Count the number of error code requests and total traffic in the sliding window for each running instance; According to the number of error code requests and the total traffic, a proportion value of all running instances connected to the target database under a sliding window is determined.

4. The method according to claim 3, characterized in that When the target database is determined to be abnormal according to the aggregated statistical result, the step of automatically isolating the target database comprises: Determine whether the proportion values ​​of all running instances of the target database in the sliding window are greater than the database abnormality threshold; When the proportion values ​​of all running instances of the target database under the sliding window are greater than the database abnormality threshold, the target database is determined to be abnormal; After determining that the target database is abnormal, the target database is automatically isolated and a database abnormality warning notification is sent.

5. The method according to claim 4, characterized in that After the step of determining whether the proportion values ​​of all running instances of the target database in the sliding window are greater than the database abnormality threshold, the following step is further performed: When the proportion values ​​of all running instances of the target database in the sliding window are not all greater than the database abnormality threshold, determining the total error quantity of the target database in the sliding window according to the number of error code requests; When the total error amount is greater than other abnormal thresholds, a database early warning notification is sent.

6. The method according to claim 1, characterized in that The step of determining that the target database is abnormal according to the aggregated statistical result and sending a database switching instruction to the current running instance so that the current running instance is connected to the healthy database includes: When the target database is determined to be abnormal according to the aggregated statistical results, the target database is automatically isolated and the health status of the database stored in the redis cluster is modified; When the health status of the database in the Redis cluster is monitored to change, the current healthy database list is obtained and a database switching instruction is sent to all currently running instances; After all currently running instances receive the database switching instruction, the loads of all currently running instances are rebalanced so that each running instance is balanced to a healthy database in the current healthy database list.

7. The method according to claim 6, characterized in that The step of modifying the health status of the database stored in the redis cluster includes: Based on the distributed lock of redis cluster, read the health status of the database in the redis cluster; Determining the number of healthy databases according to the health status of the databases; When the number of healthy databases is greater than a preset number, the health status of the databases stored in the redis cluster is modified.

8. A high-availability solution to database anomalies in high-frequency query scenarios, characterized in that: The device comprises: An acquisition module, used to acquire the operation log of the query access request through a quasi-real-time link; An allocation module, configured to allocate the query access request to a sliding window of a sliding window mechanism according to the operation log, and calculate an aggregated statistical result of a target database within the sliding window according to a preset rule; The start module is used to automatically isolate the target database when it is determined that the target database is abnormal according to the aggregate statistical result, and send a database switching instruction to the current running instance so that the current running instance is connected to a healthy database.

9. A high-availability solution to database anomalies in high-frequency query scenarios, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of a high-availability solution to database anomalies in a high-frequency query scenario as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of a high-availability solution to database anomalies in a high-frequency query scenario according to any one of claims 1 to 7 are implemented.

Images