National standard cascade platform flow optimization method based on Redis storage and management

Abstract

The invention relates to the technical field of video surveillance code stream security transmission, and in particular to a national standard cascade platform flow optimization method based on Redis storage and management; the method comprises S1: after the national standard cascade upper service is successfully started, the streaming media initiates an application for a flow sending operation; S2: when the lower-level cascade platform returns a response to the cascade service that a flow sending channel is successfully created: S3: when a client needs to end real-time flow taking, a flow interruption notification is sent to Kafka through the streaming media, and after the cascade obtains the flow interruption notification, the flow taking information is read from Redis, and if the flow exists, the lower-level cascade platform is notified to interrupt the flow in time, that is, a flow interruption BYE signaling is sent, and the lower-level cascade platform ends the flow taking; S4: by comparing with tokenID information, an invalid flow taking session is terminated through regular verification; the method focuses on the optimization practice of flow taking function management between platforms, and by means of the storage and management capabilities of Redis, various challenges in the flow taking process are coped with, and the continuous development and improvement of code stream transmission technology in video surveillance systems are promoted.

Description

Technical Field

[0001] The present invention relates to the technical field of video surveillance code stream security transmission, and in particular to a national standard cascade platform flow optimization method based on Redis storage and management. The method focuses on the optimization practice of flow acquisition function management between platforms, and uses the storage and management capabilities of Redis to cope with various challenges in the flow acquisition process, thereby promoting the continuous development and improvement of code stream transmission technology in video surveillance systems. Background Art

[0002] In modern society, video surveillance technology has become an indispensable part of all fields and is widely used in many industries such as security, transportation, and industry. As a bridge connecting different levels of video surveillance equipment and systems, the cascade platform realizes the transmission and interaction of video streams between multiple platforms, and plays a key role in building a large-scale, distributed video surveillance network. With the continuous growth of video surveillance demand, the scale of device access faced by the cascade platform is also increasing, reaching hundreds of thousands or even more.

[0003] The information storage method of the traditional cascade platform is as follows: the traditional national standard cascade platform mainly relies on the temporary cache inside the cascade service to record the flow information. Under this architecture, when a device accesses the platform and initiates a flow request, the platform will store the key information related to the flow operation, such as the device identification, the start time of the flow, and the relevant parameters of the flow channel, in its own temporary cache area. For example, in a city-level security monitoring system, a large number of camera devices are connected to the cascade platform, and the flow status information of each camera (such as whether the video is being transmitted, the frame rate of the transmission, the resolution, etc.) is temporarily recorded in the cache of the platform service.

[0004] When processing the streaming service, the platform will manage and control the transmission of the video stream based on the information in the temporary cache. For example, when it is necessary to stop the streaming of a certain device, the platform will search for the corresponding streaming record in the temporary cache and then perform the interruption operation.

[0005] The prior art has at least the following problems:

[0006] 1. Inefficient information management: As the number of connected devices continues to increase, the limitations of temporary caches are gradually becoming apparent. A large number of devices frequently update streaming information, such as real-time changes in device status (such as camera steering, focal length adjustment, etc.) or streaming parameter adjustments caused by changes in the network environment. All of these require corresponding update operations in the temporary cache. However, the storage capacity and processing speed of the temporary cache are limited. Faced with such large-scale information update synchronization requirements, its retrieval and update efficiency drops sharply. This causes the platform to experience significant delays in normal business operations, such as forwarding and storage of video streams, because it needs to wait for the temporary cache information to be processed, which seriously affects the real-time and smoothness of the entire monitoring system.

[0007] 2. Service stability issues. Abnormal restarts lead to information loss. The increase in business volume has brought tremendous pressure to the cascade service, which is easy to cause uncontrollable abnormal restarts. Since the flow information is completely dependent on temporary cache storage, once the service is restarted, all data in the temporary cache will be cleared, and the previously stored flow information will no longer exist. This makes it impossible to obtain the previous flow status after the service is restored, causing users who are currently streaming to experience interruptions, seriously affecting the user experience, especially in some scenarios with high requirements for video surveillance continuity, such as security monitoring in key areas, interruptions may cause safety hazards.

