Disaster recovery method and device, disaster recovery server and computer storage medium

By recording user operation trajectories to calculate the interface lifespan threshold, generating target page templates, and parsing them on the client side, the problem of traditional disaster recovery system paralysis is solved, achieving service continuity and improved user experience during system failures.

CN115865633BActive Publication Date: 2025-11-04MIGU CO LTD +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211393036.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-11-08
Publication Date
2025-11-04
Estimated Expiration
2042-11-08

AI Technical Summary

Technical Problem

Traditional disaster recovery systems cannot provide services when both the main service system and the backend service system experience problems, leading to the paralysis of the entire system.

Method used

By recording user operation trajectories to obtain user access data for the interface, calculating the interface lifespan threshold, generating a target page template and sending it to the client, the client can parse the target page through a thin client when it is unable to obtain data from the backend service system.

Benefits of technology

Even when both the main service system and the traditional disaster recovery system experience problems, the system can continue to provide services to users, offering a buffer period and improving the user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115865633B_ABST
    Figure CN115865633B_ABST
Patent Text Reader

Abstract

The embodiment of the present application relates to the technical field of computers, and discloses a disaster recovery method and device, a disaster recovery server and a computer storage medium.The method comprises the following steps: determining the interface survival time threshold of each interface according to the user access data of each interface and the interface survival time of each interface; determining the target interface to be accessed by the user according to the interface survival time threshold of the interface, obtaining the service data corresponding to the target interface, and generating the target page template corresponding to the target interface according to the service data; and sending the target page template to the client, so that the client obtains the target page corresponding to the target interface by analyzing the target page template through the thin client when the data of the back-end service system cannot be obtained.The embodiment of the present application can continue to provide services for the user in the case that the data of the back-end service system cannot be obtained, and provides a buffer time for system recovery.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, in particular to a disaster recovery method and device, a disaster recovery server and a computer storage medium. BACKGROUND

[0002] Disaster recovery refers to establishing a disaster recovery system at a different place, which is an available copy of a local key application data. When a disaster occurs in the local application system, the disaster recovery system can continue to provide available services.

[0003] In the prior art, a traditional disaster recovery system replicates the relevant application deployment and data synchronization of a primary service system of a backend service system, so that when a problem occurs in the primary service system, the traditional disaster recovery system can replace the primary service system to provide services for a client in time through the communication connection between the backend service system and the client.

[0004] However, the present inventor has found in practical application that when a problem occurs in the primary service system of the backend service system and the traditional disaster recovery system is started, the traditional disaster recovery system also has a problem (such as power failure or network device downtime), or the network between the client and the backend service system is completely disconnected, and the client cannot obtain the data of the backend service system, the primary service system and the traditional disaster recovery system cannot provide services, and the entire system will be completely paralyzed. SUMMARY

[0005] In view of the above problems, embodiments of the present application provide a disaster recovery method and device, a disaster recovery server and a computer storage medium, which are used to solve the problem that the entire system is paralyzed when a problem occurs in the primary service system and the disaster recovery system in the prior art.

[0006] According to an aspect of an embodiment of the present application, a disaster recovery method is provided, which comprises:

[0007] According to the user access data of each interface and the interface survival time of each interface, an interface survival time threshold of each interface is determined;

[0008] According to the interface survival time threshold of each interface, a target interface to be accessed by a user is determined;

[0009] Business data corresponding to the target interface is obtained, and a target page template corresponding to the target interface is generated according to the business data;

[0010] The target page template is sent to a client, so that the client can obtain a target page corresponding to the target interface by analyzing the target page template through a thin client when the data of a backend service system cannot be obtained.

[0011] In an alternative manner, the user access data of each interface comprises the number of times of access of each interface and the time of access of each interface, and the determining of the interface survival time threshold of each interface according to the obtained user access data of each interface and the interface survival time of each interface further comprises:

[0012] dividing the user access data according to the time of access of each interface into a plurality of time periods to obtain the number of times of access and the interface survival time of each interface in each time period of the plurality of time periods;

[0013] calculating the interface average survival time of each interface in each time period of the plurality of time periods according to the number of times of access of each interface in each time period of the plurality of time periods and the interface survival time of each interface;

[0014] calculating the weight value of each time period of the plurality of time periods according to the size of each time period of the plurality of time periods from the time period to which the currently accessed interface of the user belongs;

[0015] calculating the interface survival time threshold of each interface according to the interface average survival time of each interface in each time period of the plurality of time periods and the weight value of each time period of the plurality of time periods.

[0016] In an alternative manner, the calculating of the weight value of each time period of the plurality of time periods according to the size of each time period of the plurality of time periods from the time period to which the currently accessed interface of the user belongs further comprises:

[0017] calculating a weight factor of each time period of the plurality of time periods according to a preset time period and the size of each time period of the plurality of time periods from the time period to which the currently accessed interface of the user belongs;

[0018] calculating the weight value of each time period of the plurality of time periods according to the weight factor of each time period of the plurality of time periods.

[0019] In an alternative manner, the determining of the target interface to be accessed by the user according to the interface survival time threshold of each interface further comprises:

[0020] calculating an average survival time threshold according to the interface survival time threshold of each interface;

[0021] determining the interface with the interface survival time threshold greater than the average survival time threshold as the target interface to be accessed by the user.

