Using Redis to record cascade and device information to achieve national standard upper service disaster recovery and rapid recovery method

Abstract

The present invention relates to an invention belonging to the field of video surveillance code stream security transmission, and specifically to a method for realizing disaster recovery and rapid recovery of national standard superior services by using Redis to record cascade and device information; a Redis storage management system is constructed to record cascade and device information, and when the service is abnormally restarted, the recovery link or waiting for registration and going online is quickly determined based on the Redis information. The first retrieval of shared device information adopts multi-threaded storage, and the second retrieval compares Redis with the reported information this time. The lower level synchronously retrieves resource information from the upper level with the help of Kafka components, and the database and Redis are accurately operated according to the information content. Each step works together to effectively solve the existing national standard cascade service in the face of various emergencies such as service failures and network anomalies. Rapid recovery of disaster recovery improves overall performance, disaster recovery capabilities and data accuracy, and meets the requirements of video surveillance systems for efficient, stable, reliable operation and accurate resource sharing.

Description

Technical Field

[0001] The invention belongs to the field of video surveillance code stream security transmission, and in particular relates to a method for realizing national standard upper service disaster recovery and rapid recovery by utilizing Redis record cascade and device information. Background Art

[0002] During operation, traditional national standard upper-level services rely on temporary cache to record the link status. Once the service restarts abnormally, according to national standards, it is necessary to wait for about 3 minutes of timeout before restarting the registration and online process to restore the normal link status. For example, in an actual video surveillance system, if the service restarts due to server hardware failure or software error, the system cannot automatically and quickly restore the link within these 3 minutes, and the user cannot perform any operations on the cascaded devices, which seriously affects the real-time and availability of the system, especially in security monitoring, traffic monitoring and other scenarios with extremely high real-time requirements, which may lead to the omission of important information.

[0003] With the widespread application of video surveillance technology, the number of devices connected to the cascade platform has increased significantly, often reaching the millions. When faced with the task of first-time retrieval of shared devices (including manual and automatic retrieval) for such a large number of devices, the traditional cascade upper-level service adopts a single-threaded strategy to store device information one by one. Taking 500,000 devices as an example, it is estimated that it will take up to 6 hours to perform the first retrieval synchronization. In this process, a large amount of system resources are occupied, and it is impossible to provide users with accurate device information in a timely manner, which seriously restricts the system's response speed and overall performance, and reduces the system's practicality and efficiency in actual applications.

[0004] When a cascade platform is connected to a large number of devices, changes in the lower-level device information are more common. If the lower level cannot notify the upper level of the device information change for some reason, in order to ensure data integrity, the traditional cascade upper-level service will start a secondary full-volume retrieval (manual or automatic) synchronization operation, and still use a single-threaded one-by-one warehousing method. For a scale of 500,000 devices, it is estimated to take about 6 hours. This method not only wastes a lot of time and computing resources, but also because all device information is reprocessed, it is impossible to distinguish between changed and unchanged information, further reducing system efficiency, affecting the system's response timeliness to other operation requests during processing, and having a negative impact on the overall performance and stability of the system.

[0005] In the conventional national standard docking scenario, when some information of the lower-level device changes and supports notification reporting of updates, the lower-level device will report the device change notification to the upper-level service through a SIP message. However, in the case of an unstable network environment, such as large network fluctuations or when the service is offline, the SIP message may be lost or unable to be delivered in time, causing the upper-level service to miss some status update messages, making it impossible to synchronize data between platforms, affecting the system's accurate judgment of the device status, and further interfering with subsequent operational decisions, such as device scheduling and resource allocation, reducing the accuracy and reliability of the system.

[0006] In addition, the existing relevant technologies still have at least the following deficiencies:

[0007] 1. Slow service restart and recovery: The waiting time specified by the national standard is too long, which makes it impossible for users to operate cascade devices normally during the service restart period, which is extremely unfavorable for video surveillance systems with high real-time requirements. In key monitoring scenarios, such as security monitoring and traffic monitoring, 3 minutes of offline time may miss the monitoring and processing of important events, seriously affecting the security and management efficiency of the system, and failing to meet the system's requirements for real-time and continuity.

[0008] 2. Low efficiency of first retrieval: The single-threaded storage method is extremely inefficient when searching for large-scale devices, and cannot meet the system's needs for rapid acquisition of device information. The long retrieval process consumes a lot of system resources, causing users to wait too long when querying device information, seriously affecting the user experience, reducing the practicality and competitiveness of the system, and making the system unable to cope with large-scale device management.

[0009] 3. Serious waste of secondary search resources and inefficiency: The traditional secondary full search method does not distinguish whether the device information has changed, and re-enters all devices into the warehouse, which causes a huge waste of time and computing resources when the number of devices is large. At the same time, due to the long processing time, the system cannot respond to other operation requests in time during the processing period, which seriously affects the overall performance and stability of the system and hinders the efficient operation of the system.

[0010] 4. Change notifications are easily missed and unreliable: The SIP message reporting method has obvious defects when the network fluctuates or the service is offline, which can easily lead to the loss of device change notifications and make the data between platforms out of sync. This may cause the system to misjudge the device status, which in turn affects subsequent operational decisions, such as device scheduling and resource allocation, reducing the accuracy and reliability of the system and failing to ensure the consistency and integrity of system data.

[0011] Traditional national standard cascade services face severe challenges in the above-mentioned key links. From the timeliness of service restart and recovery, to the efficiency of device retrieval and synchronization, to the reliability of device information change notification, they are unable to meet the strict requirements of modern video surveillance systems for efficient, stable and reliable operation. These problems seriously restrict the efficient sharing and accurate synchronization of video surveillance resources between different platforms. An innovative solution is urgently needed to effectively solve them, so as to comprehensively improve the overall performance and disaster recovery capabilities of national standard cascade services, ensure that video surveillance systems can operate stably and reliably, and meet the diverse needs of various industries for video surveillance. Summary of the invention

[0012] In view of the shortcomings of the current relevant existing technologies, the present invention provides a method for realizing disaster recovery and rapid recovery of national standard superior services by utilizing Redis to record cascade and device information, aiming to overcome the defects of slow service restart recovery, low device retrieval and synchronization efficiency, unreliable device information change notification and difficulty in ensuring data consistency in the existing national standard cascade service. By utilizing Redis to record cascade and device information and combining multi-threading, Kafka and other technologies, the national standard superior service can quickly restore the link status when it is abnormally restarted, improve the efficiency of the first retrieval, optimize the secondary retrieval process to save resources, ensure the timeliness and completeness of the device information change notification with the help of Kafka, and ensure the consistency of Redis and database data through regular verification, thereby comprehensively improving the overall performance, disaster recovery capability and data accuracy of the national standard cascade service, and meeting the requirements of modern video surveillance systems for efficient, stable, reliable operation and accurate resource sharing.

[0013] To achieve the above purpose, the technical solution adopted by the present invention is: using Redis to record cascade and device information to realize the national standard upper-level service disaster recovery and rapid recovery method, which is characterized by: through the recording and management of information and the collaborative operation between various processes, the national standard cascade upper-level service can quickly resume normal operation in the face of various emergencies, specifically including the following steps:

[0014] S1: During the operation of the national standard cascade upper-level service, a Redis storage management system for platform cascade and device information is built to classify and record key information closely related to the service operation status and device management, and establish a storage structure that facilitates fast query and accurate management. At the same time, the information in Redis is updated in a timely manner according to dynamic changes in service operation, providing basic data support for subsequent service recovery, device retrieval and information synchronization;