[0008] 3. Invalid bitstreams cause waste of resources: When a service goes offline abnormally, if the stream extraction is not properly handled in time before the service ends, the ongoing stream extraction operations will continue to consume network resources, but because the service is abnormal, these stream extractions cannot be effectively managed. For example, a camera device was transmitting a video stream to the platform before the service went offline abnormally, but after the service went offline, the stream was still transmitted in the network, but there was no corresponding management mechanism to stop it, which resulted in additional bitstreams being unmanaged and consuming network bandwidth for a long time. This not only wastes precious network resources and reduces network transmission efficiency, but may also affect the video transmission quality of other normal stream extraction devices, resulting in a decline in the performance of the entire system.

[0009] In view of the above-mentioned defects of the existing cascade platform traffic management technology when facing large-scale device access and business volume growth, there is an urgent need for a new solution to improve the efficiency, stability and reliability of cascade platform traffic management. Summary of the invention

[0010] In view of the significant deficiencies in the existing technologies related to flow management of the current traditional national standard cascade platform, especially the defects in service exception handling and bitstream management, such as when the service is abnormally offline and restarted, the cascade service relies on the internal temporary cache to record the flow information, resulting in cache data loss, which in turn causes the users who are currently drawing the flow to experience flow interruption, seriously affecting the user experience; and the inability to effectively manage the flow when the service is abnormally offline, resulting in invalid bitstreams continuously consuming network traffic and reducing network transmission efficiency.

[0011] The present invention aims to provide a national standard cascade platform flow optimization method based on Redis storage and management, so as to overcome the problems existing in the prior art such as abnormal service offline restart leading to flow interruption affecting user experience and invalid code streams continuously consuming network traffic. In terms of stability, the inter-platform flow function can greatly reduce the impact of service anomalies on flow acquisition and ensure the continuity of user flow acquisition; in terms of flow control, the flow acquisition can be accurately managed to prevent invalid code streams from wasting bandwidth; in terms of exception handling capabilities, various emergencies can be effectively responded to, and flow acquisition services can be quickly restored, etc., with significant optimization in multiple key aspects. Ultimately, it ensures that the video surveillance system can operate efficiently and stably, continuously provide users with high-quality, smooth and uninterrupted video streaming services, and improve the overall performance of the video surveillance system and user satisfaction.

[0012] To achieve the above purpose, the technical solution adopted by the present invention is: a national standard cascade platform flow optimization method based on Redis storage and management, comprising the following steps:

[0013] S1: After the national standard cascade upper service is successfully started, the streaming media initiates an application for streaming. After receiving the request, the national standard cascade upper service records the streaming status information in Redis, and at the same time applies to the lower-level cascade platform to create a streaming channel, that is, sends an INVITE signaling;

[0014] S2: If the national standard cascade upper-level service is restarted and restored during the above process, when the lower-level cascade platform returns a response to the cascade service that successfully created the streaming channel:

[0015] S3: When the customer needs to end the real-time streaming, a streaming media will send a disconnection notification to Kafka. After the cascade receives the disconnection notification, it will read the streaming information from Redis. If the information exists, it will promptly notify the lower-level cascade platform to disconnect the streaming, that is, send a disconnection notification BYE signaling, and the lower-level cascade platform will end the streaming.

[0016] S4: By comparing with the tokenID information, the invalid streaming session is periodically verified and terminated; the tokenID key-value pair of whether the streaming media is valid is recorded in Redis regularly to verify and clear the invalid streaming, and release the invalid streaming in time.

[0017] Furthermore, in step S1, when recording the flow status information to Redis, a data integrity verification mechanism is used to ensure that the data is stored accurately, and the verification method includes data format verification and / or data length verification; AS_cascade port: Session_Map is used as the primary key of the hash table, and each flow session ID is used as a separate key value for each information to record, so as to achieve efficient reading and writing. The recorded flow status information includes one or more of the device identification, flow start time, flow channel related parameters and device network status information, so as to fully grasp the flow related situation and provide data basis for flow management and troubleshooting.