[0022] In an alternative, the user access data of each interface comprises the number of times of access and the time of access of each interface, and the determining the target interface to be accessed by the user according to the interface survival time threshold of each interface further comprises:

[0023] determining the target interface to be accessed by the user according to the number of times of access, the time of access and the interface survival time threshold of each interface.

[0024] In an alternative, the determining the target interface to be accessed by the user according to the number of times of access, the time of access and the interface survival time threshold of each interface further comprises:

[0025] determining the interface currently accessed by the user according to the time of access of each interface;

[0026] determining the time period and the number of times of continuous access of each interface within a preset time length according to the number of times of access and the time of access of each interface;

[0027] determining the interface in which the interface survival time threshold is less than the interface survival time threshold of the interface currently accessed by the user and the time period and the number of times of continuous access are the same as the time period and the number of times of continuous access of the interface currently accessed by the user as the target interface to be accessed by the user.

[0028] In an alternative, after the acquiring the service data corresponding to the target interface and generating the target page template corresponding to the target interface according to the service data, the method further comprises: taking the interface survival time threshold of the interface currently accessed by the user as the template survival time of the target page template.

[0029] According to another aspect of the embodiment of the present application, a disaster recovery device is provided, comprising:

[0030] a determining module configured to determine the interface survival time threshold of each interface according to the acquired user access data of each interface and the interface survival time of each interface;

[0031] a predicting module configured to determine the target interface to be accessed by the user according to the interface survival time threshold of each interface;

[0032] a generating module configured to acquire the service data corresponding to the target interface and generate the target page template corresponding to the target interface according to the service data;

[0033] The execution module is configured to send the target page template to the client, so that the client parses the target page template through the thin client to obtain the target page corresponding to the target interface when the data of the backend service system cannot be obtained.

[0034] According to another aspect of the embodiments of the present application, a disaster recovery server is provided, comprising a processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete communication with each other through the communication bus;

[0035] The memory is configured to store at least one executable instruction, and the executable instruction causes the processor to perform the operations of the disaster recovery method as described above.

[0036] According to still another aspect of the embodiments of the present application, a computer storage medium is provided, and the storage medium stores at least one executable instruction, and the executable instruction causes the server to perform the operations of the disaster recovery method as described above when running on the server.

[0037] The disaster recovery server provided by the embodiments of the present application determines the interface survival time threshold according to the user access data of the interfaces and the interface survival time of the interfaces, determines the target interface to be accessed by the user according to the interface survival time threshold of the interfaces, obtains the service data corresponding to the target interface, generates the target page template corresponding to the target interface according to the service data, and sends the target page template to the client, so that the client parses the target page template through the thin client to obtain the target page corresponding to the target interface when the data of the backend service system cannot be obtained. In the case that the main service system and the traditional disaster recovery system both have problems, or the backend service system and the client cannot communicate, that is, the client cannot obtain the data of the backend service system, the user can continue to be provided with services, the buffer time for system recovery is provided, the user has no perception of system problems, and the user experience is improved.

[0038] The above description is only a summary of the technical solutions of the embodiments of the present application, in order to more clearly understand the technical means of the embodiments of the present application, the embodiments of the present application can be implemented according to the content of the specification, and in order to make the above and other purposes, characteristics and advantages of the embodiments of the present application more obvious and easy to understand, the specific embodiments of the present application are described below. BRIEF DESCRIPTION OF DRAWINGS

[0039] The accompanying drawings are only used to show the embodiments, and are not considered as limiting the present application. Moreover, the same reference signs are used to represent the same parts throughout the drawings. In the drawings:

[0040] Figure 1is an interaction diagram of a conventional disaster recovery system of prior art of embodiments of the present application;

[0041] Figure 2 is an interaction diagram of a disaster recovery method of embodiments of the present application;

[0042] Figure 3 is a flow diagram of a disaster recovery method of embodiments of the present application;

[0043] Figure 4 is a diagram of interface time-to-live of embodiments of the present application;

[0044] Figure 5 is Figure 1 is a detailed flow diagram of step 10 in

[0045] Figure 6 is a flow diagram of another disaster recovery method of embodiments of the present application;

[0046] Figure 7 is a structural diagram of a disaster recovery device of embodiments of the present application;

[0047] Figure 8 is a structural diagram of another disaster recovery device of embodiments of the present application;

[0048] Figure 9 is a structural diagram of a disaster recovery server of embodiments of the present application. DETAILED DESCRIPTION

[0049] Exemplary embodiments of the present application will be described herein below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it is understood that the present application can be embodied in various forms and should not be limited by the embodiments set forth herein.

[0050] A conventional disaster recovery system refers to establishing an off-site backup application system equivalent to a local application's back-end service system. The disaster recovery system replicates application data of a master service system of the back-end service system, and the main technologies include load balancing and cluster technology. As shown in Figure 1 When the master service system of the back-end service system has a problem (such as power failure in the computer room, or network equipment problem), it cannot continue to provide services externally. The conventional disaster recovery system of the back-end service system is switched to continue to provide services. The conventional disaster recovery system also relies on the real-time service capability of the back-end service system. The conventional disaster recovery system plays a role equivalent to the local master service system. Users interact with the conventional disaster recovery system through a client and the back-end service system. When the conventional disaster recovery system also has a problem, or the client and the back-end service system are completely disconnected, that is, the client cannot obtain data from the back-end service system, the master service system and the conventional disaster recovery system cannot provide services, and the entire system will be completely paralyzed.