[0015] S2: When the national standard cascade upper-level service encounters an abnormal restart, it quickly makes a multi-dimensional status judgment based on the information stored in Redis, and intelligently decides to restore the cascade link status or wait for the lower-level registration and online based on the judgment result. After the link is successfully restored, a continuous and stable information update mechanism is established to ensure real-time and accurate reflection of the service status and reduce the impact of abnormal restart on the overall business;

[0016] S3: When performing the first retrieval of shared device information, an optimized multi-stage device information storage process is implemented, covering accurate classification and processing of information, efficient queue management of organization and device information, and single-threaded and multi-threaded collaborative storage operations, which improves the efficiency of device information storage and saves time and server resources;

[0017] S4: When performing the task of secondary retrieval of shared device information, a comparison algorithm is used to distinguish the difference between the currently reported information and the previously recorded information in Redis, and a differentiated processing strategy is implemented based on the comparison results. A timed verification mechanism is established to ensure that the device information in Redis is highly consistent with that in the database, avoiding repeated processing of unchanged information and improving the efficiency of secondary retrieval;

[0018] S5: In the process of synchronously retrieving resource information from the subordinate to the superior, the Kafka component is used to build an information reporting and sequential consumption channel, and accurate database operations and Redis information updates are performed according to the reported information content to ensure the timeliness, continuity and integrity of data synchronization between platforms, and solve the problem of information loss caused by network fluctuations or service abnormalities.

[0019] Furthermore, in S1, the key information closely related to the service operation status and device management includes platform cascade basic information and shared device resource information, wherein the key value of the platform cascade basic information is "AS: cascade port", and the internal record includes the cascade link status, the last heartbeat time, the last registration information, the registration validity period, and the basic information of the upper and lower platforms, and the shared device resource information includes the device ID, the device network status, and the information of the organization to which the device belongs; the cascade service ID, i.e., spid, is used as the primary key of the Redis hash device table, and the device ID is used as the internal key value to construct a storage structure, and the cascade link status is represented by binary coding, the heartbeat timestamp is recorded as the cascade heartbeat information, and the registration time and registration validity period are recorded for the management of the lower-level registration online status, so as to achieve efficient storage and fast query of information; updating the cascade status information in Redis according to the heartbeat timing keep-alive means that each time the heartbeat signaling arrives, the heartbeat timestamp is immediately updated. If the heartbeat signaling is not received for multiple consecutive times, it is automatically determined that the cascade may be abnormal and the corresponding processing measures are triggered in time to ensure real-time monitoring and effective management of the cascade status.

[0020] Furthermore, in S2, in the recovery process of the abnormal restart of the national standard cascade upper service, key status and condition judgments are performed based on the Redis storage information, and the restoration of the link or waiting for registration and online is determined based on the judgment result. After the link is restored, a stable information update mechanism is established to ensure the continuous and stable operation of the service. The judgment basis includes using a specific status flag to judge the cascade status, comparing the information conditions with the configuration file parameters, and determining the keep-alive time period according to the set time range. The information update mechanism is to update the cascade service status information to Redis in real time based on the heartbeat.

[0021] Furthermore, the specific implementation of the cascade platform rapid recovery process includes at least the following steps:

[0022] S11: After the national standard cascade upper service is successfully started for the first time, when the lower level is successfully registered and launched for the first time, the cascade service is successfully linked;

[0023] S12: Record the cascade online status into Redis, and update the cascade service status information in Redis according to the heartbeat timing keep-alive mechanism;

[0024] S13: Service abnormal restart;

[0025] S14: Immediately read the cascade service status information from Redis and the cascade basic information from the database if the following conditions are met: (1) The current cascade status recorded in Redis is linked; (2) The cascade basic information conditions read from the database and the cascade basic information in Redis meet the requirements of the current cascade configuration, that is, the cascade information in Redis is consistent with the cascade configuration information in the database; (3) The heartbeat timestamp recorded in Redis is within the keep-alive time period of the cascade heartbeat; If the conditions are met, the service directly restores the link status, otherwise waits for the next registration signaling from the subordinate to register the link online;

[0026] S15. If the condition of step S14 is met, the service resumes the normal connection state, continues to process the cascaded business normally, and updates the cascaded service status information to Redis in real time according to the heartbeat.

[0027] Furthermore, in S3, when the shared device information is first retrieved, efficient information storage is achieved through classification processing and multi-threaded operation of the information reported by the subordinates;

[0028] The initial retrieval process for shared device information includes the following steps:

[0029] S31, after the national standard cascade upper service is started, a search signal is sent to the lower platform;

[0030] S32, the lower-level cascade platform reports the retrieval organization information and retrieval device information in a hierarchical order;

[0031] S33, the national standard cascade upper service receives and parses the search information reported by the lower cascade platform, and then determines whether the reported information is an organization. If it is an organization, it is written into the waiting-to-enter organization queue; if it is a device, it is written into the waiting-to-enter device queue;

[0032] S34, repeating steps S32 and S33 until the lower-level cascade platform completes reporting the search information;

[0033] S35. While the search information is being reported to the lower-level cascade platform, a distribution thread for processing the search pending tasks is also running at the same time: including

[0034] (1) First, the retrieval information is processed, and the organization and equipment are respectively put into the organization queue and equipment queue to be stored;

[0035] (2) First, use the single-organization warehousing thread to sequentially process all organization information in the queue of organizations to be warehousing;

[0036] (3) After all the organizations have been put into storage, multi-threaded processing of the equipment information in the equipment queue to be put into storage begins;

[0037] In the whole process, except for the single-thread operation of the organization information entering the warehouse, after the organization is entered into the warehouse, the multi-thread operation of the equipment entering the warehouse begins;

[0038] Different thread pools are intelligently allocated according to device types, and the number of threads in each thread pool is dynamically optimized and adjusted based on the number of devices and the real-time performance of the system.

[0039] Furthermore, during the second retrieval of S4, an algorithm is used to compare the currently reported information with the past recorded information of Redis. The changed or first reported information is stored in the database and recorded in Redis. The unchanged information is discarded, and the consistency of the Redis and database device information is checked regularly.

[0040] Furthermore, the optimization process of retrieving the shared device information includes the following steps:

[0041] The optimization process of retrieving shared device information for the second time includes step S41 and / or step S42, wherein

[0042] Step S41 is as follows:

[0043] S411: After the national standard cascade upper service is successfully started, the search signaling is sent for the first time, and the lower-level cascade platform reports the search response.

[0044] S412: Process the first search response and store the information in the database. After the storage is completed, the information is recorded in the device information hash table of the Redis service.

[0045] S413: The national standard cascade upper service sends a search signaling for the second time, and the lower cascade platform reports a search response.

[0046] S414: After receiving the response information of the retrieval device, compare the current report with the previous report information recorded in Redis according to the device ID to see whether it has changed or is the first report;

[0047] S415: If the information has changed or is reported for the first time, the information is stored in the database, and after the storage is completed, the information is promptly recorded in the device information hash table of the Redis service; if the information has not changed, the message is directly discarded and the next message is processed.

[0048] Step S42 is as follows:

[0049] S421: After the second retrieval is completed, the consistency of the cascade device information recorded in Redis and the cascade device information recorded in the database is checked regularly. The checking period can be flexibly adjusted according to the real-time load of the system and the importance of the data.

[0050] S422: During verification, the device data in the database shall prevail. If data inconsistency is found, the information in Redis shall be accurately adjusted in a timely manner based on the accurate device data in the database to ensure the accuracy and completeness of the data.

