业务操作数据处理方法、装置、电子设备、服务器及系统与流程

本申请属于终端应用数据处理技术领域，尤其涉及一种业务操作数据处理方法、装置、电子设备、服务器及系统。

背景技术：

随着智能手机的普及，越来越多的社交类手机应用出现，其中，聊天以及点赞等场景称为社交中用户经常使用的业务项。一般情况下，这些操作场景都要求用户手机数据网络连接正常，否则无法进行。例如，断网状态下，用户发送一条聊天消息，系统会显示发送失败的红圈，当手机网络再次连接正常后，需要用户点击重新发送该条消息。现有的常用通信工具如qq、阿里旺旺、微信或者其他聊天工具等，这些聊天通信应用常常需要对应用中的各种业务进行类似这样的操作，例如用户对同生活圈中的一条动态进行点赞或取消点赞操作。

现有技术中，传统的手机应用(或其他客户端应用)在向服务器提交数据的时候，需要手机正常连接到无线网络；并且如果用户在提交数据后，服务器返回异常的话，此次提交失败，用户需要重新操作提交一次请求，给用户造成了极大的不方便。因此，现有的这种信息交互方式至少存在以下问题：用户需要在手机网络正常的情况下才能提交数据，否则不能提交，这限制了用户对应用业务操作的使用场景和用户体验；用户提交数据后，由于网络慢或者抖动超时等原因导致提交失败后。

一般来说，对手机离线状态下本地类似关闭服务器推送消息开关操作的处理通常如下：应用监测到手机为离线状态，将应用的运行态设置为离线状态，然后将离线状态下用户的网络操作请求存储起来，待手机网络恢复连接后，再将离线数据发送到服务器。而另一种类似直接展现操作效果的如点赞操作，如果手机没有联网，则现有技术中通常是不能进行操作的，即点赞后取消点赞均无法在用户手机上体现出操作结果，必须要等到联网后才能操作。

显然，在离线状态下，用于对应用中的某项业务进行的n次重复性操作(比如用于对同一条生活圈动态进行n次反复的点赞和取消点赞操作，或者用户反复操作n次开启/关闭群设置中“消息免打扰”功能)，实际只有最后一次操作有效，前面的n-1次操作都是无效的。这种情况下，现有机制采用将用户的所有n次网络请求操作都离线存储起来，待手机恢复网络后，需要发送n次的网络数据，同时业务服务器需要处理n次请求，浪费了n-1次的网络资源和造成业务服务器无效的压力和重复计算，浪费用户流量和宽带资源。甚至，更有甚者，如果手机不能联网，则用户不能进行业务操作，这大大限制了用户业务使用场景，降低了用户体验。

技术实现要素：

本申请目的在于提供一种业务操作数据处理方法、装置、电子设备、服务器及系统，可以在终端设备离线(如断网)的情况下可以响应需要联网的用户操作，并且可以自动识别去重，处理重复无效的用户操作数据。待终端设备上线后(如重新联网)自动发送给接收方，减少用户手动业务操作和业务服务器负荷，节约用户流量和带宽资源，提高用户操作使用体验。

本申请提供的一种业务操作数据处理方法、装置、电子设备、服务器及系统是这样实现的：

一种业务操作数据处理方法，所述方法包括：

第一客户端获取基于用户对业务的操作生成的最新业务操作数据；

第一客户端在离线状态下，将所述最新业务操作数据作为离线业务操作数据进行存储，并按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；

检测到所述第一客户端处于在线状态时，所述第一客户端将存储的离线业务操作数据发送至第二客户端；

所述第二客户端响应接收到所述离线业务操作数据，向所述第一客户端返回确认消息；

所述第一客户端基于收到的确认消息确认所述离线业务操作数据发送成功，并删除存储的所述发送成功的离线业务操作数据。

一种业务操作数据处理方法，所述方法包括：

获取基于用户的业务操作生成的最新业务操作数据；

在离线状态下，将所述最新业务操作数据作为离线业务操作数据进行存储，并按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；

检测到处于在线状态时，发送存储的离线业务操作数据。

一种业务操作数据处理方法，所述方法包括：

接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；

将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

一种业务操作数据处理装置，所述装置包括：

操作数据获取模块，用于获取基于用户的业务操作生成的最新业务操作数据；

存储模块，用于将离线状态下所述生成的业务操作数据作为离线业务操作数据进行存储；

去重处理模块，用于照预设的去重规则删除所述存储模块中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；

发送模块，用于检测到处于在线状态时，发送存储的离线业务操作数据。

