一种数据推送方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种数据推送方法及装置。

背景技术：

目前，互联网在日常生活中已经大大普及，用户可以通过使用终端上各种应用的客户端，与相应的服务端进行业务交互，以获得服务商提供的业务服务。其中，所述终端可以是个人计算机、手机、平板电脑、智能手表、车载移动台等终端，所述业务可以是即时通讯业务、网购业务、网上金融业务、在线视频业务等网上业务。

在现有技术中，在交互过程中，终端上应用的客户端一般基于超文本传输协议(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、 光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。