[0051] Further, the Kafka search information reporting process of the national standard cascade upper service includes step S51 and step S52;

[0052] Step S51 is as follows:

[0053] S511: The national standard cascade upper-level service was started successfully.

[0054] S512: The lower-level cascade platform actively produces and reports device retrieval information, sets the number of partitions of the Kafka message queue according to the number of lower-level devices and data flow, sends the device retrieval information to the Kafka message queue, and stores the messages in each partition in chronological order.

[0055] S513: The national standard cascade upper service retrieves message data from the consumer device in Kafka in the order of offset. If the upper service restarts abnormally, it continues to consume the data in the Kafka message queue from the offset position where it was interrupted last time, relying on the sequential consumption characteristics of Kafka.

[0056] Step S52 is as follows:

[0057] S521: The national standard cascade upper service judges the received retrieval device response information; compares the current report with the past report information recorded in Redis according to the device ID to see if there is a change; or if it is the first report;

[0058] S522: If the information has changed or is reported for the first time, the information will be stored in the database. After the database storage is completed, the information will be recorded in the device information hash table of the Redis service; if the information has not changed, the message will be discarded directly and the next message will be processed to ensure the timeliness, continuity and integrity of data synchronization between platforms.

[0059] Furthermore, the steps described above work in coordination with each other. The information recorded in S1 provides key judgment basis for service restart and recovery in S2, provides basic data query source for device retrieval synchronization in S3 and S4, and provides device information reference for change notification in S5. After the link status is restored in S2, it interacts with the lower-level services to ensure normal device operation and data transmission, and continuously updates information with Redis to ensure the overall operation of the system. The efficient storage of S3 provides fast data support for subsequent device information management and retrieval. The information processing and verification of S4 ensure the accuracy and consistency of device information, and provide reliable data for other processes. The information reporting and processing of S5 ensures timely synchronization of data between platforms, provides guarantee for the collaboration of the entire system, and jointly realizes the comprehensive improvement of national standard superior services in disaster recovery, device information management and collaboration between platforms.

[0060] The present invention adopts the above technical solution, which has at least the following beneficial effects:

[0061] 1. In terms of service restart and recovery, unlike the old technical solution that relies on cache to record link status and needs to wait for three minutes for the subordinate to timeout registration before restoring the normal link status, the present invention uses Redis to record and read link status information. When the national standard cascade upper service encounters an abnormal restart, it can quickly make multi-dimensional status judgments based on the information stored in Redis, and intelligently decide to restore the cascade link status or wait for the subordinate to register online based on the judgment results, and establish a continuous and stable information update mechanism after successfully restoring the link. This method greatly shortens the service recovery time, ensures the real-time and accurate reflection of the service status, effectively reduces the impact of abnormal restart on the overall business, significantly improves the business interruption situation, has a more efficient and stable disaster recovery method, and ensures that the platform can quickly restore the normal link status after restart.

[0062] 2. For the first retrieval of shared device information, the old technology uses a single-threaded one-by-one warehousing method to perform the first full retrieval and warehousing, which consumes a lot of time and server resources. The present invention implements an optimized multi-stage device information warehousing process, covering accurate classification and processing of information, efficient queue management of organization and device information, and single-threaded and multi-threaded collaborative warehousing operations. Through reasonable task allocation and thread collaboration, especially after the single-threaded warehousing of organization information is completed, different thread pools are intelligently allocated according to the device type for multi-threaded device warehousing, and the number of threads in each thread pool is dynamically optimized and adjusted according to the number of devices and the real-time performance of the system, which significantly improves the efficiency of device information warehousing, greatly shortens the time spent on the first retrieval and warehousing, makes the first retrieval and warehousing more efficient and fast, and effectively saves time and server resources.

[0063] 3. In the task of secondary retrieval of shared device information, the old technical solution performs full warehousing and updates regardless of whether the device resource information has changed during the secondary full retrieval, resulting in a waste of resources. The present invention uses a comparison algorithm to distinguish the difference between the information reported this time and the previously recorded information in Redis, and implements a differentiated processing strategy based on the comparison results. Only the changed or first reported information is entered into the database and recorded in Redis, and the unchanged information is discarded. A timed verification mechanism is established to ensure that the device information in Redis is highly consistent with that in the database. This method avoids repeated processing of unchanged information, effectively improves the efficiency of secondary retrieval, does not occupy database resources by repeated entry, makes secondary retrieval and entry more efficient and fast, and at the same time ensures the accuracy and consistency of the data.

[0064] 4. In terms of the process of synchronously retrieving resource information from the lower level to the upper level, compared with the old technology that reports the lower level retrieval change notification through SIP messages, which is prone to packet loss and missing synchronization information due to network fluctuations or service restarts, the present invention uses Kafka components to build information reporting and sequential consumption channels, and performs accurate database operations and Redis information updates according to the reported information content. Kafka's sequential consumption characteristics ensure that even in the case of network fluctuations or abnormal service restarts, the upper level service can continue to accurately consume the data in the Kafka message queue from the offset position of the last interruption, ensuring the timeliness, continuity and integrity of data synchronization between platforms, and successfully solving the problem of frequent and time-consuming searches by the upper level for synchronization when the lower level shared resources are changed, so that important resource sharing is not affected by network fluctuations or abnormal service restarts, greatly improving the data reliability and stability of the entire national standard cascade service system.

[0065] In summary, the present invention comprehensively improves the overall performance, disaster recovery capability and data accuracy of the national standard cascade service, effectively meets the requirements of modern video surveillance systems for efficient, stable, reliable operation and accurate resource sharing, and has significant progressive significance and broad application prospects in related technical fields. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0067] Figure 1 It is a flow chart of the rapid recovery process of the cascade platform of the present invention.

[0068] Figure 2 It is a flow chart of multi-threaded warehousing retrieval of the cascade platform of the present invention.

[0069] Figure 3 It is a flow chart of rapid secondary search of the cascade platform of the present invention.

[0070] Figure 4 This is a flowchart of the cascading platform of the present invention reporting, retrieving and warehousing through Kafka. DETAILED DESCRIPTION

[0071] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0072] Embodiment 1

[0073] See also Figure 1 This embodiment provides a method for realizing disaster recovery and rapid recovery of national standard upper-level services by using Redis to record cascade and device information. By recording and managing information and coordinating operations between various processes, the national standard cascade upper-level service can be quickly restored to normal operation in the face of various emergencies. Specifically, the following steps are included:

[0074] S1: During the operation of the national standard cascade upper-level service, a Redis storage management system for platform cascade and device information is built to classify and record key information closely related to the service operation status and device management, and establish a storage structure that facilitates fast query and accurate management. At the same time, the information in Redis is updated in a timely manner according to dynamic changes in service operation, providing basic data support for subsequent service recovery, device retrieval and information synchronization;

[0075] S2: When the national standard cascade upper-level service encounters an abnormal restart, it quickly makes a multi-dimensional status judgment based on the information stored in Redis, and intelligently decides to restore the cascade link status or wait for the lower-level registration and online based on the judgment result. After the link is successfully restored, a continuous and stable information update mechanism is established to ensure real-time and accurate reflection of the service status and reduce the impact of abnormal restart on the overall business;

[0076] S3: When performing the first retrieval of shared device information, an optimized multi-stage device information storage process is implemented, covering accurate classification and processing of information, efficient queue management of organization and device information, and single-threaded and multi-threaded collaborative storage operations, which improves the efficiency of device information storage and saves time and server resources;

