METHOD AND DEVICE FOR PROCESSING DATA

Description

[0001] The present application claims priority to Chinese Patent Application No. 201610490808.1, filed with the Chinese Patent Office on June 28, 2016 and entitled "METHOD AND DEVICE FOR PROCESSING DATA".

TECHNICAL FIELD

[0002] The present application relates to the field of computer technologies, and in particular, to a method and a device for processing data.

BACKGROUND

[0003] Currently, in scenarios such as live streaming and live TV, a data live broadcast is widely applied (the data live broadcast is real-time display of data). Users can learn of corresponding information on time through the data live broadcast.

[0004] For example, a passenger flow volume in the Spring Festival transportation peak time can be displayed during the live TV, and therefore, a user who watches the live TV can learn of the corresponding passenger flow volume in the Spring Festival transportation peak time. For another example, access traffic, a sales volume, etc. of a shopping website can be displayed on the website, and therefore, a user who accesses the shopping website can learn of the access traffic and the sales volume on a corresponding page.

[0005] The live display of data is usually implemented by a live data service (the live data service runs on a corresponding server) on the server (or a server cluster). The live data service obtains data from a data source in real time, performs corresponding statistics processing to obtain live data, and sends the live data to a terminal device for display. It is worthwhile to note that an actual data live display process is essentially a delay live broadcast. To be specific, there is a time difference between data displayed by the terminal device and data generated by the server, in other words, the live data displayed by the terminal device is usually generated by the server n seconds before.

[0006] However, in actual application scenarios, an exception may occur when the live data service runs (e.g., counting error or lagging), and corresponding service staff need to perform troubleshooting and recovery.

[0007] In the existing technology, when an exception occurs in the live data service, the server switches to a backup live data service to replace the abnormal live data service.

[0008] However, a "jump" or a rollback may occur in real-time data in the method of switching to the backup service for the following reason: The live data service running on the server buffers real-time data obtained from the data source, to perform corresponding statistics processing. If an exception occurs in the live data service and the live data service is replaced with the backup live data service, the real-time data stored in a buffer of the live data service is cleared, and the backup live data service buffers the real-time data again to perform statistics processing after the backup live data service runs. In this case, data statistics processing is repeatedly performed, and therefore, a rollback occurs in the data live broadcast.

[0009] Using access traffic data as an example, an original live data service buffers real-time data a₉₀₀ to a₉₆₀ obtained from the data source, and performs statistics processing on the 60 pieces of data to generate access traffic data 900 to 960. Assume that the live data server generates access traffic data 930 to 950 based on real-time data a₉₃₀ to a₉₅₀, and sends the access traffic data to the terminal device for display. As shown in FIG. 1a, access traffic currently displayed by the terminal device based on the access traffic data sent by the server is 935.

[0010] If an exception occurs when the live data service generates access traffic data 955, the server stops the abnormal live data service, and enables a backup live data service to replace the abnormal live data service. After the backup live data service runs, the data buffered by the original live data service is cleared, and the backup live data service buffers the real-time data a₉₀₀ to a₉₆₀ again to perform statistics processing, generates access traffic data 900 to 920, and sends the access traffic data to the terminal device for display. In this case, after the terminal device displays access traffic 950 based on the access traffic data received previously (as shown in FIG. 1b), access traffic is rolled back to 900 based on the access traffic data 900 to 920 received recently, and the terminal device performs display starting from 900, as shown in FIG. 1c. It can be seen that this is the data rollback.

[0011] Apparently, such a method affects the live data displayed by the terminal device.

[0012] US 2016/127795 describes a method providing searchable streaming video broadcasts via an interactive media server. The interactive media server generates a live broadcast video stream for each of a plurality of interactive media sessions and a video provider server providing a connection to the live broadcast video stream for viewing. The method comprises receiving an interactive media events stream for each interactive media session from the interactive media server, generating statistics data for each interactive media session based upon the events stream, and generating a searchable index of a directory of the live broadcast video streams, the searchable index including a plurality of entries, each entry including (a) a link to the live broadcast video stream for a corresponding interactive media session provided by the video provider server, and (b) metadata associated with the corresponding interactive media session, the metadata generated based upon the statistics data for the corresponding interactive media session.

[0013] US 2005/084237 describes systems and methods for managing frame rates during multimedia playback. An ideal playback timing associated with video data is determined. If an actual playback timing of the video data lags the ideal playback timing, a frame rate associated with the video data is varied using a smoothing function to recover toward the ideal playback timing. An iterative frame-dropping algorithm is applied to vary the frame rate in accordance with the smoothing function. The smoothing function incorporates as a variable an average delay associated with playback of frames in the video data.

[0014] US 2014/173055 describes a media streaming method and a device using the same. A method for smooth and flawless playback of live media streaming in dynamic network environment is described. When network congestion occurs for a period, a media receiver may play media data as more as possible by adjusting the transmission order of media data meaningful to the receiver or a provider for providing the media data. An exemplary method for smooth and flawless playback of live media streaming includes caching a certain amount of media data and then playing them at an appropriate speed to catch up to the progress of the live media streaming, or includes dynamically changing bit rates of the live media streaming in time by the provider to meet the most acceptable bit rate according to the network environment between the provider and the receiver.

SUMMARY