[0018] Furthermore, if the national standard cascade upper-level service is restarted and resumes service during the above process, when the lower-level cascade platform returns a response to the cascade service that the streaming channel has been successfully created:

[0019] S21: If the cascade service is not restored at this time, the flow acquisition is not started, and the flow acquisition process will be restarted later;

[0020] S22: If the cascade service has been restored at this time, the national standard cascade upper service reads the stream status information from Redis according to the session ID in the response, and then continues to record the successful application status into redis. The record is used for subsequent process monitoring and data statistics; then the lower-level cascade platform is formally notified to send the stream, that is, an ACK signal is sent; the lower-level cascade platform starts to send the video stream to the upper-level streaming media.

[0021] Furthermore, after the lower-level cascade platform receives the BYE signaling, the national standard cascade upper-level service monitors the execution of the disconnection of the lower-level cascade platform without interference, that is, the abnormal restart state of this service; if the disconnection operation is not completed within the specified time, the national standard cascade upper-level service will take further forced disconnection measures, including sending multiple disconnection instructions or directly cutting off the connection resources with the lower-level cascade platform to ensure that invalid code streams do not continue to consume network resources.

[0022] Furthermore, in the entire process of traffic acquisition and disconnection, key operation steps are recorded in detail, including the regular cleaning of invalid traffic acquisition paths to ensure the effective use of broadband traffic, signaling sending and receiving, Redis information reading and writing, and traffic acquisition operations. The log content includes operation time, operation type, involved device or session information, and operation results, so that the root cause of the problem can be quickly located when the system fails or an abnormal situation occurs, and it also provides data basis for system performance analysis and optimization.

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

[0024] 1. Enhance the stability of traffic acquisition services and user experience;

[0025] In traditional video cascade platforms, key information about streams is usually recorded in the temporary cache of the service. Once the service is restarted, in order to avoid problems due to unmanageable management, all streams are often disconnected before the service ends, which results in the forced interruption of the video stream that the user is watching, seriously affecting the user experience. Our new technology solution innovatively records all key information about streams in Redis, a reliable distributed memory database. Since Redis has data persistence, even if the national standard cascade upper service is restarted, it can continue to effectively manage the code stream based on the stream information stored in it, without forcibly disconnecting the normal stream when the service restarts. In this way, the process of users watching video streams becomes more stable, and they will not frequently encounter the trouble of video interruptions, which greatly improves the possibility of users getting a good viewing experience, allowing users to watch video content more smoothly and comfortably, and enhancing users' satisfaction and trust in the entire video cascade platform.

[0026] 2. Optimize network traffic management and resource utilization;

[0027] In the past, when the key information was recorded in the temporary cache of the service, if the service was abnormally offline, it was likely that there was no time to properly finish before the end of the service, and all the streams would be disconnected, resulting in the extra streams being unmanaged. These invalid streams would continue to consume network traffic for a long time, resulting in the unnecessary occupation of valuable network bandwidth, affecting other normal stream-taking services and the operating efficiency of the entire system. However, after adopting the new technical solution, the stream-taking information is uniformly recorded in Redis, and the disconnection notification can be continuously and uninterruptedly retrieved from Kafka. When the customer no longer needs to fetch the stream, the system can close the corresponding stream-taking channel in a timely and accurate manner based on the information in Redis and the disconnection notification transmitted by Kafka. This scientific and effective stream-taking management method enables the network traffic to be finely controlled, avoids the long-term occupation of bandwidth by invalid streams, allows the limited network bandwidth to be reasonably allocated and fully utilized, and releases more bandwidth resources for other effective stream-taking services. This not only improves the operating efficiency of the entire network, but also reduces the waste of resources caused by invalid traffic, provides strong support for the efficient and stable operation of the system from the stream-taking link, and also helps to reduce network operating costs.

[0028] 3. Improve disaster recovery capabilities and system reliability;