[0077] S4: When performing the task of secondary retrieval of shared device information, a comparison algorithm is used to distinguish the difference between the currently reported information and the previously recorded information in Redis, and a differentiated processing strategy is implemented based on the comparison results. A timed verification mechanism is established to ensure that the device information in Redis is highly consistent with that in the database, avoiding repeated processing of unchanged information and improving the efficiency of secondary retrieval;

[0078] S5: In the process of synchronously retrieving resource information from the subordinate to the superior, the Kafka component is used to build an information reporting and sequential consumption channel, and accurate database operations and Redis information updates are performed according to the reported information content to ensure the timeliness, continuity and integrity of data synchronization between platforms, and solve the problem of information loss caused by network fluctuations or service abnormalities.

[0079] As an implementation mode, in S1 of this embodiment, the key information closely related to the service operation status and device management includes platform cascade basic information and shared device resource information, wherein the key value of the platform cascade basic information is "AS: cascade port", and the internal record includes the cascade link status, the last heartbeat time, the last registration information, the registration validity period, and the basic information of the upper and lower platforms; the shared device resource information includes the device ID, the device network status, and the information of the organization to which the device belongs; the cascade service ID, i.e., spid, is used as the primary key of the Redis hash device table, and the device ID is used as the internal key value to construct a storage structure, and the cascade link status is represented by binary coding, the heartbeat timestamp is recorded as the cascade heartbeat information, the registration time and the registration validity period are recorded, and the basic information of the upper and lower platforms is recorded for the management of the lower registration online status, so as to realize efficient storage and fast query of information; updating the cascade status information in Redis according to the heartbeat timing keep-alive means that each time the heartbeat signaling arrives, the heartbeat timestamp is immediately updated. If the heartbeat signaling is not received for multiple consecutive times, it is automatically determined that the cascade may be abnormal and the corresponding processing measures are triggered in time to ensure real-time monitoring and effective management of the cascade status.

[0080] As an implementation method, in S2 of this embodiment, in the recovery process of abnormal restart of the national standard cascade upper service, key status and condition judgments are performed based on Redis storage information, and the restoration link or waiting for registration and online is determined based on the judgment result. After the link is restored, a stable information update mechanism is established to ensure continuous and stable operation of the service, wherein the judgment basis includes determining the cascade status based on a specific status flag, comparing the information conditions with the configuration file parameters, and determining the keep-alive time period according to the set time range, and the information update mechanism is to update the cascade service status information to Redis in real time based on the heartbeat.

[0081] like Figure 1 As shown, as an implementation mode, the specific implementation mode of the cascade platform rapid recovery process in this embodiment includes at least the following steps:

[0082] S11: After the national standard cascade upper service is successfully started for the first time, when the lower level is successfully registered and launched for the first time, the cascade service is successfully linked;

[0083] S12: Record the cascade online status into Redis, and update the cascade service status information in Redis according to the heartbeat timing keep-alive mechanism;

[0084] S13: Service abnormal restart;

[0085] S14: Immediately read the cascade service status information from Redis and the cascade basic information from the database if the following conditions are met: (1) The current cascade status recorded in Redis is linked; (2) The cascade basic information conditions read from the database and the cascade basic information in Redis meet the requirements of the current cascade configuration, that is, the cascade information in Redis is consistent with the cascade configuration information in the database; (3) The heartbeat timestamp recorded in Redis is within the keep-alive time period of the cascade heartbeat; If the conditions are met, the service directly restores the link status, otherwise waits for the next registration signaling from the subordinate to register the link online;

[0086] S15. If the condition of step S14 is met, the service resumes the normal connection state, continues to process the cascaded business normally, and updates the cascaded service status information to Redis in real time according to the heartbeat.

[0087] like Figure 2 As shown, as an implementation mode, in S3, when the shared device information is first retrieved, efficient information storage is achieved through classification processing and multi-threaded operation of the subordinate reported information;

[0088] The initial retrieval process for shared device information includes the following steps:

[0089] S31, after the national standard cascade upper service is started, a search signal is sent to the lower platform;

[0090] S32, the lower-level cascade platform reports the retrieval organization information and retrieval device information in a hierarchical order;

[0091] S33, the national standard cascade upper service receives and parses the search information reported by the lower cascade platform, and then determines whether the reported information is an organization. If it is an organization, it is written into the waiting-to-enter organization queue; if it is a device, it is written into the waiting-to-enter device queue;

[0092] S34, repeating steps S32 and S33 until the lower-level cascade platform completes reporting the search information;

[0093] S35. While the search information is being reported to the lower-level cascade platform, a distribution thread for processing the search pending tasks is also running at the same time: including

[0094] (1) First, the retrieval information is processed, and the organization and equipment are respectively put into the organization queue and equipment queue to be stored;

[0095] (2) First, use the single-organization warehousing thread to sequentially process all organization information in the queue of organizations to be warehousing;

[0096] (3) After all the organizations have been put into storage, multi-threaded processing of the equipment information in the equipment queue to be put into storage begins;

[0097] In the whole process, except for the single-thread operation of the organization information entering the warehouse, after the organization is entered into the warehouse, the multi-thread operation of the equipment entering the warehouse begins;

[0098] Different thread pools are intelligently allocated according to device types, and the number of threads in each thread pool is dynamically optimized and adjusted based on the number of devices and the real-time performance of the system.

[0099] As an implementation method, this embodiment uses an algorithm to compare the currently reported information with the past recorded information of Redis during the secondary retrieval in S4, enters the changed or first reported information into the database and records it in Redis, discards the unchanged information, and periodically checks the consistency of Redis and database device information.

[0100] like Figure 3 As shown, as an implementation mode, the optimization process of secondary retrieval of shared device information in this embodiment includes the following steps:

[0101] The optimization process of retrieving shared device information for the second time includes step S41 and / or step S42, wherein

[0102] Step S41 is as follows:

[0103] S411: After the national standard cascade upper service is successfully started, the search signaling is sent for the first time, and the lower-level cascade platform reports the search response.

[0104] S412: Process the first search response and store the information in the database. After the storage is completed, the information is recorded in the device information hash table of the Redis service.

[0105] S413: The national standard cascade upper service sends a search signaling for the second time, and the lower cascade platform reports a search response.

[0106] S414: After receiving the response information of the retrieval device, compare the current report with the previous report information recorded in Redis according to the device ID to see whether it has changed or is the first report;

[0107] S415: If the information has changed or is reported for the first time, the information is stored in the database, and after the storage is completed, the information is promptly recorded in the device information hash table of the Redis service; if the information has not changed, the message is directly discarded and the next message is processed.

[0108] Step S42 is as follows:

[0109] S421: After the second retrieval is completed, the consistency of the cascade device information recorded in Redis and the cascade device information recorded in the database is checked regularly. The checking period can be flexibly adjusted according to the real-time load of the system and the importance of the data.

[0110] S422: During verification, the device data in the database shall prevail. If data inconsistency is found, the information in Redis shall be accurately adjusted in a timely manner based on the accurate device data in the database to ensure the accuracy and completeness of the data.

[0111] like Figure 4 As shown, as an implementation mode, the Kafka search information reporting process of the national standard cascade upper service in this embodiment includes step S51 and step S52;

[0112] Step S51 is as follows:

[0113] S511: The national standard cascade upper-level service was started successfully.

[0114] S512: The lower-level cascade platform actively produces and reports device retrieval information, sets the number of partitions of the Kafka message queue according to the number of lower-level devices and data flow, sends the device retrieval information to the Kafka message queue, and stores the messages in each partition in chronological order.