[0015] Implementations of the present application provide a method for processing data, to reduce jumps, rollbacks, etc. caused by an exception in live data in the existing technology.

[0016] Implementations of the present application provide a device for processing data, to reduce jumps, rollbacks, etc. caused by an exception in live data in the existing technology.

[0017] The following technical solutions are used in the implementations of the present application:
An implementation of the present application provides a method for processing data, including the following: monitoring, by a server, a running status of a live data service; determining predicted recovery duration when it is detected that an exception occurs in the running status; calculating a first rate based on the predicted recovery duration; and sending the calculated first rate to a terminal device, so that the terminal device displays live data based on the first rate.

[0018] An implementation of the present application further provides a method for processing data, including the following: receiving, by a terminal device, a first rate sent by a server, where the first rate is calculated by the server based on predicted recovery duration that is determined by the server when the server detects that an exception occurs in a running status; and displaying live data based on the first rate.

[0019] An implementation of the present application provides a device for processing data, including the following: a monitoring module, configured to monitor a running status of a live data service; a prediction module, configured to determine predicted recovery duration when it is detected that an exception occurs in the running status; a calculation module, configured to calculate a first rate based on the predicted recovery duration; and a sending module, configured to send the calculated first rate to a terminal device, so that the terminal device displays live data based on the first rate.

[0020] An implementation of the present application further provides a device for processing data, including the following: a receiving module, configured to receive a first rate sent by a server, where the first rate is calculated by the server based on predicted recovery duration that is determined by the server when the server detects that an exception occurs in a running status; and a display module, configured to display live data based on the first rate.

[0021] The at least one technical solution used in the implementations of the present application can achieve the following beneficial effects:

[0022] When detecting that an exception occurs in the live data service, the server determines the predicted recovery duration, calculates the first rate based on the predicted recovery duration, and sends the first rate to the terminal device. The first rate can be used to control a display rate of displaying the live data by the terminal device. In other words, the display rate of displaying the live data by the terminal device can be decreased with the first rate, and the terminal device decreases the rate of displaying the live data based on the first rate. Therefore, it takes more time for the terminal device to display locally stored live data that is to be displayed. As such, on a server side, service staff have enough time to perform troubleshooting and recovery on the live data service running on the server.

[0023] In comparison with a method of switching to a backup live data service in the existing technology, the original live data service can be reserved (no service switching is performed) in the method of the present application. After the live data service returns to normal, the live data service further performs statistics processing based on real-time data buffered by the live data service. In other words, the real-time data buffered by the live data service is not cleared if no live data service switching is performed. As such, no exceptions such as a live data rollback and a live data jump occur.

[0024] In addition, an end user is not significantly aware of a change such as a jump, a rollback, or stagnancy of the live data.

BRIEF DESCRIPTION OF DRAWINGS

[0025] The accompanying drawings here are used to provide further understanding of the present application, and constitute a part of the present application. Example implementations of the present application and descriptions of the implementations are used to explain the present application. In the accompanying drawings:

FIG. 1a to FIG. 1c are schematic diagrams illustrating a data live broadcast in the existing technology;

FIG. 2a is a schematic diagram illustrating a data processing process, according to an implementation of the present application;

FIG. 2b to FIG. 2d are schematic diagrams illustrating a process of adjusting a display rate of a terminal device by a server, according to an implementation of the present application;

FIG. 3 is a schematic structural diagram illustrating a device for processing data on a server side, according to an implementation of the present application; and

FIG. 4 is a schematic structural diagram illustrating a device for processing data on a terminal device side, according to an implementation of the present application.

DESCRIPTION OF IMPLEMENTATIONS

[0026] To make the objectives, technical solutions, and advantages of the present application clearer, the following clearly and comprehensively describes the technical solutions of the present application with reference to the specific implementations and the corresponding accompanying drawings of the present application.

[0027] As described above, in a data live broadcast scenario, live data generated by a server is constantly sent to a terminal device, so that the terminal device can perform data live display based on the live data. However, after an exception occurs in a live data service on a server side, the server switches to a backup service, which causes a change such as a data rollback or a data jump in the data live broadcast process, thereby affecting normal running of the data live broadcast.

[0028] In view of this, a method for reducing data rollbacks or data jumps in a data live broadcast process is needed. Therefore, the implementations of the present application provide a method for processing data, so that no data rollback or data jump occurs even when an exception occurs in a live data service on a server, thereby ensuring normal running of a data live broadcast.

[0029] In the implementations of the present application, the server can be a server that can provide a live data service, including but not limited to a website server, a data center server, etc. The server can work independently (only one server provides a live data service), or can work in a cluster. The terminal device can be a terminal device of a user with a data display function, for example, a mobile phone, a tablet computer, a smart TV, or a computer. In some actual application scenarios, the terminal device can be a large display device (e.g., a device with a large screen in a live hall).

[0030] In addition, it is worthwhile to note that, the live data service on the server usually generates live data in batches in a process of performing statistics processing to generate live data. In other words, the live data service generates a certain amount of live data at a very short time interval. For example, the live data service generates current 2000 pieces of live data after 15 ms of the last generation of live data. Certainly, in practice, a time interval of generating live data by the live data service each time and an amount of live data generated each time are related to real-time data of a data source and running load of the server.