[0051] In view of this, such as Figure 2 As shown, this invention proposes a disaster recovery method that, based on traditional disaster recovery systems, allows continued service provision even when the backend service system is unavailable—that is, when both the main service system and the traditional disaster recovery system are unable to provide service. This disaster recovery method includes a backend service system (i.e., the backend service environment), a traditional disaster recovery system (i.e., the conventional disaster recovery environment), and client-side and thin-client disaster recovery systems (i.e., the thin-client disaster recovery environment).

[0052] For example, the backend service system includes a server and a database. The server can be a service module that normally provides request processing and message response to clients. The server can be a single server, a server cluster consisting of multiple servers, or a cloud computing server center. The server includes a processor, memory, and network interfaces, etc. In embodiments of the present invention, the server includes a main service system and a traditional disaster recovery system.

[0053] For example, the client can be any system capable of human-computer interaction with the user, such as client software or browser pages used on a user's mobile phone or PC. A thin client is a computer terminal in a client-server network architecture that essentially requires no application.

[0054] In this embodiment of the invention, when a user normally accesses the backend service system through a client, the backend service system records the user's operation trajectory in real time when the client requests the backend service system, and obtains user access data for each interface from the user's trajectory, storing the user access data for each interface in a database. Furthermore, a pre-defined initial lifespan is assigned to each interface accessed by the user. Based on the user access data for each interface and the interface lifespan of the interface, an interface lifespan threshold is determined for that interface. Based on the interface lifespan threshold, the target interface that the user will access is determined, and the business data corresponding to the target interface is obtained. A target page template corresponding to the target interface is pre-generated based on the business data and sent to the client. The client stores the pre-generated target page template. If the client cannot obtain data from the backend service system, it does not access the backend service system but directly parses the target page template to obtain the target page corresponding to the target interface to provide services to the user. When the user finishes their operation, the client dynamically clears the cached target page template data to ensure data security. The client also generates second-line data based on the user's operation on the thin client through the caching module and caches the second-line data. After the backend service system recovers, the second-line data is sent to the backend service system so that the backend service system can update the business data in the database corresponding to the second-line data based on the second-line data.

[0055] Figure 3 A flow chart of a disaster recovery method of an embodiment of the present application is shown, which is executed by a backend service system providing application services for a client. As shown in the figure, the method comprises the following steps: Figure 3

[0056] Step 10: determining the interface survival time threshold of each interface according to the user access data of each interface obtained and the interface survival time of each interface.

[0057] In an embodiment of the present application, each interface refers to all interfaces accessed by a user in a user operation track recorded by the backend service system in real time. When a user normally accesses the backend service system through a client and performs a browsing operation, the backend service system will record the operation track of the user in real time, and obtain the user access data of each interface from the operation track of the user. Among them, the operation track of the user mainly records the corresponding page, interface, business data involved, the number of times of access of each interface and the access time of each interface of the user operation. Specifically, the user access data of each interface in a preset time period can be obtained, such as obtaining the user access data of each interface from the operation track in the last 100 days. Exemplarily, part of the interface information corresponding to the recorded user operation is shown in Table 1:

[0058]

[0059] And the interface survival time of each interface refers to the survival time of each interface remaining when the survival time is counted, wherein the survival time is represented by ttl. And the interface survival time of each interface can be obtained by the initial survival time preset for each interface. The backend service system presets an initial survival time for all interfaces accessed by the user in the user operation track, and the initial survival time is automatically calculated and reduced over time, such as automatically reducing 1 per second.

[0060] The process of obtaining the interface survival time of each interface further comprises: setting a statistical node for all interfaces accessed by the user in the user operation track and presetting an initial survival time, and when the statistical node is counted, the survival time of each interface remaining is taken as the interface survival time of each interface.

[0061] ​The process of obtaining the interface survival time of each interface further comprises: presetting a same initial survival time for all interfaces accessed by the user in the user operation track; dividing a preset time period into a plurality of time segments to obtain all interfaces accessed by the user in each time segment of the plurality of time segments; setting a same statistical node for each time segment of the plurality of time segments; and taking the remaining survival time of each interface at the statistical node of each time segment of the plurality of time segments as the interface survival time of each interface. It should be noted that the initial survival time and the statistical node of each interface accessed by the user can be automatically recorded by Redis, and the interface survival time of each interface can be automatically generated. Redis is an in-memory database that provides the function of setting the survival time and expiration time of a key. Exemplarily, taking a day as each time segment of the plurality of time segments, the getMiguCoin interface is accessed 5 times on t-1 day, where t represents the current day and t-1 represents the previous day. When the statistics are performed on the previous day, the initial survival time is preset as 86400 for the first access, the remaining survival time is calculated as 6500, and it is indicated that the getMiguCoin interface is accessed for the first time at 79900s before 86400-6500=79900s, and the interface survival time of the getMiguCoin interface accessed this time is 6500s. The interface survival time (i.e., the interface ttl value) of the getMiguCoin interface accessed 5 times on t-1 day recorded by Redis is shown in FIG. 8. Figure 4

[0062] It should be noted that the user access data of each interface comprises the number of accesses of each interface and the access time of each interface.

[0063] As shown in FIG. 8, step 10 can comprise the following steps: Figure 5