[0115] S513: The national standard cascade upper service retrieves message data from the consumer device in Kafka in the order of offset. If the upper service restarts abnormally, it continues to consume the data in the Kafka message queue from the offset position where it was interrupted last time, relying on the sequential consumption characteristics of Kafka.

[0116] Step S52 is as follows:

[0117] S521: The national standard cascade upper service judges the received retrieval device response information; compares the current report with the past report information recorded in Redis according to the device ID to see if there is a change; or if it is the first report;

[0118] S522: If the information has changed or is reported for the first time, the information will be stored in the database. After the database storage is completed, the information will be recorded in the device information hash table of the Redis service; if the information has not changed, the message will be discarded directly and the next message will be processed to ensure the timeliness, continuity and integrity of data synchronization between platforms.

[0119] As an implementation method, the steps described in this embodiment work together. The information recorded in S1 provides key judgment basis for service restart and recovery of S2, provides basic data query source for device retrieval synchronization of S3 and S4, and provides device information reference for change notification of S5; after the link status is restored in S2, it interacts with the lower-level service to ensure normal device operation and data transmission, and continuously updates information with Redis to ensure the overall operation of the system; S3's efficient warehousing provides fast data support for subsequent device information management and retrieval; S4's information processing and verification ensure the accuracy and consistency of device information, and provide reliable data for other processes; S5's information reporting and processing ensures timely synchronization of data between platforms, provides guarantee for the collaboration of the entire system, and jointly realizes the comprehensive improvement of national standard superior services in disaster recovery, device information management and collaboration between platforms.

[0120] The present invention has at least the following innovative highlights:

[0121] 1. Efficient service disaster recovery and rapid recovery based on Redis;

[0122] Innovatively, the online status of the link of the superior cascade service is backed up and stored in Redis, and the superior restart registration and online logic is improved. With the storage advantages of Redis and the optimized logic, when the service encounters an abnormal restart, it can break through the traditional limitations and quickly restore the normal link status of the superior in just 5 seconds, greatly shortening the service interruption time, effectively ensuring the continuity of the business, and significantly improving the disaster recovery capability and system stability of the entire national standard cascade service, ensuring that the business can resume normal operation in a short time, avoiding business interruptions and adverse effects caused by restart.

[0123] Second, multi-threading helps to speed up the first search and storage;

[0124] In the upper-level retrieval and warehousing link, the traditional single-threaded warehousing method is abandoned, and multi-threaded operation is introduced to realize the key innovative measure of equipment warehousing. Through reasonable planning of thread allocation, intelligent configuration of different thread pools according to device type, and dynamic optimization of the number of threads in each thread pool in combination with the real-time performance of the system, the speed of the first retrieval and warehousing is greatly improved. For example, in the retrieval and warehousing scenario facing up to 10,000 devices, compared with the traditional method, the adoption of the solution of the present invention significantly speeds up the warehousing process, effectively saves a lot of time and server resources, greatly improves the efficiency of the first retrieval, and lays a good data foundation for subsequent equipment information management and related business operations.

[0125] 3. Redis national standard cascade upper service storage structure optimizes the secondary retrieval process;

[0126] A unique storage format is designed with the cascaded service ID, spid, as the primary key of the Redis hash device table and the device ID as the internal key value, which is used to accurately and efficiently back up the device information shared by the lower-level platform to this platform and store it in Redis (collaborative database). This innovative storage structure has brought significant optimization to the secondary retrieval process, especially when the lower-level shared device information changes and the upper-level platform conducts a secondary full-volume retrieval. With this storage structure and the corresponding data processing mechanism, the system can accurately identify the information that has been stored and unchanged, avoid repeated storage, and only process the information with incremental changes, thereby greatly shortening the time spent on secondary retrieval, saving the time spent on repeated storage processes, improving the efficiency of secondary retrieval and the overall accuracy of device information management, and ensuring that the processing of device information is more efficient and accurate.

[0127] 4. Kafka national standard cascading upper-level services ensure the integrity and timeliness of resource information synchronization;

[0128] The method of synchronously retrieving resource information from subordinates to superiors was creatively transferred to the Kafka component, and a reporting method adapted to it was constructed. Through Kafka's powerful sequential consumption characteristics, when the subordinate shared device information is reported for change, it can effectively avoid the problem of missing change information that was easy to occur in the past, ensuring that the superior platform can receive all change notifications in a comprehensive and timely manner, and achieve more complete and timely updates of shared device resource information. This method ensures the timeliness, continuity and integrity of data synchronization between platforms, making the entire system more reliable and efficient in resource information sharing, effectively improving the overall efficiency of resource management, and meeting the strict requirements of modern video surveillance systems for accurate resource sharing.

[0129] To sum up, the technical solution provided in this embodiment has innovative highlights, which have comprehensively and deeply optimized and upgraded the national standard cascade service from multiple core dimensions such as service disaster recovery, retrieval and warehousing efficiency, secondary retrieval accuracy, and resource information synchronization. The various highlights cooperate with each other and work together to enhance efficiency, which comprehensively and significantly improves the overall performance, disaster recovery capability and data accuracy of the national standard cascade service, making it show outstanding advantages in the same field and better adapt to the high standards of modern video surveillance systems for efficient, stable, reliable operation and accurate resource sharing.

[0130] Embodiment 2

[0131] Note: No new drawings are provided in the second embodiment. The second embodiment can refer to the relevant drawings provided in the first embodiment.

[0132] This embodiment provides a specific implementation method of a method for realizing national standard upper-level service disaster recovery and rapid recovery by using Redis to record cascade and device information.

[0133] 1. Overall system architecture

[0134] The system involved in the present invention mainly includes the national standard cascade upper server, the lower cascade platform and the related database and Redis storage system, and integrates the Kafka component for information reporting and consumption. Before starting the system, the following basic configurations need to be completed:

[0135] Configure Redis connection parameters to ensure that the national standard cascade upper service can establish a stable connection with Redis. Set an appropriate memory allocation strategy to meet the storage requirements of platform cascade and device information. For example, allocate enough memory space for Redis based on the estimated number of cascades and devices, and enable the persistence function to prevent data loss.

[0136] For the database, design and create relevant data table structures for storing platform cascade information and device resource information, ensuring that the data fields can fully record key data such as platform cascade basic information (cascade link status, cascade heartbeat information, and subordinate registration and online status) and shared device resource information (device ID, device network status, and device organization information).

[0137] Configure the Kafka cluster and set key parameters such as the number of partitions of the Kafka message queue according to the number of downstream devices and data traffic estimates. For example, if there are an estimated 5,000 downstream devices and the data traffic is large, the number of partitions can be set to 5 (based on the rule of dividing the number of downstream devices by 1,000 and rounding up), and ensure that each partition has enough disk space to store message data.

[0138] 2. Specific implementation process of each step

[0139] 1. S1: Building a Redis storage management system.

[0140] When the national standard cascade upper service is running, start the Redis storage management module. The cascade service ID, spid, is used as the primary key of the Redis hash device table, and the device ID is used as the internal key value to build the storage structure. For example, when a cascade service ID is "002101001732069540" and a device information with a device ID of "Device_123" is received, a record item with "Port_001" as the hash table name and "Device_123" as the key is created in Redis.

[0141] The key value of the platform cascade basic information is "AS: cascade port". The internal record includes the cascade link status, the last heartbeat time, the last registration information, the registration validity period, and the basic information of the upper and lower platforms. The cascade link status is represented by binary code. For example, "1" indicates a normal connection, "0" indicates a disconnected connection, etc. Whenever the cascade link status changes, the corresponding binary code value is updated in a timely manner.