一种业务操作数据处理装置，所述装置包括：

离线消息处理模块，用于接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；还用于将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

一种具有上行通信能力的电子设备，所述电子设备包括：

存储单元，用于获取并存储基于用户的业务操作生成的最新业务操作数据；

处理单元，用于按照预设去重规则判断存储单元中判断是否有与所述最新业务操作数据属于相同操作的离线业务操作数据；以及，若有，则删除所述与所述最新业务操作数据属于相同操作的离线业务操作数据；

网络通信模块，用于检测到处于在线状态时，发送存储的离线业务操作数据。

一种服务器，包括离线消息处理装置，所述离线消息处理装置被设置成，用于接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；还用于将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

一种业务系统，所述系统包括：

第一客户端，用于获取基于用户的业务的操作生成的最新业务操作数据；以及，在离线状态下，将所述最新业务操作数据作为离线业务操作数据进行存储，并按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；还用于检测到所述第一客户端处于在线状态时，将存储的离线业务操作数据发送至第二客户端；还可以用于基于收到的确认消息确认所述离线业务操作数据发送成功，并删除存储的所述发送成功的离线业务操作数据；

第二客户端，用于响应接收到所述离线业务操作数据，向所述第一客户端返回确认消息。

本申请提供的一种业务操作数据处理方法、装置、电子设备、服务器及系统，可以通过客户端离线数据的去重机制，用户可以在手机离线状态下提交数据请求，例如发消息或者点赞等操作，不限制用户的使用场景，节约了用户的时间，提高业务处理效率。并可以在离线(如断网)的情况下，存储用户在应用中各项业务的操作数据，实现自动识别去重，处理重复无效的用户操作数据，节约用户流量和带宽资源，处理服务器负荷，提高用户操作使用体验，过滤重复性操作。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的一种业务操作数据处理方法一种实施例的方法流程图；

图2是本申请的一种实施例中存储业务操作数据并删除重复的离线业务操作数据的实施过程示意图；

图3是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程；

图4是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程；

图5是本申请提供的一种业务操作数据处理方法一种实施例的方法流程图；

图6是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程图；

图7是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程图；

图8是本申请提供的一种业务操作数据处理装置一种实施例的模块结构示意图；

图9是本申请提供的一种业务操作数据处理装置另一种实施例的模块结构示意图；

图10是本申请提供的一种业务操作数据处理装置一种实施例的模块结构示意图；

图11是本申请提供的所述电子设备一种实施例的产品模块结构示意图；

图12是本申请提供的所述电子设备另一种实施例的产品模块结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1是本申请所述一种业务操作数据处理方法一种实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理的实施环境)。

具体的如图1所述，本申请一种实施例提供的一种业务操作数据处理方法可以包括：

s1：第一客户端获取基于用户的业务操作生成的最新业务操作数据。

本申请实施例中所述的第一客户端可以包括移动通信终端(如手机)、pc、平板、手持设备、车载人机等具有网络通信模块的终端电子设备。信息交互的另一方可以为业务处理的服务端，如c/s网络中的服务器，或者也可以为对等网络(p2p)的其他客户端，如第一客户端直接将用户对本地应用的业务操作发送至第二客户端进行处理。本实施例中为便于描述，可以以手机作为第一客户端，处理手机中应用的各项业务操作的服务器作为第二客户端，以及以用户对生活圈动态点赞为应用场景进行说明。

一般的，手机数据网络断开的情况可以称为“离线状态”，手机数据网络连接正常时，可以称为“在线状态”。在线状态时手机主动向服务器发送的消息，比如聊天消息、点赞请求消息等，可以称为上行同步消息(sync_ul)。因此，终端应用的客户端中除包括终端业务模块还可以包括进行信息通信交互的网络模块等。本实施例应用场景中，可以在第一客户端设置同步消息处理模块，可以用于对客户端业务模块产生的业务操作数据进行处理后发送至相应的第二客户端，如图1所示。当然，也可以在第二客户端同样设置可以用于接收、存储、转发、下发消息等处理的同步消息处理模块，在此可以称为第二客户端的同步消息处理模块。本申请实施例中，所述第一客户端至少具有上行消息发送的能力，如第一客户端的同步消息处理模块至少可以发送消息至第二客户端。优选的实施方式中，第一客户端可以接收第二客户端发送的下行同步消息(sync_dl)。