[0029] Compared with the relatively weak disaster recovery means of the traditional video cascade platform, the stream optimization method based on Redis storage and management of the present invention has shown significant advantages. When facing emergencies such as service failures, the traditional method relies on temporary cache to store key information, which can easily lead to out-of-control of stream management, resulting in business interruption and difficulty in rapid recovery. However, our new technology solution ensures the reliable storage of key stream information by utilizing the characteristics of Redis. When encountering various situations such as service restart and abnormal offline, it can still manage the stream business in an orderly manner and achieve rapid disaster recovery. This greatly improves the ability of the entire national standard cascade platform to deal with unexpected events, enhances the overall reliability of the system, reduces the business stagnation time caused by failures, and ensures that important stream business can continue to operate stably. Whether it is for daily video service provision or for dealing with high-concurrency and high-demand business scenarios, it has shown stronger adaptability and stability, and improved the competitiveness of the platform in the market.

[0030] 4. Assist in long-term stable operation and maintenance of the system;

[0031] The new technical solution not only ensures the stability of the streaming service, optimizes network traffic management, and improves disaster recovery capabilities, but also brings many conveniences to the long-term stable operation and maintenance of the system. The stable streaming process means that operation and maintenance personnel do not need to frequently deal with various problems caused by streaming interruptions, code stream confusion, etc., reducing the workload of operation and maintenance and the difficulty of troubleshooting. Reasonable network traffic management makes the use of network resources more efficient and orderly, and reduces the risk of system failures caused by network congestion and other problems. The powerful disaster recovery capability further ensures the rapid repair and re-online of the system after encountering unexpected situations, reducing the impact on the business. Overall, the new technical solution helps to reduce the operation and maintenance costs of the system, extend the service life of the system, and enable the entire national standard cascade platform to provide users with high-quality video streaming services more continuously and stably to meet the ever-evolving business needs. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] Figure 1 It is a flow chart of the national standard cascade platform flow optimization method of the present invention;

[0034] Figure 2 It is a schematic diagram of the flow management interaction of the cascade platform of the present invention. DETAILED DESCRIPTION

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

[0036] Embodiment 1

[0037] refer to Figure 1 and Figure 2 This embodiment provides a national standard cascade platform flow optimization method based on Redis storage and management, including the following steps:

[0038] S1: After the national standard cascade upper service is successfully started, the streaming media initiates an application for streaming. After receiving the request, the national standard cascade upper service records the streaming status information in Redis, and at the same time applies to the lower-level cascade platform to create a streaming channel, that is, sends an INVITE signaling;

[0039] S2: If the national standard cascade upper-level service is restarted and restored during the above process, when the lower-level cascade platform returns a response to the cascade service that successfully created the streaming channel:

[0040] S3: When the customer needs to end the real-time streaming, a streaming media will send a disconnection notification to Kafka. After the cascade receives the disconnection notification, it will read the streaming information from Redis. If the information exists, it will promptly notify the lower-level cascade platform to disconnect the streaming, that is, send a disconnection notification BYE signaling, and the lower-level cascade platform will end the streaming.

[0041] S4: By comparing with the tokenID information, the invalid streaming session is periodically verified and terminated; the tokenID key-value pair of whether the streaming media is valid is recorded in Redis regularly to verify and clear the invalid streaming, and release the invalid streaming in time.

[0042] Furthermore, in step S1, when recording the flow status information to Redis, a data integrity verification mechanism is used to ensure that the data is stored accurately, and the verification method includes data format verification and / or data length verification; AS_cascade port: Session_Map is used as the primary key of the hash table, and each flow session ID is used as a separate key value for each information to record, so as to achieve efficient reading and writing. The recorded flow status information includes one or more of the device identification, flow start time, flow channel related parameters and device network status information, so as to fully grasp the flow related situation and provide data basis for flow management and troubleshooting.

[0043] As a preferred implementation, in this embodiment, if the national standard cascade upper-level service is restarted and the service is restored in the above process, when the lower-level cascade platform returns a response to the cascade service that the flow channel has been successfully created:

[0044] S21: If the cascade service is not restored at this time, the flow acquisition is not started, and the flow acquisition process will be restarted later;