[0031] When the live data service on the server runs normally, a process of displaying live data by the terminal device is detailed as follows:
First, the terminal device interacts with the server to obtain live data.

[0032] In a method of the implementations of the present application, the terminal device periodically obtains the live data from the server at a very short time interval. For example, the terminal device obtains the live data from the server every 0.5s. In this method, the terminal device actively obtains the data from the server. In practice, this method is applicable to scenarios that the server provides a data live service for many terminal devices.

[0033] In another method, the terminal device keeps a persistent connection to the server. After the live data service on the server generates live data each time, the server sends the newly generated live data to the terminal device through the persistent connection established between the server and the terminal device. Certainly, in practice, the method of establishing a persistent connection between the terminal device and the server is more applicable to scenarios such as a data live hall and a centralized data live broadcast. When there are many terminal devices, work load of the server can be significantly increased if the server keeps a persistent connection to each terminal device. Certainly, in practice, if the server can bear enough work load, the method of establishing a persistent connection can also be used in the case of many terminal devices. Implementations are not limited in the present application.

[0034] After obtaining the live data, the terminal device displays the live data.

[0035] Based on the previously described content, the live data obtained by the terminal device is a batch of live data (the batch of live data includes a plurality of pieces of data) generated by the data live service. After obtaining the live data, the terminal device locally buffers the live data, and displays the live data based on a rate specified by the server. For example, in a data live broadcast process of website access traffic, a batch of access traffic data obtained by the terminal device from the server includes access traffic data 300 to 350, and the server specifies that a display rate of the access traffic data is to change every 1s (to increase five pieces of data each time). In this case, if the terminal device displays access traffic 300 at 08:01:10, access traffic displayed by the terminal device at 08:01: 11 is 305.

[0036] The technical solutions provided in the implementations of the present application are described in detail below with reference to the previously described content.

[0037] FIG. 2a illustrates a data processing process in the implementations of the present application, and the process specifically includes the following steps.

[0038] S201. A server monitors a running status of a live data service.

[0039] The live data service runs on the server. The live data service obtains real-time data from a data source, and performs corresponding statistics processing to generate live data for display. In practice, the live data service processes lots of data. Therefore, in a running process, there may be a back end call conflict, or operation may be choppy because of many operations, resulting in abnormal running of the live data service. It can be understood that, after an exception occurs in the live data service, live data generated by the live data service is abnormal.

[0040] Therefore, the server monitors the running status of the live data service, to take corresponding measures when an exception occurs in the live data service, thereby reducing exceptions such as an obvious jump or rollback of live data displayed by a terminal device.

[0041] S202. Determine predicted recovery duration when it is detected that an exception occurs in the running status.

[0042] In practice, if an exception occurs in the live data service, corresponding service staff can perform operations such as troubleshooting and recovery. It takes some time to perform the troubleshooting or recovery operation. Therefore, the server determines duration (the predicted recovery duration) between occurrence of an exception in the live data service and a predicted recovery time.

[0043] S203. Calculate a first rate based on the predicted recovery duration.

[0044] It is worthwhile to note that the first rate in this implementation of the present application can be a change rate of the live data. For example, the live data changes every ns.

[0045] Alternatively, the first rate can be a magnitude of each change of the live data. For example, n pieces of live data are increased once or n pieces of live data are decreased once.

[0046] Alternatively, the first rate can be a time lapse rate. To be specific, an actual time is used as a reference, and the first rate is determined by multiplying a rate coefficient by a unit time. For example, it can be specified that 1s for the first rate=1.5^∗1s in the actual time. In other words, 1s in the terminal device is 1.5s in the actual time with the first rate. Certainly, the optional methods of the first rate do not constitute a limitation on the present application.

[0047] Considering the previously described content, when the terminal device displays the live data, because a display rate is specified by the server, the terminal device displays the live data obtained by the terminal device based on the display rate specified by the server. Therefore, when an exception occurs in the live data service on the server, if the display rate of the live data is decreased for the terminal device, the service staff can have more time to perform troubleshooting or recovery on the live data service.

[0048] For example, if normally the terminal device locally stores access traffic data 300 to 350, and the terminal device performs live display by updating live data every 1s (assume that five pieces of access traffic data are increased once), duration of 10s is usually needed for displaying the access traffic 300 to 350 by the terminal device. If an exception occurs in the live data service on the server, and the server learns of the first rate through calculation based on the predicted recovery duration: to change every 2s (to increase five pieces of access traffic data), duration of 20s is needed for displaying the access traffic 300 to 350 by the terminal device based on the first rate.

[0049] It can be seen from the previous example that, with the first rate, the display duration of displaying the live data is 10s more than that in a normal state. In the case, the back end service staff have 10s to perform troubleshooting or recovery on the live data service. Certainly, the previous example merely describes a function of the first rate. In practice, the first rate can be predicted based on the predicted recovery duration.

[0050] S204. Send the calculated first time lapse rate to a terminal device, so that the terminal device displays live data based on the first rate.

[0051] After obtaining the first rate as described above, the server sends the first rate to the terminal device, so that the terminal device displays the live data obtained by the terminal device based on the first rate. For details, references can be made to the previous example.