第一客户端中可以安装有多种应用，每个应用可以包括多个业务项。用户可以对某个应用的业务进行操作，如同一条生活圈动态进行n次反复的点赞和取消点赞操作，或者游戏应用中用户角色多次选择不同的传输门进入相应的副本场景等。用户在第一客户端对业务的操作可以基于应用设置生成相应的操作数据，在此可以将其称为业务操作数据。如用户对某条动态进行点赞后，第一客户端相应的业务模块可以基于用户的点赞操作生成一条用户对该条动态进行点赞的点赞消息，第一客户端可以获取该条点赞消息，并可以在上行消息处理模块被封装成一条业务操作数据，此条业务操作数据可以作为该用户的最新业务操作数据，可以插入到数据库中存储为数据条目。

所述的点赞消息在第一客户端被封装成业务操作数据，其中所述的业务操作数据可以包括很多字段。本申请提供的一种实施方案中，为实现用户业务操作数据的有效识别和去重处理，可以采用至少包括设置的三个字段信息来确定用户操作的唯一性。因此，本申请的提供的一种实施例中，

所述最新业务操作数据可以被设置成包括业务操作类型、业务操作对象、操作用户账户的字段信息。

具体的，在用户对生活圈动态点赞为应用场景中，可以在业务操作数据中设置typeid表示业务操作类型，如点赞操作，具体的取值可以设置包括点赞和取消点赞；设置operationid表示业务操作对象的id，如取值可以为生活圈中某条动态的标号或识别符等；userid表示当前触发业务操作的用户账户，可以为用户账号或者其他对应的账户信息等。那么，采用本申请实施例实施方式即可以通过typeid+operationid+userid这三个字段信息组合就可以唯一确定一类操作。当然，其他的实施例中所述业务操作数据还可以包括其他字段信息，或者与上述可以表示业务操作类型、操作对象、操作行为实施者的相同或等同及变换、变形的其他字符信息。

本实施例中的手机第一客户端可以获取用户在手机上进行业务操作生成的最新业务操作数据。

s2：第一客户端在离线状态下，将所述最新业务操作数据作为离线业务操作数据进行存储，并按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据。

若所述第一客户端在离线状态下，则用户在离线状态下消息或操作请求等没有通过通信网络发出去。离线状态下，所述第一客户端可以对用户对业务的操作进行记录，并存储同一业务相同操作的最新数据，按照去重规则删除离线状态下存储的历史重复的业务操作数据。具体的实施过程可以如图2所示，图2是本申请的一种实施例中存储业务操作数据并删除重复的离线业务操作数据的实施过程示意图，当第一客户端在离线状态下对生活圈的一条动态消息进行点赞，此点赞操作经过第一客户端上行消息处理模块后生成了一条新的业务操作数据msg_1，可以将该业务操作数据msg_1插入到上行消息处理模块的数据库中，存储为一个离线业务数据条目。然后可以提取业务操作数据的关键字段，确定出该用户的操作typeid+operationid+userid为：like+life_news_001+user_01，上述字段可以解释为user_01对生活圈业务项中编号为life_news_001动态消息进行了点赞操作。在此，所述的点赞操属于社交应用中的同一种类型业务操作行为，可以包括点赞和取消点赞，具体的可以设置不同的取值进行表示。

同样，用户可以进行多次业务操作，在同一应用的业务模块中可以产生不同的业务消息或请求，生成多个业务操作数据。所述第一客户端可以存储某项业务操作最新(最近)的有效操作生成的业务操作数据，并可以在存储之前删除同样在离线状态下存储的相同业务操作的重复的离线业务操作数据。如用户user_01又想对刚才的点赞进行取消，则对上述life_news_001动态消息再次点击完成取消上次的点赞操作，此时可以生成另一条新的业务操作数据msg_6。因为是同一用户对同一条动态消息进行的取消赞操作，因此，在本实施例设置的字段信息实施方案中typeid+operationid+userid没有改变，仍被认为是与业务操作数据msg_1相同的业务操作。根据预设的去重规则，可以在业务操作数据msg_6存储到数据库中前将之前将存储的离线业务数据msg_1从第一客户端的数据库中删除，如图2所示。此时，所述第一客户端的上行消息处理模块的数据库中，用户user_01对生活圈业务中编号为life_news_001动态消息进行的点赞操作仅有msg_6这一条最新的有效业务操作数据，这样可以有效的防止产生的无用消息对服务器和网络的资源浪费。因为在本实施例实施应用场景中，同一用户在离线状态下对同一条动态消息的前n-1次点赞或者取消点赞的操作都是无用的，实际服务器需要处理的仅是最后一次n的操作即达到用户操作需求。采用本实施例方案，可以真正、有效的实现为用户节省网络流量、降低网络开销，优化用户操作等。