[0064] Step 11: dividing the user access data into a plurality of time segments according to the access time of each interface to obtain the number of accesses of each interface in each time segment of the plurality of time segments and the interface survival time of each interface.

[0065] In this embodiment, the user access data is divided by days to obtain the number of accesses of each interface per day and the interface survival time.

[0066] Step 12: calculating the interface average survival time of each interface in each time segment of the plurality of time segments according to the number of accesses of each interface in each time segment of the plurality of time segments and the interface survival time of each interface.

[0067] ​​In the embodiment, the interface survival time of each interface in each time period according to the number of times of access is divided by the number of times of access of each interface in each time period, to obtain the interface average survival time of each interface in each time period. The size of the interface survival time of each interface is related to the time of access of each interface, and the greater the interface average survival time of each interface in a time period, the higher the probability of access of the interface in the time period to a certain extent. Exemplarily, the interface average survival time of a part of interfaces in a time period of the plurality of time periods is shown in Table 2 as follows:

[0068]

[0069] Step 13: According to the size of each time period in the plurality of time periods from the time period to which the interface currently accessed by the user belongs, the weight value of each time period in the plurality of time periods is calculated.

[0070] In the embodiment, the closer the user access time is to the current, the more valuable it is, and the closer it is to the time period to which the interface accessed by the user last time belongs, the higher the weight of the interface average survival time.

[0071] The calculation of the weight value of each time period in the plurality of time periods can include: calculating the weight factor of each time period in the plurality of time periods according to the preset time period of the user access data and the size of each time period in the plurality of time periods from the time period to which the interface currently accessed by the user belongs; calculating the weight value of each time period in the plurality of time periods according to the weight factor of each time period in the plurality of time periods.

[0072] Further, the weight factor of each time period in the plurality of time periods can be calculated by the following formula:

[0073]

[0074] Wherein, t is the time period in which the interface currently accessed by the user is located, and x is the number of time periods in the past from t. Exemplarily, the time period of the first behavior data of the user is 100 days, which is divided by days, t is the current day, x is the number of past days from t, t is the current day, for example, October 2, x = 1 represents yesterday, October 1, and the weight factor is fixed as 1, that is, W1 = 1, the weight factor of t-10 t-100 weight factor

[0075] Further, the weight value of each time period in the plurality of time periods can be calculated according to the weight factor of each time period in the plurality of time periods by the following formula:

[0076]

[0077] wherein w is the weight factor of each time period in the plurality of time periods, t is the time period in which the user is accessing the interface, and x is the number of time periods away from t.

[0078] Step 14: calculating the interface survival time threshold of each interface according to the interface average survival time of each interface in the plurality of time periods and the weight value of each time period in the plurality of time periods.

[0079] In this embodiment, the interface survival time threshold of each interface can be obtained by the following formula:

[0080] ∑ttl x *K x wherein ttl x is the interface average survival time of each interface in the plurality of time periods, k x is the weight value of each time period in the plurality of time periods.

[0081] Step 20: determining the target interface to be accessed by the user according to the interface survival time threshold of each interface.

[0082] In one embodiment of the present application, the target interface to be accessed by the user can be determined by calculating the average survival time threshold according to the interface survival time threshold of each interface, and determining the interface whose interface survival time threshold is greater than the average survival time threshold as the target interface to be accessed by the user. Through the above calculation method, the interface whose interface survival time threshold is greater than the average survival time threshold is the interface that has been accessed most frequently by the user recently, and according to the user behavior trend, it is determined that the user will have a greater possibility to access next time.

[0083] When the user access data of the interfaces comprises the access times of the interfaces and the access times of the interfaces, the target interface to be accessed by the user can also be determined according to the access times of the interfaces, the access times of the interfaces and the interface survival time threshold of the interfaces. When a user accesses a service provided by a backend service system, since the backend service system can provide more than one application or function, the same application or function can involve multiple pages and interfaces, and multiple pages and / or interfaces belonging to the same application or function have mutual dependency, i.e., there is a certain sequence after the access sequence. And according to the user's demand, when the same user accesses an application, the pages and interfaces involved each time can tend to a certain regularity. Therefore, when the user is accessing an interface, it has a greater possibility to access the interface having an association relationship with the interface and having an execution sequence after the interface. The interface having an association relationship with the interface currently accessed by the user and having an execution sequence after the interface currently accessed is determined as at least one target interface to be accessed by the user within a future preset time period. Exemplarily, when a user accesses the same application, the operations involved include: operation 1: opening a bookshelf, needing to read a book, showing how much book coupon amount and member information, needing to obtain user book coupon amount and member information and authentication related business data; operation 2: deducting book coupon amount, authenticating whether the user has the right to read the book, needing to obtain user book coupon amount and right benefit validity period data. And operation 3: reading a book by chapter, obtaining user read book chapter information. Among them, operation 1, operation 2 and operation 3 have an execution sequence association relationship.

[0084] In another embodiment of the present application, determining the target interface to be accessed by the user according to the access times of the interfaces, the access times of the interfaces and the interface survival time threshold of the interfaces can comprise the following steps:

[0085] Step 21: determining the interface currently accessed by the user according to the access times of the interfaces.

[0086] In this embodiment, the interface currently accessed by the user refers to the interface accessed by the user last time in the recorded user operation track.

[0087] Step 22: determining the time period and times of continuous access of the interfaces within a preset time length according to the access times of the interfaces and the access times of the interfaces.