[0052] In the previous steps, when detecting that an exception occurs in the live data service, the server determines the predicted recovery duration, calculates the first rate based on the predicted recovery duration, and sends the first rate to the terminal device. The first rate can be used to control the display rate of displaying the live data by the terminal device. In other words, the display rate of displaying the live data by the terminal device can be decreased with the first rate, and the terminal device decreases the rate of displaying the live data based on the first rate. Therefore, it takes more time for the terminal device to display locally stored live data that is to be displayed. As such, on a server side, the service staff have enough time to perform troubleshooting and recovery on the live data service running on the server.

[0053] In comparison with a method of switching to a backup live data service in the existing technology, the original live data service can be reserved (no service switching is performed) in the method of the present application. After the live data service returns to normal, the live data service further performs statistics processing based on real-time data buffered by the live data service. In other words, the real-time data buffered by the live data service is not cleared if no live data service switching is performed. As such, no exceptions such as a live data rollback and a live data jump occur.

[0054] It is worthwhile to note that the steps in the method provided in the previous implementation can be performed by one device, specifically, the server.

[0055] The following describes in detail a case when an exception occurs in the live data service.

[0056] It is worthwhile to note that, in practice, when an exception occurs in the live data service, troubleshooting or recovery is usually performed on the abnormal live data service manually. In this process, the corresponding service staff determine predicted recovery time. Certainly, in an optional method, the server provides a corresponding diagnosis interface, and the interface provides an option of the predicted recovery time. When performing troubleshooting or recovery, the service staff can enter the corresponding predicted recovery time in the option.

[0057] In this implementation of the present application, the determining predicted recovery duration specifically includes the following: determining a predicted recovery time; determining a time when an exception occurs in the running status of the live data service; and determining the predicted recovery duration based on the determined predicted recovery time and the determined time.

[0058] For example, if the time when an exception occurs in the live data service is 12:08:02, and the recovery time predicted by the service staff is 12:08:40, the predicted recovery duration is 38s.

[0059] After the predicted recovery duration is determined, the first time lapse rate can be further calculated. Specifically, a time of stopping displaying the live data by the terminal device when an exception occurs in the running status of the live data service is determined, and the first rate is determined based on the determined time of stopping displaying the live data by the terminal device and the predicted recovery duration.

[0060] Longer predicted recovery duration indicates a lower first rate. For ease of description, the predicted recovery duration is referred to as T_yu below.

[0061] It is worthwhile to note that, when an exception occurs in the live data service, the server stops sending live data to the terminal device, and the terminal device displays local live data at the original display rate. It can be understood after a period of time, the terminal device can complete displaying local live data that is not displayed. Therefore, the terminal device stops updating live data after displaying the last live data (because in this case, the terminal device has displayed all live data locally buffered, and has not obtained new live data provided by the server), which is represented as follows: the live data displayed by the terminal device stops at a value. For example, access traffic displayed by the terminal device stops at 500.

[0062] Therefore, in this implementation of the present application, when an exception occurs in the running status of the live data service, the server determines duration between a current time and the time of stopping updating the live data by the terminal device (for ease of description, duration between occurrence of an exception in the live data service and stopping updating the live data by the terminal device is referred to as T_c1 below). Certainly, in an optional method of this implementation of the present application, the display rate of displaying the live data by the terminal device is specified by the server, and therefore, the server can learn of the display rate of the terminal device. In addition, because a time when the live data service on the server performs statistics processing to generate live data each time is recorded (e.g., in a corresponding data log), and an amount of live data corresponding to the time is also recorded, the server can determine a time of generating live data that is sent to the terminal device last time, and therefore, the server can determine an amount of live data stored in the terminal device. It can be understood that both the amount of live data stored in the terminal device and the display rate are known, and therefore, the server can determine T_c1.

[0063] T_c1 can be considered as time duration for displaying the live data by the terminal device when the display rate is unchanged, but after T_c1, the terminal device stops updating the live data, which causes a display exception to the data live broadcast. Because T_yu is the time duration that the back end service staff may need to perform recovery, in this implementation of the present application, the first rate is determined based on T_c1 and T_yu, so that T_c1 is prolonged with the first rate.

[0064] Assume that a display rate of displaying access traffic data of a website by the terminal device is to increase 10 pieces of data every second, and access traffic data obtained by the terminal device from the server currently includes 1000 to 1200. If an exception occurs in the live data service running on the server when the display displays the access traffic 1000, the terminal device cannot continue to obtain access traffic data from the server. It can be seen that, duration T_c1 of 20s is needed for displaying the access traffic 1000 to the access traffic 1200 by the terminal device at the display rate. However, because the predicted recovery duration T_yu is 40s, the current display rate of the terminal device needs to be adjusted to reduce data stagnancy after 20s.

[0065] In this example, first rate=T_c1/T_yu^∗current display rate=0.5*10=5.

[0066] In other words, the first rate is to increase five pieces of data every second. Apparently, duration needed for displaying the access traffic 1000 to the access traffic 1200 by the terminal device based on the first rate is 40s, and the original display duration is prolonged.

[0067] Certainly, the previous method is a description of a case that the first rate indicates a change to an amount of live data. If the first rate is a time lapse rate, the first rate can be calculated in the following way:

[0068] First rate (time lapse rate of the client)=[(time difference between the server and the client*client time)/T_yu]+original time lapse rate of the client.