当然，上述中所述的去重规则、判断离线存储的业务操作数据是否与最新获取的业务操作数据属于相同的数据条目等具体的识别判断规则可以根据应用场景进一步设置。结合上述所述，本申请提供的一种实施例中，若如上述业务操作数据被设置成包括业务操作类型、业务操作对象、操作用户账户的字段信息，那么相应的，

s201：所述按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据可以包括：

根据业务操作数据中的业务操作类型、业务操作对象、操作用户账户的字段信息计算所述最新业务操作数据和离线业务操作数据的唯一业务操作标识；

查找所述离线业务操作数据中是否有与所述最新业务操作数据的唯一业务操作标识相同的重复离线业务操作数据；若有，则删除所述重复离线业务操作数据。

在本实施例中，在离线状态下用户在第一客户端应用上执行的多次业务操作，每一次可以生成相应的最新业务操作数据进行存储，在插入数据库存储前可以按照一定的去重规则删除数据库中相同的数据条目(如删除数据库中存储的用户之前对某条动态的点赞或取消点赞操作)，然后再存储到数据库中，可以有效保障离线状态下第一客户端的数据库中对该条动态消息点赞操作的唯一性，不需在离线状态下每次的点赞或取消点赞都发送到服务器进行执行，减少无用操作产生的数据。

s3：检测到所述第一客户端处于在线状态时，所述第一客户端将存储的离线业务操作数据发送至第二客户端。

所述第一客户端可以存储离线状态下用户对业务操作生成的业务操作数据，并进行去重处理。当所述第一客户端重新处于在线状态时，可以自动将存储的离线业务操作数据发送至相应的目标客户端。如本实施例应用场景中，手机中的上行消息处理模块可以实时检测到网络的变化。当用户的手机重新联网后，上行消息处理模块可以启动扫描任务扫描手机的数据库，可以逐条分析在离线状态期间存储的离线业务操作数据。然后可以将包括离线消息等的累积生成的离线业务操作数据打包发送到服务器的消息同步处理模块。这样，用户可以不需要顾忌因处于离线状态而对应用中某项业务不进行操作或操作也无用的常规行为认知导致的场景限制，用户可以在离线状态下对业务进行操作，待客户端处于在线状态时即可识别用户真正有效的操作，然后发送到服务端进行相应的业务处理。显然，这种实施方式可以让用户明确类似即使手机未联网仍然可以进行场景下的业务操作，如点赞或打开关闭消息提醒开关等，提升用户终端应用使用体验。并且无需手机联网后再次手动进行点击或打开界面进行开关操作等，第一客户端可以自动的在上线后将离线状态下的业务操作数据发送到服务端进行处理，减少用户操作，进一步提高用户使用体验。

本实施例中，当检测到所述第一客户端处于在线状态时，所述第一客户端将存储的离线业务操作数据发送至第二客户端。

s4：所述第二客户端响应接收到所述离线业务操作数据，向所述第一客户端返回确认消息。

在本实施例中接收处理所述第一客户端离线业务操作数据的第二客户端可以包括业务系统的服务器。服务器的同步消息处理模块接收到客户端发送来的离线业务操作数据后可以进行相应的业务处理，如图1中所示的可以将所述离线业务操作数据转发给业务系统的相应业务模块进行处理。当然，其他的实施例中所述第二客户端也可以直接进行处理，可以不需包括图1中所示的转发过程。图1中所示的服务器一侧的同步消息处理模块和业务模块是具体终端装置或产品应用的一种实施方式。

如果第二客户端接收到了客户端发送来的离线业务操作数据，则可以表示所述第一客户端发送的离线业务操作数据发送成功，已经送达到目标客户端。此时，所述第二客户端可以向所述第一客户端返回一个确认消息(ack，acknowledgement)，以向所述第一客户端表述发送的离线业务操作数据接收成功。

进一步的，另一种方式中，如果所述第一客户接收到了所述第二客户端发送来的确认消息，表述之前发送的离线业务操作数据发送成功，已经被服务器确认过，此时可以将相应的离线业务操作数据从第一客户端数据库中安全删除。因此，本申请所述的一种业务操作数据处理方法还可以包括：

s5：所述第一客户端基于收到的确认消息确认所述离线业务操作数据发送成功，并删除存储的所述发送成功的离线业务操作数据。