[0142] Record the heartbeat timestamp as the cascade heartbeat information. Set up a heartbeat detection thread to receive heartbeat signals from the lower level every 60 seconds (default for national standards) and update the heartbeat timestamp after receiving the heartbeat signal. If the heartbeat signal is not received for three consecutive times (configurable), it will automatically determine that the cascade may be abnormal and trigger the corresponding alarm and processing mechanism.

[0143] The registration time and registration validity period are recorded for the management of the subordinate registration and online status. When a subordinate cascade platform is registered and online, the current time is recorded as the registration time, and the validity period is managed according to the preset registration validity period (such as 2 hours). During the validity period, the subordinate platform is regarded as a normal registration status. If the renewal operation is not performed after the validity period, it is marked as a registration expired status.

[0144] Record other basic information of the cascaded upper and lower platforms, such as the SIP server code (upper platform code), lower platform code, and registered transport layer protocol. If the service is restarted, the basic information stored in Redis and the basic information in the database can be quickly compared. If the comparison is successful, the connection will be restored immediately.

[0145] Update the information in Redis in a timely manner according to the dynamic changes in service operation. For example, when a new device is connected or the device network status changes, update the record of shared device resource information in Redis in a timely manner to ensure the real-time and accuracy of the information, and provide reliable basic data support for subsequent service recovery, device retrieval and information synchronization.

[0146] (ii) S2: National standard cascade upper service abnormal restart recovery process;

[0147] When the national standard cascade upper service encounters an abnormal restart, during the startup process, abnormal restart recovery is started. First, the cascade service status information is read from Redis. For example, the cascade service status information in the hash table corresponding to the specific "AS: cascade port" is read to obtain the cascade status, information conditions, and the last heartbeat timestamp and other data.

[0148] Perform multi-dimensional status judgment. Determine whether the current cascade status is linked by reading the previously stored cascade status code. If the read status code is "1", it means that the current cascade is in the linked state.

[0149] Information condition judgment. Compare the cascade information read from Redis with the cascade configuration parameters read from the database. For example, compare whether the lower-level registration and online status meets the current configuration requirements, check the integrity and accuracy of the upper and lower cascade platform information, etc. If the SIP server code (upper-level platform code), lower-level platform code, registration transport layer protocol and other information required in the configuration file are inconsistent with the predefined parameters, it is determined that the information condition is not met.

[0150] Keep-alive time period judgment. Calculate based on the preset keep-alive time period (such as 5 minutes) and the last heartbeat timestamp. If the difference between the current time and the last heartbeat timestamp is less than the keep-alive time period, it is determined to be within the keep-alive time period.

[0151] If the above three conditions (the current cascade status is linked, the information conditions meet the requirements of the cascade configuration, and it is in the keep-alive time period) are met, the service directly restores the link status. After the link is restored, start the information update thread, and update the cascade service status information to Redis in real time based on the heartbeat. For example, update the cascade link status, heartbeat timestamp and other information every 60 seconds (consistent with the heartbeat cycle) to ensure that the information in Redis is synchronized with the actual service status. If any of the conditions is not met, wait for the next registration signaling from the lower level to register the link online. During the waiting process, continue to listen to the registration signaling port. Once the registration signaling is received, re-perform the above judgment process until the link is successfully restored or the preset waiting timeout (such as 3 minutes) is reached.

[0152] (III) S3: The process of first retrieving shared device information into the database;

[0153] After the national standard cascade upper service is started, a search signal is sent to the lower platform. The signal content includes instructions for retrieving device information and related search scopes and conditions (such as retrieving devices under a specific organization or a specific type of device, etc.).

[0154] After receiving the search signaling, the lower-level cascade platform reports the search organization information and the search device information in order and in layers. For example, the organizational structure information is reported first, including the organization name, organizational hierarchy, etc., and then the device information under the organization is reported. Each device information contains detailed content such as device ID, device network status, and device organization information.

[0155] The national standard cascade upper service receives and parses the search information reported by the lower cascade platform. Start the parsing thread, parse the received information line by line, and determine whether the reported information is an organization. If the information contains organizational characteristic fields such as organization name and organizational level, it is determined to be organizational information and written into the organization queue to be stored; if the information contains device characteristic fields such as device ID, it is determined to be device information and written into the device queue to be stored.

[0156] Repeat the above steps S2 and S3 until the lower-level cascade platform completes reporting the search information. When the lower-level cascade platform reports the search information, the distribution thread for processing the search pending tasks is started.

[0157] The distribution thread first pre-processes the received retrieval information and puts the organization and the device into the corresponding organization queue and device queue to be stored. For example, using the queue data structure, the organization information is added to the end of the organization queue and the device information is added to the end of the device queue.

[0158] Start the single-organization warehousing thread and process all the organization information in the queue of organizations to be stored in sequence. The single-organization warehousing thread reads the organization information from the head of the queue and inserts it into the organization information table of the database according to the database table structure requirements. For example, insert the organization name, organization level and other information into the corresponding fields of the organization information table. During the insertion process, perform data integrity and legality checks, such as checking whether the organization name is empty and whether the organization level complies with the preset rules. If data anomalies are found, record the error log and perform corresponding error handling (such as notifying the administrator or performing data repair operations).

[0159] After synchronously waiting for all organizations to be stored in the warehouse (determined by the return result of the database insertion operation or a specific completion mark), multi-threaded processing of the device information in the queue of devices to be stored in the warehouse begins. Different thread pools are intelligently allocated according to the device type. For example, one thread pool is allocated for network camera devices and another thread pool is allocated for storage devices. The number of threads in each thread pool is dynamically optimized and adjusted according to the number of devices and the real-time performance of the system. If the current number of devices is large and the system performance allows, the number of threads in the thread pool can be increased; if the system resources are tight, the number of threads can be appropriately reduced to avoid system overload. Multi-threaded parallel processing of device information storage, each thread obtains the device information from the device queue and inserts it into the device information table of the database, and updates the device information record in Redis at the same time to ensure that the device information in the database and Redis are synchronized.

[0160] (iv) S4: Secondary retrieval of shared device information process;

[0161] After the national standard cascade upper service is successfully started, the first search signaling is sent, and the lower cascade platform reports the search response. Process the first search response and store the information in the database. After the storage is completed, the information is recorded in the device information hash table of the Redis service. The operation process is similar to the first search storage process in S3.

[0162] The national standard cascade upper service sends the search signaling for the second time, and the lower cascade platform reports the search response. After receiving the response information of the search device, the comparison module is started to compare the current report with the past report information recorded in Redis according to the device ID to determine whether it has changed or is the first report. For example, the CRC32 checksum algorithm is used (other efficient algorithms can be selected according to actual conditions) to calculate the hash value of the current report information and the past record information in Redis. If the hash values ​​are the same, it is determined that the information has not changed; if the hash values ​​are different, it is determined that the information has changed or is the first report.

[0163] If the information has changed or is reported for the first time, the information will be stored in the database, and after the storage is completed, the information will be recorded in the Redis device information hash table in a timely manner. During the storage process, the database transaction processing principles are followed to ensure the consistency and integrity of the data. If the information has not changed, the message is directly discarded and the next message is processed. In this way, repeated processing of unchanged information is avoided, the efficiency of secondary retrieval is effectively improved, and database resources are saved.