[0069] The previously described content is a process of adjusting the display rate of the terminal device when an exception occurs in the live data service. Specifically, as shown in FIG. 2b, in the previous process, the display rate of the terminal device is essentially decreased based on the calculated first rate. In actual application scenarios, after the back end service staff recover the live data service, the live data service normally performs statistics processing on real-time data to generate corresponding live data, and sends the live data to the terminal device. The terminal device displays the live data at a relatively low display rate based on the first rate. After the terminal device can normally receive live data sent by the server, the terminal device can increase the display rate to adapt to new live data.

[0070] The following describes in detail a process after the live data service is recovered.

[0071] In the previous recovery process, the service staff predicts a time (the predicted recovery time) when the live data service can be recovered. In actual application scenarios, a time difference may exist between an actual recovery time of the live data service and the recovery time predicted by the service staff. For example, if the recovery time predicted by the service staff is 12:08:40, and the live data service is actually recovered at 12:07:50, a time difference of 50s exists between the two times.

[0072] In practice, because the first rate is determined based on the predicted recovery duration, if a time difference exists between the actual recovery time of the live data service and the predicted recovery time, an increment in the display rate of the terminal device needs to be determined based on the time difference, that is, a second rate is determined.

[0073] Therefore, after the live data service is recovered, the method further includes the following: determining a recovery time difference when it is detected that the running status of the live data service returns to normal; calculating a second rate based on the recovery time difference; and sending the calculated second time lapse rate to the terminal device, so that the terminal device displays the live data based on the second rate.

[0074] Certainly, it can be seen from the previously described content that the determining a recovery time difference specifically includes the following: determining a time when the running status of the live data service returns to normal; and determining the recovery time difference based on the time when the running status of the live data service returns to normal and the predicted recovery time.

[0075] In the previous example, if an exception occurs in the live data service at 12:01:00, the predicted recovery time is 12:01:40 because the predicted recovery duration is 40s, but the actual recovery time of the live data service is 12:01:20 (new access traffic data is generated at this time). In other words, the live data service is recovered 20s earlier than the predicted recovery time. In this case, the terminal device has 100 pieces of access traffic data that is not displayed. After the live data service runs normally, the server needs to adjust the current display rate (the first rate) of the terminal device so that the terminal device can adapt to new access traffic data generated by the live data service after the live data service runs normally. In this case, the terminal device accelerates display of remaining access traffic data (in other words, the second rate is generated).

[0076] Certainly, it can be understood that a smaller recovery time difference indicates a higher second rate.

[0077] Likewise, the previous method is a description of a case that the second rate indicates a change to an amount of live data. If the second rate is a time lapse rate, the second rate can be calculated in the following way:
Second rate (time lapse rate of the client)=[(actual recovery time-client time)^∗T_yu/actual recovery time difference]+first rate.

[0078] The process of adjusting the display rate of the terminal device when the live data service returns to normal is described above. A detailed process is shown in FIG. 2c.

[0079] Certainly, after the terminal device accelerates display of remaining live data (and receives new live data), the server sends a normal rate to the terminal device again, so that the terminal device displays live data based on the normal rate. This process is shown in FIG. 2d.

[0080] In addition, it is worthwhile to note that in actual application scenarios, the actual recovery time of the live data service can be later than the predicted recovery time. For example, if an exception occurs in the live data service at 12:01:00, and the predicted recovery time is 12:01:40, but the live data service actually returns to normal at 12:02:20. Apparently, in this case, if the terminal device displays live data only based on the first rate calculated in the previous method, live data display may still be stopped. Therefore, in this implementation of the present application, the first rate can be dynamically adjusted to reduce such cases. In other words, a plurality of first rates can be calculated and sent to the terminal device.

[0081] For example, continuing with the previous example about the first rate, it can be seen from the previous example that a first rate generated the first time is to increase five pieces of access traffic data every second, and the live data service is still not recovered after 10s (in this case, access traffic displayed by the terminal device is 1150, and 150 pieces of access traffic data are left and can be all displayed in 30s). Therefore, the server can calculate a new first rate (which is used to prolong display duration of the terminal device). If the new first rate is to increase two pieces of access traffic data every second, the display duration of the terminal device can be prolonged to 75s.

[0082] Certainly, the previous example is merely a possible method for actual application scenarios in this implementation of the present application, and does not constitute a limitation on the present application.

[0083] In the previously described content, when an exception occurs in the live data service on the server, the server can decrease a current display rate of the terminal device, and prolong troubleshooting or recovery time of the back end staff, without making an end user significantly aware of a change such as a jump, a rollback, or stagnancy of the live data. Correspondingly, after the live data service is recovered, the display rate of the terminal device can be increased, so that the terminal device can adapt to new live data sent by the server.

[0084] Certainly, on a terminal device side, the present application provides a method for processing data. Specifically, when an exception occurs in a live data service on a server, the method includes the following steps.

[0085] Step 1: A terminal device receives a first rate sent by the server, where the first rate is calculated by the server based on predicted recovery duration that is determined by the server when the server detects that an exception occurs in a running status.

[0086] Step 2: Display live data based on the first rate.