图3是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程。这样，所述第一客户端在离线状态/在线状态的场景变换下实现离线存储用户业务操作数据并根据去重规则保留最新的有效操作数据，在线后自动发送。如果发送成功，则可以删除原存储的离线业务数据，腾出存储空间以预留下一次离线时的数据存储和处理。例如服务端收到数据后，会主动向客户端发送一条确认信息“我收到了你刚才发送的这条信息，我会帮你处理，请放心”，客户端收到该条确认信息后，表示之前离线发送的对应的请求消息已被服务端接收或处理。此时第一客户端的同步消息处理模块可以将存储的发送成功的离线业务操作数据条目删除。

本申请提供的业务操作数据处理方法，提供一种可以支持去重的离线状态下提交的上行数据的方法，实现对业务操作数据的不同操作分类并按照去重规则进行去重，将同类操作数据的前n-1条删除，保留最后1条发送。待终端设备上线后(如重新联网)自动发送给接收方。这样，当用户需要尽快的将提交数据到服务器时，可以避免用户不能第一时间知道手机网络能通畅的情况下，导致延迟用户提交数据的实时性。采用本申请上述各个实施例方案可以并可以有效减少用户手动业务操作和无用的操作数据，节约带宽资源、降低业务处理服务端负荷，提高用户操作使用体验。

另一种应用场景中，例如待手机网络恢复连接，但由于网络超时或抖动等原因产生的网络不稳定，可能导致所述第一客户端没有能够将离线业务操作数据发送到服务器。因此，本申请提供的所述一种业务操作数据处理方法的另一种实施例中，所述方法还可以包括：

s6：所述第一客户端发送所述离线业务操作数据后启动重发定时器，监视所述离线业务操作数据的发送时间；若在设置的超时间隔时间内没有收到返回的确认消息，则重新发送超时的离线业务操作数据。

图4是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程。如第一客户端的同步消息处理模块启动扫描任务扫描数据库，并逐条分析所有数据；将所有累积生成的离线消息打包发送到服务器的同步消息处理模块，同时启动重发定时器，超时间隔时间设置为15秒。如果15秒内没有收到服器返回的确认消息，将触发重发定时器，否则关闭定时器。

如果由于此时网络不够稳定，出现抖动，那么第一客户端发出去的消息迟迟没有送达服务端，超时后导致重发定时器触发，重新发送刚才的包括业务离线业务操作数据的打包数据。经过重发后，如果打包数据顺利到达服务端，并经过服务端确认，则可以关闭监视该离线业务操作数据的定时器线程。

在本实施例应用场景中，任何一条从第一客户端上行同步消息处理模块发送到服务器同步消息处理模块的数据，都必须经过服务器返回消息进行确认，以确保数据完整到达服务器。如果客户端在定时器超时时间内没有收到服务器的确认消息，将触发定时器重发消息；相应的，每条被服务器经过确认的消息，第一客户端的同步消息处理模块都会删除数据库中对应的数据条目，同时关闭重发定时器。这样可以确保用户发送的消息一定能到达服务端，而不会丢失。

上述所述各个实施例所述的业务操作数据处理方法可以用于多种移动终端或pc设备、服务器等通信电子设备中，实现用户在离线状态下仍然可以进行业务操作，并提交数据请求，不限制业务操作的离线或在线使用场景。并且可以检测到终端设备处于在线状态时自动将累积的去重处理后的离线数据发送到服务端，节约网络资源，优化操作，提高用户使用体验。因此，对于离线业务操作的终端设备一侧而言，本申请提供的一种业务操作数据处理方法的另一种实施例中，所述方法可以包括：

s11：获取基于用户的业务操作生成的最新业务操作数据；

s22：在离线状态下，将所述最新业务操作数据作为离线业务操作数据进行存储，并按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；

s33：检测到处于在线状态时，发送存储的离线业务操作数据。

图5是本申请提供的一种业务操作数据处理方法一种实施例的方法流程图。本申请实施例提供的业务操作数据处理方法，可以在终端设备处理离线状态时提交上行数据法，并按照去重规则进行去重，将同类操作数据的前n-1条删除，保留最后1条发送。待终端设备上线后(如重新联网)自动发送给接收方。这样，当用户需要尽快的将提交数据到服务器时，可以避免用户不能第一时间知道手机网络能通畅的情况下，导致延迟用户提交数据的实时性。并可以有效减少用户手动业务操作和无用的操作数据，节约带宽资源、降低业务处理服务端负荷，提高用户操作使用体验。

进一步的，如果处理所述离线业务操作数据的第二客户端接收到了所述第一客户发送的离线业务操作数据，则所述第二客户端可以向所述第一客户端返回一个确认消息。如果所述第一客户端接收到确认消息，可以表示之前发送的相应的离线业务操作数据发送成功，此时可以删除存储的已经发送成功的离线业务操作数据。因此，本申请提供的一种业务操作数据处理方法的另一种实施例中，所述方法还可以包括：

