WO2020062674A1 - 一种更新数据包的推送方法及服务器 - Google Patents

一种更新数据包的推送方法及服务器 Download PDF

Info

Publication number
WO2020062674A1
WO2020062674A1 PCT/CN2018/123987 CN2018123987W WO2020062674A1 WO 2020062674 A1 WO2020062674 A1 WO 2020062674A1 CN 2018123987 W CN2018123987 W CN 2018123987W WO 2020062674 A1 WO2020062674 A1 WO 2020062674A1
Authority
WO
WIPO (PCT)
Prior art keywords
fault
information
user terminal
data packet
update data
Prior art date
Application number
PCT/CN2018/123987
Other languages
English (en)
French (fr)
Inventor
韦享忠
Original Assignee
深圳壹账通智能科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳壹账通智能科技有限公司 filed Critical 深圳壹账通智能科技有限公司
Publication of WO2020062674A1 publication Critical patent/WO2020062674A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy

Definitions

  • the present application belongs to the field of information processing technology, and particularly relates to a method and server for pushing an update data packet.
  • Update packages such as patches
  • the existing update data package push method adopts the global unified push release method, that is, the software update is uniformly performed to all user terminals installed with the application or system that needs to be repaired by the update data package to modify the software Existing loopholes.
  • the above method requires that update data packages be pushed to all user terminals at the same time. If some user terminals do not fail and need to download update data packages, the data traffic of this part of users is wasted, causing waste of resources, and may also be caused by installation. In order to update the data package and cause a new failure condition, the user experience and the stability of the software are reduced.
  • the embodiments of the present application provide a method and server for pushing update data packets to solve the existing technology for pushing update data packets.
  • the update data packet is pushed uniformly. It is easy to cause problems of wasting resources and reducing terminal stability.
  • a first aspect of the embodiments of the present application provides a method for pushing an update data packet, including:
  • the fault information includes device information of the user terminal and an application identifier of a faulty application program
  • the abnormality coefficient is greater than a preset push threshold, obtaining an update data packet for repairing the fault information according to the fault information;
  • the historical fault record corresponding to the device information is extracted from the fault information database according to the device information contained in the fault information, and then the abnormal coefficient of the device information is calculated based on the historical fault record and the fault information. Therefore, based on the magnitude of the anomaly coefficient, it can be determined whether there is a compatibility issue between the application and the user terminal corresponding to the device information. If the anomaly coefficient is greater than a preset push threshold, it indicates that there are multiple users corresponding to the device information There are abnormal conflicts between the terminal and the application.
  • the user terminal list associated with the device information needs to be obtained, and update data packets are sent to all user terminals in the user terminal list uniformly to modify the relationship between the application and this type of user terminal.
  • FIG. 1 is an implementation flowchart of a method for pushing an update data packet according to a first embodiment of the present application
  • FIG. 2 is a specific implementation flowchart of a method S103 for pushing an update data packet according to a second embodiment of the present application
  • FIG. 3 is a detailed implementation flowchart of a method S105 for pushing an update data packet according to a third embodiment of the present application
  • FIG. 4 is a specific implementation flowchart of a method for pushing an update data packet according to a fourth embodiment of the present application.
  • FIG. 5 is a specific implementation flowchart of a method for pushing an update data packet according to a fifth embodiment of the present application
  • FIG. 6 is a structural block diagram of a server according to an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a server according to another embodiment of the present application.
  • the execution subject of the process is a server.
  • the server includes, but is not limited to, devices with a push function for updating data packets, such as servers, computers, smartphones, and tablet computers.
  • the server may be a server corresponding to an application publishing platform, and each user terminal may download a program file of the application program and an update data package about the application program from the server.
  • FIG. 1 shows an implementation flowchart of a method for pushing an update data packet provided by the first embodiment of the present application, which is detailed as follows:
  • fault information fed back by a user terminal is received; the fault information includes device information of the user terminal and an application identifier of a faulty application program.
  • a fault message is generated.
  • the specific abnormal content of the application, and the application identification corresponding to the application is encapsulated in the fault information.
  • the user terminal In order to determine whether the failure of the application is caused by compatibility with the device, in addition to adding the application table to the failure information, the user terminal also obtains device information locally related to the user terminal.
  • the device information includes, but is not limited to, a device number, a device model, a system version, and an operating environment type of the application.
  • the type of running environment of the application program is the system type of the user terminal, for example, a working environment based on Android, a working environment based on Microsoft, or a working environment based on Linux.
  • the device information specifically includes two types of information: a running environment type and a system version.
  • the above two types of information can uniquely determine the operating environment of the application, so that the server can set up a corresponding operating environment locally to simulate The operation of the user terminal determines whether the fault information is caused by the compatibility of the device system.
  • the server can query the corresponding product information based on the two types of information, and obtain the system environment in which the application program runs based on the product information.
  • the user terminal before sending the fault information, determines a target address of the fault information according to a download channel of the application, that is, a publishing platform to which the application belongs. Due to the differences between the developers of different application programs, the user terminal can parse the program file of the application program or obtain the download record of the application program before feedback the fault information, determine the download channel of the application program, and send one through the download channel. A target address acquisition instruction, so that the server of the application program returns its corresponding target address to the user terminal, and returns fault information to the server according to the target address.
  • the target address of the fault information can be determined by querying the correspondence table, and the fault information is sent to the server through the target address.
  • a fault information database of the application is determined based on the application identifier, and a historical fault record corresponding to the device information is extracted from the fault information database.
  • application failure may be sporadic, such as device memory overflow, insufficient main thread resources, or insufficient user terminal power, which causes the application to run abnormally.
  • the program file that is not in the application exists Vulnerabilities, no need for maintenance staff to fix the application. Therefore, in order to determine whether the fault information is an occasional fault, the server determines the fault information base of the application according to the application identifier contained in the fault information.
  • the fault information base is mainly used for uploading by all user terminals of the application corresponding to the application identifier. Fault information, so that maintenance personnel can locate the cause of the fault through the fault information database and generate a corresponding update data package during fault repair.
  • the fault information database may be stored in a server.
  • a server may be used to publish update data packages of one or more application programs, and store the fault information database of the application program.
  • the fault information database can be stored in an independent database server, that is, each user terminal uploads fault information to the database server, and then the database server stores the fault information in the corresponding fault according to the application identifier contained in the fault information.
  • the server provided in this embodiment may obtain a corresponding historical fault record from the database.
  • the server extracts all historical fault records about the equipment information from the fault information base according to the equipment information of the fault information. Since each historical fault record in each fault information database is fault information uploaded by a user terminal on which the application is installed, each historical fault record also records equipment information corresponding to the user terminal that uploaded the fault information.
  • the server can match the uploaded fault information with the device information contained in each historical fault record, select the successfully matched historical fault record as the historical fault record associated with the fault information, and perform the related operation of S103.
  • the matching method may be: the server imports the fault information in the fault information into a preset hash function, and determines the corresponding hash value of the device information.
  • the server may be based on the correspondence of each product and the device environment of the product. Relationship, create a hash function so that the server can get the corresponding device environment by entering device information. Perform the above operations on both the fault information and the historical fault record, and identify the historical fault information whose output hash value is consistent with the hash value of the fault information as the historical hash record associated with the fault information.
  • an abnormality coefficient of the device information is calculated according to the historical fault record and the fault information.
  • the server can determine the abnormality coefficient of the equipment information based on the two types of information above.
  • the larger the abnormality coefficient the more the equipment indicates the equipment. The more fault conditions exist in the information, so the probability of the fault being sporadic is smaller. Therefore, the application needs to be repaired, and an update data package for repairing the fault information is issued to the user terminal; otherwise, if The smaller the anomaly coefficient is, the less failure conditions appear in the equipment information. Therefore, within a certain range, it can be determined that the anomaly is an occasional anomaly, and it is not a common anomaly.
  • the server does not need to configure a corresponding update packet to fix the abnormal situation. Based on this, the server can calculate the anomaly coefficient of the device information, so that it can determine whether it is necessary to send an update data packet to the application program of the device channel to repair the fault condition.
  • the method of calculating the abnormality coefficient may be: the server may include the historical fault record and the total number of fault information included in the device information as the abnormality coefficient of the device information, that is, the two types of information described above. The larger the number, the larger the coefficient of abnormality of the device information; the server can also determine the weight value of each historical fault record according to the creation time of each historical fault record, and perform weighted operation according to the weight value of each historical fault record to determine Abnormality coefficient of the device information.
  • the method of calculating the abnormality coefficient may be: the server extracts the fault modules included in each historical fault record, and counts the number of times that each fault module has failed, and determines the fault weight of each fault module based on the number of times,
  • the abnormal coefficient of the device information is calculated.
  • the server extracts the fault modules included in each historical fault record, and counts the number of times that each fault module has failed, and determines the fault weight of each fault module based on the number of times,
  • the abnormal coefficient of the device information is calculated.
  • the server extracts the fault modules included in each historical fault record, and counts the number of times that each fault module has failed, and determines the fault weight of each fault module based on the number of times.
  • the server stores a push threshold.
  • the anomaly coefficient is greater than the push threshold, it indicates that there is a compatibility problem between the device information and the application, so it is necessary to generate an application for the application to repair the two Update the data package with the compatibility of the user, so as to be able to troubleshoot the fault information on the user terminal.
  • the push threshold can be changed by the administrator on the device or can be changed correspondingly based on the change in the download amount of the application, so that the push threshold can be dynamically adjusted to match the current download amount, which improves the Accuracy of update packet push timing.
  • the server may obtain source code data corresponding to each faulty module based on the faulty module included in the fault information, and perform syntax check and semantic check on the source data. If both of the above tests pass, the server obtains The interface information and thread information of the faulty module are matched with the interface identifier and the thread identifier contained in the device information, whether there is an interface conflict or a thread conflict, and the interface information and thread information of the faulty module are adjusted based on the conflict situation. An update data package is generated based on the repaired source data.
  • the server may forward the fault information to the developer's terminal to notify the developer to generate an update data packet for the fault information, and return the generated update data packet to the server, so that the server can push the update data packet.
  • the server after the server generates an update packet of the fault information or the historical fault record, the server deletes the fault information and the historical fault record from the fault information database, so as to avoid repeated faults. Information and historical fault records for repeated repairs.
  • the update data packet is pushed to all user terminals in the user terminal list associated with the device information.
  • the server manages a user terminal list for each device information.
  • the device information of all user terminals in the user terminal list is the same. For example, if the device information is a device model, all users in the user terminal list The device models of the terminals are the same.
  • the user terminal list can be obtained by downloading statistics of the application program.
  • the user terminal downloads an application program, it sends a download request.
  • the download request includes device information, and the server returns the device information to the user terminal based on the download request. Match the program file of the application program and generate a download record, so the download record records the device information of the user terminal that downloaded the application program, so that the user terminal list can be statistically obtained.
  • the device information may also be an application download channel, for example, an application store, and a terminal device may obtain all user terminals installed with the application store client, generate a list of user terminals, and send the generated update data package to All user terminals in the user terminal list are pushed, thereby fixing the fault conditions of all user terminals of the device information.
  • an application download channel for example, an application store
  • a terminal device may obtain all user terminals installed with the application store client, generate a list of user terminals, and send the generated update data package to All user terminals in the user terminal list are pushed, thereby fixing the fault conditions of all user terminals of the device information.
  • the method for pushing an update data packet extracts a historical fault record corresponding to the device information from the fault information database according to the device information included in the fault information. Then calculate the abnormality coefficient of the device information based on the historical fault record and the fault information, so as to determine whether there is a compatibility issue between the application and the user terminal corresponding to the device information based on the numerical value of the abnormality coefficient.
  • the set push threshold indicates that multiple user terminals corresponding to the device information have an abnormal conflict with the application. You need to obtain the user terminal list associated with the device information and send updates to all user terminals in the user terminal list uniformly. Data packets to modify compatibility issues between applications and this type of user terminal.
  • FIG. 2 shows a specific implementation flowchart of S103 of a method for pushing an update data packet according to a second embodiment of the present application.
  • S103 includes: S1031 to S1032, and details are as follows:
  • each historical fault record and a fault module included in the fault information are acquired, and a fault weight value of each fault module is determined.
  • the server can determine the fault weight value of each functional module according to the priority order of each functional module in the application.
  • the server obtains the priority information of the functional module and queries the priority information. Corresponding fault weight value, so that the fault weight value of the fault module can be obtained.
  • the fault weight value can be configured by a developer, and the developer configures a corresponding fault weight value for each functional module, or as described above, the user sets a priority conversion function, and the server is based on each function The number of times the module is used determines the priority of each functional module and imports the priority into the priority conversion function to calculate the fault weight value corresponding to each functional module.
  • the priority conversion function may be a hash function.
  • each historical fault record and the fault information uploaded this time record the fault module in the application, so the server can determine the fault weight value corresponding to the fault module according to the module identification of each fault module.
  • the fault weight value, the historical fault record, and the fault information are imported into an abnormal coefficient conversion model to calculate the abnormal coefficient of the equipment information.
  • the abnormal coefficient conversion model is specifically:
  • UpdateLv is the abnormal coefficient of the device information
  • ErrorNum is the number of the historical fault information
  • CurrentTime is the time of the current time
  • ErrorTime i is the creation time of the i-th historical fault information
  • Partnum i is the i-th historical The number of fault modules included in the fault information
  • ErrorPart ij is the fault weight value of the j-th fault module in the i-th historical fault information
  • ErrorTime 0 is the sending time of the fault information
  • ErrorPart 0j is the j-th fault in the fault information
  • the fault weight value of the module; Parameter 0 and Parameter i are preset coefficients.
  • the terminal device imports each historical fault record, the fault information obtained this time, and the determined fault weight value into the abnormal coefficient conversion model to calculate the abnormal coefficient of the device information, where each historical fault record In addition to recording the faulty module, the creation time of the historical fault record is also recorded. Because the greater the difference between the creation time and the current time, the greater the probability that the historical fault record has been repaired, so the historical fault information The smaller the contribution to the anomaly coefficient, so by setting This factor reflects the changing relationship between the time when the historical fault record was created and the degree of influence of the anomaly coefficient, realizes non-linear weighting, and improves the accuracy of the anomaly coefficient.
  • the average fault degree of the equipment information can be determined, the abnormal factors corresponding to each historical fault record can be smoothed, and the accuracy of the abnormal coefficient calculation can be further improved. Sex.
  • the abnormal coefficient of the device information is calculated, so that the abnormal coefficient can be improved. Accuracy.
  • FIG. 3 shows a specific implementation flowchart of a method for pushing an update data packet S105 according to a second embodiment of the present application.
  • a method S105 for pushing an update data packet provided in this embodiment includes: S1051 to S1053, and the details are as follows:
  • the server before sending the update data packet, the server first determines the data amount of the update data packet, and compares the data amount with a preset data amount threshold. The data amount of the update data packet is less than the If the data volume threshold is set, the operation of S1052 is performed; otherwise, if the data volume is greater than or equal to the preset data volume threshold, the operation of S1053 is performed.
  • the data amount threshold in this embodiment may be manually set by an administrator, or the server may automatically adjust it according to the bandwidth resource of the network in which it is located.
  • the server sets the estimated duration of sending an update data packet to 4 seconds, and the occupied bandwidth resource cannot exceed 50%.
  • the main thread is set to a serial operation mode, and all user terminals in the user terminal list are sent to the user terminal list one by one through the main thread. Sending the update packet.
  • the server determines that the data amount of the update data packet is less than a preset data amount threshold, it means that the data amount of the update data packet is small, and the time required to send one data packet is short, which is not There may be a case where the sending of the update data packet causes the sending to be over the preset time period and the sending is not completed, and based on this, the sending of the update data packet through the main thread is more efficient. Because the main thread has more hardware resources and bandwidth resources that can be called, it is more efficient to send data packets. However, when the server detects that the main thread is running, it will set a maximum response time.
  • the response threshold will recognize that the main thread is in a response abnormal state, and will terminate the operation of the main thread and restart the response. Therefore, if the amount of data in the update data packet is large, the server will recognize that the main thread is in an abnormal response state, and repeatedly terminate and retransmit, resulting in a waste of resources and failure to send the normal data packet. Therefore, when the data volume of the faulty data packet is small, the server publishes data through the main thread, thereby improving the success rate of sending.
  • the server when determining that the update data packet is sent to each user terminal through the main thread, the server may use the order in which the user terminal uploads fault information as the sending order of the user terminal to send the update data packet.
  • the server determines that the update data packet is greater than or equal to the data amount threshold, it indicates that the data amount of the update data packet is large. If the main thread is used to send the serial data in a serial manner, the above-mentioned main thread factor is easily generated Perform a send operation time process to identify a thread timeout. Therefore, in this case, update packets will be sent to each user terminal in a parallel manner by child threads.
  • the server queries the correspondence relationship of the fault type, records the number of terminals of the user terminal, and creates the same number of sub-threads as the number of terminals under the main thread, and runs the operations of each sub-thread.
  • the mode is set to an asynchronous parallel mode, so that each sub-thread is controlled to communicate with each user terminal, and each sub-thread sends an update data packet to each user terminal.
  • the number of terminals is greater than the maximum number of child threads on the server, create the same number of child threads as the maximum number of threads, and send an update packet to some user terminals. After sending, the remaining users are sent The terminal sends until the user terminal corresponding to the fault type performs a data packet sending operation.
  • the server selects an appropriate transmission method for data transmission according to the data amount of the update data packet, thereby improving transmission efficiency and success rate of transmission.
  • FIG. 4 shows a specific implementation flowchart of a method for pushing an update data packet according to a third embodiment of the present application.
  • the device information is calculated according to the historical fault record and the fault information. After the abnormal coefficient, it also includes: S401 ⁇ S402, detailed as follows:
  • the anomaly coefficient is a reference value used to determine whether an update data packet needs to be pushed to a user terminal
  • the anomaly coefficient is greater than a push threshold
  • an update data packet of fault information is generated and a push process is performed; and when When the anomaly coefficient is less than or equal to the push threshold, it indicates that the fault condition of the device information is not serious and may be an occasional abnormality.
  • the server does not generate a corresponding update packet for the fault information, but instead Obtain the current time information, and generate a fault record based on the time information and the fault information received this time.
  • the time information may include current date information and specific time information.
  • the fault record is added to the fault information database of the application identifier, and fault pending information about the fault record is sent to the user terminal.
  • the server determines the fault information database of the application according to the application identifier, and Fault records are stored in the fault information database. Since this abnormal operation is an occasional abnormality, the server also wants the user terminal to feedback a failure pending information.
  • a fault record is generated according to the fault information and stored in the fault information database, thereby facilitating developers to manage fault conditions of the application program.
  • FIG. 5 shows a specific implementation flowchart of a method for pushing an update data packet according to a fourth embodiment of the present application.
  • a method for pushing an update data packet provided in this embodiment pushes all the user terminals in the user terminal list associated with the device information.
  • the update data packet also includes: S501 to S502, the details are as follows:
  • the server may send a network status acquisition request to the user terminal to determine the current network status of the user terminal.
  • the network status is a specific connection method for communicating with the Internet, and is through a wired network, a wireless local area network, or a mobile network.
  • the user terminal generates a network status result and returns it to the server based on the current network status of communication with the server.
  • the server determines that the current network status of the user terminal is a preset data packet download status, it sends an update data packet to the user terminal.
  • the data packet download status is: wireless LAN status or wired network status.
  • a retransmission timer is set, and after the retransmission timer count value is greater than the retransmission count value, the related operation of S501 is returned until The network status of the user terminal satisfies a preset data packet download status, and then performs a download operation.
  • the user terminal may enter a download waiting state when it is determined that the current state does not satisfy the preset data packet download state, and when it is detected that the network state of the user terminal meets the data packet download state , Actively send a packet acquisition request to the server to initiate a packet download operation.
  • the network state of the user terminal is acquired to determine whether to perform data packet sending, so as to avoid the user terminal from unintentionally downloading and wasting a large amount of data traffic.
  • FIG. 6 shows a structural block diagram of a server according to an embodiment of the present application, and each unit included in the server is configured to execute steps in the embodiment corresponding to FIG. 1.
  • each unit included in the server is configured to execute steps in the embodiment corresponding to FIG. 1.
  • only the parts related to this embodiment are shown.
  • the server includes:
  • the fault information receiving unit 61 is configured to receive fault information fed back by a user terminal; the fault information includes device information of the user terminal and an application identifier of a faulty application program;
  • a historical fault record acquiring unit 62 configured to determine a fault information database of the application based on the application identifier, and extract a historical fault record corresponding to the device information from the fault information database;
  • An abnormality coefficient calculating unit 63 configured to calculate an abnormality coefficient of the device information according to the historical fault record and the fault information
  • An update data packet obtaining unit 64 configured to obtain an update data packet for repairing the fault information according to the fault information if the abnormality coefficient is greater than a preset push threshold;
  • the update data packet pushing unit 65 is configured to push the update data packet to all user terminals in a user terminal list associated with the device information.
  • the abnormal coefficient calculation unit 63 includes:
  • a fault weight value determining unit configured to obtain each historical fault record and a fault module included in the fault information, and determine a fault weight value of each fault module;
  • the fault information importing unit is configured to import the fault weight value, the historical fault record, and the fault information into an abnormal coefficient conversion model to calculate an abnormal coefficient of the equipment information.
  • the abnormal coefficient conversion model is specifically:
  • UpdateLv is the abnormal coefficient of the device information
  • ErrorNum is the number of the historical fault information
  • CurrentTime is the time of the current time
  • ErrorTime i is the creation time of the i-th historical fault information
  • Partnum i is the i-th historical The number of fault modules included in the fault information
  • ErrorPart ij is the fault weight value of the j-th fault module in the i-th historical fault information
  • ErrorTime 0 is the sending time of the fault information
  • ErrorPart 0j is the j-th fault in the fault information
  • the fault weight value of the module; Parameter 0 and Parameter i are preset coefficients.
  • the update data packet pushing unit 65 includes:
  • a data amount acquiring unit configured to acquire a data amount of the update data packet
  • a serial push unit configured to set the main thread to a serial operation mode if the data amount of the update data packet is less than a preset data amount threshold, and one by one to the user terminal list through the main thread All user terminals send the update data packet;
  • a parallel push unit configured to create a plurality of asynchronous parallel child threads in the main thread if the data amount of the update data packet is greater than or equal to the data amount threshold, and to each of the child threads All user terminals in the user terminal list send the update data packet; the number of the sub-threads is the same as the number of user terminals included in the fault type.
  • the server further includes:
  • a fault record generating unit configured to obtain current time information if the abnormality coefficient is less than or equal to the push threshold, and generate a fault record based on the current time information and the fault information;
  • a fault record importing unit is configured to add the fault record to a fault information database of the application identifier, and send to the user terminal fault pending information about the fault record.
  • the server further includes:
  • a network state acquiring unit configured to acquire a network state of the user terminal
  • a network status identifying unit is configured to execute the push of the update data packet to all user terminals in a user terminal list associated with the device information if the network status meets a preset data packet download status.
  • the server provided in the embodiment of the present application can also extract historical fault records corresponding to the device information from the fault information database according to the device information included in the fault information, and then based on the historical fault records and fault information. Calculate the anomaly coefficient of the device information, so as to determine whether there is a compatibility issue between the application and the user terminal corresponding to the device information based on the value of the anomaly coefficient. If the anomaly coefficient is greater than a preset push threshold, it indicates that there is more Each user terminal corresponding to the device information has an abnormal conflict with the application program. It is necessary to obtain a list of user terminals associated with the device information and send an update data packet to all user terminals in the user terminal list uniformly to modify the application program and Compatibility issues between this type of user terminal.
  • FIG. 7 is a schematic diagram of a server according to another embodiment of the present application.
  • the server 7 of this embodiment includes a processor 70, a memory 71, and computer-readable instructions 72 stored in the memory 71 and executable on the processor 70, such as an update data packet.
  • Pusher When the processor 70 executes the computer-readable instructions 72, the steps in the embodiment of the method for pushing each update data packet are implemented, such as S101 to S105 shown in FIG. 1. Alternatively, when the processor 70 executes the computer-readable instructions 72, functions of each unit in the foregoing device embodiments are implemented, for example, functions of modules 61 to 65 shown in FIG. 6.
  • the computer-readable instructions 72 may be divided into one or more units, and the one or more units are stored in the memory 71 and executed by the processor 70 to complete the application.
  • the one or more units may be a series of computer-readable instruction instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer-readable instructions 72 in the server 7.
  • the computer-readable instructions 72 may be divided into a failure information receiving unit, a historical failure record obtaining unit, an abnormality coefficient calculating unit, an update data packet obtaining unit, and an update data packet pushing unit. The specific functions of each unit are as described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请适用于信息处理技术领域，提供了一种更新数据包的推送方法及服务器，包括：接收用户终端反馈的故障信息；基于应用标识确定应用程序的故障信息库，并从故障信息库中提取设备信息对应的历史故障记录；根据历史故障记录以及故障信息计算设备信息的异常系数；若异常系数大于预设的推送阈值，则根据故障信息，获取用于修复故障信息的更新数据包；向与设备信息关联的用户终端列表内的所有用户终端推送更新数据包。本申请只有在异常系数较大时，才对设备信息对应的用户终端进行更新数据包的推送操作，从而实现定向推送的目的，并不会对未发生异常的设备型号的用户终端发送更新数据包，减少用户数据流量的浪费，提高用户的使用体验以及软件的稳定性。