[0087] When the live data service on the server returns to normal, the method further includes the following: receiving, by the terminal device, a second rate sent by the server, where the second rate is calculated by the server based on a recovery time difference that is determined by the server when the server detects that the running status of a live data service returns to normal; and displaying the live data based on the second rate.

[0088] For an implementation process that the terminal device side obtains the live data and displays the live data based on different rates, references can be made to the previously described content. Details are omitted here.

[0089] The method for processing data provided in the implementations of the present application is described above. Based on the same idea, an implementation of the present application further provides a device for processing data.

[0090] As shown in FIG. 3, the device for processing data is disposed on a server side, and the device includes the following: a monitoring module 301, configured to monitor a running status of a live data service; a prediction module 302, configured to determine predicted recovery duration when it is detected that an exception occurs in the running status; a calculation module 303, configured to calculate a first rate based on the predicted recovery duration; and a sending module 304, configured to send the calculated first rate to a terminal device, so that the terminal device displays live data based on the first rate.

[0091] Specifically, the prediction module 302 determines a predicted recovery time, determines a time when an exception occurs in the running status of the live data service, and determines the predicted recovery duration based on the determined predicted recovery time and the determined time.

[0092] Further, the prediction module 302 determines a time of stopping updating the live data by the terminal device when an exception occurs in the running status of the live data service, and determines the first rate based on the determined time of stopping displaying the live data by the terminal device and the predicted recovery duration.

[0093] Longer predicted recovery duration indicates a lower first rate.

[0094] The device further includes the following: a recovery module 305, configured to determine a recovery time difference when it is detected that the running status of the live data service returns to normal; calculate a second rate based on the recovery time difference; and send the calculated second time lapse rate to the terminal device, so that the terminal device displays the live data based on the second rate.

[0095] Further, the recovery module 305 determines a time when the running status of the live data service returns to normal; and determines the recovery time difference based on the time when the running status of the live data service returns to normal and the predicted recovery time.

[0096] Based on this, the calculation module 303 determines the second rate based on the recovery time difference and the first rate.

[0097] A smaller recovery time difference indicates a higher second rate.

[0098] As shown in FIG. 4, an implementation of the present application further provides a device for processing data, disposed on a terminal device side, and the device includes the following: a receiving module 401, configured to receive a first rate sent by a server, where the first rate is calculated by the server based on predicted recovery duration that is determined by the server when the server detects that an exception occurs in a running status; and a display module 402, configured to display live data based on the first rate.

[0099] Certainly, after a live data service is recovered, the server further sends a second rate to the terminal device, and the receiving module 401 receives the second rate sent by the server. The second rate is calculated by the server based on a recovery time difference that is determined by the server when the server detects that the running status of the live data service returns to normal.

[0100] The display module 402 displays the live data based on the second rate.

[0101] A person skilled in the art should understand that the implementations of the present disclosure can be provided as a method, a system, or a computer program product. Therefore, the present disclosure can use a form of hardware only implementations, software only implementations, or implementations with a combination of software and hardware. In addition, the present disclosure can use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a magnetic disk storage, a CD-ROM, an optical memory, etc.) that include computer-usable program code.

[0102] The present disclosure is described with reference to the flowcharts and/or block diagrams of the method, the device (system), and the computer program product according to the implementations of the present disclosure. It should be understood that computer program instructions can be used to implement each process and/or each block in the flowcharts and/or the block diagrams and a combination of a process and/or a block in the flowcharts and/or the block diagrams. These computer program instructions can be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device to generate a machine, so that the instructions executed by the computer or the processor of the another programmable data processing device generate an apparatus for implementing a specific function in one or more processes in the flowcharts and/or in one or more blocks in the block diagrams.

[0103] These computer program instructions can be stored in a computer readable memory that can instruct the computer or the another programmable data processing device to work in a specific method, so that the instructions stored in the computer readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more processes in the flowcharts and/or in one or more blocks in the block diagrams.

[0104] These computer program instructions can be loaded onto the computer or the another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, thereby generating computer-implemented processing. Therefore, the instructions executed on the computer or the another programmable device provide steps for implementing a specific function in one or more processes in the flowcharts and/or in one or more blocks in the block diagrams.

[0105] In a typical configuration, a computing device includes one or more processors (CPU), an input/output interface, a network interface, and a memory.

[0106] The memory can include a non-persistent memory, a random access memory (RAM), a nonvolatile memory, and/or another form in a computer readable medium, for example, a read-only memory (ROM) or a flash memory. The memory is an example of the computer readable medium.

[0107] The computer readable medium includes persistent, non-persistent, movable, and unmovable media that can implement information storage by using any method or technology. Information can be a computer readable instruction, a data structure, a program module, or other data. The computer storage medium includes but is not limited to a phase-change random access memory (PRAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a random access memory (RAM) of another type, a read-only memory, an electrically erasable programmable read-only memory (EEPROM), a flash memory or another memory technology, a compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), or another optical storage, a cassette, a cassette magnetic disk storage, or another magnetic storage device or any other non-transmission medium. The computer storage medium can be configured to store information that can be accessed by the computing device. Based on the definition in the present specification, the computer readable medium does not include transitory computer-readable media, for example, a modulated data signal and carrier.