[0045] S22: If the cascade service has been restored at this time, the national standard cascade upper service reads the stream status information from Redis according to the session ID in the response, and then continues to record the successful application status into redis. The record is used for subsequent process monitoring and data statistics; then the lower-level cascade platform is formally notified to send the stream, that is, an ACK signal is sent; the lower-level cascade platform starts to send the video stream to the upper-level streaming media.

[0046] As a preferred implementation mode, in this embodiment, after the lower-level cascade platform receives the BYE signaling, the national standard cascade upper-level service monitors the execution of the disconnection of the lower-level cascade platform without interference, that is, the abnormal restart state of this service; if the disconnection operation is not completed within the specified time, the national standard cascade upper-level service will take further forced disconnection measures, including sending multiple disconnection instructions or directly cutting off the connection resources with the lower-level cascade platform to ensure that invalid code streams do not continue to consume network resources.

[0047] As a preferred implementation mode, in this embodiment, in the entire process of flow acquisition and interruption, key operation steps are carried out; including timed cleaning of invalid flow acquisition paths to ensure the effective use of broadband traffic; and detailed logging of signaling sending and receiving, Redis information reading and writing, and flow acquisition operations. The log content includes operation time, operation type, involved device or session information, and operation results, so as to quickly locate the root cause of the problem when a system failure or abnormal situation occurs, and also provide data basis for system performance analysis and optimization.

[0048] Embodiment 2

[0049] refer to Figure 2 In this embodiment, a method for optimizing the flow of national standard cascade platform based on Redis storage and management is provided. The entire flow optimization process covers multiple key stages and interactive links. The first is the S1 stage. After the national standard cascade upper service is successfully started, Figure 2As shown in the interactive diagram, the streaming media initiates an application for streaming. At this point, the national standard cascade upper service receives the request and proceeds to record the streaming status information completely into Redis. When recording information, a data integrity verification mechanism is used, in which the data format verification checks whether the device identification conforms to specific format specifications (for example, whether it is an alphanumeric combination of a specified length), and the data length verification ensures that the record length of the streaming start time conforms to the time data format requirements, etc., to ensure that the data is accurately stored in Redis. In addition, AS_Cascade Port: Session_Map is used as the primary key of the hash table, and each streaming session ID is recorded as a separate key value for each piece of information. For example, if there is a stream acquisition request from a specific AS_cascade port "Port_01", and its session ID is "Session_101", the corresponding hash table entry will be constructed in Redis, and the device ID, stream acquisition start time, stream acquisition channel related parameters and device network status information will be stored as specific key-value pairs under the session ID. For example, the device ID may be "Camera_001", the stream acquisition start time is "2024-12-0514:30:00", the stream acquisition channel related parameters are "Channel_Type:HD,Encoding:H.264", and the device network status information is "Bandwidth:10Mbps,Latency:20ms", etc. Such a storage structure facilitates subsequent efficient read and write operations, and also provides a comprehensive data basis for stream acquisition management and troubleshooting. At the same time, the national standard cascade upper service applies to the lower cascade platform to create a stream channel, that is, to send INVITE signaling. The corresponding signaling flow direction indication for this operation can be seen in the attached figure.

[0050] If the S2 phase is entered, that is, the national standard cascade upper service is restarted and restored in the above process, when the lower-level cascade platform returns a response to the cascade service that the streaming channel has been successfully created, it will be processed differently according to the recovery status of the cascade service. From the figure, we can clearly see this branch judgment process. If the cascade service has not been restored at this time, then the stream has not started, and the stream fetching process will be restarted later, just like the process loop returns to the initial application stream link; if the cascade service has been restored at this time, the national standard cascade upper service reads the stream fetching status information from Redis according to the session ID in the response, and then continues to record the successful application status into redis. This record is used for subsequent process monitoring and data statistics, such as recording the timestamp of the successful application, the update of related parameters, etc., and then formally notifies the lower-level cascade platform to send the stream, that is, sends the ACK signaling. After receiving the ACK signaling, the lower-level cascade platform starts to send the video stream to the upper-level streaming media. This series of operations is clearly reflected in the process trend of the attached figure.

