A storm cluster-based application version online switching method and device

Abstract

The embodiment of the application discloses a storm cluster-based application program version online switching method and device, the method comprises the following steps: obtaining first version identification information, second version identification information, first version application state information and second version application state information, the first version is a current online version, the second version is different from the first version, and the second version is in a running state; determining a priority version according to a preset version priority, the first version identification information and the second version identification information, the priority version is a target output version; if the second version is the priority version, determining whether the first version application state information is consistent with the second version application state information; if the first version application state information is consistent with the second version application state information, switching the first version to the second version. The application solves the problem that manual intervention is required in the application program version switching process in the storm cluster, and also avoids the loss of application state information caused by version switching.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and more specifically, to a method and apparatus for online switching of application versions based on a Storm cluster. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology and applications, intelligent connected vehicle systems are gradually entering the practical application stage. Compared with traditional internet applications, intelligent connected vehicle application scenarios are characterized by long data collection durations, low latency, and high concurrency. To meet the real-time computing requirements of these application scenarios and provide millisecond-level services for intelligent connected vehicles, the cloud control platform employs a real-time computing engine to perform online calculations for these applications. Considering factors such as technology maturity, computing performance, and resource requirements, the cloud control platform uses a Storm cluster as its real-time computing engine.

[0003] While Storm can meet the computing performance and resource requirements of cloud-based control platforms in intelligent connected vehicle applications, its current Storm cluster architecture lacks an effective online hot-swapping method for application versions due to limitations in its implementation principles. Switching between different versions of an application running on a Storm cluster requires manually stopping the old version's application task in the Storm console and then resubmitting the new version's task to Storm. This method is not only time-consuming but also causes service interruptions. Another approach involves scanning and automatically loading class files to replace existing class instances, binding business requests to class instances to automatically switch versions when a user submits a request. While this solution eliminates manual intervention, it results in the loss of application state information, preventing the new version from using the accumulated calculation results and status information cached by the old version. Therefore, avoiding manual intervention and ensuring no loss of application state information during Storm cluster application switching is a critical issue that needs to be addressed. Summary of the Invention

[0004] This invention provides a method and apparatus for online switching of application versions based on a Storm cluster, enabling online hot switching of application versions within the Storm cluster while ensuring that application status information is not lost during the switching process. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of the present invention provide a method for online switching of application versions based on a Storm cluster, the method comprising:

[0006] Obtain the first version identifier information, the second version identifier information, the first version application status information, and the second version application status information. The first version is the currently online version, and the second version is different from the first version. The second version is in the running state.

[0007] Based on the preset version priority, first version identifier information, and second version identifier information, the priority version is determined, and the priority version is the target output version;

[0008] If the second version is the preferred version, then determine whether the application status information of the first version and the application status information of the second version are consistent;

[0009] If the application status information of the first version is consistent with that of the second version, switch the first version to the second version.

[0010] Optionally, before obtaining the first version identifier information, the second version identifier information, the first version application status information, and the second version application status information, the method further includes:

[0011] Acquire the distributed lock corresponding to the first version and output the data of the first version;

[0012] Request the distributed lock corresponding to the second version, and listen for the distributed lock corresponding to the second version;

[0013] Switching from version 1 to version 2 specifically includes:

[0014] Stop outputting the first version of data and release the distributed lock corresponding to the first version;

[0015] Obtain the distributed lock corresponding to the second version and output the data for the second version.

[0016] Optionally, after stopping the output of the first version of the data, the method also includes:

[0017] Send a scheduled task command to create and stop the first version of the scheduled task;

[0018] Stop the first version of the application according to the scheduled task.

[0019] Optionally, the steps of acquiring the distributed lock corresponding to the first version and outputting the first version data include:

[0020] Request the distributed lock corresponding to the first version;

[0021] Determine whether the distributed lock request corresponding to the first version was successful. If the request is successful, acquire the distributed lock corresponding to the first version and output the data of the first version. If the request fails, listen for the distributed lock corresponding to the first version until the distributed lock corresponding to the first version is acquired.

[0022] Optionally, version priority includes at least one of version upgrade and version rollback.

[0023] Optionally, the application status information of the first version is stored in real time during the operation of the first version, the application status information of the second version is stored in real time during the operation of the second version, the identification information of the first version is stored during the operation of the first version, and the identification information of the second version is stored during the operation of the second version.