[0108] It is worthwhile to further note that the term "include", "contain", or any other variant thereof is intended to cover a non-exclusive inclusion, so that a process, a method, an article, or a device that includes a list of elements not only includes those elements but also includes other elements which are not expressly listed, or further includes elements inherent to such a process, method, article, or device. An element preceded by "includes a..." does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or device that includes the element.

[0109] A person skilled in the art should understand that the implementations of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can use a form of hardware only implementations, software only implementations, or implementations with a combination of software and hardware. In addition, the present application can use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a magnetic disk storage, a CD-ROM, an optical memory, etc.) that include computer-usable program code.

Claims

1. A computer-implemented method for processing data, the method comprising:

monitoring (S201), by a server, a running status of a live data service configured to generate an amount of live data within a time interval, wherein the live data is generated in batches, each batch of live data including a plurality of pieces of data;

determining (S202), by the server, a predicted recovery duration when it is detected that an exception occurs in the running status, wherein determining (S202) the predicted recovery duration comprises

determining, by the server, a predicted recovery time,

determining, by the server, an exception time when the exception occurs in the running status of the live data service, and

determining, by the server, the predicted recovery duration based on the determined predicted recovery time and the exception time;

calculating (S203), by the server, a first rate based on the predicted recovery duration, wherein calculating (S203) the first rate based on the predicted recovery duration comprises

determining a stopping time of stopping updating the live data by the terminal device when the exception occurs in the running status of the live data service, and

determining the first rate based on the stopping time of stopping displaying the live data by the terminal device and the predicted recovery duration, wherein a longer predicted recovery duration indicates a lower first rate;

sending (S204), by the server, the calculated first rate to a terminal device to display live data based on the first rate;

determining a recovery time difference when it is detected that the running status of the live data service returns to normal;

calculating a second rate based on the recovery time difference; and

sending the calculated second rate to the terminal device, so that the terminal device displays the live data based on the second rate.

2. The method according to claim 1, wherein the predicted recovery time is determined based on an input entered by service staff using a diagnosis interface provided by the server.

3. The method according to any one of claims 1 or 2, wherein the determining a recovery time difference comprises:

determining a time when the running status of the live data service returns to normal; and

determining the recovery time difference based on the time when the running status of the live data service returns to normal and the predicted recovery time.

4. The method according to claim 3, wherein the calculating a second rate based on the recovery time difference comprises:

determining the second rate based on the recovery time difference and the first rate; wherein

a smaller recovery time difference indicates a higher second rate.

5. The method according to claim 3, wherein the live data service performs corresponding statistics processing to generate live data for display.

6. The method according to claim 3, wherein the live data is generated at an abnormal rate because of the exception.

7. A device for processing data, the device comprising a plurality of modules (301, 302, 303, 304, 305) configured to perform the method of any one of claims 1 to 6.

Ansprüche

1. Computerimplementiertes Verfahren zum Verarbeiten von Daten, wobei das Verfahren umfasst:

Überwachen (S201), durch einen Server, eines laufenden Status eines Live-Datendienstes, der dazu ausgelegt ist, eine Menge von Live-Daten innerhalb eines Zeitintervalls zu erzeugen, wobei die Live-Daten in Batches erzeugt werden, wobei jeder Batch von Live-Daten eine Mehrzahl von Datenteilen beinhaltet;

Bestimmen (S202), durch den Server, einer vorhergesagten Wiederherstellungsdauer, wenn erkannt wird, dass eine Ausnahme im laufenden Status auftritt, wobei das Bestimmen (S202) der vorhergesagten Wiederherstellungsdauer umfasst

Bestimmen einer vorhergesagten Zeit für die Wiederherstellung durch den Server,

Bestimmen eines Ausnahmezeitpunkts durch den Server, wenn die Ausnahme im laufenden Status des Live-Datendienstes auftritt, und

Bestimmen der vorhergesagten Wiederherstellungsdauer basierend auf dem bestimmten vorhergesagten Wiederherstellungszeitpunkt und dem Ausnahmezeitpunkt durch den Server;

Berechnen (S203) einer ersten Rate basierend auf der vorhergesagten Wiederherstellungsdauer durch den Server, wobei das Berechnen (S203) der ersten Rate basierend auf der vorhergesagten Wiederherstellungsdauer umfasst

Bestimmen eines Anhaltezeitpunktes des Anhaltens des Aktualisierens der Live-Daten durch die Endgerätevorrichtung, wenn die Ausnahme im laufenden Status des Live-Datendienstes auftritt, und

Bestimmen der ersten Rate basierend auf dem Anhaltezeitpunkt des Anhaltens der Anzeige der Live-Daten durch die Endgerätevorrichtung und der vorhergesagten Wiederherstellungsdauer, wobei eine längere vorhergesagte Wiederherstellungsdauer eine niedrigere erste Rate angibt;

Senden (S204) der berechneten ersten Rate durch den Server an eine Endgerätevorrichtung, um Live-Daten basierend auf der ersten Rate anzuzeigen;

Bestimmung eines Unterschieds im Wiederherstellungszeitpunkt, wenn erkannt wird, dass der laufende Status des Live-Datendienstes in den Normalzustand zurückkehrt;

Berechnen einer zweiten Rate basierend auf dem Unterschied im Wiederherstellungszeitpunkt, und

Senden der berechneten zweiten Rate an die Endgerätevorrichtung, so dass die Endgerätevorrichtung die Live-Daten basierend auf der zweiten Rate anzeigt.