s44：基于收到的确认消息确认所述离线业务操作数据发送成功，并删除存储的所述发送成功的离线业务操作数据。

图6是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程图。本申请所述方法的另一种实施例中，可以根据包括设置的业务操作数据三个关键字段来判断识别重复的业务操作，实现业务操作数据去重处理。具体的，本申请所述一种业务操作数据的另一种实施例中，所述最新业务操作数据可以被设置成包括业务操作类型、业务操作对象、操作用户账户的字段信息；

相应的，所述按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据，可以包括：

根据业务操作数据中的业务操作类型、业务操作对象、操作用户账户的字段信息计算所述最新业务操作数据和离线业务操作数据的唯一业务操作标识；

查找所述离线业务操作数据中是否有与所述最新业务操作数据的唯一业务操作标识相同的重复离线业务操作数据；若有，则删除所述重复离线业务操作数据。

本申请所述一种业务操作数据的另一种实施例中，另一种应用场景中，例如待手机网络恢复连接，但由于网络超时或抖动等原因产生的网络不稳定，可能导致所述第一客户端没有能够将离线业务操作数据发送到服务器。图7是本申请提供的一种业务操作数据处理方法另一种实施例的方法流程图，如图7所示，所述方法还可以包括：

s55：发送所述离线业务操作数据后启动重发定时器，监视所述离线业务操作数据的发送时间；若在设置的超时间隔时间内没有收到返回的确认消息，则重新发送超时的离线业务操作数据。

本申请提供的业务操作数据处理方法，可以使终端设备在离线状态下提交上行数据，实现并按照去重规则进行去重。待终端设备上线后(如重新联网)自动发送给接收方。这样，当用户需要尽快的将提交数据到服务器时，可以避免用户不能第一时间知道手机网络能通畅的情况下，导致延迟用户提交数据的实时性。采用本申请上述各个实施例方案可以并可以有效减少用户手动业务操作和无用的操作数据，节约带宽资源、降低业务处理服务端负荷，提高用户操作使用体验。

另一种实施应用场景中，对于服务器一侧而言，可以接收客户发送而来的离线业务操作数据。由于客户端一侧进行的离线业务数据去重处理，所以可以降低服务器数据处理负荷。在服务器一侧，具体的实施过程中可以由上述实施例中所述的同步消息处理模块接收客户端发送来的离线业务操作数据，然后可以转发给相应的服务器中的其他业务模块进行具体的业务层处理。并且，服务器接收到离线业务操作数据后，可以向发送该离线业务操作数据的客户端返回一个确认消息，告知客户端已经成功接收，以使客户端可以执行离线业务操作数据发送成功后的后续操作，如删除发送成功的消息、向用户提示发送成功等。因此，本申请提供的一种业务操作数据处理方法的另一种实施方案可以适用于处理离线业务操作数据的服务器一侧。具体的，所述方法可以包括：

s100：接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；

s200：将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

基于上述所述的一种业务操作数据处理方法，本申请提供一种业务操作数据处理装置。所述业务数据处理装置可以如上述实施例中所述的第一客户端中的同步消息处理模块，或者终端设备中其他可以实现业务操作数据处理的装置结构、单元等。这些装置可以是终端设备如手机中应用的某一模块结构，其他的实施例中也可以为与所述第一客户端有通信链接但不属于同一物理设备的装置结构，如分布式系统中设置的单独实施获取、去重、存储、发送离线业务操作数据的计算机设备。具体的，图8是本申请提供的一种业务操作数据处理装置一种实施例的模块结构示意图，如图8所示，所述装置可以包括：

操作数据获取模块101，可以用于获取基于用户的业务操作生成的最新业务操作数据；

存储模块102，可以用于将离线状态下所述生成的业务操作数据作为离线业务操作数据进行存储；

去重处理模块103，可以用于照预设的去重规则删除所述存储模块102中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；

发送模块104，可以用于检测到处于在线状态时，发送存储的离线业务操作数据。

本申请实施例提供的一种业务操作数据处理装置，通过离线数据的去重机制，用户可以在终端离线状态下提交数据请求，例如发消息或者点赞等操作，不限制用户的使用场景，节约了用户的时间，提高业务处理效率。并可以在离线(如断网)的情况下，存储用户在应用中各项业务的操作数据，实现自动识别去重，处理重复无效的用户操作数据，节约用户流量和带宽资源，降低处理服务器一侧的负荷，提高用户操作使用体验。