[0024] Secondly, embodiments of the present invention provide an online version switching device for a Storm cluster application, the device comprising:

[0025] The first acquisition module is used to acquire first version identification information, second version identification information, first version application status information, and second version application status information. The first version is the currently online version, and the second version is different from the first version. The second version is in the running state.

[0026] The determination module is used to determine the priority version based on the preset version priority, the first version identifier information, and the second version identifier information. The priority version is the target output version.

[0027] The first judgment module is used to determine whether the application status information of the first version and the application status information of the second version are consistent if the second version is the preferred version.

[0028] The second judgment module is used to switch the first version to the second version if the application status information of the first version is consistent with the application status information of the second version.

[0029] Optionally, the device also includes:

[0030] The second acquisition module is used to acquire the distributed lock corresponding to the first version before executing the first acquisition module, and output the first version data;

[0031] The listening module is used to request the distributed lock corresponding to the second version and to listen for the distributed lock corresponding to the second version.

[0032] To switch from version 1 to version 2, follow these steps:

[0033] Stop outputting the first version of data and release the distributed lock corresponding to the first version;

[0034] Obtain the distributed lock corresponding to the second version and output the data for the second version.

[0035] Optionally, the device also includes:

[0036] Create a module to send a scheduled task command after stopping the output of the first version of data, and create a scheduled task to stop the first version.

[0037] The processing module is used to stop the first version of the application based on a scheduled task.

[0038] Optionally, the first acquisition module includes:

[0039] The request unit is used to request the distributed lock corresponding to the first version;

[0040] The judgment unit is used to determine whether the distributed lock request corresponding to the first version is successful. If the request is successful, the distributed lock corresponding to the first version is acquired and the first version data is output. If the request fails, the unit listens for the distributed lock corresponding to the first version until it acquires the distributed lock corresponding to the first version.

[0041] Optionally, version priority includes at least one of version upgrade and version rollback.

[0042] Optionally, the application status information of the first version is stored in real time during the operation of the first version, the application status information of the second version is stored in real time during the operation of the second version, the identification information of the first version is stored during the operation of the first version, and the identification information of the second version is stored during the operation of the second version.

[0043] As described above, the present invention provides an online application version switching method and apparatus based on a Storm cluster. This method acquires first version identifier information, second version identifier information, first version application status information, and second version application status information. The first version is the currently online version, and the second version is different from the first version and is in a running state. Based on a preset version priority, the first version identifier information, and the second version identifier information, a priority version is determined, which is the target output version. If the second version is the priority version, it is determined whether the first version application status information and the second version application status information are consistent. If the first version application status information and the second version application status information are consistent, the first version is switched to the second version.

[0044] By applying the embodiments of this invention, not only can online hot-swapping of application versions in a Storm cluster be achieved, but also application state information is not lost during the switching process. Of course, implementing any product or method of this invention does not necessarily require achieving all of the advantages described above simultaneously.

[0045] The innovative aspects of this invention include:

[0046] 1. Existing application version hot-switching is achieved by scanning and automatically loading class files to replace existing class instances. This method of reloading class instances causes the loss of application state information, and the new version cannot continue to use the cached cumulative calculation results, status information, etc., of the old version. This application stores version identification information and application state information in real time after version startup. When switching to a new version, it reads and determines whether the application state information of the current online version and the new version are consistent. If they are consistent, the current online version stops outputting data, and the new version application, having obtained the necessary permissions, provides data for online services. This application avoids the loss of application state information during version switching by synchronously checking the data cache.

[0047] 2. In intelligent connected vehicle applications, Storm clusters typically rely on manual intervention for version switching. This manual intervention leads to long switching times, business interruptions, and a failure to guarantee business continuity. This application employs a distributed lock contention mechanism to achieve online hot switching between versions, ensuring business continuity. The distributed lock contention mechanism uses requests, listening, and acquiring distributed locks to compete for application data output permissions, eliminating the need for manual intervention and ensuring business continuity. This enables online hot switching of versions within the Storm cluster.

[0048] 3. After the first version of the data stops outputting, this application also employs a timed program. If the first version of the application is terminated immediately after the first version of the data stops outputting, the calculation data may be lost. By creating timed tasks with different task types and execution times, the embodiments of the present invention are further optimized. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0050] Figure 1 A flowchart illustrating an online application version switching method based on a Storm cluster provided in an embodiment of the present invention;