Description

一种更新数据包的推送方法及服务器
本申请申明享有2018年9月26日递交的申请号为201811121969.9、名称为“一种更新数据包的推送方法及服务器”中国专利申请的优先权，该中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
本申请属于信息处理技术领域，尤其涉及一种更新数据包的推送方法及服务器。
背景技术
更新数据包，例如补丁，作为热修复的重要手段，被广泛用于各种应用程序或系统在运行中出现的故障修复。现有的更新数据包的推送方式，采用的是全局统一推送的发布方式，即向安装了更新数据包所需修复的应用程序或系统的所有用户终端统一进行的软件更新，以修改软件中所存在的漏洞。
然而上述方式，要求同时向所有用户终端推送更新数据包，若部分用户终端并未出现故障情况，也需要下载更新数据包，则浪费了该部分用户的数据流量，造成资源浪费，还可能因为安装了更新数据包而引起新的故障情况，降低用户的使用体验以及软件的稳定性。
技术问题
有鉴于此，本申请实施例提供了一种更新数据包的推送方法及服务器，以解决现有的更新数据包的推送技术，对于并未出现故障情况的用户终端，也统一进行更新数据包推送，容易造成资源浪费以及降低终端稳定性的问题。
技术解决方案
本申请实施例的第一方面提供了一种更新数据包的推送方法，包括：
接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
有益效果
本申请实施例在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题。与现有的更新数据包的统一推送方式相比，本实施例只有在异常系数较大时，才对设备信息对应的用户终端进行更新数据包的推送操作，从而实现定向推送的目的，而并不会对未发生异常的设备型号的用户终端发送更新数据包，减少了用户数据流量的浪费，提高了用户的使用体验以及软件的稳定性。
附图说明
图1是本申请第一实施例提供的一种更新数据包的推送方法的实现流程图；
图2是本申请第二实施例提供的一种更新数据包的推送方法S103具体实现流程图；
图3是本申请第三实施例提供的一种更新数据包的推送方法S105具体实现流程图；
图4是本申请第四实施例提供的一种更新数据包的推送方法具体实现流程图；
图5是本申请第五实施例提供的一种更新数据包的推送方法具体实现流程图；
图6是本申请一实施例提供的一种服务器的结构框图；
图7是本申请另一实施例提供的一种服务器的示意图。
本发明的实施方式
在本申请实施例中，流程的执行主体为服务器。该服务器包括但不限于：服务器、计算机、智能手机以及平板电脑等具有更新数据包的推送功能的设备。特别地，该服务器可以为一应用程序发布平台对应的服务器，各个用户终端可以从该服务器下载应用程序的程序文件，以及关于该应用程序的更新数据包，同样地，当用户终端发现应用程序在运行过程中存在异常，也可以向该服务器反馈故障信息。图1示出了本申请第一实施例提供的更新数据包的推送方法的实现流程图，详述如下：
在S101中，接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识。
在本实施例中，用户终端在运行已安装的应用程序时，若出现故障情况，例如程序无响应、异常关闭或按键点击异常等情况，会生成一条故障信息，该故障信息中记录有本次应用程序的具体异常内容，并将该应用程序对应的应用标识封装于该故障信息。为了确定 该应用程序发生的故障是否为与设备之间的兼容性而导致的，用户终端除了将应用表添加到故障信息外，还会获取用户终端本地相关的设备信息。
具体地，在本实施例中，该设备信息包括但不限于：设备编号、设备型号、系统版本以及应用程序的运行环境类型。其中，应用程序的运行环境类型即该用户终端的系统类型，例如是基于安卓搭建的工作环境，或是基于微软搭建的工作环境，或是基于Linux搭建的工作环境等。优选地，该设备信息具体包括运行环境类型以及系统版本两类信息。为了检测应用程序与该用户终端之间的故障情况是否由于兼容性的问题导致，而上述两类信息即可唯一确定该应用程序的运行环境，便于服务器可以在本地搭建对应的运行环境，以模拟用户终端的操作，继而判断该故障信息是否因设备系统兼容性而导致。其中，若故障信息中包含设备编号或设备型号等信息，服务器可以基于上述两类信息查询对应的产品信息，并通过该产品信息获取应用程序所运行的系统环境。
可选地，在本实施例中，用户终端在发送故障信息之前，会根据应用程序的下载渠道，即该应用程序所属的发布平台，确定该故障信息的目标地址。由于不同的应用程序所属开发商存在差异，用户终端在反馈故障信息之前，可以解析该应用程序的程序文件或获取该应用程序的下载记录，确定该应用程序的下载渠道，通过该下载渠道发送一个目标地址获取指令，以便该应用程序的服务器向用户终端返回其对应的目标地址，并根据该目标地址将故障信息反馈给服务器。当然，若用户终端存储有应用程序与服务器的对应关系表，则可以通过查询该对应关系表确定故障信息的目标地址，并通过该目标地址向服务器发送故障信息。
在S102中，基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录。
在本实施例中，由于应用程序发生故障有可能是偶发性，例如设备内存溢出、主线程资源不足或用户终端电量不足而导致应用程序运行异常，对于上述异常情况并非处于应用程序的程序文件存在漏洞，无需维护人员对该应用程序进行修复。因此，为了判断该故障信息是否为偶发故障，服务器会根据故障信息中包含的应用标识，确定该应用程序的故障信息库，该故障信息库主要用于该应用标识对应的应用程序所有用户终端上传的故障信息，以便维护人员在故障修复时能够通过故障信息库定位故障原因，并生成对应的更新数据包。需要说明的是，该故障信息库可以存储于服务器内，在该情况下，一个服务器可以用于发布一个或多个应用程序的更新数据包，并存储应用程序的故障信息库。当然，该故障信息库可以存储于一独立的数据库服务器，即各个用户终端会将故障信息上传至该数据库服务器，继而数据库服务器根据故障信息中包含的应用标识，将该故障信息存储于对应的故障 信息库内，本实施例提供的服务器可以从该数据库内获取对应的历史故障记录。
在本实施例中，服务器在确定了应用程序的故障信息库后，会根据该故障信息的设备信息，从故障信息库内提取所有关于该设备信息的历史故障记录。由于各个故障信息库中的各个历史故障记录均为有安装有该应用程序的用户终端上传的故障信息，因此各个历史故障记录中也会记载有上传该故障信息的用户终端对应的设备信息。服务器可以通过各个历史故障记录中包含的设备信息，与本次上传的故障信息进行匹配，并选取匹配成功的历史故障记录作为该故障信息关联的历史故障记录，并执行S103的相关操作。其中，匹配的方式可以为：服务器将故障信息内的故障信息导入到预设的哈希函数内，确定该设备信息对应的哈希值，例如服务器可以基于各个产品以及该产品的设备环境的对应关系，创建一个哈希函数，从而服务器可以通过输入设备信息，得到与之对应的设备环境。对于故障信息以及历史故障记录均执行上述操作，并将输出的哈希值与故障信息的哈希值一致的历史故障信息，识别为故障信息关联的历史哈希记录。
在S103中，根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数。
在本实施例中，服务器在确定了该设备信息的历史故障记录以及本次上传的故障信息后，可以基于上述两类信息确定该设备信息的异常系数，该异常系数越大，则表示该设备信息所存在的故障情况越多，从而该故障为偶发性故障的概率较小，因此需要对该应用程序进行故障修复，并向用户终端发布用于修复该故障信息的更新数据包；反之，若该异常系数越小，则表示该设备信息所出现的故障情况较少，因此在一定范围内，可以判定该异常情况为偶发性异常，并不属于普遍存在的异常情况，对于该类情况，由于是个体设备的原因导致的异常，因此服务器无需为其配置对应的更新数据包来修复异常情况。基于此，服务器可以通过计算该设备信息的异常系数，从而能够确定是否需要向该设备渠道的应用程序下发更新数据包，来修复故障情况。
可选地，在本实施例中，计算异常系数的方式可以为：服务器可以将该设备信息包含的历史故障记录以及故障信息的总个数，作为该设备信息的异常系数，即上述两类信息的数量越大，则该设备信息的异常系数越大；服务器还可以根据各个历史故障记录的创建时间，确定各个历史故障记录的权重值，并根据各个历史故障记录的权重值进行加权运行，确定该设备信息的异常系数。
优选地，在本实施例中，计算异常系数的方式可以为：服务器提取各个历史故障记录中包含的故障模块，并统计各个故障模块出现故障的次数，基于该次数确定各个故障模块的故障权重，从而计算该设备信息的异常系数。例如，对于某一应用程序包含5个功能模块，分别为功能模块A至E，而某一设备信息的3个历史故障记录中记载了功能模块A出 现故障，4个历史故障记录中记载了功能模块B出现故障，而本次获取的故障信息中也记录了功能模块A和功能模块B出现故障，即功能模块A的故障次数为4，功能模块B的故障次数为5，即根据该故障次数确定对应的故障权重，例如故障次数为4时对应的故障权重为α，而故障次数为5时对应的故障权重为β，则该设备信息的故障系数则为：4α+5β。
在S104中，若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包。
在本实施例中，服务器存储有一推送阈值，当异常系数大于该推送阈值时，则表示该设备信息与应用程序之间存在兼容性的问题，因此需要为该应用程序生成一个用于修复上述两者兼容性的更新数据包，从而能够用户终端上关于故障信息的故障问题。需要说明的是，该推送阈值可以由管理员进行设备，也可以基于该应用程序的下载量的变化进行对应的变化，从而使得该推送阈值能够动态调整，与当前的下载量相匹配，提高了更新数据包推送时机的准确性。
在本实施例中，服务器可以基于故障信息内包含的故障模块，获取各个故障模块对应的源码数据，并对该源码数据进行语法校验以及语义校验，若上述两项检测均通过，则获取该故障模块的接口信息以及线程信息，并与该设备信息中包含的接口标识以及线程标识进行匹配，是否存在接口冲突或线程冲突的情况，并基于冲突情况调整故障模块的接口信息以及线程信息，并根据修复后的源码数据生成更新数据包。
可选地，服务器可以将故障信息转发给开发人员的终端，以通知开发人员生成该故障信息的更新数据包，并将生成后的更新数据包返回给服务器，以便服务器进行更新数据包的推送操作。
可选地，在本实施例中，服务器在生成了一个故障信息或历史故障记录的更新数据包后，会将该故障信息以及该历史故障记录从故障信息库中删除，从而避免重复对该故障信息以及历史故障记录进行重复修复。
在S105中，向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
在本实施例中，服务器会为每个设备信息管理一个用户终端列表，该用户终端列表内所有用户终端的设备信息相同，例如若该设备信息为设备型号，则该用户终端列表内的所有用户终端的设备型号均一致。该用户终端列表可以通过应用程序的下载记录统计得到，用户终端在下载一个应用程序时，会发送一个下载请求，该下载请求包括有设备信息，服务器会基于该下载请求向用户终端返回该设备信息匹配的应用程序的程序文件，并生成一条下载记录，因而下载记录中记载有下载应用程序的用户终端的设备信息，从而能够统计 得到该用户终端列表。当然，该设备信息还可以为应用程序的下载渠道，例如某一应用商城，终端设备则可以获取安装有该应用商城客户端的所有用户终端，生成该用户终端列表，并将生成的更新数据包向该用户终端列表内的所有用户终端进行推送，从而修复了该设备信息的所有用户终端的故障情况。
以上可以看出，本申请实施例提供的一种更新数据包的推送方法在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题。与现有的更新数据包的统一推送方式相比，本实施例只有在异常系数较大时，才对设备信息对应的用户终端进行更新数据包的推送操作，从而实现定向推送的目的，而并不会对未发生异常的设备型号的用户终端发送更新数据包，减少了用户数据流量的浪费，提高了用户的使用体验以及软件的稳定性。
图2示出了本申请第二实施例提供的一种更新数据包的推送方法的S103具体实现流程图。参见图2，相对于图1述实施例，本实施例提供的一种更新数据包的推送方法中S103包括：S1031～S1032，具体详述如下：
在S1031中，获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值。
在本实施例中，应用程序中根据不同功能模块的重要程度，当该功能模块发生故障时，其对应的故障权重值也会不同。例如，若某一应用程序的主功能模块，例如实现应用程序启动以及关闭的功能模块，由于应用程序每次打开以及关闭均需要调用，若该功能模块出现异常，则无论应用程序内的其他模块是否异常，该应用程序也无法被用户正常使用，因此其对应的故障权重值较高，以便在该类型的功能模块出现故障时，能够尽快发布更新数据包，以修复该故障情况。因此，服务器可以根据应用程序内各个功能模块的优先级次序，确定各个功能模块的故障权重值，当该功能模块发生故障时，服务器则获取该功能模块的优先级信息，并查询该优先级信息对应的故障权重值，从而能够得到故障模块的故障权重值。
在本实施例中，该故障权重值可以由开发人员进行配置，则开发人员为每个功能模块配置对应的故障权重值，也可以如上述所，用户设置有一优先级转换函数，服务器基于各 个功能模块的使用次数，确定各个功能模块的优先级，并将优先级导入该优先级转换函数内，计算各个功能模块对应的故障权重值，特别地，该优先级转换函数可以为一哈希函数。
在本实施例中，各个历史故障记录以及本次上传的故障信息均记录有应用程序中发生故障的故障模块，因此服务器可以根据各个故障模块的模块标识，确定与之对应的故障权重值。
在S1032中，将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
Figure PCTCN2018123987-appb-000001
其中，UpdateLv为所述设备信息的异常系数；ErrorNum为所述历史故障信息的个数；CurrentTime为当前时刻的时间；ErrorTime i为第i个历史故障信息的创建时间；Partnum i为第i个历史故障信息包含的故障模块个数；ErrorPart ij为第i个历史故障信息中第j个故障模块的所述故障权重值；ErrorTime 0为故障信息的发送时间；ErrorPart 0j为故障信息中第j个故障模块的所述故障权重值；Parameter 0以及Parameter i为预设系数。
在本实施例中，终端设备会将各个历史故障记录、本次获取得到故障信息以及上述确定的故障权重值导入到异常系数转换模型内，计算该设备信息的异常系数，其中，各个历史故障记录除了记录有故障模块外，还会记录有该历史故障记录的创建时间，由于该创建时间与当前时间的差值越大，则该历史故障记录已被修复的概率越大，从而该历史故障信息对于异常系数的贡献则越小，因此通过设置
Figure PCTCN2018123987-appb-000002
这一因子来体现历史故障记录的创建时间对于异常系数的影响程度的变化关系，实现非线性加权，提高了异常系数的准确性。对各个历史故障记录通过上述加权叠加后，在计算平均值，从而能够确定该设备信息的平均故障程度，能够对各个历史故障记录对应的异常因子进行平滑处理，也能够进一步提高异常系数计算的准确性。
在本申请实施例中，通过确定历史故障记录以及故障信息中各个故障模块的故障权重值，并将上述三类信息导入到异常系数转换模型内，计算设备信息的异常系数，从而能够提高异常系数的准确性。
图3示出了本申请第二实施例提供的一种更新数据包的推送方法S105的具体实现流程图。参见图3，相对于图1述实施例，本实施例提供的一种更新数据包的推送方法S105包 括：S1051～S1053，具体详述如下：
在S1051中，获取所述更新数据包的数据量。
在本实施例中，服务器在发送更新数据包前，会先确定该更新数据包的数据量，并把该数据量与预设的数据量阈值进行比对，该更新数据包的数据量小于预设的数据量阈值，则执行S1052的操作；反之，若数据量大于或等于预设的数据量阈值，则执行S1053的操作。
可选地，本实施例的数据量阈值可以由管理员进行手动设置，也可以服务器根据所处网络的带宽资源自动进行调整。例如，服务器设定了发送一个更新数据包的预计时长为4秒，且占用的带宽资源不能超过50％，当前的带宽资源为100M/s，由此可见，该数据量阈值则可以为：Vmax＝100M/s*50％*4＝200M。
在S1052中，若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包。
在本实施例中，若服务器确定了该更新数据包的数据量小于预设的数据量阈值，则表示该更新数据包的数据量较小，发送一个数据包所需的时间较短，并不会出现因发送更新数据包，而导致发送超出预设时长仍未发送完毕的情况，在此基础上，通过主线程进行更新数据包的发送效率较高。由于主线程可调用的硬件资源以及带宽资源较多，因此进行数据包发送的效率也较高，但由于服务器在检测主线程运行时，会设置一个最大响应时长，若该响应时长超过预设的响应阈值，则会识别该主线程处于响应异常状态，则会终止该主线程的操作，重新进行响应。因此，若更新数据包的数据量较大，服务器则会识别该主线程处于响应异常状态，并反复终止并重发，导致资源浪费以及故障数据包无法正常发送的情况。因此，当故障数据包的数据量较小时，服务器才通过主线程进行数据发布，从而提高发送的成功率。
在本实施例中，服务器在确定通过主线程向各个用户终端发送更新数据包时，可以根据用户终端上传故障信息的先后次序，作为该用户终端发送更新数据包的发送次序。
在S1053中，若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
在本实施例中，若服务器在确定了更新数据包大于或等于数据量阈值，则表示该更新数据包的数据量较大，通过主线程串行方式进行发送的话，容易产生上述的主线程因执行 发送操作时间过程而识别线程超时的情况。因此，在该情况下，将通过子线程并行的方式向各个用户终端发送更新数据包。
在本实施例中，服务器查询该故障类型的对应关系中记录了用户终端的终端个数，并在主线程下创建与该终端个数相同的子线程的个数，并将各个子线程的运行模式设置为异步并行模式，从而控制各个子线程分别与各个用户终端进行通信连接，通过各个子线程分别向各个用户终端发送更新数据包。
可选地，若终端个数大于服务器最大子线程数，则创建与最大线程数数量相同的子线程，向部分用户终端进行更新数据包的发送操作，在发送完毕后，再对余下部分的用户终端进行发送，直到将该故障类型对应的用户终端均进行数据包发送操作。
在本申请实施例中，服务器根据更新数据包的数据量大小，选择合适的发送方式进行数据发送，从而提高了发送效率以及发送的成功率。
图4示出了本申请第三实施例提供的一种更新数据包的推送方法的具体实现流程图。参见图4，相对于图1-图3所述实施例，本实施例提供的一种更新数据包的推送方法中，在所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数之后，还包括：S401～S402，具体详述如下：
在S401中，若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录。
在本实施例中，由于异常系数是用于判断是否需要向用户终端推送更新数据包的参考值，当该异常系数大于推送阈值时，则生成故障信息的更新数据包并执行推送流程；而当异常系数小于或等于推送阈值时，则表示该设备信息的故障情况并不严重，可能属于偶发性异常，在该情况下，服务器并不会为该故障信息生成对应的更新数据包，而是将获取当前的时间信息，并基于该时间信息以及本次接收到的故障信息，生成故障记录。需要说明的是，该时间信息可以包括有当前的日期信息以及具体时刻信息。
在S402中，将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
在本实施例中，服务器在生成了该故障信息对应的故障记录后，为了便于发开人员对于应用程序的故障信息进行管理，服务器会根据应用标识确定该应用程序的故障信息库，并将该故障记录存储于该故障信息库内。由于本次异常操作属于偶发性异常，服务器还会想用户终端反馈一个故障待处理信息。
在本申请实施例中，在异常系数较少时，根据故障信息生成故障记录并存储于故障信息库内，从而便于开发人员对应用程序的故障情况进行管理。
图5示出了本申请第四实施例提供的一种更新数据包的推送方法的具体实现流程图。参见图5，相对于图1-图3所述实施例，本实施例提供的一种更新数据包的推送方法在所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包之前，还包括：S501～S502，具体详述如下：
在S501中，获取所述用户终端的网络状态。
在本实施例中，服务器在向用户终端发送更新数据包之前，可以向用户终端发送一个网络状态获取请求，确定当前用户终端的网络状态。该网络状态即为与互联网进行通信联机的具体连接方式，是通过有线网络、无线局域网或是移动网络。用户终端基于当前与服务器通信的网络状态，生成一个网络状态结果返回给服务器。
在S502中，若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
在本实施例中，服务器若确定当前用户终端的网络状态为预设的数据包下载状态，则向用户终端发送更新数据包。特别地，该数据包下载状态为：无线局域网状态或有线网络状态。
可选地，若服务器确定当前网络状态不满足预设的数据包下载状态，则设置一个重发计时器，在重发计时器的计数值大于重发计数值后，返回S501的相关操作，直到用户终端的网络状态满足预设的数据包下载状态，再执行下载操作。
可选地，用户终端在接收到网络状态获取请求后，当确定当前状态不满足预设的数据包下载状态时，可进入下载等待状态，当检测到用户终端的网络状态满足数据包下载状态时，主动向服务器发送一个数据包获取请求，以启动数据包下载操作。
在本申请实施例中，通过获取用户终端的网络状态，判定是否执行数据包发送，避免用户终端无意下载而浪费大量的数据流量。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
图6示出了本申请一实施例提供的一种服务器的结构框图，该服务器包括的各单元用于执行图1对应的实施例中的各步骤。具体请参阅图1与图1所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。
参见图6，所述服务器包括：
故障信息接收单元61，用于接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
历史故障记录获取单元62，用于基于所述应用标识确定所述应用程序的故障信息库， 并从故障信息库中提取所述设备信息对应的历史故障记录；
异常系数计算单元63，用于根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
更新数据包获取单元64，用于若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
更新数据包推送单元65，用于向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
可选地，所述异常系数计算单元63包括：
故障权重值确定单元，用于获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值；
故障信息导入单元，用于将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
Figure PCTCN2018123987-appb-000003
其中，UpdateLv为所述设备信息的异常系数；ErrorNum为所述历史故障信息的个数；CurrentTime为当前时刻的时间；ErrorTime i为第i个历史故障信息的创建时间；Partnum i为第i个历史故障信息包含的故障模块个数；ErrorPart ij为第i个历史故障信息中第j个故障模块的所述故障权重值；ErrorTime 0为故障信息的发送时间；ErrorPart 0j为故障信息中第j个故障模块的所述故障权重值；Parameter 0以及Parameter i为预设系数。
可选地，所述更新数据包推送单元65包括：
数据量获取单元，用于获取所述更新数据包的数据量；
串行推送单元，用于若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包；
并行推送单元，用于若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
可选地，所述服务器还包括：
故障记录生成单元，用于若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录；
故障记录导入单元，用于将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
可选地，所述服务器还包括：
网络状态获取单元，用于获取所述用户终端的网络状态；
网络状态识别单元，用于若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
因此，本申请实施例提供的服务器同样可以在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题。
图7是本申请另一实施例提供的一种服务器的示意图。如图7所示，该实施例的服务器7包括：处理器70、存储器71以及存储在所述存储器71中并可在所述处理器70上运行的计算机可读指令72，例如更新数据包的推送程序。所述处理器70执行所述计算机可读指令72时实现上述各个更新数据包的推送方法实施例中的步骤，例如图1所示的S101至S105。或者，所述处理器70执行所述计算机可读指令72时实现上述各装置实施例中各单元的功能，例如图6所示模块61至65功能。
示例性的，所述计算机可读指令72可以被分割成一个或多个单元，所述一个或者多个单元被存储在所述存储器71中，并由所述处理器70执行，以完成本申请。所述一个或多个单元可以是能够完成特定功能的一系列计算机可读指令指令段，该指令段用于描述所述计算机可读指令72在所述服务器7中的执行过程。例如，所述计算机可读指令72可以被分割成故障信息接收单元、历史故障记录获取单元、异常系数计算单元、更新数据包获取单元以及更新数据包推送单元，各单元具体功能如上所述。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上 描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (20)

  1. 一种更新数据包的推送方法，其特征在于，包括：
    接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
    基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
    根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
    若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
    向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  2. 根据权利要求1所述的推送方法，其特征在于，所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数，包括：
    获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值；
    将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
    Figure PCTCN2018123987-appb-100001
    其中，UpdateLv为所述设备信息的异常系数；ErrorNum为所述历史故障信息的个数；CurrentTime为当前时刻的时间；ErrorTime i为第i个历史故障信息的创建时间；Partnum i为第i个历史故障信息包含的故障模块个数；ErrorPart ij为第i个历史故障信息中第j个故障模块的所述故障权重值；ErrorTime 0为故障信息的发送时间；ErrorPart 0j为故障信息中第j个故障模块的所述故障权重值；Parameter 0以及Parameter i为预设系数。
  3. 根据权利要求1所述的推送方法，其特征在于，所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包，包括：
    获取所述更新数据包的数据量；
    若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式， 并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包；
    若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
  4. 根据权利要求1-3任一项所述的推送方法，其特征在于，在所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数之后，还包括：
    若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录；
    将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
  5. 根据权利要求1-3任一项所述的推送方法，其特征在于，在所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包之前，还包括：
    获取所述用户终端的网络状态；
    若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  6. 一种服务器，其特征在于，包括：
    故障信息接收单元，用于接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
    历史故障记录获取单元，用于基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
    异常系数计算单元，用于根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
    更新数据包获取单元，用于若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
    更新数据包推送单元，用于向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  7. 根据权利要求6所述的服务器，其特征在于，所述异常系数计算单元包括：
    故障权重值确定单元，用于获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值；
    故障信息导入单元，用于将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
    Figure PCTCN2018123987-appb-100002
    其中，UpdateLv为所述设备信息的异常系数；ErrorNum为所述历史故障信息的个数；CurrentTime为当前时刻的时间；ErrorTime i为第i个历史故障信息的创建时间；Partnum i为第i个历史故障信息包含的故障模块个数；ErrorPart ij为第i个历史故障信息中第j个故障模块的所述故障权重值；ErrorTime 0为故障信息的发送时间；ErrorPart 0j为故障信息中第j个故障模块的所述故障权重值；Parameter 0以及Parameter i为预设系数。
  8. 根据权利要求6所述的服务器，其特征在于，所述更新数据包推送单元包括：
    数据量获取单元，用于获取所述更新数据包的数据量；
    串行推送单元，用于若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包；
    并行推送单元，用于若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
  9. 根据权利要求6-8任一项所述的服务器，其特征在于，所述服务器还包括：
    故障记录生成单元，用于若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录；
    故障记录导入单元，用于将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
  10. 根据权利要求6-8任一项所述的服务器，其特征在于，所述服务器还包括：
    网络状态获取单元，用于获取所述用户终端的网络状态；
    网络状态识别单元，用于若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  11. 一种服务器，其特征在于，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现如下步骤：
    接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
    基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
    根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
    若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
    向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  12. 根据权利要求11所述的服务器，其特征在于，所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数，包括：
    获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值；
    将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
    Figure PCTCN2018123987-appb-100003
    其中，UpdateLv为所述设备信息的异常系数；ErrorNum为所述历史故障信息的个数；CurrentTime为当前时刻的时间；ErrorTime i为第i个历史故障信息的创建时间；Partnum i为第i个历史故障信息包含的故障模块个数；ErrorPart ij为第i个历史故障信息中第j个故障模块的所述故障权重值；ErrorTime 0为故障信息的发送时间；ErrorPart 0j为故障信息中第j个故障模块的所述故障权重值；Parameter 0以及Parameter i为预设系数。
  13. 根据权利要求11所述的服务器，其特征在于，所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包，包括：
    获取所述更新数据包的数据量；
    若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包；
    若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发 送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
  14. 根据权利要求11-13任一项所述的服务器，其特征在于，在所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数之后，所述处理器执行所述计算机可读指令时实现如下步骤：
    若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录；
    将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
  15. 根据权利要求11-13任一项所述的服务器，其特征在于，在所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包之前，所述处理器执行所述计算机可读指令时实现如下步骤：
    获取所述用户终端的网络状态；
    若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  16. 一种计算机非易失性可读存储介质，所述计算机非易失性可读存储介质存储有计算机可读指令，其特征在于，所述计算机可读指令被处理器执行时实现如下步骤：
    接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
    基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
    根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
    若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
    向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
  17. 根据权利要求16所述的计算机非易失性可读存储介质，其特征在于，所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数，包括：
    获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值；
    将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
    Figure PCTCN2018123987-appb-100004
    其中，UpdateLv为所述设备信息的异常系数；ErrorNum为所述历史故障信息的个数；CurrentTime为当前时刻的时间；ErrorTime i为第i个历史故障信息的创建时间；Partnum i为第i个历史故障信息包含的故障模块个数；ErrorPart ij为第i个历史故障信息中第j个故障模块的所述故障权重值；ErrorTime 0为故障信息的发送时间；ErrorPart 0j为故障信息中第j个故障模块的所述故障权重值；Parameter 0以及Parameter i为预设系数。
  18. 根据权利要求16所述的计算机非易失性可读存储介质，其特征在于，所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包，包括：
    获取所述更新数据包的数据量；
    若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包；
    若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
  19. 根据权利要求16-18任一项所述的计算机非易失性可读存储介质，其特征在于，在所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数之后，所述处理器执行所述计算机可读指令时实现如下步骤：
    若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录；
    将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
  20. 如权利要求16-18任一项所述的计算机非易失性可读存储介质，其特征在于，在所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包之前，所述处理器执行所述计算机可读指令时实现如下步骤：
    获取所述用户终端的网络状态；
    若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