[0164] After the second retrieval is completed, the timing verification module is started to start the timing verification of the consistency between the cascade device information recorded in Redis and the cascade device information recorded in the database. The verification period is initially set to 30 minutes, which can be flexibly adjusted according to the real-time load of the system and the importance of the data. For example, when the system load is light and the data importance is high, the verification period can be shortened to 15 minutes; when the system load is heavy, the verification period can be appropriately extended to 1 hour. The device data in the database shall prevail during the verification. If the data is inconsistent, the information in Redis shall be accurately adjusted in time according to the accurate device data in the database to ensure the accuracy and completeness of the data. By comparing the device information records in the database and Redis, the fields are compared one by one. If a difference is found, such as the device network status is "online" in the database and "offline" in Redis, the information in the database shall prevail and the device network status information in Redis shall be updated.

[0165] (V) S5: Kafka national standard cascade upper service retrieval information reporting process;

[0166] After the national standard cascade upper service is successfully started, it enters the Kafka information processing module. The lower-level cascade platform actively produces and reports device retrieval information, sets the number of partitions of the Kafka message queue according to the number of lower-level devices and data flow, and sends the device retrieval information to the Kafka message queue. The messages in each partition are stored in chronological order. For example, when a lower-level cascade platform reports the retrieval information of a device, the information is sent to the corresponding partition according to the previously configured partition rules. During the sending process, timestamp information is added to ensure that the messages are arranged in chronological order within the partition.

[0167] The national standard cascade upper service retrieves message data from the consumer device in Kafka in the order of offset. Start the Kafka consumer thread and read the message data from the offset position of the last consumption. If the upper service restarts abnormally, it continues to consume the data in the Kafka message queue from the offset position of the last interruption due to the sequential consumption characteristics of Kafka. For example, if the last message consumed was offset 100, after restarting, the consumer thread will automatically continue to consume from the message with offset 101 to ensure that data is not lost and the consumption order is correct.

[0168] The national standard cascade upper service judges the received retrieval device response information. According to the device ID, the current report is compared with the previous report information recorded in Redis to see if there is a change; or if it is the first report, the judgment logic is similar to the secondary retrieval information judgment in S4. If the information has changed or is reported for the first time, the information will be stored in the database, and after the database storage is completed, the information will be recorded in the device information hash table of the Redis service; if the information has not changed, the message will be discarded directly and the next message will be processed to ensure the timeliness, continuity and integrity of data synchronization between platforms. Throughout the process, Kafka's high reliability and sequential consumption characteristics effectively solve the problem of information loss caused by network fluctuations or service anomalies, ensuring that the lower-level shared resource change notifications can be accurately received and processed by the upper-level service.

[0169] 3. Collaborative working mechanism of each step;

[0170] During the entire system operation, the Redis storage management system built in S1 provides core data support for other steps. For example, the abnormal restart recovery process in S2 depends on the cascade status information, heartbeat information, and registration and online information recorded by S1. By reading this information, key status and condition judgments are made to determine the strategy of restoring the link or waiting for registration and online.

[0171] The equipment retrieval synchronization operations of S3 and S4 are based on the equipment information stored in S1 as the basic data query source. During the first retrieval (S3), the equipment information reported by the subordinate can be quickly located and classified according to the organizational information in S1, thereby improving the efficiency of warehousing; during the second retrieval (S4), by comparing the past equipment information recorded in S1 with the current reported information, differentiated processing is achieved to avoid duplication of work.

[0172] In the Kafka retrieval information reporting process of S5, the device information in S1 will also be referenced for information comparison and processing. At the same time, the device information change notification reported in S5 will promptly update the Redis storage information in S1 to ensure the real-time and consistency of data.

[0173] After the link status is restored in S2, normal interaction operations are performed with the lower-level services, such as receiving device information reported by the lower-level services, sending control instructions, etc., to ensure normal device operation and data transmission. In the interaction process, information is continuously exchanged with Redis, and the information in Redis is updated in a timely manner according to changes in device status. The continuous update of information with Redis ensures the stability and reliability of the overall operation of the system.

[0174] The efficient storage of S3 provides fast data support for subsequent equipment information management and retrieval (secondary retrieval of S4). For example, during the secondary retrieval, since the first retrieval and storage were completed efficiently, relatively complete and accurate equipment information has been stored in the database, so the secondary retrieval can quickly compare and process information, improving the overall retrieval efficiency.

[0175] The information processing and verification of S4 ensures the accuracy and consistency of device information and provides a reliable data basis for other processes. For example, accurate device information helps the abnormal restart recovery process in S2 to make correct decisions, and also provides a correct data basis for information storage in S3 and information reporting in S5, avoiding system failures or information synchronization errors caused by data errors.

[0176] S5's information reporting and processing ensures timely synchronization of data between platforms, providing a guarantee for the collaboration of the entire system. For example, when the information of the lower-level equipment changes, it is reported to the upper-level service in a timely manner through Kafka. The upper-level service can respond quickly, update the information in the database and Redis, and notify other related modules to perform corresponding processing, thereby achieving efficient collaboration of the entire national standard cascade service system and jointly achieving comprehensive improvement of national standard upper-level services in disaster recovery, equipment information management and collaboration between platforms.

[0177] Through the above specific implementation methods, the present invention can effectively overcome many problems existing in the existing national standard cascade service, realize efficient, stable and reliable service operation and resource sharing, and has high feasibility and practicality in actual application scenarios.

[0178] Although the embodiments of the present invention have been shown and described above, it will be appreciated that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, substitute and vary the above embodiments within the scope of the present invention.

Claims

1. Using Redis to record cascade and device information to implement a national standard upper-level service disaster recovery and rapid recovery method, which is characterized by: Through the recording and management of information and the collaborative operation between various processes, the national standard cascade upper-level service can quickly resume normal operation in the face of various emergencies. The specific steps include: S1: During the operation of the national standard cascade upper-level service, a Redis storage management system for platform cascade and device information is built to classify and record key information closely related to the service operation status and device management, and establish a storage structure that facilitates fast query and accurate management. At the same time, the information in Redis is updated in a timely manner according to dynamic changes in service operation, providing basic data support for subsequent service recovery, device retrieval and information synchronization; S2: When the national standard cascade upper-level service encounters an abnormal restart, it quickly makes a multi-dimensional status judgment based on the information stored in Redis, and intelligently decides to restore the cascade link status or wait for the lower-level registration and online based on the judgment result. After the link is successfully restored, a continuous and stable information update mechanism is established to ensure real-time and accurate reflection of the service status and reduce the impact of abnormal restart on the overall business; S3: When performing the first retrieval of shared device information, an optimized multi-stage device information storage process is implemented, covering accurate classification and processing of information, efficient queue management of organization and device information, and single-threaded and multi-threaded collaborative storage operations, which improves the efficiency of device information storage and saves time and server resources; S4: When performing the task of secondary retrieval of shared device information, a comparison algorithm is used to distinguish the difference between the currently reported information and the previously recorded information in Redis, and a differentiated processing strategy is implemented based on the comparison results. A timed verification mechanism is established to ensure that the device information in Redis is consistent with that in the database, avoiding repeated processing of unchanged information and improving the efficiency of secondary retrieval; S5: In the process of synchronously retrieving resource information from the subordinate to the superior, the Kafka component is used to build an information reporting and sequential consumption channel, and accurate database operations and Redis information updates are performed according to the reported information content to ensure the timeliness, continuity and integrity of data synchronization between platforms, and solve the problem of information loss caused by network fluctuations or service abnormalities.