[0051] Figure 2 An architecture diagram of an online application version switching method based on a Storm cluster provided in an embodiment of the present invention;

[0052] Figure 3 This is another flowchart illustrating the online application version switching method based on a Storm cluster provided in this embodiment of the invention.

[0053] Figure 4 This is a schematic diagram of a device for online switching of application versions based on a Storm cluster, provided in an embodiment of the present invention. Detailed Implementation

[0054] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0055] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0056] This invention provides a method and apparatus for online switching of application versions based on a Storm cluster. The embodiments of this invention are described in detail below.

[0057] Figure 1 This is a flowchart illustrating an online application version switching method based on a Storm cluster, provided in an embodiment of the present invention. The method may include the following steps:

[0058] S101: Obtain the first version identifier information, the second version identifier information, the first version application status information, and the second version application status information. The first version is the currently online version, and the second version is different from the first version. The second version is in the running state.

[0059] Version 1 refers to the current version of an application running in the Storm cluster; that is, Version 1 is the only version of the data currently output by that application. Version 1 also runs simultaneously in the same Storm cluster, with Version 1 and Version 2 running independently without interference. Application state information includes, but is not limited to, the type of application state and its offset.

[0060] The online version switching method for Storm cluster applications provided in this invention is applied to a cloud platform. In one implementation, the software implementing this online version switching method for Storm cluster applications can exist as a standalone client software or as a plugin for existing client software; either is acceptable.

[0061] In existing technologies, due to the limitations of the Storm cluster architecture implementation principle, when switching between different versions of an application running in a Storm cluster, there will be problems such as long switching time, business service interruption, and loss of application state information. The version switching implemented by this application can ensure business continuity and ensure that application state information is not lost.

[0062] In an optional embodiment, the first version application status information is stored in real time during the operation of the first version, the second version application status information is stored in real time during the operation of the second version, the first version identification information is stored during the operation of the first version, and the second version identification information is stored during the operation of the second version.

[0063] In this embodiment, the first version and the second version can be stored in the same storage unit. The application state information for both the first and second versions is stored in real time. In one implementation, the application state information can be written to Redis (remote dictionary server), an in-memory data structure storage server that provides in-memory data storage in a key-value format.

[0064] S102: Determine the priority version based on the preset version priority, the first version identification information, and the second version identification information. The priority version is the target output version.

[0065] In one implementation, when a second version is detected, the version identifiers of the first and second versions are compared according to the version priority. If the second version is determined to be the priority version, step S103 is executed. If the first version is determined to be the priority version, the priority is re-determined.

[0066] In an optional embodiment, the version priority includes at least one of version upgrade and version rollback.

[0067] S103: If the second version is the preferred version, then determine whether the application status information of the first version and the application status information of the second version are consistent.

[0068] The priority version is the target version that will be switched to and output data. When the second version is determined to be the target version, it is necessary to further determine whether the application status information of the current online version and the target version is consistent. Only when the application status information is consistent can the version switch be carried out. This ensures the integrity of application data during the version switch process and avoids data loss caused by the version switch.

[0069] S103: If the application status information of the first version is consistent with the application status information of the second version, switch the first version to the second version.

[0070] The first version is the currently released version, and the second version is the version that will be released to replace the first version. When the application status information of the two versions is consistent, the first version is switched to the second version. This switching method will not cause the application process information to be lost. In one possible implementation, the first version is the currently released version, and the second version is a newer version than the first version. The application status information of the first version and the second version stored in the cache are read separately and compared. If they are consistent, the first version is switched to the second version; if they are inconsistent, the application status information of both versions is read again from the cache.

[0071] In an optional embodiment, before obtaining the first version identifier information, the second version identifier information, the first version application status information, and the second version application status information, the method further includes:

[0072] Obtain the distributed lock corresponding to the first version and output the data of the first version.

[0073] Request the distributed lock corresponding to the second version, and listen for the distributed lock corresponding to the second version.

[0074] Switching from the first version to the second version specifically includes: stopping the output of the first version data, releasing the distributed lock corresponding to the first version; acquiring the distributed lock corresponding to the second version, and outputting the second version data.

[0075] This application employs a distributed lock contention mechanism to coordinate version switching and the corresponding data output. The distributed lock contention mechanism competes for application data output permissions by requesting, listening, and acquiring a distributed lock, eliminating the need for manual intervention.