[0088] Step 23: determining the interface that the interface lifetime threshold of which is less than the interface lifetime threshold of the interface currently accessed by the user, and the time period and the number of times of continuous access of which are the same as the time period and the number of times of continuous access of the interface currently accessed by the user as the target interface to be accessed by the user.

[0089] In one embodiment of the present application, the interface that the time period and the number of times of continuous access of which are the same as the time period and the number of times of continuous access of the interface currently accessed by the user is determined, so as to exclude the interface that belongs to the same application as the interface currently accessed by the user and has been accessed before the user accesses the interface currently accessed. That is, the access order of the interface is before the access order of the interface currently accessed. The determination of whether the number of times of access of the interface within a preset time length is the same as the number of times of access of the interface currently accessed does not include the current access of the interface currently accessed. For example, if the interface currently accessed is accessed from October 1 to October 15, the time period of access of the interface is from October 2 to October 7, and the number of times of access of the interface before the current access of the user is 10, then the interface that the time period of continuous access of which is from October 2 to October 7 and the number of times of access of which is 10 within the 6 days is determined as the interface that the time period and the number of times of continuous access of which are the same as the time period and the number of times of continuous access of the interface currently accessed by the user. By determining the interface that the time period and the number of times of continuous access of which are the same as the time period and the number of times of continuous access of the interface currently accessed by the user, the case that the interface that the time period and the number of times of continuous access of which are the same as the time period and the number of times of continuous access of the interface currently accessed by the user is excluded from the interface that belongs to the same application as the interface currently accessed by the user and has been accessed before the user accesses the interface currently accessed, and the interface that the time period and the number of times of continuous access of which are the same as the time period and the number of times of continuous access of the interface currently accessed by the user is not the same application as the interface currently accessed by the user.

[0090] It should be noted that the interface survival time threshold of the interface currently accessed by the user refers to the interface survival time threshold calculated including the interface survival time of the current access by the user, for example, the time period of the interface connection currently accessed by the user is from October 2nd to October 7th, and the number of accesses before this access in the 6 days is 10 times, so when calculating the interface survival time threshold of the interface currently accessed by the user, the interface survival time threshold of the interface accessed 11 times in 6 days is calculated. The interface survival time threshold indicates the number of recent accesses of the interface and the distance from the current access time of the user to a certain extent. By comprehensively judging the time period and the number of continuous accesses and the interface survival time threshold, the interface that the user is most likely to access and that belongs to the same application as the interface currently accessed by the user and is located after the currently accessed interface is obtained. Exemplarily, the interface currently accessed by the user is the getMiguCoin interface, the time period of the recent connection of the interface is from October 2nd to October 7th, and the number of accesses before this access in the 6 days is 10 times, and by calculation, a total of 20 interfaces have a recent connection access time period of 6 days and a number of accesses of 10 times in the 6 days. The interface survival time threshold of the getMiguCoin interface is 6399s, and the interface survival time threshold of the getMiguCoin interface is less than 6399s. The interface is at least one target interface to be accessed by the user.

[0091] Further, the embodiment of the present application can simultaneously determine the interface with the interface survival time threshold greater than the average survival time threshold and the interface with the same time period and number of continuous accesses as the time period and number of continuous accesses of the interface currently accessed by the user and the interface survival time threshold less than the interface survival time threshold of the interface currently accessed by the user as the target interface to be accessed by the user. The target interface can be one or more. The user access data of each interface is screened to obtain the interface that the user is most likely to access, and the corresponding target page template is generated according to the interface, which reduces the data of the target page template generated by the backend server, speeds up the speed of sending the target page template to the client, and saves the storage space of the client.

[0092] Step 30: obtaining the business data corresponding to the target interface, and generating the target page template corresponding to the target interface according to the business data.

[0093] In the embodiment, the target page template refers to a static page template. The business data refers to data required for generating the target page template corresponding to the target interface, and the business data is stored in a database. The process of generating the target page template corresponding to the target interface comprises: determining a preset page template corresponding to the business data corresponding to the target interface, replacing the business data corresponding to the target interface into a corresponding variable in the corresponding preset page template, and generating the target page template corresponding to the target interface. Exemplarily, the business operation involved in the target interface is operation 1 to operation 3 in step 20, wherein the business data, the target page template, the operation variable and the interface survival time involved in operation 1 to operation 3 are shown in Table 3 as follows:

[0094] Step Involving business data Template Operation variable Interface time-to-live threshold Opening bookshelf Book coupon, membership information Page template 1 var1, var2 6399 Deducting book coupon Book coupon, right effective period Page template 2 var1, var2 6266 Reading book Book chapter data Page template 3 var1 6000

[0095] Taking operation 1 as an example, the user book coupon quota and the member information and the authentication related business data are obtained. The book coupon quota in the operation is replaced into the template var1 variable, and the member information is replaced into the var2 variable, and the operation 1 static page template generation is completed. The preset page template corresponding to the operation is as follows:

[0096]

[0097] <div class="open-con">

[0098] <img src=" cdnmusic.cn v3 static img music service platinum-2.jpg"alt="">

[0099] <div class="btn btn-primary open-now j_btn_open">${var1}

[0100]

[0101]

[0102] <div class="open-con">

[0103] <img src={" cdnmusic.cn v3 static img music service platinum-1.jpg"}alt="">

[0104] <div class="btn btn-primary open-now j_btn_open">${var2}