2. The method according to claim 1, characterized in that: In S1, the key information closely related to the service operation status and device management includes platform cascade basic information and shared device resource information, wherein the key value of the platform cascade basic information is "AS: cascade port", the internal record includes the cascade link status, the last heartbeat time, the last registration information, the registration validity period, the upper and lower platform basic information, and the shared device resource information includes the device ID, the device network status, and the device organization information; the cascade service ID, i.e., spid, is used as the primary key of the Redis hash device table, and the device ID is used as the internal key value to construct a storage structure, and the cascade link status is represented by binary coding, the heartbeat timestamp is recorded as the cascade heartbeat information, the registration time and the registration validity period are recorded, and the upper and lower platform basic information is recorded for the lower registration online status management, so as to achieve efficient storage and fast query of information; updating the cascade status information in Redis according to the heartbeat timing keep-alive means that each time the heartbeat signaling arrives, the heartbeat timestamp is immediately updated. If the heartbeat signaling is not received for multiple consecutive times, it is automatically determined that the cascade may be abnormal and the corresponding processing measures are triggered in time to ensure real-time monitoring and effective management of the cascade status.

3. The method according to claim 2, characterized in that In S2, in the recovery process of abnormal restart of the national standard cascade upper service, key status and condition judgments are performed based on Redis storage information, and the restoration of the link or waiting for registration and online is determined based on the judgment results. After the link is restored, a stable information update mechanism is established to ensure the continuous and stable operation of the service. The judgment basis includes judging the cascade status with a specific status flag, comparing the information conditions with the configuration file parameters, and determining the keep-alive time period according to the set time range. The information update mechanism is to update the cascade service status information to Redis in real time based on the heartbeat.

4. The method according to claim 3, characterized in that The specific implementation of the cascading platform rapid recovery process includes at least the following steps: S11: After the national standard cascade upper service is successfully started for the first time, when the lower level is successfully registered and launched for the first time, the cascade service is successfully linked; S12: Record the cascade online status into Redis, and update the cascade service status information in Redis according to the heartbeat timing keep-alive mechanism; S13: Service abnormal restart; S14: When the service is restarted abnormally, the cascade service status information is immediately read from Redis and the cascade basic information is read from the database. If the following conditions are met: (1) The current cascade status recorded in Redis is linked; (2) The cascade basic information conditions read from the database and the cascade basic information in Redis meet the requirements of the current cascade configuration, that is, the cascade information in Redis is consistent with the cascade configuration information in the database; (3) The heartbeat timestamp recorded in Redis is in the keep-alive time period of the cascade heartbeat; If the conditions are met, the service directly restores the link status, otherwise waits for the next registration signaling from the subordinate to register the link online; S15. If the condition of step S14 is met, the service resumes the normal connection state, continues to process the cascaded business normally, and updates the cascaded service status information to Redis in real time according to the heartbeat.

5. The method according to claim 1, characterized in that In S3, when retrieving shared device information for the first time, efficient information storage is achieved through classification processing and multi-threaded operation of subordinate reported information; The initial retrieval process for shared device information includes the following steps: S31, after the national standard cascade upper service is started, a search signal is sent to the lower platform; S32, the lower-level cascade platform reports the retrieval organization information and retrieval device information in a hierarchical order; S33, the national standard cascade upper service receives and parses the search information reported by the lower cascade platform, and then determines whether the reported information is an organization. If it is an organization, it is written into the waiting-to-enter organization queue; if it is a device, it is written into the waiting-to-enter device queue; S34, repeating steps S32 and S33 until the lower-level cascade platform completes reporting the search information; S35. While the search information is being reported to the lower-level cascade platform, a distribution thread for processing the search pending tasks is also running at the same time: including (1) First, the retrieval information is processed, and the organization and equipment are respectively put into the organization queue and equipment queue to be stored; (2) First, use the single-organization warehousing thread to sequentially process all organization information in the queue of organizations to be warehousing; (3) After all the organizations have been put into storage, multi-threaded processing of the equipment information in the equipment queue to be put into storage begins; In the whole process, except for the single-thread operation of the organization information entering the warehouse, after the organization is entered into the warehouse, the multi-thread operation of the equipment entering the warehouse begins; Different thread pools are intelligently allocated according to device types, and the number of threads in each thread pool is dynamically optimized and adjusted based on the number of devices and the real-time performance of the system.

6. The method according to claim 1, characterized in that: During the second retrieval of S4, an algorithm is used to compare the currently reported information with the past recorded information of Redis. The changed or first reported information is stored in the database and recorded in Redis. The unchanged information is discarded, and the consistency of the Redis and database device information is checked regularly.

7. The method according to claim 6, characterized in that: The optimization process of secondary retrieval of shared device information includes the following steps: The optimization process of retrieving shared device information for the second time includes step S41 and / or step S42, wherein Step S41 is as follows: S411: After the national standard cascade upper service is successfully started, the search signaling is sent for the first time, and the lower cascade platform reports the search response; S412: Process the first search response and store the information in the database. After the storage is completed, the information is recorded in the device information hash table of the Redis service; S413: The national standard cascade upper service sends a search signaling for the second time, and the lower cascade platform reports the search response; S414: After receiving the response information of the retrieval device, compare the current report with the previous report information recorded in Redis according to the device ID to see whether it has changed or is the first report; S415: If the information has changed or is reported for the first time, the information is stored in the database, and after the storage is completed, the information is promptly recorded in the device information hash table of the Redis service; if the information has not changed, the message is directly discarded and the next message is processed; Step S42 is as follows: S421: After the second retrieval is completed, the consistency of the cascade device information recorded in Redis and the cascade device information recorded in the database is checked regularly. The checking period can be flexibly adjusted according to the real-time load of the system and the importance of the data. S422: During verification, the device data in the database shall prevail. If data inconsistency is found, the information in Redis shall be accurately adjusted in a timely manner based on the accurate device data in the database to ensure the accuracy and completeness of the data.

8. The method according to claim 7, characterized in that: The Kafka retrieval information reporting process of the national standard cascade upper service includes steps S51 and S52; Step S51 is as follows: S511: The national standard cascade upper service is started successfully; S512: The lower-level cascade platform actively produces and reports device retrieval information, sets the number of partitions of the Kafka message queue according to the number of lower-level devices and data traffic, sends the device retrieval information to the Kafka message queue, and stores the messages in each partition in chronological order; S513: The national standard cascade upper service retrieves message data from the consumer device in Kafka in the order of offset. If the upper service restarts abnormally, it continues to consume the data in the Kafka message queue from the offset position where it was interrupted last time, relying on the sequential consumption characteristics of Kafka. Step S52 is as follows: S521: The national standard cascade upper service judges the received retrieval device response information; compares the current report with the past report information recorded in Redis according to the device ID to see if there is a change; or if it is the first report; S522: If the information has changed or is reported for the first time, the information will be stored in the database. After the database storage is completed, the information will be recorded in the device information hash table of the Redis service; if the information has not changed, the message will be discarded directly and the next message will be processed to ensure the timeliness, continuity and integrity of data synchronization between platforms.

9. The method according to any one of claims 1 to 8, characterized in that: The steps described above work together. The information recorded in S1 provides key judgment basis for service restart and recovery in S2, provides basic data query source for device retrieval synchronization in S3 and S4, and provides device information reference for change notification in S5. After the link status is restored in S2, it interacts with the lower-level services to ensure normal device operation and data transmission, and continuously updates information with Redis to ensure the overall operation of the system. The efficient storage of S3 provides fast data support for subsequent device information management and retrieval. The information processing and verification of S4 ensure the accuracy and consistency of device information, and provide reliable data for other processes. The information reporting and processing of S5 ensures timely synchronization of data between platforms, provides guarantee for the collaboration of the entire system, and jointly realizes the comprehensive improvement of national standard superior services in disaster recovery, device information management and collaboration between platforms.

Images