[0076] In one feasible approach, the first version, while processing business logic, writes its application state information to the cache module and requests a distributed lock. Once the distributed lock processing module acquires the distributed lock, the first version gains output permission and outputs its data. When the second version starts, it similarly writes its application state information to the cache module and requests a distributed lock while processing business logic. However, since the first version has already successfully requested and acquired the distributed lock, the second version can only listen for the distributed lock and wait for the first version to release it before it can acquire the lock itself. The application state information of both versions is read from the cache module and compared. If they match, the first version releases the distributed lock and stops outputting its data. Then, the second version acquires the distributed lock, gains output permission, and outputs its data.

[0077] In an optional embodiment, after stopping the output of the first version of the data, the method further includes:

[0078] Send a scheduled task command to create and stop the first version of the scheduled task.

[0079] The first version of the application is stopped according to the scheduled task.

[0080] When the first version stops outputting, although it loses output permissions, the first version application is actually still running and has not terminated. If the first version application is stopped immediately upon losing output permissions, data loss may occur. Therefore, to further optimize the process, a scheduled task step needs to be set for the first version. Scheduled tasks can be created with different task types and execution times based on the consistency of application status information. The execution time is the time elapsed after outputting before the first version application process terminates.

[0081] In an optional embodiment, the step of acquiring the distributed lock corresponding to the first version and outputting the first version data includes:

[0082] Request the distributed lock corresponding to the first version.

[0083] Determine whether the distributed lock request corresponding to the first version is successful. If the request is successful, acquire the distributed lock corresponding to the first version and output the data of the first version. If the request fails, listen for the distributed lock corresponding to the first version until the distributed lock corresponding to the first version is acquired.

[0084] When the first version is launched for the first time, output permission is required to output the first version data. In this embodiment, a distributed lock is obtained through requesting, listening, and acquiring. After obtaining the distributed lock, the first version data can be output. This embodiment further optimizes the technical solution of this application.

[0085] In one embodiment, the version priority is to roll back the version, detect the first version identifier information and the second version identifier information, and if the second version is lower than the first version, the second version is determined to be the priority version. At this time, the second version can be given output permission by comparing the application state information of the two and contending for a distributed lock, and finally the data of the second version is output.

[0086] In one embodiment, it is possible to switch between old and new versions of an application that processes vehicle perception data and roadside perception data in intelligent connected vehicles. Figure 2 This is an architecture diagram of an online application version switching method based on a Storm cluster provided in an embodiment of the present invention. The architecture of the online application version switching method based on a Storm cluster mainly includes four modules: a business logic processing module 203, a data output module 204, a data caching module 205, a distributed lock processing module 208, and a scheduled task 209. The business logic processing module 203 is responsible for receiving, parsing, and fusing perception data reported by vehicles and roadside units in real time, using the fused data to perform calculations for intelligent connected vehicle application scenarios, and sending the application status information generated during the application calculation process to the data caching module. The data output module 204 is responsible for receiving the fused perception data and application scenario calculation results sent by the business logic processing module 203, and outputting the data to Kafka in real time. Kafka is a distributed streaming media platform used for receiving, sending, and storing message queues. The data caching module 205 receives application status information sent by the business logic processing module 230 and writes it to Redis 207 in real time. It also reads the application status information cached in Redis 207 for a specified version, referring to the version information in the cache configuration information 206, and performs consistency checks on the application status information. Based on the results, it notifies the data output module, distributed lock processing module, and scheduled task module to execute corresponding operations. The cache configuration information 206 stores version identifiers for each version. The distributed lock processing module 208 connects to Zookeeper, providing functions for requesting, acquiring, listening to, and releasing distributed locks. It controls data output based on the distributed lock request results. Zookeeper is a distributed application coordination service that provides consistency services for distributed applications through interfaces such as distributed exclusive locks, election, and queues.

[0087] Figure 3This is another flowchart illustrating the online application version switching method based on a Storm cluster provided in an embodiment of the present invention.

[0088] S301: The first version of the application is running normally. The first version receives, parses and merges the perception data reported by vehicles and roadside in real time through the business logic processing module. It uses the merged data to calculate the application scenarios of intelligent connected vehicles. At the same time, the first version of the application writes the first version identification information into the cache configuration information file through the data caching module.