[0105]

[0106] <script type="text javascript">

[0107] function(){

[0108] var s=document.createElement("script");

[0109] s.async=true;s.src=" / / cdnmusic.cn / v2 / zt / common / js / mg_sdc_load.js";

[0110] var s2=document.getElementsByTagName("script")[0];

[0111] s2.parentNode.insertBefore(s,s2);

[0112] }。

[0113] 进一步地,为了及时地清除目标页面模板,减轻客户端的内存,还将所述用户当前访问的接口的接口生存时间阈值作为目标页面模板的模板生存时间,并将所述模板生存时间与所述目标页面模板一同发送给客户端。以令客户端在模板生存时间结束之后,将所述目标页面模板进行清除。

[0114] 步骤40:将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。

[0115] 在本发明实施例,将所述目标页面模板发送至客户端,以令客户端进行存储。客户端在获取不到后端服务系统的数据时,客户端将存储的目标页面模板推送到瘦客户端。其中,客户端获取不到后端服务系统的数据包括两种情况,一种是传统容灾系统故障,即检测到传统容灾系统故障,备用容灾系统不可用,备用容灾系统即为传统容灾系统。另一种是主服务端与客户端失去断开通信。瘦客户端通过流量器将提前生成的目标页面模板解析为目标接口对应的目标页面,该目标页面为用户即将访问的瘦客户端页面,瘦客户端不需要再访问后端服务系统获取数据,还可以持续提供用户即将访问接口的业务服务,为系统恢复提供缓冲时间。提高用户体验感。

[0116] 进一步地,为了减轻客户端的内存负担以及数据安全,为预生成的目标页面模板设置模板生存阈值,并将该模板生存阈值同目标页面模板一同发送给客户端,以令客户端在目标页面模板的模板生存时间之后,将静态页面模板自动删除。进一步地,将用户当前访问的接口的接口生存时间阈值作为所述目标页面模板的模板生存时间。

[0117] 进一步地,为了保证数据的一致性,在后端服务系统恢复正常之后,还包括:从客户端从获取第二行为数据,所述第二行为数据包括在瘦客户端提供服务时,用户执行的操作信息;根据所述第二行为数据对数据库中与所述第二行为数据对应的业务数据进行更新。具体地,将所述第二行为数据按操作数据进行回放,得到与所述第二行为数据对应的业务数据,并对数据库中对应的业务数据进行更新。保证用户的操作行为产生的数据不丢失,同时在所有后台服务系统宕机的情况下还是能继续保证用户核心操作可用。

[0118] 本发明实施例提供的容灾方法,通过根据获取到的所述各个接口的用户访问数据和所述接口的接口生存时间,确定的接口生存时间阈值,根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口,获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板,将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。实现在主服务系统和传统的容灾系统均出现问题,或者后端服务系统与客户端无法通信,即客户端无法获取到后端服务系统的数据的情况下,可以继续给用户提供服务,为系统恢复提供缓冲时间,用户对系统问题无感知,提高用户体验感。

[0119] 如图6所述,本发明提供第二实施例提供一种容灾方法,应用于客户端,所述方法包括以下步骤:

[0120] 步骤50:获取目标页面模板。

[0121] 在本实施例中,目标页面模板通过以上步骤10到30得到,具体地实现方式与第一实施例相同,在此不再赘述。

[0122] 需要说明的是,本发明实施例的容灾方法主要是应对在客户端无法获取到后端服务系统的数据时,如在后端服务系统出现问题(如突然奔溃),且备用容灾系统也出现问题时,或者后端服务系统与客户端断开通信时,为了能够继续提供服务而提出。而系统奔溃一般的恢复时间并不会很长,最快可低至十几秒,最长可达几个小时。且目标页面模板是通过确定用户未来预设时间段内最有可能将要访问的至少一个目标接口得到的。而用户最有可能访问的目标接口是实时且动态变化的,为了保证确定的目标页面模板的准确性,目标页面模板的生成时间间隔是较短的,如几个小时生成一次,为了减轻客户端的内存负担以及数据安全,在后端服务系统正常运行,且用户正在访问该后端服务系统时,获取到目标页面模板之后,将目标页面模板存储到数据缓存模块中。当用户退出访问后端服务系统时,将数据缓存模块缓存的页面模板数据清空,保证用户数据安全。

[0123] 进一步地,所述方法还包括:获取目标页面模板对应的模板生存时间,在用户未退出系统,且目标页面模板的模板生存时间之后,将目标页面模板自动删除。

[0124] 步骤60:在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。

[0125] 在本实施例中,对用户在瘦客户端上执行的操作生成第二行为数据,并将第二行为数据进行缓存,待后端服务系统恢复正常后,将第二行为数据发送至后端服务系统,以令后端服务系统根据第二行为数据对数据库中与所述第二行为数据对应的业务数据进行更新。保证用户的操作行为产生的数据不丢失,同时在所有后台服务系统宕机的情况下还是能继续保证用户核心操作可用。示例性地,目标接口涉及的业务操作为步骤20中的操作1至操作3,对应的目标页面模板为1至3,将目标页面模板1至3推送给瘦客户端,瘦客户端上的浏览器将目标页面模板1至3解析为对应的目标页面,供用户进行访问,用户可以继续访问目标页面模板1至3,根据用户权益有效期看书,以及查看书券额度和会员信息。在瘦客户端上操作的业务数据如下表4所示:

[0126]

[0127]

[0128] 如表4所示,对于操作2,涉及用户扣减书券,用户点击"书券扣减”操作,执行扣减操作后会将用户执行的操作接口信息作为第二行为数据缓存下来,并在后端服务系统恢复正常后,发送给后端服务系统,以令后端服务系统进行信息更新。

[0129] 在本实施例中,客户端将存储的目标页面模板推送到瘦客户端,瘦客户端通过浏览器将提前生成的目标页面模板解析为用户即将访问的瘦客户端页面,在客户端获取后端服务系统的数据时,瘦客户端不需要再访问后端服务获取数据,还可以持续提供用户即将访问接口的业务服务,为系统恢复提供缓冲时间。提高用户体验感。

[0130] 图7示出了本发明实施例的容灾装置的结构示意图。如图7所示,该装置300包括:

[0131] 确定模块301,用于根据获取到的各个接口的用户访问数据和所述各个接口的接口生存时间,确定所述各个接口的接口生存时间阈值;

[0132] 预测模块302,用于根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口;

[0133] 第二生成模块303,用于获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板;

[0134] 执行模块304,用于将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。

[0135] 本发明实施例提供的容灾装置所用于执行的操作过程与前述方法实施大致相同,不再赘述。

[0136] 本发明实施例提供的容灾装置,通过根据获取到的所述各个接口的用户访问数据和所述接口的接口生存时间,确定的接口生存时间阈值,根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口,获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板,将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。实现在主服务系统和传统的容灾系统均出现问题,或者后端服务系统与客户端无法通信,即客户端无法获取到后端服务系统的数据的情况下,可以继续给用户提供服务,为系统恢复提供缓冲时间,用户对系统问题无感知,提高用户体验感。

[0137] 图8示出了本发明实施例的另一容灾装置的结构示意图。如图8所示,该装置400包括:

[0138] 获取模块401,用于获取目标页面模板。

[0139] 页面生成模块402,用于在检测到备用容灾环境故障时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。

[0140] 在本实施例中,客户端将存储的目标页面模板推送到瘦客户端,瘦客户端通过浏览器将提前生成的目标页面模板解析为用户即将访问的瘦客户端页面,瘦客户端不需要再访问后端服务获取数据,还可以持续提供用户即将访问接口的业务服务,为系统恢复提供缓冲时间。提高用户体验感。

[0141] 图9示出了本发明实施例的容灾服务器的结构示意图,该容灾服务器可以是为客户端提供服务后端服务器,本发明具体实施例并不对该容灾服务器的具体实现做限定。

[0142] 如图9所示,该容灾服务器可以包括:处理器(processor)502、通信接口(Communications Interface)504、存储器(memory)506、以及通信总线508。

[0143] 其中:处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。通信接口504,用于与其它设备比如客户端或其它服务器等的网元通信。处理器502,用于执行程序510,具体可以执行上述用于信息处理方法实施例中的相关步骤。

[0144] 具体地,程序510可以包括程序代码,该程序代码包括计算机可执行指令。

[0145] 处理器502可能是中央处理器CPU,或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit),或者是被配置成实施本发明实施例的一个或多个集成电路。容灾服务器包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个CPU;也可以是不同类型的处理器,如一个或多个CPU以及一个或多个ASIC。

[0146] 存储器506,用于存放程序510。存储器506可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。

[0147] 程序510具体可以被处理器502调用使容灾服务器执行以下操作:

[0148] 根据获取到的各个接口的用户访问数据和所述各个接口的接口生存时间,确定所述各个接口的接口生存时间阈值;

[0149] 根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口;

[0150] 获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板;

[0151] 将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。

[0152] 本发明实施例提供的容灾服务器所用于执行的操作过程与前述方法实施大致相同,不再赘述。

[0153] 本发明实施例提供的容灾服务器,通过根据获取到的所述各个接口的用户访问数据和所述接口的接口生存时间,确定的接口生存时间阈值,根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口,获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板,将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。实现在主服务系统和传统的容灾系统均出现问题,或者后端服务系统与客户端无法通信,即客户端无法获取到后端服务系统的数据的情况下,可以继续给用户提供服务,为系统恢复提供缓冲时间,用户对系统问题无感知,提高用户体验感。

[0154] 本发明实施例提供了一种计算机存储介质,所述存储介质存储有至少一可执行指令,该可执行指令在容灾服务器上运行时,使得所述容灾服务器执行上述任意方法实施例中的容灾方法。

[0155] 可执行指令具体可以用于使得容灾服务器执行以下操作:

[0156] 根据获取到的各个接口的用户访问数据和所述各个接口的接口生存时间,确定所述各个接口的接口生存时间阈值;

[0157] 根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口;

[0158] 获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板;

[0159] 将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。

[0160] 本发明实施例提供的计算机存储介质所存储的可执行指令所用于执行的操作过程与前述方法实施大致相同,不再赘述。

[0161] 本发明实施例提供的计算机存储介质,通过根据获取到的所述各个接口的用户访问数据和所述接口的接口生存时间,确定的接口生存时间阈值,根据所述各个接口的接口生存时间阈值确定用户将要访问的目标接口,获取所述目标接口对应的业务数据,并根据所述业务数据生成所述目标接口对应的目标页面模板,将所述目标页面模板发送至客户端,以令所述客户端在获取不到后端服务系统的数据时,通过瘦客户端对所述目标页面模板进行解析获取所述目标接口对应的目标页面。实现在主服务系统和传统的容灾系统均出现问题,或者后端服务系统与客户端无法通信,即客户端无法获取到后端服务系统的数据的情况下,可以继续给用户提供服务,为系统恢复提供缓冲时间,用户对系统问题无感知,提高用户体验感。