图9是本申请提供的一种业务操作数据处理装置一种实施例的模块结构示意图，如图9所示，所述装置还可以包括：

操作数据删除模块105，可以用于基于接收到的确认消息删除所述存储模块中相应的发送成功的离线业务操作数据。

这样，所述装置在离线状态/在线状态的场景变换下实现离线存储用户业务操作数据并根据去重规则保留最新的有效操作数据，在线后自动发送。如果发送成功，则可以删除原存储的离线业务数据，腾出存储空间以预留下一次离线时的数据存储和处理。例如服务端收到数据后，会主动向客户端发送一条确认信息“我收到了你刚才发送的这条信息，我会帮你处理，请放心”，所述装置收到该条确认信息后，表示之前离线发送的对应的请求消息已被服务端接收。此时所述装置可以将存储的发送成功的离线业务操作数据条目删除。

所述的去重规则、判断离线存储的业务操作数据是否与最新获取的业务操作数据属于相同的数据条目等具体的识别判断规则可以根据应用场景进一步设置。所述去重处理模块103可以包括：

操作标识计算模块1031，可以用于根据业务操作数据中的业务操作类型、业务操作对象、操作用户账户的字段信息计算所述最新业务操作数据和离线业务操作数据的唯一业务操作标识；

查找模块1032，可以用于查找所述离线业务操作数据中是否有与所述最新业务操作数据的唯一业务操作标识相同的重复离线业务操作数据；

删除模块1032，可以用于删除查找到的所述重复离线业务操作数据。

用户可以进行多次业务操作，在同一应用的业务模块中可以产生不同的业务消息或请求，生成多个业务操作数据。本申请实施例装置可以存储某项业务操作最新(最近)的有效操作生成的业务操作数据，并可以在存储之前删除同样在离线状态下存储的相同业务操作的重复的离线业务操作数据。这样可以有效的防止产生的无用消息对服务器和网络的资源浪费。例如上述手机点赞操作的应用场景中，同一用户在离线状态下对同一条动态消息的前n-1次点赞或者取消点赞的操作都是无用的，实际服务器需要处理的仅是最后一次n的操作即达到用户操作需求。采用本实施例方案，可以真正、有效的实现为用户节省网络流量、降低网络开销，优化用户操作等。

图10是本申请提供的一种业务操作数据处理装置一种实施例的模块结构示意图，如图10所示，所述装置还可以包括：

定时重发模块106，可以用于发送所述离线业务操作数据后启动重发定时器，监视所述离线业务操作数据的发送时间；若在设置的超时间隔时间内没有收到返回的确认消息，则重新发送超时的离线业务操作数据。

在本实施例应用场景中，从第一客户端上行同步消息处理模块发送到服务器同步消息处理模块的数据，须经过服务器返回消息进行确认，以确保数据完整到达服务器。如果在定时器超时时间内没有收到服务器的确认消息，将触发定时器重发消息；相应的，每条被服务器经过确认的消息，所述装置都会删除数据库中对应的数据条目，同时关闭重发定时器。这样可以确保用户发送的消息一定能到达服务端，而不会丢失。

另一种实施应用场景中，对于服务器一侧而言，可以接收客户发送而来的离线业务操作数据。由于客户端一侧进行的离线业务数据去重处理，所以可以降低服务器数据处理负荷。在服务器一侧，具体的实施过程中可以由上述实施例中所述的同步消息处理模块接收客户端发送来的离线业务操作数据，然后可以转发给相应的服务器中的其他业务模块进行具体的业务层处理。并且，服务器接收到离线业务操作数据后，可以向发送该离线业务操作数据的客户端返回一个确认消息，告知客户端已经成功接收，以使客户端可以执行离线业务操作数据发送成功后的后续操作，如删除发送成功的消息、向用户提示发送成功等。因此，本申请提供的一种业务操作数据处理装置的另一种实施应用场景中可以用于服务器一侧。具体的，所述装置的另一种实施例中，所述装置可以包括：

离线消息处理模块，可以用于接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；还可以用于将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

相应的，基于上述，本申请还提供一种服务器，可以包括离线消息处理模块，所述离线消息处理模块客体设置成，用于接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；还用于将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

本申请上述实施例中所述方法或装置可以应用于多种客户端中，如移动通信终端(如手机)、pc、平板、手持设备、车载人机等具有网络通信模块的终端电子设备。这种电子设备通常具有网络通信模块，至少具有上行通信能力，使得处于在线状态时可以向服务器或其他客户端发送消息。图11是本申请提供的所述电子设备一种实施例的产品模块结构示意图。具体的，本申请提供一种具有上行通信能力的电子设备可以包括：