PCT/CN2018/123987 2018-09-26 2018-12-26 一种更新数据包的推送方法及服务器 WO2020062674A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811121969.9A CN109144559B (zh) 2018-09-26 2018-09-26 一种更新数据包的推送方法及服务器
CN201811121969.9 2018-09-26

Publications (1)

Publication Number Publication Date
WO2020062674A1 true WO2020062674A1 (zh) 2020-04-02

Family

ID=64812498

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/123987 WO2020062674A1 (zh) 2018-09-26 2018-12-26 一种更新数据包的推送方法及服务器

Country Status (2)

Country Link
CN (1) CN109144559B (zh)
WO (1) WO2020062674A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112541011A (zh) * 2020-12-04 2021-03-23 北京来也网络科技有限公司 基于rpa和ai的电网终端故障处理方法及装置
CN114706709A (zh) * 2022-06-01 2022-07-05 成都运荔枝科技有限公司 一种saas服务异常处理方法、装置及可读存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110012344A (zh) * 2019-02-25 2019-07-12 努比亚技术有限公司 一种视频下载方法、终端及计算机可读存储介质
CN110442478A (zh) * 2019-07-04 2019-11-12 深圳壹账通智能科技有限公司 产品故障处理方法、装置、计算机设备和存储介质
CN110611705A (zh) * 2019-09-02 2019-12-24 深圳市丰润达科技有限公司 设备修复方法、服务器和应用终端
CN110674149B (zh) * 2019-09-12 2022-03-11 金蝶软件（中国）有限公司 业务数据处理方法、装置、计算机设备和存储介质
CN111143134B (zh) * 2019-12-30 2024-06-04 深圳Tcl新技术有限公司 故障处理方法、设备及计算机存储介质
CN112286656B (zh) * 2020-10-21 2023-08-29 百度在线网络技术（北京）有限公司 小程序模拟方法、装置、电子设备和计算机可读存储介质
CN113254056B (zh) * 2021-04-16 2022-04-19 荣耀终端有限公司 一种更新预警及故障修复的方法及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8451997B2 (en) * 2010-06-04 2013-05-28 Microsoft Corporation Safe conversation park and retrieval
CN104301203A (zh) * 2014-09-10 2015-01-21 腾讯科技（深圳）有限公司 一种消息推送方法和设备
US9547579B1 (en) * 2014-12-30 2017-01-17 Ca, Inc. Method and apparatus for automatically detecting defects
CN108322345A (zh) * 2018-02-07 2018-07-24 平安科技（深圳）有限公司 一种故障修复数据包的发布方法及服务器

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013000749A1 (en) * 2011-06-28 2013-01-03 Malvacom Ab Method of updating a mobile device, and an updating device
CN106161079A (zh) * 2015-04-28 2016-11-23 小米科技有限责任公司 故障反馈方法和装置
CN106685744A (zh) * 2017-03-13 2017-05-17 福建中金在线信息科技有限公司 一种故障排除方法、装置及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8451997B2 (en) * 2010-06-04 2013-05-28 Microsoft Corporation Safe conversation park and retrieval
CN104301203A (zh) * 2014-09-10 2015-01-21 腾讯科技（深圳）有限公司 一种消息推送方法和设备
US9547579B1 (en) * 2014-12-30 2017-01-17 Ca, Inc. Method and apparatus for automatically detecting defects
CN108322345A (zh) * 2018-02-07 2018-07-24 平安科技（深圳）有限公司 一种故障修复数据包的发布方法及服务器

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112541011A (zh) * 2020-12-04 2021-03-23 北京来也网络科技有限公司 基于rpa和ai的电网终端故障处理方法及装置
CN114706709A (zh) * 2022-06-01 2022-07-05 成都运荔枝科技有限公司 一种saas服务异常处理方法、装置及可读存储介质