[0162] 本发明实施例提供了一种计算机程序,所述计算机程序可被处理器调用使容灾服务器执行上述任意方法实施例中的容灾方法。

[0163] 本发明实施例提供了一种计算机程序产品,计算机程序产品包括存储在计算机可读存储介质上的计算机程序,计算机程序包括程序指令,当程序指令在计算机上运行时,使得所述计算机执行上述任意方法实施例中的容灾方法。

[0164] 在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明实施例也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

[0165] 在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。

[0166] 类似地,应当理解,为了精简本发明并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。

[0167] 本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和 / 或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

[0168] 此外,本领域的技术人员能够理解,尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

[0169] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词"包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词"一”或"一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤,除有特殊说明外,不应理解为对执行顺序的限定。< / script>

Claims

1. A disaster recovery method, characterized in that, include: Based on the user access data of each interface and the interface lifespan of each interface, determine the interface lifespan threshold of each interface. The target interface to be accessed by the user is determined based on the interface lifetime threshold of each interface; wherein, an average lifetime threshold is calculated based on the interface lifetime threshold of each interface, and the interface whose interface lifetime threshold is greater than the average lifetime threshold is determined as the target interface to be accessed by the user. Obtain the business data corresponding to the target interface, and generate the target page template corresponding to the target interface based on the business data; The target page template is sent to the client so that when the client cannot obtain data from the backend service system, it can parse the target page template through a thin client to obtain the target page corresponding to the target interface.

2. The method according to claim 1, characterized in that, The user access data for each interface includes the number of times each interface is accessed and the access time for each interface. The step of determining the interface lifespan threshold for each interface based on the obtained user access data and the interface lifespan of each interface further includes: The user access data is divided into multiple time periods based on the access time of each interface, and the number of times each interface is accessed and the interface lifespan in each of the multiple time periods are obtained. Based on the number of times each interface is accessed in each of the multiple time periods and the interface lifespan of each interface, calculate the average interface lifespan of each interface in each of the multiple time periods. Calculate the weight value of each of the multiple time periods based on the distance between each time period and the time period to which the user's current access interface belongs; The interface survival time threshold of each interface is calculated based on the average interface survival time of each interface in each of the multiple time periods and the weight value of each time period in the multiple time periods.

3. The method according to claim 2, characterized in that, The step of calculating the weight value of each of the multiple time periods based on the distance between each time period and the time period to which the user's currently accessed interface belongs further includes: Calculate the weight factor for each of the multiple time periods based on the preset time period and the distance between each time period and the time period to which the user's current access interface belongs. The weight value of each time period is calculated based on the weight factor of each time period among the plurality of time periods.

4. The method according to claim 1, characterized in that, The user access data for each interface includes the number of times each interface has been accessed and the access time for each interface. The step of determining the target interface that the user will access based on the interface lifespan threshold of each interface further includes: The target interface that the user will access is determined based on the number of times each interface is accessed, the access time of each interface, and the interface lifespan threshold of each interface.

5. The method according to claim 4, characterized in that, The step of determining the target interface that the user will access based on the number of times each interface is accessed, the access time of each interface, and the interface lifespan threshold of each interface further includes: The interface currently accessed by the user is determined based on the access time of each interface. Based on the number of times each interface is accessed and the access time of each interface, determine the time period and number of times each interface is continuously accessed within a preset duration. Among the various interfaces, the interface whose interface lifespan threshold is less than the interface lifespan threshold of the interface currently accessed by the user, and whose consecutive access time period and number of times are the same as those of the interface currently accessed by the user, is determined to be the target interface that the user will access.

6. The method according to any one of claims 1 to 3, characterized in that, After obtaining the business data corresponding to the target interface and generating the target page template corresponding to the target interface based on the business data, the method further includes: using the interface lifetime threshold of the interface currently accessed by the user as the template lifetime of the target page template.

7. A disaster recovery device, characterized in that, include: The determination module is used to determine the interface lifetime threshold of each interface based on the user access data of each interface and the interface lifetime of each interface. The prediction module is used to determine the target interface that the user will access based on the interface lifetime threshold of each interface; wherein, an average lifetime threshold is calculated based on the interface lifetime threshold of each interface, and the interface whose interface lifetime threshold is greater than the average lifetime threshold is determined to be the target interface that the user will access. The generation module is used to obtain the business data corresponding to the target interface and generate the target page template corresponding to the target interface based on the business data. The execution module is used to send the target page template to the client, so that when the client cannot obtain data from the backend service system, it can parse the target page template through a thin client to obtain the target page corresponding to the target interface.

8. A disaster recovery server, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the disaster recovery method as described in any one of claims 1-6.

9. A computer storage medium storing at least one executable instruction, which, when executed on a server, causes the server to perform the operation of the disaster recovery method as described in any one of claims 1-6.

Citation Information

Patent Citations

  • Page service disaster recovery methods and devices and electronic equipment

    CN108156013A

  • Page display method and device, equipment and readable storage medium

    CN110096659A