WO2016177285A1 - 一种数据推送方法及装置 - Google Patents
一种数据推送方法及装置 Download PDFInfo
- Publication number
- WO2016177285A1 WO2016177285A1 PCT/CN2016/079820 CN2016079820W WO2016177285A1 WO 2016177285 A1 WO2016177285 A1 WO 2016177285A1 CN 2016079820 W CN2016079820 W CN 2016079820W WO 2016177285 A1 WO2016177285 A1 WO 2016177285A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- client
- service data
- data
- service
- server
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000001360 synchronised effect Effects 0.000 abstract description 12
- 230000005540 biological transmission Effects 0.000 abstract description 11
- 230000008569 process Effects 0.000 description 18
- 238000012545 processing Methods 0.000 description 14
- 230000007246 mechanism Effects 0.000 description 9
- 238000004590 computer program Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 230000002085 persistent effect Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
Definitions
- the present application relates to the field of computer technologies, and in particular, to a data push method and apparatus.
- the terminal may be a terminal such as a personal computer, a mobile phone, a tablet computer, a smart watch, or a mobile phone station
- the service may be an online service such as an instant messaging service, an online shopping service, an online financial service, or an online video service.
- the client applied on the terminal generally sends a data request to the server based on the Hyper Text Transfer Protocol (HTTP) protocol, and the server responds to the data request, and the corresponding The business data is sent to the client.
- HTTP Hyper Text Transfer Protocol
- the above-mentioned service data may be lost during the transmission from the server to the client.
- the business data acquired by the client is incomplete, and the server is not aware of it. Therefore, in the above case, the reliability of the service data acquired by the client is low.
- the embodiment of the present application provides a data pushing method, which is used to solve the problem that the reliability of the service data acquired by the client from the server is low in some application scenarios in the prior art.
- the embodiment of the present application provides a data pushing device, which is used to solve the problem that the reliability of the service data acquired by the client from the server is low in some application scenarios in the prior art.
- the server obtains synchronization information of the service data on the client;
- the server according to the synchronization information, through a long connection established with the client, The client pushes incremental data of the service data.
- the client generates synchronization information of the service data for the service data on the client;
- the client reports the synchronization information to the server, so that the server pushes the incremental data of the service data to the client according to the synchronization information.
- An obtaining module configured to acquire synchronization information of service data on the client
- a pushing module configured to push the incremental data of the service data to the client by using a long connection established with the client according to the synchronization information.
- a generating module configured to generate synchronization information of the service data for service data on the client
- the reporting module is configured to report the synchronization information to the server, so that the server pushes the incremental data of the service data to the client according to the synchronization information.
- the server can determine the existing service data on the client and the incremental data of the service data that has not been synchronized in the past according to the synchronization information, and the server and the client A long connection is maintained between the terminals. Therefore, the server can sequentially push the incremental data that has not been synchronized to the client, and even if the incremental data is lost during the transmission, the server can subsequently pass the synchronization information. Knowing, and then retransmitting the lost incremental data to the client, thereby improving the reliability of the service data obtained by the client from the server.
- FIG. 1 is a data pushing process provided by an embodiment of the present application
- Figure 2 shows the data push details provided by the embodiment of the present application in a practical application scenario. process
- FIG. 3 shows a detailed process of data push provided by an embodiment of the present application in another practical application scenario
- FIG. 4 is a data pushing process corresponding to FIG. 1 according to an embodiment of the present application.
- FIG. 5 is a schematic structural diagram of a data pushing apparatus according to an embodiment of the present application.
- FIG. 6 is a schematic structural diagram of another data pushing apparatus according to an embodiment of the present application.
- FIG. 1 is a data pushing process provided by an embodiment of the present application, which specifically includes the following steps:
- S101 The server obtains synchronization information of the service data on the client.
- the execution body of the method for information verification provided by the embodiment of the present application may be: a server of an application on a terminal or a server.
- the server may be a server in a client/server (C/S) structure, or may be a server in a browser/server (Bower/Server, B/S) structure.
- the client may be a client in a C/S structure or a browser in a B/S structure;
- the terminal includes but is not limited to: a personal computer, a mobile phone, a tablet computer, a smart watch, The vehicle mobile station or the like;
- the server includes but is not limited to: a personal computer, a large and medium-sized computer, a computer cluster, and the like.
- the service data may be service data in any determined service scenario.
- it may include multiple service scenarios, and a service scenario for managing the address book.
- the service data is a number information of a user in the address book, and the like, for a business scenario of managing short messages sent and received with a specific user, the service data is related to the specific user. Short messages sent and received, and so on.
- the user when using various applications on the terminal, the user can first log in to the client of the application, and then, through various operations performed on the client, and the corresponding server (the server can be located above) The server interacts with other terminals to obtain service data in the corresponding service scenario.
- the business data in most business scenarios is ordered.
- the user can perform various operations such as querying the order and adding goods to the shopping cart on the client.
- the server sends corresponding service data to the client according to the predetermined business logic according to the operation of the user.
- the server will query the details of each order that the user has pressed.
- the information (that is, the service data) is sent to the client.
- the service data is the detailed information of each order.
- the detailed information of each order is ordered and can be The order order information included in the order details is used to indicate the order of the detailed information of each order. The earlier the order is placed, the higher the order of the order details.
- the server may only send the incremental data of the service data related to the user operation to the client (incremental data of the service data, that is, the new service scenario that belongs to the same service scenario as the service data. Business data).
- the server can only return the details of the new order of the user to the client, instead of sending the detailed information of each order that has been sent before to the client, thereby reducing the service.
- the processing load of the end improves the processing efficiency of the server.
- the format of the service data and the format of the incremental data of the service data may be pre-agreed between the client and the server, which is not limited in this application.
- the above-mentioned service data may be lost during the transmission process from the server to the client, resulting in the lack of the lost service data on the client, but the server does not know, or During the transmission process of the foregoing service data from the server to the client, the transmission sequence may be disordered, causing the client to obtain out-of-order service data and affect subsequent use.
- the server can solve the above problem based on the long connection established with the client and the synchronization information of the service data on the client. Specifically, based on the long connection, the server may send the service data to the client without waiting for the client to send the operation request, but may actively push the incremental data of the service data to the client, thereby improving the client. And processing efficiency of the server; and based on the synchronization information, the server can determine the existing service data on the client, and then push the incremental data of the existing service data to the client in an orderly manner, where the service data The order can be determined by the server and/or the client based on the business logic of the business data.
- the service data is synchronized by the server to the client
- the synchronization information may reflect a synchronization point between the service data on the client and the service data on the server, that is, in the order of The service data before the synchronization point (including the synchronization point), the server has been synchronized to the client, and the service data in the order after the synchronization point, the server has not been synchronized to the client. Therefore, when the server synchronizes the service data with the client, or when the client actively requests the service data from the server, the server can obtain the synchronization information of the service data on the client, so as to determine which service data is synchronized to the client. And how to synchronize these business data to the client.
- S102 The server pushes the incremental data of the service data to the client by using a long connection established with the client according to the synchronization information.
- the server may establish and maintain a long connection with the client in advance, and then push the incremental data of the service data based on the long connection, so that the client may be in the duration of the long connection for a period of time.
- the server actively pushes the incremental data to the client.
- the server can orderly provide the client to the client according to the synchronization information. Push these incremental data.
- the long connection may be any length based on a communication protocol used by the transport layer. Connections, such as Transmission Control Protocol (TCP) long connections, and so on.
- TCP Transmission Control Protocol
- the long connection can be implemented by using a prior art, for example, by using a heartbeat packet method. Specifically, a TCP connection is first established between the client and the server, and then the client sends the server to the server at a preset time interval. A heartbeat packet, the server responds to the heartbeat packet, and the client determines whether the response of the server to the heartbeat packet is received within a specified time. If yes, it is determined that the established TCP connection is still valid, otherwise, the server is re-enabled. Establish a TCP connection. The above TCP connection can be called a TCP long connection.
- the server can determine the existing service data on the client and the incremental data of the service data that has not been synchronized, and maintain a long connection between the server and the client, according to the synchronization information. Therefore, the server can order the incremental data that has not been synchronized in the order to the client, and accordingly, the client can receive the incremental data in an orderly manner, and even if the incremental data is lost during the transmission, the server Subsequently, the synchronization information can be known, and the lost incremental data is retransmitted to the client, thereby improving the reliability of the service data acquired by the client from the server. Moreover, the client can no longer actively request the server to obtain the incremental data of the service data, but can passively wait for the server to push the incremental data, thereby reducing the processing load of the client.
- the server may obtain the synchronization information of the service data on the client in multiple manners, including but not limited to the following two modes:
- the server obtains the synchronization information of the service data on the client, and specifically includes: the server receives the synchronization information of the service data reported by the client, and saves the synchronization information.
- the server searches for synchronization information of the service data stored on the client or saved in another location.
- the synchronization request may be sent by a module that is responsible for managing the service data on the server, or may be sent by the client.
- the synchronization information of the business data on the client can be generated by the client and maintained and updated.
- the synchronization information of the service data stored by the server on the client itself is obviously saved by the client to the server during the previous interaction with the client.
- the server performs the subsequent push operation, and performs the operation based on the acquired synchronization information, and saves the acquired synchronization information to replace the synchronization information.
- the previously saved synchronization information in this way, can improve the real-time and reliability of the synchronization information used by the server.
- the first method is generally applicable to an application scenario in which a user queries the latest service data in real time on the client, or an application scenario in which the client just logs in and uses the user's account to log in to the server, or the client The application scenario when the terminal registers a new service scenario with the server.
- the second method is applicable to the update of the service data of the server (that is, the incremental data of the service data generated on the client), and it is necessary to synchronize the application scenarios of the incremental data to the client in time.
- the service data on the client may be composed of multiple service data blocks.
- the incremental data of the service data may also be composed of multiple incremental data blocks, and the service data is Block and delta blocks are ordered.
- the server can identify the sequence generated for each service data block and each incremental data block.
- the incremental data block is sequentially sent to the client, and the server can determine the progress of receiving the incremental data block on the current client according to the synchronization information of the obtained service data on the client, thereby determining whether a sent data has been sent.
- the incremental data block is lost during transmission, and if so, the server can re-push the lost incremental data block to the client.
- the server pushes the incremental data of the service data to the client by using a long connection established with the client according to the synchronization information, specifically including The server identifies, according to the sequence identifier included in the synchronization information, and the sequence identifier generated by each incremental data block included in the incremental data of the service data, by using a long connection established with the client, Pushing each incremental data block to the client.
- the service data and the service data block are further described in detail.
- the application maintains different service data for different users who log in, and the service data can belong to different service scenarios. Therefore, in order to distinguish the service data corresponding to different users and corresponding to different service scenarios, the user identifier and the user identifier may be used.
- the service scenario type identifier identifies the service data.
- the service data specifically includes a user identifier, a service scene type identifier, and an ordered at least one service data block, where an order of each service data block in the service data is generated by the server.
- the sequential identification representation of the business data block is further described in detail.
- the service data block may be the smallest logical unit in the service data, and the instant messaging application is still taken as an example for description. Assume that user A logs in to the instant messaging application with his or her own user ID and uses the short message function in the instant messaging application, and the corresponding service scenario is a short information service scenario, and the instant messaging application is maintained by user A. All the short messages sent and received between the communication contacts may be referred to as service data in the short message service scenario. Further, each service data block included in the service data corresponds to a short message. Obviously, the short messages are ordered, and the order of the short messages with the higher sending and receiving time is higher.
- the server may generate a sequence identifier of the service data block for the order of the service data block in each service data block.
- the synchronization information may include the user identifier, the service scenario identifier, and the sequence identifier of the service data block that is included in the service data.
- the server may generate a sequence identifier for each incremental data block included in the incremental data of the service data according to the following method: the server determines that the saved information corresponding to the synchronization information includes a data block of the user identifier and the service scenario identifier, as an incremental data block included in the incremental data of the service data, and identified according to the sequence of each service data block included in the service data, and the service data block. And a sequence of service logic between each incremental data block, respectively generating a sequence identifier for each incremental data block, wherein the sequential identifier of each incremental data block indicates that the incremental data block is in each of the service data blocks And the order in each incremental data block.
- the business logic sequence may reflect the order of the business data blocks on the client and the incremental data blocks to be pushed by the server.
- the short message service scenario is still taken as an example. It is assumed that there are two service data blocks (ie, two short messages) on the current client, according to the short message.
- the order of receiving and/or issuing short messages at a time should be higher than the order of short messages received and/or issued later, then it can be considered that the business logic order of the former is higher than that of the latter. before.
- the server identifies, according to the sequence identifier included in the synchronization information, and the sequence identifier generated by each incremental data block included in the incremental data of the service data, by establishing with the client The long connection, the pushing the incremental data blocks to the client, specifically: the server determines, in each incremental data block, that the order is after the service data block corresponding to the sequence identifier included in the synchronization information Incremental data blocks, and in the order of the incremental data blocks, push the determined incremental data blocks to the client through a long connection established with the client, so that the client is receiving After each incremental data block pushed by the server, the incremental data block is added to the service data as a service data block, and the synchronization information is updated.
- the server may define a corresponding data structure as a container for the incremental data block to be pushed to the client, and for each incremental data block, the user identifier and the service scenario corresponding to the synchronization information are included.
- the identifier, and the incremental data block and the generated sequence identifier of the incremental data block are all put in the same container for pushing, so that the processing efficiency of the server can be improved, and the processing is processed by the client.
- the following examples are given.
- the container defined by the server for the incremental data block may be a data structure named operation log OPLOG, and the OPLOG contains at least four fields: PAYLOAD (representing the incremental data block), USER ID (representing the user identifier), and BIZ_TYPE (representing Service scenario type identifier), OPLOG ID (indicating the sequence identifier of the incremental data block).
- PAYLOAD presents the incremental data block
- USER ID presents the user identifier
- BIZ_TYPE presenting Service scenario type identifier
- OPLOG ID indicating the sequence identifier of the incremental data block.
- the server can generate an OPLOG correspondingly.
- the server synchronizes the service data to the client, only the OPLOGs after the sequence identifiers included in the acquired synchronization information are sequentially arranged. Push it to the client.
- the client after receiving the OPLOG, extracts the incremental data blocks it contains, and then adds each incremental data as a new business data block according to the order of each incremental data.
- the sequence identifier in the synchronization information is updated to: after adding the incremental data, the order of the service data on the self is the most backward. It should be noted that if you add each incremental data After that, the sequence identifiers of the service data blocks on the client are discontinuous, that is, if at least one sequence identifier is missing in each sequence identifier, some incremental data blocks that the server has sent may be inferred (corresponding to the missing order). The identified incremental data block may have been lost during the transmission.
- the client may update the sequence identifier in the synchronization information to: the condition that the business data on itself is kept continuous after adding the incremental data.
- the server can re-push the lost incremental data block to the client according to the updated synchronization information.
- the sequence identifier of the service data blocks is also used by the server.
- the volume data block is generated by the method of generating sequence identification.
- the server can use a positive integer as the sequence identifier, and the smaller the value, the higher the order of the sequence identification. Assume that the order of each service data block in the service data on the client is 1 to 8. On the server side, in addition to these service data blocks, there are several incremental data blocks (assuming 8), then the client The synchronization information of the service data includes a sequence identifier of 8, and the server generates sequence identifiers 9 to 16 for the eight incremental data blocks according to the business logic relationship between the eight incremental data blocks. The order of the incremental data blocks with the higher order is smaller. That is, the sequential identification of each service data block on the client and each incremental data block pushed by the server is incremented according to the business logic sequence. Similarly, in addition to positive integers, the server can also use other ordered character sets as sequential identifiers, such as English letters.
- the locking mechanism can be used to solve the problem, wherein the locking mechanism includes but is not limited to an optimistic locking mechanism and a pessimistic locking mechanism. Specifically, when the optimistic locking mechanism is adopted, the server obtains the saved latest sequence identifier (called the current value) from the database before submitting the request for generating the sequence identification to the database, and then carries the request for generating the sequence identification request.
- the optimistic locking mechanism when adopted, the server obtains the saved latest sequence identifier (called the current value) from the database before submitting the request for generating the sequence identification to the database, and then carries the request for generating the sequence identification request.
- the database receives the build After the sequence identification request, it is determined whether the current value is the same as the actual current value of the sequence identifier in the database. If yes, the generation sequence identification request is successfully processed; otherwise, the failure response is returned to the server, and correspondingly, the server receives the failure response. You can try again later to prevent the sequential identification from being generated repeatedly.
- the pessimistic locking mechanism when a server is submitting a request for generating a sequence identification to the database, the sequence identification is locked, and other servers need to wait in the database maintenance waiting queue, and wait for the lock to be released before continuing to generate the sequence identifier. It is possible to prevent the sequential identification from being generated repeatedly. Obviously, these two lock mechanisms have their own advantages and disadvantages.
- the optimistic lock mechanism does not require a database maintenance wait queue.
- the response to the requester is fast and does not block the requester.
- the requestor processing mode is relatively complicated, and the pessimistic lock requestor processing mode is Simple, but the database overhead is relatively large. More suitable locking mechanisms can be selected according to different application scenarios.
- the client is specifically divided into three functional modules: a service client module, a synchronization (SYNC) (SYNC) client module, and a long connection client module; and the server is also specifically divided into three functional modules: Business server module, SYNC server module, long connection server module. Specifically, the following steps are included:
- the SYNC client module generates synchronization information of the service data on the client, and forwards the information to the long connection client module.
- the long connection client module establishes a long connection with the long connection server module in advance or in real time, and reports the synchronization information to the long connection server module through the long connection.
- a specific long connection client module and a long connection server module can establish a TCP two-way communication connection.
- the long connection client module sends the long connection server module every preset time period.
- a heartbeat packet the long connection server module responds to the heartbeat packet within a preset time, thereby maintaining the TCP two-way communication connection, and the TCP two-way communication connection may be referred to as a long connection.
- the long connection server module forwards the synchronization information to the SYNC server module.
- the SYNC server module determines the incremental data of the service data according to the synchronization information.
- S205 The SYNC server module forwards the incremental data to the persistent connection server module.
- S206 The long connection server module pushes the incremental data to the persistent connection client through the established long connection.
- S207 The long connection client forwards the incremental data to the SYNC client module.
- the SYNC client module extracts each incremental data block from the incremental data and forwards it to the service client module.
- the SYNC client module updates the synchronization information of the service data on itself according to the extracted sequence identifier of each incremental data block, and notifies the SYNC server module to update the saved synchronization information.
- FIG. 3 shows a detailed process of data push provided by an embodiment of the present application in another practical application scenario.
- the functional modules of the client and the server are still divided according to the description of FIG. 2 . Specifically, the following steps are included:
- the service server module sends an incremental data synchronization request to the SYNC server module.
- the SYNC server module determines the incremental data of the service data on the client according to the synchronization information saved on the server.
- S303 The SYNC server module forwards the incremental data to the persistent connection server module.
- S304 The long connection server module pushes the incremental data to the persistent connection client through the established long connection.
- S305 The long connection client forwards the incremental data to the SYNC client module.
- the SYNC client module extracts each incremental data block from the incremental data and forwards it to the service client module.
- the SYNC client module updates the synchronization information of the service data on itself according to the extracted sequence identifier of each incremental data block, and notifies the SYNC server module to update the saved synchronization information.
- the functional modules of the client and the server may not be divided according to FIG. 2 and FIG. 3, but are divided into other functional modules.
- the application does not limit the functional module division and architecture organization of the client and the server.
- FIG. 4 is a data forwarding process corresponding to FIG. 1 according to an embodiment of the present application.
- the execution entity is the client described in the embodiment of the present application, and specifically includes the following steps:
- S401 The client generates synchronization information of the service data for the service data on the client.
- S402 The client reports the synchronization information to the server, so that the server pushes the incremental data of the service data to the client according to the synchronization information.
- the embodiment of the present application further provides a corresponding data pushing device, as shown in FIG. 5 and FIG. 6.
- FIG. 5 is a schematic structural diagram of a data pushing apparatus according to an embodiment of the present disclosure, which specifically includes:
- the obtaining module 501 is configured to acquire synchronization information of service data on the client.
- the pushing module 502 is configured to push, according to the synchronization information, incremental data of the service data to the client by using a long connection established with the client.
- the obtaining module 501 is specifically configured to receive synchronization information of the service data reported by the client, and save the synchronization information.
- the obtaining module 501 is specifically configured to: when the synchronization request for the service data on the client is received, search for the saved synchronization information of the service data on the client.
- the incremental data of the service data includes at least one incremental data block
- the pushing module 502 is specifically configured to: establish, according to the sequence identifier included in the synchronization information, a sequence identifier generated by each incremental data block included in the incremental data of the service data, by establishing with the client Long connection, pushing the incremental data blocks to the client.
- the service data specifically includes a user identifier, a service scene type identifier, and an ordered at least one service data block, where the order of each service data block in the service data is generated by the server.
- the synchronization information specifically includes the user identifier, the service scenario identifier, and the sequence identifier of the service data block that is included in the service data.
- the pushing module 502 is further configured to generate a sequence identifier for each incremental data block included in the incremental data of the service data.
- the pushing module 502 is specifically configured to: determine a saved data block corresponding to the user identifier and the service scene identifier included in the synchronization information, as an incremental data block included in the incremental data of the service data, and according to the a sequence identifier of each service data block included in the service data, and a service logic sequence between each service data block and each incremental data block, respectively generating a sequence identifier for each incremental data block, wherein each increase
- the sequential identification of the quantity data block represents the order of the incremental data block in each of the service data blocks and each incremental data block.
- the pushing module 502 is specifically configured to: in each incremental data block, determine an incremental data block that is sequentially after the service data block corresponding to the sequence identifier included in the synchronization information, and in the order of the incremental data block, And each of the determined incremental data blocks is pushed to the client by using a long connection established with the client, after the client receives each incremental data block pushed by the server, The incremental data block is added to the service data as a service data block, and the synchronization information is updated.
- the specific device shown in FIG. 5 above may be located on the server.
- FIG. 6 is a schematic structural diagram of another data pushing apparatus according to an embodiment of the present disclosure, which specifically includes:
- a generating module 601, configured to generate synchronization information of the service data for service data on the client;
- the reporting module 602 is configured to report the synchronization information to the server, so that the server pushes the incremental data of the service data to the client according to the synchronization information.
- the specific device shown in FIG. 6 above may be located on the client.
- the embodiment of the present invention provides a data push method and device, where the server obtains synchronization information of service data on a client, and the server obtains a long connection with the client according to the synchronization information. And pushing the incremental data of the service data to the client.
- the server can determine the already existing service data on the client according to the synchronization information, and The incremental data of the past business data has not been synchronized, and the server and the client maintain a long connection. Therefore, the server can order the incremental data that has not been synchronized in the order, and even if the data is incremental.
- the server can also be known by the synchronization information, and then the lost incremental data is retransmitted to the client, thereby improving the reliability of the service data acquired by the client from the server.
- embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
- computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
- the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
- the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
- These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
- the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
- the computing device includes one or more processors (CPUs), input/output Outbound interface, network interface, and memory.
- processors CPUs
- input/output Outbound interface network interface
- memory volatile and non-volatile memory
- the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
- RAM random access memory
- ROM read only memory
- Memory is an example of a computer readable medium.
- Computer readable media includes both permanent and non-persistent, removable and non-removable media.
- Information storage can be implemented by any method or technology.
- the information can be computer readable instructions, data structures, modules of programs, or other data.
- Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
- computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
- embodiments of the present application can be provided as a method, system, or computer program product.
- the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
- the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请公开了一种数据推送方法及装置，该方法服务端获取客户端上的业务数据的同步信息，然后，根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。通过上述方法，由于服务端根据所述同步信息，可确定客户端上的已经有的业务数据，以及尚未同步过去的业务数据的增量数据，因此，服务端可以有序地将尚未同步过去的增量数据推送给客户端，且即使增量数据在传输过程中丢失，服务端后续也可以通过所述同步信息知晓，进而重传丢失的增量数据，从而，提高了客户端从服务端获取到的业务数据的可靠性。
Description
本申请涉及计算机技术领域，尤其涉及一种数据推送方法及装置。
目前，互联网在日常生活中已经大大普及，用户可以通过使用终端上各种应用的客户端，与相应的服务端进行业务交互，以获得服务商提供的业务服务。其中，所述终端可以是个人计算机、手机、平板电脑、智能手表、车载移动台等终端，所述业务可以是即时通讯业务、网购业务、网上金融业务、在线视频业务等网上业务。
在现有技术中，在交互过程中，终端上应用的客户端一般基于超文本传输协议(Hyper Text Transfer Protocol，HTTP)协议，向服务端发送数据请求，服务端则响应该数据请求，将相应的业务数据发送给客户端。
但是，在某些应用场景下，如客户端与服务端之间的通信质量较差时，或者，客户端的进程异常时，上述的业务数据在从服务端至客户端的传输过程中可能会丢失一部分，从而导致客户端获取到的业务数据不全，而服务端也并不知晓。因此，在上述情况下，客户端获取到的业务数据的可靠性较低。
发明内容
本申请实施例提供一种数据推送方法，用以解决现有技术中在某些应用场景下，客户端从服务端获取到的业务数据的可靠性较低的问题。
本申请实施例提供一种数据推送装置，用以解决现有技术中在某些应用场景下，客户端从服务端获取到的业务数据的可靠性较低的问题。
本申请实施例提供的一种数据推送方法，包括：
服务端获取客户端上的业务数据的同步信息；
所述服务端根据所述同步信息，通过与所述客户端之间建立的长连接，向
所述客户端推送所述业务数据的增量数据。
本申请实施例提供的一种数据推送方法，包括：
客户端针对自身上的业务数据，生成所述业务数据的同步信息；
所述客户端将所述同步信息上报给服务端，以便于所述服务端根据所述同步信息，向所述客户端推送所述业务数据的增量数据。
本申请实施例提供的一种数据推送装置，包括：
获取模块，用于获取客户端上的业务数据的同步信息；
推送模块，用于根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。
本申请实施例提供的一种数据推送装置，包括：
生成模块，用于针对客户端上的业务数据，生成所述业务数据的同步信息；
上报模块，用于将所述同步信息上报给服务端，以便于所述服务端根据所述同步信息，向所述客户端推送所述业务数据的增量数据。
本申请实施例通过上述至少一种技术方案，由于服务端根据所述同步信息，可以确定客户端上的已经有的业务数据，以及尚未同步过去的业务数据的增量数据，且服务端与客户端之间维持有长连接，因此，服务端可以有序地将尚未同步过去的增量数据推送给客户端，且即使增量数据在传输过程中丢失，服务端后续也可以通过所述同步信息知晓，进而向客户端重传丢失的增量数据，从而，提高了客户端从服务端获取到的业务数据的可靠性。
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的数据推送过程；
图2示出了，在一种实际应用场景下，本申请实施例提供的数据推送详细
过程；
图3示出了，在另一种实际应用场景下，本申请实施例提供的数据推送详细过程；
图4为本申请实施例提供的对应于图1的数据推送过程；
图5为本申请实施例提供的数据推送装置结构示意图；
图6为本申请实施例提供的另一种数据推送装置结构示意图。
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图1为本申请实施例提供的数据推送过程，具体包括以下步骤：
S101：服务端获取客户端上的业务数据的同步信息。
本申请实施例提供的信息验证的方法的执行主体可以是：终端或服务器上的应用的服务端。其中，所述服务端可以是客户端/服务端(Client/Server，C/S)结构中的服务端，也可以是浏览器/服务端(Brower/Server，B/S)结构中的服务端，相应的，所述客户端可以是C/S结构中的客户端，也可以是B/S结构中的浏览器；所述终端包括但不限于：个人计算机、手机、平板电脑、智能手表、车载移动台等；所述服务器包括但不限于：个人计算机、大中型计算机、计算机集群等。
在本申请实施例中，所述的业务数据可以是任一确定的业务场景下的业务数据，例如，对于即时通讯应用的客户端，其可能包含多个业务场景，对于管理通讯录的业务场景，所述业务数据为通讯录中的用户的号码信息等，对于管理与特定用户之间收发的短信息的业务场景，所述业务数据为与该特定用户之
间收发的短信息，等等。
一般的，用户在使用终端上的各类应用时，首先，可以登录应用的客户端，然后，通过在客户端上进行的各种操作，与对应的服务端(所述服务端可以位于上述的服务器上或者其他终端上)进行交互，从而，获得对应的业务场景下的业务数据。
在实际应用中，大部分业务场景下的业务数据都是有序的，例如，对于网上购物应用的客户端，用户可以在客户端上执行查询订单、往购物车中添加商品等各种操作，相应的，服务端根据用户的操作，按照预先确定的业务逻辑向客户端发送对应的业务数据，如当用户执行查询订单操作时，服务端则将查询到的用户下过的每个订单的详细信息(也即，业务数据)都发送至客户端，在该业务场景下，所述的业务数据即为各订单的详细信息，显然，各订单的详细信息相互之间是有序的，且可以用订单的详细信息中包含的下单时间，来表示各订单的详细信息的顺序，下单时间越早的订单的详细信息的顺序越靠前。
对于用户在客户端上执行的操作，若服务端每次都要将对应于该操作的全量的业务数据发送至客户端，这样的话，增加了服务端的处理负担。因此，在本申请实施例中，服务端可以只向客户端发送与用户操作相关的业务数据的增量数据(业务数据的增量数据，也即，与该业务数据属于同一业务场景的新增的业务数据)。继续用上例进行说明，假定用户通过客户端已经查询过一次订单，客户端可以将服务端查询后发送过来的各订单的详细信息缓存，然后，下一次用户再查询订单时，假定有新增的该用户的订单，则服务端可以只向客户端返回该用户新增的订单的详细信息，而不用将之前已经发送过的各订单的详细信息再向客户端发送一次，从而，降低了服务端的处理负担，提高了服务端的处理效率。其中，在本申请实施例中，所述业务数据的格式与所述业务数据的增量数据的格式，可以由客户端与服务端之间预先进行约定，本申请并不做限定。
进一步的，目前，在某些应用场景下，如客户端与服务端之间的通信质量
较差时，或者，客户端的进程异常时，上述的业务数据在从服务端至客户端的传输过程中可能丢失，导致客户端上缺少丢失的这部分业务数据，而服务端却并不知晓，或者，上述的业务数据从服务端至客户端的传输过程中，传输顺序可能错乱，导致客户端获取到乱序的业务数据，影响后续使用。
在本申请实施例中，服务端可以基于与客户端之间建立的长连接，以及客户端上的业务数据的同步信息，解决上述问题。具体的，基于所述长连接，服务端可以不用等待客户端发送操作请求后，再向客户端发送业务数据，而是可以主动向客户端推送业务数据的增量数据，因此，提高了客户端和服务端的处理效率；而基于所述同步信息，服务端可以确定客户端上已有的业务数据，进而有序地向客户端推送该已有的业务数据的增量数据，其中，业务数据的顺序可以由服务端和/或客户端根据业务数据的业务逻辑进行确定。
在本申请实施例中，业务数据是由服务端向客户端进行同步的，所述的同步信息可以反映客户端上的业务数据与服务端上的业务数据的同步点，也即，对于顺序在该同步点之前(包括该同步点)的业务数据，服务端已经同步给了客户端，而顺序在该同步点之后的业务数据，服务端尚未同步给客户端。因此，服务端当要向客户端同步业务数据时，或者，客户端主动向服务端请求业务数据时，服务端可以获取客户端上的业务数据的同步信息，以便确定向客户端同步哪些业务数据，以及如何向客户端同步这些业务数据。
S102：所述服务端根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。
在本申请实施例中，服务端可以预先与客户端建立并维持长连接，后续基于该长连接推送业务数据的增量数据，这样的话，在一段该长连接的持续时间段内，客户端可以不用主动向服务端请求获取自身上的业务数据的增量数据，而是，由服务端主动向客户端推送这些增量数据，进一步的，服务端根据所述同步信息，可以有序地向客户端推送这些增量数据。
需要说明的是，所述长连接可以是任一基于传输层所使用的通信协议的长
连接，例如传输控制协议(Transmission Control Protocol，TCP)长连接，等等。所述长连接可以采用现有技术实现，例如，采用心跳包方式实现，具体的，客户端与服务端之间首先建立一条TCP连接，然后，客户端每隔预设时间间隔就向服务端发送一次心跳包，服务端则对该心跳包进行响应，客户端判断是否在规定的时间内收到了服务端对心跳包的响应，若是，则确定建立的TCP连接仍然有效，否则，重新与服务端建立一条TCP连接，上述的TCP连接可以称为TCP长连接。
通过上述方法，由于服务端根据所述同步信息，可以确定客户端上的已有的业务数据，以及尚未同步过去的业务数据的增量数据，且服务端与客户端之间维持有长连接，因此，服务端可以有序地将尚未同步过去的增量数据推送给客户端，相应的，客户端也可以有序地接收这些增量数据，且即使增量数据在传输过程中丢失，服务端后续也可以通过所述同步信息知晓，进而向客户端重传丢失的增量数据，从而，提高了客户端从服务端获取到的业务数据的可靠性。而且，客户端可以不再频繁地向服务端主动请求获得业务数据的增量数据，而是可以被动地等待服务端推送这些增量数据即可，因此，也减轻了客户端的处理负担。
在本申请实施例中，对于上述步骤S101，服务端可以通过多种方式获取客户端上的业务数据的同步信息，这些获取方式包括但不限于以下两种方式：
第一种，服务端获取客户端上的业务数据的同步信息，具体包括：服务端接收客户端上报的、所述客户端上的业务数据的同步信息，并保存所述同步信息。
第二种，服务端当接收到针对客户端上的业务数据的同步请求时，查找自身保存的或者在其他位置保存的、所述客户端上的业务数据的同步信息。其中，所述同步请求既可以由是服务端上负责管控业务数据的模块所发送的，也可以由客户端发送的。
客户端上的业务数据的同步信息可以由客户端生成，并进行维护更新，对
于上述第二种方式，服务端在自身保存的、所述客户端上的业务数据的同步信息，显然，也是在以前与客户端的交互中，由客户端发送至服务端保存的。进而，当服务端获取到的同步信息，与自身保存的同步信息不相同时，服务端进行后续的推送操作时应当基于获取到的同步信息进行操作，且保存获取到的同步信息，以替换掉之前保存的同步信息，这样的话，可以提高服务端所使用的同步信息的实时性和可靠性。
在实际应用中，上述第一种方式一般比较适用于用户在客户端上实时查询最新的业务数据的应用场景，或者，客户端在刚开启并使用用户的账号登录服务端的应用场景，或者，客户端向服务端注册新的业务场景时的应用场景。而上述第二种方式比较适用于服务端的业务数据发生更新(也即，生成了客户端上的业务数据的增量数据)，且有必要及时向客户端同步这些增量数据的应用场景。
在本申请实施例中，客户端上的业务数据可以由多个业务数据块组成，类似的，所述业务数据的增量数据相应的也可以由多个增量数据块组成，且这些业务数据块和增量数据块是有序的。后续每个增量数据块被推送至客户端后，即可作为客户端上新增的一个业务数据块，这样的话，服务端可以根据为各业务数据块和各增量数据块生成的顺序标识，将各增量数据块有序地推送给客户端，且服务端可以根据获取的客户端上的业务数据的同步信息确定当前客户端上接收增量数据块的进度，进而确定是否有已发送的增量数据块在传输途中丢失，若是，则服务器可以重新向客户端推送丢失的增量数据块。
根据上述说明，在上述步骤S102中，所述服务端根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据，具体包括：所述服务端根据所述同步信息包含的顺序标识，以及为所述业务数据的增量数据包含的各增量数据块生成的顺序标识，通过与所述客户端之间建立的长连接，向所述客户端推送所述各增量数据块。
进一步地对所述业务数据和所述业务数据块进行详细说明。对于应用而
言，应用会为登录的不同用户维护不同的业务数据，且业务数据又可以属于不同的业务场景，因此，为了区分对应于不同用户，以及对应于不同业务场景的业务数据，可以用用户标识和业务场景类型标识对业务数据进行标识。具体的，所述业务数据具体包括用户标识、业务场景类型标识，以及有序的至少一个业务数据块，其中，每个业务数据块在所述业务数据中的顺序，由所述服务端生成的该业务数据块的顺序标识表示。
所述业务数据块可以是所述业务数据中的最小的逻辑单位，在此仍以即时通讯应用为例进行说明。假定用户A用自己的用户标识登录该即时通讯应用，并使用该即时通讯应用中的短信息功能，则对应的业务场景为短信息业务场景，该即时通讯应用为用户A维护的、与某位通讯联系人之间收发的所有短信息，可称为在短信息业务场景下的业务数据，进而，该业务数据所包含的每个业务数据块对应为一条短信息。显然，各短信息之间是有序的，收发时间越靠前的短信息的顺序越靠前。对于客户端业务数据中的每个业务数据块，可以由服务端预先为其生成该业务数据块的顺序标识，用于表示该业务数据块在各业务数据块中的顺序。相应的，所述同步信息可以包括所述用户标识、所述业务场景标识、所述业务数据包含的、顺序位于最后的业务数据块的顺序标识。
在本申请实施例中，所述服务端可以按照如下方法为所述业务数据的增量数据包含的各增量数据块生成顺序标识：所述服务端确定保存的、对应于所述同步信息包含的用户标识和业务场景标识的数据块，作为所述业务数据的增量数据包含的增量数据块，并根据所述业务数据包含的各业务数据块的顺序标识，以及所述各业务数据块与各增量数据块之间的业务逻辑顺序，分别为每个增量数据块生成顺序标识，其中，每个增量数据块的顺序标识表示了该增量数据块在所述各业务数据块和各增量数据块中的顺序。
其中，业务逻辑顺序可以反映客户端上的各业务数据块和服务端后续要推送过来的各增量数据块之间在业务上的顺序。仍以短信息业务场景为例进行说明，假定当前客户端上有两个业务数据块(也即，两条短信息)，根据短信息
一般的业务逻辑，接收和/或发出时间靠前的短消息的顺序，应当比接收和/或发出时间靠后的短消息的顺序靠前，则可以认为：前者的业务逻辑顺序比后者靠前。
更进一步的，所述服务端根据所述同步信息包含的顺序标识，以及为所述业务数据的增量数据包含的各增量数据块生成的顺序标识，通过与所述客户端之间建立的长连接，向所述客户端推送所述各增量数据块，具体包括：所述服务端在各增量数据块中，确定出顺序在所述同步信息包含的顺序标识对应的业务数据块之后的增量数据块，并按照增量数据块的顺序，将确定出的各增量数据块通过与所述客户端之间建立的长连接推送给所述客户端，使所述客户端在接收到所述服务端推送的每个增量数据块后，将该增量数据块作为业务数据块加入所述业务数据中，并更新所述同步信息。
在实际应用中，服务端可以为要向客户端进行推送的增量数据块定义相应的数据结构作为容器，针对每个增量数据块，将对应于所述同步信息包含的用户标识和业务场景标识，以及该增量数据块、生成的该增量数据块的顺序标识均置于同一个容器中进行推送，这样的话，可以提高服务端的处理效率，也便于客户端接收后进行处理。以下举例进行说明。
例如，服务端为增量数据块定义的容器可以是名为操作日志OPLOG的数据结构，OPLOG至少包含4个字段：PAYLOAD(表示增量数据块)、USER ID(表示用户标识)、BIZ_TYPE(表示业务场景类型标识)、OPLOG ID(表示增量数据块的顺序标识)。则每当服务端增加一个增量数据块，服务端可以对应地生成一条OPLOG，当服务端要向客户端同步业务数据时，仅需将顺序位于获取的同步信息包含的顺序标识之后的各OPLOG推送给客户端即可。相应的，客户端在接收到OPLOG后，将其包含的各增量数据块提取出来，然后，并根据各增量数据的顺序标识，将各增量数据作为新增的业务数据块加入自身上的业务数据中，再将同步信息中的顺序标识更新为：加入各增量数据后，自身上的业务数据中顺序最靠后的顺序标识。需要说明的是，若加入各增量数据
后，客户端上的各业务数据块的顺序标识不连续，也即，各顺序标识中缺少至少一个顺序标识，则可以推测出服务端已发送的某些增量数据块(对应于缺少的顺序标识的增量数据块)可能已在传输过程中丢失，在这种情况下，客户端可以将同步信息中的顺序标识更新为：加入各增量数据后，自身上的业务数据保持连续的前提下顺序最靠后的业务数据块的顺序标识。这样的话，服务端可以根据更新后的同步信息，重新向客户端推送丢失的增量数据块。
另外，需要说明的是，对于当前客户端上的各业务数据块，在这些业务数据块之前尚未被服务端推送至客户端时，这些业务数据块的顺序标识也是由服务端，采用为各增量数据块生成顺序标识的方法生成的。
为了便于理解，在此举例一些可行的、生成顺序标识的具体实现方法：
服务端可以用正整数作为顺序标识，则数值越小的顺序标识的顺序越靠前。假定客户端上的业务数据中的各业务数据块的顺序标识为1～8，服务端上除了有这些业务数据块之外，还有若干增量数据块(假定有8个)，则客户端上的业务数据的同步信息包含的顺序标识为8，则服务端按照这8个增量数据块之间的业务逻辑关系，为这8个增量数据块分别生成顺序标识9～16，其中，顺序越靠前的增量数据块的顺序标识越小。也即，客户端上的各业务数据块与服务端后续推送过来的各增量数据块的顺序标识，是按照业务逻辑顺序递增的。类似的，除了正整数之外，服务端还可以用其他有序的字符集作为顺序标识，例如，英文字母等。
另外，在分布式应用场景下，由于同一个客户端可能对应于多个服务端，多个服务端可能会同时执行生成顺序标识的操作，则多个服务端可能为不同的增量数据块生成同一个顺序标识，从而影响后续推送过程的可靠性。在本申请实施例中，可以采用锁机制解决这个问题，其中，所述锁机制包括但不限于乐观锁机制和悲观锁机制。具体的，采用乐观锁机制时，服务端在向数据库提交生成顺序标识请求前，先从数据库中取得已保存的最新的顺序标识(称为当前值)，然后，在提交生成顺序标识请求时携带该当前值，数据库接收到该生成
顺序标识请求后，会判断该当前值是否与数据库中顺序标识实际的当前值相同，若是，则成功处理该生成顺序标识请求，否则，向服务端返回失败响应，相应的，服务器接收到失败响应后可以重试，从而可以防止顺序标识重复生成。而采用悲观锁机制时，当某个服务端正在向数据库提交生成顺序标识请求时，即将顺序标识锁定，而其他服务端需要在数据库维护等待队列中，等待锁释放后才能继续生成顺序标识，从而可以防止顺序标识重复生成。显然，这两种锁机制各有优缺点，乐观锁机制不需要数据库维护等待队列，对请求方的响应速度快，不会阻塞请求方，但请求方处理模式相对复杂，悲观锁请求方处理模式简单，但数据库开销相对大。可以根据不同的应用场景选择更适用的锁机制。
根据上述的说明，图2中示出了，在一种实际应用场景下，本申请实施例提供的数据推送详细过程。其中，将所述客户端具体划分为三个功能模块：业务客户端模块、同步(Synchronization，SYNC)客户端模块、长连接客户端模块；将所述服务端也具体划分为三个功能模块：业务服务端模块、SYNC服务端模块、长连接服务端模块。具体包括以下步骤：
S201：SYNC客户端模块生成客户端上的业务数据的同步信息，并转交给长连接客户端模块。
S202：长连接客户端模块预先地、或者实时地与长连接服务端模块之间建立长连接，并通过该长连接，将该同步信息上报给长连接服务端模块。
在建立长连接时，具体的，长连接客户端模块和长连接服务端模块可以建立一条TCP双向通讯连接，建立成功后，长连接客户端模块每隔预设时间段向长连接服务端模块发送一个心跳包，长连接服务端模块则在预设时间内响应该心跳包，从而可以维持该TCP双向通讯连接，该TCP双向通讯连接即可称为长连接。
S203：长连接服务端模块将该同步信息转交给SYNC服务端模块。
S204：SYNC服务端模块根据该同步信息，确定出所述业务数据的增量数据。
S205：SYNC服务端模块将该增量数据转交给长连接服务端模块。
S206：长连接服务端模块将该增量数据，通过建立的长连接，推送给长连接客户端。
S207：长连接客户端将该增量数据转交给SYNC客户端模块。
S208：SYNC客户端模块从增量数据中提取出各增量数据块，转交给业务客户端模块。
S209：SYNC客户端模块根据提取出的各增量数据块的顺序标识，对自身上业务数据的同步信息进行更新，以及通知SYNC服务端模块更新保存的同步信息。
图3中示出了，在另一种实际应用场景下，本申请实施例提供的数据推送详细过程。其中，所述客户端和所述服务端的功能模块，仍按照图2的说明进行划分。具体包括以下步骤：
S301：业务服务端模块向SYNC服务端模块发送增量数据同步请求。
S302：SYNC服务端模块根据服务端上保存的同步信息，确定出客户端上的业务数据的增量数据。
S303：SYNC服务端模块将该增量数据转交给长连接服务端模块。
S304：长连接服务端模块将该增量数据，通过建立的长连接，推送给长连接客户端。
S305：长连接客户端将该增量数据转交给SYNC客户端模块。
S306：SYNC客户端模块从增量数据中提取出各增量数据块，转交给业务客户端模块。
S307：SYNC客户端模块根据提取出的各增量数据块的顺序标识，对自身上业务数据的同步信息进行更新，以及通知SYNC服务端模块更新保存的同步信息。
可以看到，图2中的数据推送过程是由客户端主动触发，而图3中的数据推送过程是由服务端端主动触发，这是本申请实施例所述提供的数据推送方法
的两种典型实际应用场景。
进一步的，在实际应用中，也可以不按照图2和图3来划分客户端和服务端的功能模块，而是划分为其他的功能模块。本申请对所述客户端和所述服务端的功能模块划分和架构组织并不做限定。
图4为本申请实施例提供的对应于图1的数据推送过程，执行主体为本申请实施例中所述的客户端，具体包括以下步骤：
S401：客户端针对自身上的业务数据，生成所述业务数据的同步信息。
S402：所述客户端将所述同步信息上报给服务端，以便于所述服务端根据所述同步信息，向所述客户端推送所述业务数据的增量数据。
以上为本申请实施例提供的数据推送方法，基于同样的思路，本申请实施例还提供相应的数据推送装置，如图5、图6所示。
图5为本申请实施例提供的数据推送装置结构示意图，具体包括：
获取模块501，用于获取客户端上的业务数据的同步信息；
推送模块502，用于根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。
所述获取模块501具体用于，接收客户端上报的、所述客户端上的业务数据的同步信息，并保存所述同步信息。
所述获取模块501具体用于，当接收到针对客户端上的业务数据的同步请求时，查找保存的、所述客户端上的业务数据的同步信息。
所述业务数据的增量数据包含至少一个增量数据块；
所述推送模块502具体用于，根据所述同步信息包含的顺序标识，以及为所述业务数据的增量数据包含的各增量数据块生成的顺序标识，通过与所述客户端之间建立的长连接，向所述客户端推送所述各增量数据块。
所述业务数据具体包括用户标识、业务场景类型标识，以及有序的至少一个业务数据块，其中，每个业务数据块在所述业务数据中的顺序，由所述服务端生成的该业务数据块的顺序标识表示；
所述同步信息具体包括所述用户标识、所述业务场景标识、所述业务数据包含的、顺序位于最后的业务数据块的顺序标识。
所述推送模块502还用于为所述业务数据的增量数据包含的各增量数据块生成顺序标识；
所述推送模块502具体用于，确定保存的、对应于所述同步信息包含的用户标识和业务场景标识的数据块，作为所述业务数据的增量数据包含的增量数据块，并根据所述业务数据包含的各业务数据块的顺序标识，以及所述各业务数据块与各增量数据块之间的业务逻辑顺序，分别为每个增量数据块生成顺序标识，其中，每个增量数据块的顺序标识表示了该增量数据块在所述各业务数据块和各增量数据块中的顺序。
所述推送模块502具体用于，在各增量数据块中，确定出顺序在所述同步信息包含的顺序标识对应的业务数据块之后的增量数据块，并按照增量数据块的顺序，将确定出的各增量数据块通过与所述客户端之间建立的长连接推送给所述客户端，使所述客户端在接收到所述服务端推送的每个增量数据块后，将该增量数据块作为业务数据块加入所述业务数据中，并更新所述同步信息。
具体的上述如图5所示的装置可以位于服务端上。
图6为本申请实施例提供的另一种数据推送装置结构示意图，具体包括：
生成模块601，用于针对客户端上的业务数据，生成所述业务数据的同步信息；
上报模块602，用于将所述同步信息上报给服务端，以便于所述服务端根据所述同步信息，向所述客户端推送所述业务数据的增量数据。
具体的上述如图6所示的装置可以位于客户端上。
本申请实施例提供一种数据推送方法及装置，该方法服务端获取客户端上的业务数据的同步信息，所述服务端根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。通过上述方法，由于服务端根据所述同步信息，可以确定客户端上的已经有的业务数据，以及
尚未同步过去的业务数据的增量数据，且服务端与客户端之间维持有长连接，因此，服务端可以有序地将尚未同步过去的增量数据推送给客户端，且即使增量数据在传输过程中丢失，服务端后续也可以通过所述同步信息知晓，进而向客户端重传丢失的增量数据，从而，提高了客户端从服务端获取到的业务数据的可靠性。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输
出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技
术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。
Claims (16)
- 一种数据推送方法，其特征在于，包括：服务端获取客户端上的业务数据的同步信息；所述服务端根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。
- 如权利要求1所述的方法，其特征在于，服务端获取客户端上的业务数据的同步信息，具体包括：服务端接收客户端上报的、所述客户端上的业务数据的同步信息；并保存所述同步信息。
- 如权利要求1所述的方法，其特征在于，服务端获取客户端上的业务数据的同步信息，具体包括：服务端当接收到针对客户端上的业务数据的同步请求时，查找保存的、所述客户端上的业务数据的同步信息。
- 如权利要求1所述的方法，其特征在于，所述业务数据的增量数据包含至少一个增量数据块；所述服务端根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据，具体包括：所述服务端根据所述同步信息包含的顺序标识，以及为所述业务数据的增量数据包含的各增量数据块生成的顺序标识，通过与所述客户端之间建立的长连接，向所述客户端推送所述各增量数据块。
- 如权利要求1～4任一所述的方法，其特征在于，所述业务数据具体包括用户标识、业务场景类型标识，以及有序的至少一个业务数据块，其中，每个业务数据块在所述业务数据中的顺序，由所述服务端生成的该业务数据块的顺序标识表示；所述同步信息具体包括所述用户标识、所述业务场景标识、所述业务数据包含的、顺序位于最后的业务数据块的顺序标识。
- 如权利要求5所述的方法，其特征在于，所述服务端按照如下方法为所述业务数据的增量数据包含的各增量数据块生成顺序标识：所述服务端确定保存的、对应于所述同步信息包含的用户标识和业务场景标识的数据块，作为所述业务数据的增量数据包含的增量数据块；并根据所述业务数据包含的各业务数据块的顺序标识，以及所述各业务数据块与各增量数据块之间的业务逻辑顺序，分别为每个增量数据块生成顺序标识，其中，每个增量数据块的顺序标识表示了该增量数据块在所述各业务数据块和各增量数据块中的顺序。
- 如权利要求6所述的方法，其特征在于，所述服务端根据所述同步信息包含的顺序标识，以及为所述业务数据的增量数据包含的各增量数据块生成的顺序标识，通过与所述客户端之间建立的长连接，向所述客户端推送所述各增量数据块，具体包括：所述服务端在各增量数据块中，确定出顺序在所述同步信息包含的顺序标识对应的业务数据块之后的增量数据块；并按照增量数据块的顺序，将确定出的各增量数据块通过与所述客户端之间建立的长连接推送给所述客户端，使所述客户端在接收到所述服务端推送的每个增量数据块后，将该增量数据块作为业务数据块加入所述业务数据中，并更新所述同步信息。
- 一种数据推送方法，其特征在于，包括：客户端针对自身上的业务数据，生成所述业务数据的同步信息；所述客户端将所述同步信息上报给服务端，以便于所述服务端根据所述同步信息，向所述客户端推送所述业务数据的增量数据。
- 一种数据推送装置，其特征在于，包括：获取模块，用于获取客户端上的业务数据的同步信息；推送模块，用于根据所述同步信息，通过与所述客户端之间建立的长连接，向所述客户端推送所述业务数据的增量数据。
- 如权利要求9所述的装置，其特征在于，所述获取模块具体用于，接收客户端上报的、所述客户端上的业务数据的同步信息，并保存所述同步信息。
- 如权利要求9所述的装置，其特征在于，所述获取模块具体用于，当接收到针对客户端上的业务数据的同步请求时，查找保存的、所述客户端上的业务数据的同步信息。
- 如权利要求9所述的装置，其特征在于，所述业务数据的增量数据包含至少一个增量数据块；所述推送模块具体用于，根据所述同步信息包含的顺序标识，以及为所述业务数据的增量数据包含的各增量数据块生成的顺序标识，通过与所述客户端之间建立的长连接，向所述客户端推送所述各增量数据块。
- 如权利要求9～12任一所述的装置，其特征在于，所述业务数据具体包括用户标识、业务场景类型标识，以及有序的至少一个业务数据块，其中，每个业务数据块在所述业务数据中的顺序，由所述服务端生成的该业务数据块的顺序标识表示；所述同步信息具体包括所述用户标识、所述业务场景标识、所述业务数据包含的、顺序位于最后的业务数据块的顺序标识。
- 如权利要求13所述的装置，其特征在于，所述推送模块还用于为所述业务数据的增量数据包含的各增量数据块生成顺序标识；所述推送模块具体用于，确定保存的、对应于所述同步信息包含的用户标识和业务场景标识的数据块，作为所述业务数据的增量数据包含的增量数据块，并根据所述业务数据包含的各业务数据块的顺序标识，以及所述各业务数据块与各增量数据块之间的业务逻辑顺序，分别为每个增量数据块生成顺序标识，其中，每个增量数据块的顺序标识表示了该增量数据块在所述各业务数据块和各增量数据块中的顺序。
- 如权利要求14所述的装置，其特征在于，所述推送模块具体用于，在各增量数据块中，确定出顺序在所述同步信息包含的顺序标识对应的业务数 据块之后的增量数据块，并按照增量数据块的顺序，将确定出的各增量数据块通过与所述客户端之间建立的长连接推送给所述客户端，使所述客户端在接收到所述服务端推送的每个增量数据块后，将该增量数据块作为业务数据块加入所述业务数据中，并更新所述同步信息。
- 一种数据推送装置，其特征在于，包括：生成模块，用于针对客户端上的业务数据，生成所述业务数据的同步信息；上报模块，用于将所述同步信息上报给服务端，以便于所述服务端根据所述同步信息，向所述客户端推送所述业务数据的增量数据。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510230741.3 | 2015-05-07 | ||
| CN201510230741.3A CN106209948B (zh) | 2015-05-07 | 2015-05-07 | 一种数据推送方法及装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2016177285A1 true WO2016177285A1 (zh) | 2016-11-10 |
Family
ID=57218060
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2016/079820 WO2016177285A1 (zh) | 2015-05-07 | 2016-04-21 | 一种数据推送方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN106209948B (zh) |
| WO (1) | WO2016177285A1 (zh) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109040326A (zh) * | 2018-11-02 | 2018-12-18 | 北京京东金融科技控股有限公司 | 推送消息的方法和装置 |
| CN112650606A (zh) * | 2020-12-30 | 2021-04-13 | 北京奇艺世纪科技有限公司 | 一种消息处理方法、装置、系统、电子设备及存储介质 |
| CN112765276A (zh) * | 2021-01-27 | 2021-05-07 | 云账户技术(天津)有限公司 | 一种增量数据同步方法及装置 |
| CN113316190A (zh) * | 2021-05-10 | 2021-08-27 | 上海仝心电子科技有限公司 | 一种智慧云盒及系统 |
| CN113590719A (zh) * | 2021-09-27 | 2021-11-02 | 北京奇虎科技有限公司 | 数据同步方法、装置、设备及存储介质 |
| CN114500630A (zh) * | 2020-10-27 | 2022-05-13 | 航天信息股份有限公司 | 消息推送的方法、装置、系统、存储介质和电子设备 |
| CN115361442A (zh) * | 2022-10-18 | 2022-11-18 | 北京京东拓先科技有限公司 | 一种消息推送方法及装置、存储介质及电子设备 |
| CN110324370B (zh) * | 2018-03-29 | 2023-05-30 | 北京京东尚科信息技术有限公司 | 服务端向客户端推送数据的方法和装置 |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107040576B (zh) * | 2016-12-08 | 2020-03-10 | 阿里巴巴集团控股有限公司 | 信息推送方法及装置、通讯系统 |
| CN106648994B (zh) * | 2017-01-04 | 2020-09-11 | 华为技术有限公司 | 一种备份操作日志的方法，设备和系统 |
| CN108632300B (zh) * | 2017-03-15 | 2021-12-10 | 阿里巴巴集团控股有限公司 | 数据同步系统、方法、服务器、客户端及电子设备 |
| CN107704607A (zh) * | 2017-10-17 | 2018-02-16 | 武汉楚鼎信息技术有限公司 | 一种数据库数据同步的方法 |
| CN108156253A (zh) * | 2018-01-05 | 2018-06-12 | 中汇信息技术（上海）有限公司 | 一种数据传输方法、装置及系统 |
| CN108391242B (zh) * | 2018-02-26 | 2021-10-19 | 青岛海信移动通信技术股份有限公司 | 一种远程控制方法和远程控制装置 |
| CN109379446A (zh) * | 2018-12-24 | 2019-02-22 | 杭州复杂美科技有限公司 | 区块推送方法、区块获取方法、设备和存储介质 |
| CN110097102A (zh) * | 2019-04-22 | 2019-08-06 | 上海车轮互联网服务有限公司 | 适用于不同业务场景的数据配置方法及装置 |
| CN110769053B (zh) * | 2019-10-21 | 2022-04-19 | 深圳震有科技股份有限公司 | 一种数据推送方法、系统及存储介质 |
| CN110795288B (zh) * | 2019-11-06 | 2023-02-10 | 杭州复杂美科技有限公司 | 数据获取方法、设备和存储介质 |
| CN111569413B (zh) * | 2020-05-14 | 2023-06-13 | 北京代码乾坤科技有限公司 | 数据同步方法和装置 |
| CN112492044B (zh) * | 2020-12-09 | 2022-10-14 | 恒生电子股份有限公司 | 缓存数据共享方法及装置、设备、计算机可读存储介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101159764A (zh) * | 2007-11-21 | 2008-04-09 | 中国电信股份有限公司 | 一种访问移动业务门户数据的方法和系统 |
| CN102938788A (zh) * | 2012-11-15 | 2013-02-20 | 易程科技股份有限公司 | 事件的处理方法和装置 |
| CN104580454A (zh) * | 2014-12-31 | 2015-04-29 | 乐视网信息技术（北京）股份有限公司 | 一种数据同步方法、装置及系统 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102761861A (zh) * | 2011-04-27 | 2012-10-31 | 中国移动通信集团广东有限公司 | 信息的更新方法、服务器以及信息的更新系统 |
| CN103338144B (zh) * | 2013-05-30 | 2016-06-22 | 华为软件技术有限公司 | 一种会话数据同步方法和装置 |
| CN103442042B (zh) * | 2013-08-14 | 2017-01-04 | 福建天晴数码有限公司 | 增量数据同步方法及系统 |
-
2015
- 2015-05-07 CN CN201510230741.3A patent/CN106209948B/zh active Active
-
2016
- 2016-04-21 WO PCT/CN2016/079820 patent/WO2016177285A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101159764A (zh) * | 2007-11-21 | 2008-04-09 | 中国电信股份有限公司 | 一种访问移动业务门户数据的方法和系统 |
| CN102938788A (zh) * | 2012-11-15 | 2013-02-20 | 易程科技股份有限公司 | 事件的处理方法和装置 |
| CN104580454A (zh) * | 2014-12-31 | 2015-04-29 | 乐视网信息技术（北京）股份有限公司 | 一种数据同步方法、装置及系统 |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110324370B (zh) * | 2018-03-29 | 2023-05-30 | 北京京东尚科信息技术有限公司 | 服务端向客户端推送数据的方法和装置 |
| CN109040326A (zh) * | 2018-11-02 | 2018-12-18 | 北京京东金融科技控股有限公司 | 推送消息的方法和装置 |
| CN114500630A (zh) * | 2020-10-27 | 2022-05-13 | 航天信息股份有限公司 | 消息推送的方法、装置、系统、存储介质和电子设备 |
| CN112650606A (zh) * | 2020-12-30 | 2021-04-13 | 北京奇艺世纪科技有限公司 | 一种消息处理方法、装置、系统、电子设备及存储介质 |
| CN112650606B (zh) * | 2020-12-30 | 2023-09-01 | 北京奇艺世纪科技有限公司 | 一种消息处理方法、装置、系统、电子设备及存储介质 |
| CN112765276A (zh) * | 2021-01-27 | 2021-05-07 | 云账户技术(天津)有限公司 | 一种增量数据同步方法及装置 |
| CN113316190A (zh) * | 2021-05-10 | 2021-08-27 | 上海仝心电子科技有限公司 | 一种智慧云盒及系统 |
| CN113316190B (zh) * | 2021-05-10 | 2023-08-01 | 上海仝心电子科技有限公司 | 一种智慧云盒及系统 |
| CN113590719A (zh) * | 2021-09-27 | 2021-11-02 | 北京奇虎科技有限公司 | 数据同步方法、装置、设备及存储介质 |
| CN115361442A (zh) * | 2022-10-18 | 2022-11-18 | 北京京东拓先科技有限公司 | 一种消息推送方法及装置、存储介质及电子设备 |
| CN115361442B (zh) * | 2022-10-18 | 2023-03-07 | 北京京东拓先科技有限公司 | 一种消息推送方法及装置、存储介质及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106209948A (zh) | 2016-12-07 |
| CN106209948B (zh) | 2019-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2016177285A1 (zh) | 一种数据推送方法及装置 | |
| TWI710979B (zh) | 跨區塊鏈的互動方法及裝置、系統、電子設備 | |
| US20240007545A1 (en) | Content payload delivery system | |
| WO2019174129A1 (zh) | 事件提醒方法、装置、计算机设备和存储介质 | |
| US20180007144A1 (en) | Event queuing and distribution system | |
| CN102255935B (zh) | 云服务消费方法、云服务中介及云系统 | |
| EP2182695B1 (en) | Method, system and device of data synchronization | |
| TWI716822B (zh) | 事務因果序的校正方法及裝置、電子設備 | |
| WO2014205842A1 (zh) | 内容分享方法和社交同步装置 | |
| CN108965359B (zh) | 通信方法、通信装置、可读介质和电子设备 | |
| US10863347B2 (en) | Policy enhancement for mixed capability devices | |
| WO2016101759A1 (zh) | 一种数据路由方法、数据管理装置和分布式存储系统 | |
| CN110798495B (zh) | 用于在集群架构模式下端到端的消息推送的方法和服务器 | |
| CN114827171A (zh) | 信息同步方法、装置、计算机设备和存储介质 | |
| US7933962B1 (en) | Reducing reliance on a central data store while maintaining idempotency in a multi-client, multi-server environment | |
| WO2023186154A1 (zh) | 数据传输系统以及方法 | |
| CN109660589B (zh) | 请求处理方法及装置、电子设备 | |
| CN103581176A (zh) | 会话初始协议sip消息注册刷新的方法及装置 | |
| CN115098528B (zh) | 业务处理方法、装置、电子设备及计算机可读存储介质 | |
| WO2018214795A1 (zh) | 通话提示方法及装置、系统 | |
| WO2012146091A1 (en) | Authentication information processing | |
| CN114338692B (zh) | 一种基于分片集群扩容的数据平衡方法与设备 | |
| CN111008222A (zh) | 数据状态查询方法和装置 | |
| CN112994894B (zh) | 基于网关的单线程请求处理方法和信息验证agent | |
| US11457085B2 (en) | Computer-based systems and/or computing devices configured for push-based transmissions using the target as a system of record |
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: 16789279 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 16789279 Country of ref document: EP Kind code of ref document: A1 |