存储单元201，可以用于获取并存储基于用户的业务操作生成的最新业务操作数据；

处理单元202，可以用于按照预设去重规则判断存储单元201中是否有与所述最新业务操作数据属于相同操作的离线业务操作数据；以及，若有，则删除所述与所述最新业务操作数据属于相同操作的离线业务操作数据；

网络通信模块203，可以用于检测到处于在线状态时，发送存储的离线业务操作数据。

当然，另一种实施例中，所述电子设备在离线状态/在线状态的场景变换下实现离线存储用户业务操作数据并根据去重规则保留最新的有效操作数据，在线后自动发送离线业务超时操作数据。如果发送成功，则可以删除原存储的离线业务数据，腾出存储空间以预留下一次离线时的数据存储和处理。因此，本申请提供的所述电子设备的另一种实施例中，所述网络通信模块被设置成，还可以用于接收发送的离线业务操作数据被成功接收的确认消息；

相应的，所述处理单元203在所述网络通信模块203接收到所述确认消息时删除存储单元201中相应的发送成功的离线业务操作数据。

所述电子设备的另一种实施例中，可以设置定时重复机制，保障网络不够稳定，出现抖动时可以重新发送刚才的离线业务操作数据。因此，另一种实施例中，所述电子设备还可以包括：

定时器204，可以用于发送所述离线业务操作数据后启动重发定时器；

相应的，所述处理单元202还被设置成，用于监视所述离线业务操作数据的发送时间，以及，若在设置的超时间隔时间内没有收到返回的确认消息，则向网络通信模块203下达重新发送超时的离线业务操作数据的指令。

图12是本申请提供的所述电子设备另一种实施例的产品模块结构示意图。图12中网络通信模块203中的天线表示为可以进行双工通信。

与所述电子设备信息交互的另一方可以为业务处理的服务端，如c/s网络中的服务器，或者也可以为对等网络(p2p)的其他服务端，可以与所述电子设备信息交实现多端的离线业务数据操作。因此，本申请还提供一种包括离线消息处理模块的服务器，具体的，所述服务器被设置成，可以用于接收客户端发送来的离线业务操作数据，所述离线业务操作数据包括所述客户端在离线状态时按照预设去重规则删除判断为相同操作的数据条目后的最新业务操作数据；还用于将接收到的离线业务操作数据转发给相应的业务模块进行处理，并向相应的客户发送接收到所述离线业务操作数据的确认消息。

基于上述所述的方法、装置、电子设备及服务器，本申请还提供一种业务操作数据处理系统，具体的，所述系统可以包括：

第一客户端，可以用于获取基于用户的业务的操作生成的最新业务操作数据；以及，在离线状态下，将所述最新业务操作数据作为离线业务操作数据进行存储，并按照预设的去重规则删除存储的离线业务操作数据中判断为与所述最新业务操作数据属于相同操作的离线业务操作数据；还可以用于检测到所述第一客户端处于在线状态时，将存储的离线业务操作数据发送至第二客户端；还可以用于基于收到的确认消息确认所述离线业务操作数据发送成功，并删除存储的所述发送成功的离线业务操作数据；

第二客户端，可以用于响应接收到所述离线业务操作数据，向所述第一客户端返回确认消息。

本申请所述的系统，可以通过终端设备离线数据的去重和离线数提交处理，用户在终端设备离线(如断网)的情况下可以响应需要联网的用户操作，并且可以自动识别去重，处理重复无效的用户操作数据。待终端设备上线后(如重新联网)自动发送给接收方，减少用户手动业务操作和业务服务器负荷，节约用户流量和带宽资源，提高用户操作使用体验。

尽管本申请内容中提到操作数据生成、去重时的关键字段设置、数据存储/删除、超时判断等之类的数据格式设置、存储/删除操作处理、消息发送/接收/判断的信息交互方式的描述，但是，本申请并不局限于必须是符合数据库数据存储规则、行业通信标准、在线/离线状态判断或实施例所描述的情况。某些行业标准或者使用自定义方式或实施例描述的实施基础上略加修改后的实施方案也可以实现上述实施例相同、等同或相近、或变形后可预料的实施效果。应用这些修改或变形后的数据生成、存储、判断、处理方法等，仍然可以属于本申请的可选实施方案范围之内。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

上述实施例阐明的单元、装置或模块等，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。