Also Published As

Publication number Publication date
CN109144559B (zh) 2022-02-01
CN109144559A (zh) 2019-01-04

Similar Documents

Publication Publication Date Title
WO2020062674A1 (zh) 一种更新数据包的推送方法及服务器
CN108322345B (zh) 一种故障修复数据包的发布方法及服务器
CN108600029B (zh) 一种配置文件更新方法、装置、终端设备及存储介质
US11119745B2 (en) Automated deployment of applications
CN108566290B (zh) 服务配置管理方法、系统、存储介质和服务器
US10474519B2 (en) Server fault analysis system using event logs
US9497072B2 (en) Identifying alarms for a root cause of a problem in a data processing system
US9548886B2 (en) Help desk ticket tracking integration with root cause analysis
WO2019184164A1 (zh) 自动部署Kubernetes从节点的方法、装置、终端设备及可读存储介质
US9497071B2 (en) Multi-hop root cause analysis
US9547564B1 (en) Automated deployment of applications
JP2023525393A (ja) ゲートウェイリソースを更新する方法および装置、ならびにｉｏｔ制御プラットフォーム
WO2019223142A1 (zh) 应用程序测试方法、装置、计算机设备及存储介质
US20140282540A1 (en) Performant host selection for virtualization centers
WO2016054770A1 (en) Techniques for checkpointing/delivery between primary and secondary virtual machines
CN111625252B (zh) 集群的升级维护方法、装置、电子设备及存储介质
WO2021115054A1 (zh) 调整集群系统内的节点配置的方法及服务器
WO2016165242A1 (zh) 系统内节点数的调整方法和装置
CN104065517A (zh) 分布式系统软件配置管理方法和系统
US10892961B2 (en) Application- and infrastructure-aware orchestration for cloud monitoring applications
WO2019153880A1 (zh) 集群中镜像文件下载的方法、节点、查询服务器
CN108737499A (zh) 服务器配置方法和装置
WO2020108443A1 (zh) 一种虚拟化管理方法及装置
WO2019062019A1 (zh) 一种数据列表的导出方法及其终端
US9098334B2 (en) Special values in oracle clusterware resource profiles

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18935300

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 09.07.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18935300

Country of ref document: EP

Kind code of ref document: A1