[0051] When the S3 stage is reached and the real-time streaming needs to be ended, a disconnection notification is sent to Kafka through the streaming media. Kafka is a distributed stream processing platform developed and maintained by the Apache Software Foundation. It is mainly used to build real-time data pipelines and streaming applications, and can efficiently process large amounts of data. Kafka is known for its high throughput, scalability, and persistence, and is widely used in scenarios such as big data processing and log collection. After the cascade receives the disconnection notification, it reads the streaming information from Redis based on the session ID. If it exists, it promptly notifies the lower-level cascade platform to disconnect the stream, that is, sends a disconnection BYE signaling. The lower-level cascade platform ends the streaming after receiving the BYE signaling. The attached figure shows the transmission path and processing process of the disconnection notification between various components.

[0052] Finally, in the S4 stage, invalid streaming sessions are periodically verified and terminated by comparing with the tokenID information. The invalid streaming is verified and cleared by the tokenID key-value pair recorded in Redis to check whether the streaming media is valid, and the invalid streaming is released in time. For example, a verification is set every 15 minutes (which can be set when the system is initialized according to actual conditions). If the tokenID of a session is found to be invalid, it may be because the streaming media source corresponding to the session has stopped sending data or a network failure has occurred, causing the tokenID to expire. At this time, the system will release the resources occupied by the invalid streaming, including closing the relevant network connection, clearing some information of the session in Redis to reclaim memory space, etc. The corresponding time trigger and resource processing diagram of this verification and cleanup process can also be seen in the attached figure.

[0053] 2. Implementation details of key steps

[0054] 1. Recording Stream Information to Redis

[0055] After the national standard cascade upper service receives the streaming application request from the streaming media, the streaming information is stored in Redis according to the established hash table structure. For example, when a streaming application is received from a specific device identified as "Device_ABC", the streaming start time is "2024-12-0609:15:00", the streaming channel related parameters are "Channel_02, Protocol: RTMP", and the device network status information is "Network_Status: Moderate", "AS_Cascade Port 2: Session_Map" will be used as the primary key in Redis to generate a record item with the unique ID of the streaming session (such as "Session_202") as a separate key value, and the above-mentioned device identification, streaming start time, streaming channel related parameters and device network status information are stored as corresponding values. In this way, when any information of the streaming session needs to be queried later, it can be quickly located and obtained through the primary key and session ID. During the storage process, the data format check will check whether the device ID contains only letters and numbers, and whether the stream start time meets the format requirements of "YYYY-MM-DDHH:MM:SS". The data length check will ensure that the device ID length does not exceed 20 characters, and the string length of the stream start time is 19 characters. If the check fails, corresponding error processing will be performed, such as prompting to resend the information in the correct format.

[0056] (II) Processing after service restart

[0057] Assuming that the national standard cascade upper service restarts and resumes service during the process of processing the above-mentioned "Device_ABC" stream acquisition, when the lower-level cascade platform returns a response that the stream channel has been successfully created for the stream acquisition session, if the cascade service has been restored, it will quickly read the previously stored stream acquisition status information from Redis according to the session ID "Session_202" in the response, such as the device identification "Device_ABC" and other information, and after confirmation, the successful application status will be recorded in Redis again, indicating "Application_Status: Success, Update_Time: 2024-12-0609:20:00" and other information for process monitoring and data statistics, and then send ACK signaling to the lower-level cascade platform, so that the lower-level cascade platform starts to stream video to the upper-level streaming media, ensuring the seamless connection of the stream acquisition process after the service restarts. From the attached figure, you can see the detailed path of information interaction and status update between various components in the recovery process after the service restarts.

[0058] (III) Cut-off operation

[0059] When the customer wants to end the real-time streaming of "Device_ABC", the streaming media will send a disconnection notification to Kafka. After the cascading service consumes the disconnection notification from Kafka in time, it reads the streaming session information from Redis according to the session ID "Session_202". If the session information exists, it sends a BYE signal to the lower-level cascading platform that issued the streaming session. After receiving the BYE signal, the lower-level cascading platform stops sending the video stream to the upper-level streaming media, ends the streaming operation, and feeds back the disconnection completion information to the cascading service. The cascading service marks the relevant information of the session in Redis as "Ended" for subsequent query and statistics. A complete signaling transmission and processing link from streaming media to Kafka, to the cascading service, and finally to the lower-level cascading platform.