[0089] S302: The first version of the application writes the application status information to Redis for caching via the data caching module.

[0090] It should be noted that when the second version is not running, the cache configuration information only contains the version identifier information of the first version. In this case, there is no need to switch versions. Once the second version application starts, proceed with the following steps:

[0091] S321: The second version of the application is launched. The second version receives, parses and merges the perception data reported by vehicles and roadside in real time through the business logic processing module. It uses the merged data to calculate the application scenarios of intelligent connected vehicles. At the same time, the second version of the application writes the identification information of the first version into the cache configuration information file through the data caching module.

[0092] S322: The second version application writes the second version application status information into Redis for caching via the data caching module.

[0093] S303: The data caching module reads the cache configuration information and checks whether there is a new version identifier in the cache configuration information.

[0094] S304: If the data caching module detects a new version, proceed to step S305; otherwise, return to S303.

[0095] S305: The data caching module reads the first and second version application status information cached in Redis and compares them.

[0096] S306: If the type, offset, and other data in the first version application status information and the second version application status information are consistent, proceed to S307; if the application status information of the two versions is inconsistent, return to S305.

[0097] S307: Notify the data output module of the first version application to stop writing data to Kafka.

[0098] S308: The distributed lock is released by the distributed lock processing module.

[0099] S309: When the second version starts, the distributed lock handling module sends a distributed lock request to Zookeeper. It should be noted that the second version is already running and outputting data at this time, so its first request can only enter the listening step, waiting for the first version to release the distributed lock.

[0100] S310: If the distributed lock request succeeds, the distributed lock processing module automatically acquires the distributed lock. If the distributed lock request fails, the distributed lock processing module starts the distributed lock listener.

[0101] S311: The distributed lock processing module starts the distributed lock listening program, and the second version waits for output data.

[0102] S312: Since the first version of the application has already released the distributed lock, the second version of the application successfully acquires the distributed lock through the distributed lock listener.

[0103] S313: After the distributed lock processing module acquires the distributed lock, it notifies the data output module to start outputting the second version of the data to Kafka.

[0104] Additionally, after S307, S330 can also be executed: The data caching module of the first version application sends a timed task scheduling instruction to the timed task module. After receiving the timed task scheduling instruction sent by the data caching module, the timed task module generates a timed task to stop the first version application.

[0105] This invention employs a distributed lock contention mechanism to achieve online switching between old and new versions. Simultaneously, data cache synchronization checks ensure business continuity. This embodiment uses requests, listening, and acquiring a distributed lock to compete for application data output permissions. When each application version starts, it writes application status information to a shared cache. Once the status information of two application versions is consistent, the first version stops outputting data, and the second version, having acquired the necessary permissions, provides data for online services. This disclosure allows for online hot-switching of versions without manual intervention and prevents the loss of application status information.

[0106] Corresponding to the above method embodiments, this invention provides an online version switching device for Storm cluster applications. Figure 4 This is a schematic diagram of a structure for an online application version switching device based on a Storm cluster, provided in an embodiment of the present invention. Figure 4 As shown, the device includes:

[0107] A Storm cluster application version online switching device, characterized in that the device comprises:

[0108] The first acquisition module 401 is used to acquire first version identification information, second version identification information, first version application status information, and second version application status information. The first version is the currently online version, and the second version is different from the first version. The second version is in the running state.

[0109] The determination module 402 is used to determine the priority version based on the preset version priority, the first version identification information, and the second version identification information, wherein the priority version is the target output version.

[0110] The first judgment module 403 is used to determine whether the application status information of the first version and the application status information of the second version are consistent if the second version is the preferred version.

[0111] The second judgment module 404 is used to switch the first version to the second version if the application status information of the first version is consistent with the application status information of the second version.

[0112] In an optional embodiment, the apparatus further includes:

[0113] The second acquisition module is used to acquire the distributed lock corresponding to the first version before executing the first acquisition module, and output the data of the first version.

[0114] The listening module is used to request the distributed lock corresponding to the second version and to listen for the distributed lock corresponding to the second version.

[0115] The step of switching the first version to the second version is specifically executed as follows:

[0116] Stop outputting the first version of data and release the distributed lock corresponding to the first version.

[0117] Obtain the distributed lock corresponding to the second version and output the second version data.

[0118] In an optional embodiment, the apparatus further includes:

[0119] A module is created to send a scheduled task command to create a scheduled task to stop the first version of data after the output of the first version of data has stopped.

[0120] The processing module is used to stop the first version of the application according to the scheduled task.

[0121] In an optional embodiment, the first acquisition module includes:

[0122] A request unit is used to request the distributed lock corresponding to the first version.

[0123] The judgment unit is used to determine whether the distributed lock request corresponding to the first version is successful. If the request is successful, the distributed lock corresponding to the first version is acquired and the first version data is output. If the request fails, the unit listens for the distributed lock corresponding to the first version until the distributed lock corresponding to the first version is acquired.

[0124] In an optional embodiment, the version priority includes at least one of version upgrade and version rollback.

[0125] In an optional embodiment, the first version application status information is stored in real time during the operation of the first version, the second version application status information is stored in real time during the operation of the second version, the first version identification information is stored during the operation of the first version, and the second version identification information is stored during the operation of the second version.

[0126] The above-described system and device embodiments correspond to the system embodiments and have the same technical effects as the method embodiments. For detailed descriptions, please refer to the method embodiments. The device embodiments are derived based on the method embodiments; detailed descriptions can be found in the method embodiments section, and will not be repeated here. Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0127] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for online version switching of applications based on a Storm cluster, characterized in that, The method includes: Request the distributed lock corresponding to the first version; Determine whether the distributed lock request corresponding to the first version is successful. If the request is successful, acquire the distributed lock corresponding to the first version and output the first version data. If the request fails, listen for the distributed lock corresponding to the first version until the distributed lock corresponding to the first version is acquired. Request the distributed lock corresponding to the second version, and listen for the distributed lock corresponding to the second version; Obtain first version identification information, second version identification information, first version application status information, and second version application status information. The first version is the currently online version, and the second version is different from the first version and is in a running state. The first version application status information is stored in real time during the running of the first version, the second version application status information is stored in real time during the running of the second version, the first version identification information is stored during the running of the first version, and the second version identification information is stored during the running of the second version. Based on the preset version priority, the first version identification information, and the second version identification information, a priority version is determined, and the priority version is the target output version; If the second version is the preferred version, then determine whether the application status information of the first version and the application status information of the second version are consistent; If the application status information of the first version is consistent with the application status information of the second version, stop outputting the data of the first version, release the distributed lock corresponding to the first version, acquire the distributed lock corresponding to the second version, and output the data of the second version. After stopping the output of the first version of data, the method further includes: Send a scheduled task command to create and stop the first version of the scheduled task; The first version of the application is stopped according to the scheduled task.

2. The method as described in claim 1, characterized in that, The version priority includes at least one of version upgrade and version rollback.

3. An online application version switching device based on a Storm cluster, characterized in that, The device includes: The first acquisition module is used to acquire first version identification information, second version identification information, first version application status information, and second version application status information. The first version is the currently online version, and the second version is different from the first version and is in a running state. The first version application status information is stored in real time during the running of the first version, the second version application status information is stored in real time during the running of the second version, the first version identification information is stored during the running of the first version, and the second version identification information is stored during the running of the second version. The listening module is used to request the distributed lock corresponding to the second version and to listen for the distributed lock corresponding to the second version. The determination module is used to determine the priority version based on the preset version priority, the first version identification information, and the second version identification information, wherein the priority version is the target output version; The first judgment module is used to determine whether the application status information of the first version and the application status information of the second version are consistent if the second version is the preferred version. The second judgment module is used to switch the first version to the second version if the application status information of the first version is consistent with the application status information of the second version. The specific steps of switching the first version to the second version are: stopping the output of the first version data, releasing the distributed lock corresponding to the first version, acquiring the distributed lock corresponding to the second version, and outputting the second version data. The first acquisition module includes a request unit and a judgment unit; the request unit is used to request the distributed lock corresponding to the first version; the judgment unit is used to judge whether the request for the distributed lock corresponding to the first version is successful. If the request is successful, the distributed lock corresponding to the first version is acquired and the first version data is output. If the request fails, the distributed lock corresponding to the first version is monitored until the distributed lock corresponding to the first version is acquired. Create a module to send a scheduled task command after stopping the output of the first version of data, and create a scheduled task to stop the first version of data; The processing module is used to stop the first version of the application according to the scheduled task.

Images