2. Verfahren nach Anspruch 1, wobei der vorhergesagte Wiederherstellungszeitpunkt basierend auf einer Eingabe bestimmt wird, die vom Servicepersonal unter Verwendung einer vom Server bereitgestellten Diagnoseschnittstelle eingegeben wird.

3. Verfahren nach einem der Ansprüche 1 oder 2, wobei das Bestimmen eines Unterschieds im Wiederherstellungszeitpunkt umfasst:

Bestimmen eines Zeitpunkts, zu dem der laufende Status des Live-Datendienstes in den Normalzustand zurückkehrt; und

Bestimmen des Unterschieds in Wiederherstellungszeitpunkt basierend auf dem Zeitpunkt, zu dem der laufende Status des Live-Datendienstes in den Normalzustand zurückkehrt, und des vorhergesagten Wiederherstellungszeitpunkts.

4. Verfahren nach Anspruch 3, wobei das Berechnen einer zweiten Rate basierend auf dem Unterschied im Wiederherstellungszeitpunkt umfasst:

Bestimmen der zweiten Rate basierend auf dem Unterschied im Wiederherstellungszeitpunkt und der ersten Rate; wobei

ein kleinerer Unterschied im Wiederherstellungszeitpunkt eine höhere zweite Rate angibt.

5. Verfahren nach Anspruch 3, wobei der Live-Datendienst eine entsprechende Statistikverarbeitung durchführt, um Live-Daten für die Anzeige zu erzeugen.

6. Verfahren nach Anspruch 3, wobei die Live-Daten aufgrund der Ausnahme mit einer anormalen Rate erzeugt werden.

7. Vorrichtung zum Verarbeiten von Daten, wobei die Vorrichtung eine Mehrzahl von Modulen (301, 302, 303, 304, 305) umfasst, die dazu ausgelegt sind, das Verfahren nach einem der Ansprüche 1 bis 6 durchzuführen.

Revendications

1. Procédé mis en oeuvre par ordinateur pour traiter des données, le procédé comportant :

la surveillance (S201), par un serveur, d'un état de fonctionnement d'un service de données en direct configuré pour générer une quantité de données en direct au cours d'un intervalle de temps, les données en direct étant générées par lots, chaque lot de données en direct comprenant une pluralité d'éléments de données ;

la détermination (S202), par le serveur, d'une durée de récupération prédite lorsqu'il est détecté qu'une exception survient dans l'état de fonctionnement, la détermination (S202) de la durée de récupération prédite comportant

la détermination, par le serveur, d'un temps de récupération prédit,

la détermination, par le serveur, d'un instant d'exception lorsque l'exception survient dans l'état de fonctionnement du service de données en direct, et

la détermination, par le serveur, de la durée de récupération prédite d'après le temps de récupération prédit déterminé et l'instant d'exception ;

le calcul (S203), par le serveur, d'une première cadence d'après la durée de récupération prédite, le calcul (S203) de la première cadence d'après la durée de récupération prédite comportant

la détermination d'un instant d'arrêt de l'arrêt de la mise à jour des données en direct par le dispositif terminal lorsque l'exception survient dans l'état de fonctionnement du service de données en direct, et

la détermination de la première cadence d'après l'instant d'arrêt de l'arrêt de l'affichage des données en direct par le dispositif terminal et la durée de récupération prédite, une plus longue durée de récupération prédite indiquant une première cadence plus basse ;

l'envoi (S204), par le serveur, de la première cadence calculée à un dispositif terminal pour afficher des données en direct sur la base de la première cadence ;

la détermination d'une différence de temps de récupération lorsqu'il est détecté que l'état de fonctionnement du service de données en direct revient à la normale ;

le calcul d'une seconde cadence d'après la différence de temps de récupération ; et

l'envoi de la seconde cadence calculée au dispositif terminal, de telle sorte que le dispositif terminal affiche les données en direct sur la base de la seconde cadence.

2. Procédé selon la revendication 1, le temps de récupération prédit étant déterminé d'après une entrée saisie par du personnel de service à l'aide d'une interface de diagnostic mise en place par le serveur.

3. Procédé selon l'une quelconque des revendications 1 ou 2, la détermination d'une différence de temps de récupération comportant :

la détermination d'un instant où l'état de fonctionnement du service de données en direct revient à la normale ; et

la détermination de la différence de temps de récupération d'après l'instant où l'état de fonctionnement du service de données en direct revient à la normale et le temps de récupération prédit.

4. Procédé selon la revendication 3, le calcul d'une seconde cadence d'après la différence de temps de récupération comportant :

la détermination de la seconde cadence d'après la différence de temps de récupération et la première cadence ;

une plus petite différence de temps de récupération indiquant une seconde cadence plus élevée.

5. Procédé selon la revendication 3, le service de données en direct effectuant un traitement statistique correspondant pour générer des données en direct en vue d'un affichage.

6. Procédé selon la revendication 3, les données en direct étant générées à une cadence anormale en raison de l'exception.

7. Dispositif de traitement de données, le dispositif comportant une pluralité de modules (301, 302, 303, 304, 305) configurés pour réaliser le procédé selon l'une quelconque des revendications 1 à 6.

Drawing