[0060] (IV) Invalid flow verification and removal

[0061] In the periodic verification of invalid flow acquisition, for example, every 15 minutes (default value), the system will traverse the tokenID key-value pairs corresponding to all flow acquisition sessions stored in Redis. If it is found that the tokenID of a flow acquisition session does not exist or has expired (such as determined by the set validity period), the flow acquisition is determined to be invalid. At this time, the system will release the resources occupied by the invalid flow acquisition, including network connection resources, memory resources, etc. For example, if it is found that the tokenID of a flow acquisition session with a session ID of "Session_303" is invalid, the system will close the network connection related to the session, clear the relevant information records of the session in Redis, such as device identification, flow acquisition start time, etc., and mark the memory space occupied by the session as recyclable, thereby ensuring that system resources can be effectively utilized and avoiding the impact of invalid flow acquisition on system performance.

[0062] In the traditional video cascade platform solution, the key information of the stream is usually recorded in the temporary cache of this service. For example, when facing a service restart, due to concerns that the stream cannot be managed after the service restarts, all streams are often disconnected before the service ends. This causes the video stream that the user is watching to be suddenly interrupted, seriously affecting the user experience. The present invention records the key information of the stream into Redis. Even if the service is restarted, the stream can continue to be managed according to the information stored in Redis, and the normal stream will not be disconnected when the service is restarted, so that users can watch the video stream more stably and obtain a better viewing experience. From the comparison of the accompanying drawings, the traditional solution directly interrupts the stream extraction process when the service is restarted, while the present solution can continue to run stably along the Redis storage information.

[0063] In addition, in the traditional solution, when the service is abnormally offline, because the key information is recorded in the temporary cache, it may not be possible to finish and disconnect all the streams before the service ends, resulting in extra code streams being unmanaged and consuming network traffic for a long time. In the new solution of the present invention, the stream information is recorded in Redis, and the disconnection notification is continuously and uninterruptedly taken out from Kafka, which can timely shut down the streams that the customer does not need, scientifically and effectively manage the network traffic from the aspect of streams, so that the bandwidth is effectively utilized and released. It can be seen from the attached figure that the code streams of the traditional solution continue to consume network resources when the service is abnormally offline, while this solution can clean up invalid streams in time.

[0064] In summary, the national standard cascade platform flow optimization method based on Redis storage and management of the present invention effectively solves many problems existing in traditional solutions through unique design and process, improves the stability of flow acquisition, resource utilization and system reliability, and provides a strong guarantee for the efficient operation of the video cascade platform.

[0065] Embodiment 3

[0066] This embodiment provides a national standard cascade platform flow optimization system based on Redis storage and management, including:

[0067] Device information management module: used to obtain the national standard number, device name, IP address, port number, user name, password, channel number, channel name, and device type information of the device when the national standard device is connected to the platform, and store the device information in the MySQL database and Redis cache database, and is responsible for the update and synchronization of device information;

[0068] Stream parameter acquisition module: When receiving a stream request from the front end, it is responsible for parsing the national standard number, channel number, and stream protocol of the device from the request, and obtaining the device's IP address, port number, user name, and password information from the Redis cache database based on the national standard number. If the information is incomplete, it is obtained from the MySQL database and the Redis cache database is updated;

[0069] Stream acquisition request processing module: Generates a stream acquisition address based on the stream acquisition protocol and the acquired device IP address, port number, and channel number, and forwards the stream acquisition request to the corresponding national standard device to achieve video stream acquisition;

[0070] Heartbeat detection and update module: regularly sends heartbeat detection requests to devices in the Redis cache database, updates device status based on device responses, and attempts to reconnect and update device information when the device is offline;

[0071] Cache cleaning and optimization module: responsible for synchronously updating or deleting the corresponding device information in the Redis cache database when the device information in the MySQL database is updated or deleted, and regularly cleaning up the device information that has not been used for a long time in the Redis cache database to release cache space.

[0072] Preferably, when storing device information in the Redis cache database, the device information management module calculates a reasonable expiration time based on the activity level of the device and the frequency of data updates to ensure the timeliness of the device information. When acquiring device information from the Redis cache database, the flow parameter acquisition module uses batch acquisition to optimize performance and reduce the number of interactions with the Redis server. The heartbeat detection and update module dynamically adjusts the sending interval of the heartbeat detection request according to the importance and stability of the device, and attempts to reconnect after the device is offline according to the configurable number of connections and connection time interval. The cache cleaning and optimization module uses an asynchronous method when performing device information synchronization operations, and when cleaning device information that has not been used for a long time in the Redis cache database, it makes judgments based on the last access time of the device and the dynamically adjusted idle time threshold.

[0073] 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. A national standard cascade platform flow optimization method based on Redis storage and management, characterized by: The steps include: S1: After the national standard cascade upper service is successfully started, the streaming media initiates an application for streaming. After receiving the request, the national standard cascade upper service records the streaming status information in Redis, and at the same time applies to the lower-level cascade platform to create a streaming channel, that is, sends an INVITE signaling; S2: If the national standard cascade upper-level service is restarted and restored during the above process, when the lower-level cascade platform returns a response to the cascade service that the stream channel has been successfully created, the cascade service is in state 1 or state 2: State 1 is S21: At this time, the cascade service has not been restored, so the flow acquisition has not started, and the flow acquisition process will be restarted later; State 2 is S22: At this time, the cascade service has been restored, and the national standard cascade upper service reads the stream status information from Redis according to the session ID in the response, and then continues to record the successful application status into Redis. This record is used for subsequent process monitoring and data statistics; then formally notifies the lower-level cascade platform to send the stream, that is, sends an ACK signal; the lower-level cascade platform starts to send the video stream to the upper-level streaming media; S3: When the customer needs to end the real-time streaming, a streaming media will send a disconnection notification to Kafka. After the cascade receives the disconnection notification, it will read the streaming information from Redis. If the information exists, it will promptly notify the lower-level cascade platform to disconnect the streaming, that is, send a disconnection notification BYE signaling, and the lower-level cascade platform will end the streaming. S4: By comparing with the tokenID information, the invalid streaming session is periodically verified and terminated; the tokenID key-value pair of whether the streaming media is valid is recorded in Redis regularly to verify and clear the invalid streaming, and release the invalid streaming in time.

2. The method according to claim 1, characterized in that: In step S1, when recording the flow status information to Redis, a data integrity verification mechanism is used to ensure that the data is stored accurately. The verification method includes data format verification and / or data length verification; AS_cascade port: Session_Map is used as the primary key of the hash table, and each stream acquisition session ID is used as a separate key value for each piece of information to achieve efficient reading and writing. The recorded stream acquisition status information includes one or more of the device identification, stream acquisition start time, stream acquisition channel related parameters and device network status information, so as to fully understand the stream acquisition related situation and provide data basis for stream acquisition management and troubleshooting.

3. The method according to claim 2, characterized in that: After the lower-level cascading platform receives the BYE signaling, the national standard cascading upper-level service monitors the interruption execution of the lower-level cascading platform without interference, that is, the abnormal restart status of this service; If the disconnection operation is not completed within the specified time, the national standard cascade upper-level service will take further forced disconnection measures, including sending multiple disconnection instructions or directly cutting off the connection resources with the lower-level cascade platform to ensure that invalid code streams do not continue to consume network resources.

4. The method according to claim 3, characterized in that: During the entire process of obtaining and disconnecting traffic, key operation steps are recorded in detail, including the regular cleaning of invalid flow paths to ensure the effective use of broadband traffic, signaling sending and receiving, Redis information reading and writing, and flow obtaining operations. The log content includes operation time, operation type, involved device or session information, and operation results, so that the root cause of the problem can be quickly located when the system fails or anomalies occur, and it also provides data basis for system performance analysis and optimization.

Images