CN107391536A - 社区应用的评论处理方法、装置和*** - Google Patents

Abstract

本申请实施例公开一种社区应用的评论处理方法、装置和应用***，该方法包括：根据用户对社区应用的第一条目内容的第一评论操作，显示第一评论操作的评论结果，生成第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对第一条目内容的评论记录进行第一维护操作，该评论记录用于记录第一条目内容尚未得到提交确认的业务数据请求对应的参数；当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，接收该社区应用的业务服务器反馈的提交结果，并根据提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。本申请实施例能够提高用户评论操作的流畅性，提供更好用户体验。

Description

社区应用的评论处理方法、装置和***

技术领域

本申请涉及计算机软件技术领域，尤其涉及一种社区应用的评论处理方法、装置和***。

背景技术

在社区类的应用中，越来越倾向于以简洁的方式进行评论，参与内容互动。点赞、关注、喜欢等评论功能，由于操作简短，只需一个鼠标点击操作即可实现，因而得到了广泛的使用。

在现有的简短评论处理方法中，如果用户在离线状态下进行评论操作，用户会得到应用反馈的提交失败的提示信息；如果用户在网络延迟较大的情况进行评论操作，用户也需要等待较长时间才能够得到应用的服务器反馈的结果。在现有的简短评论处理方法中，用户操作不方便，用户体验较差。

如何保证用户操作的流畅性，提高用户体验，是本申请实施例所要解决的技术问题。

发明内容

本申请实施例的目的是提供一种社区应用的评论处理方法、装置和应用***，以提高用户的评论操作的流畅性，为用户提供更好的用户体验。

为解决上述技术问题，本申请实施例是这样实现的：

第一方面，提供了一种社区应用的评论处理方法，该方法包括：

根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果，并生成该第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，并接收该社区应用的业务服务器反馈的提交结果，并根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

第二方面，提供了一种社区应用的评论处理装置，该装置包括：

显示单元，根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果；

业务数据请求单元，生成该第一评论操作对应的第一业务数据请求；

维护单元，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

发送单元，当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器；

接收单元，接收该社区应用的业务服务器反馈的提交结果；

该维护单元，还根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

第三方面，提供了一种社区应用的评论处理装置，该装置包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果，并生成该第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，并接收该社区应用的业务服务器反馈的提交结果，并根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

第四方面，提供了一种社区应用***，该***包括第二方面或第三方面的社区应用的评论处理装置。

第五方面，提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序当被包括多个应用程序的电子设备执行时，使得该电子设备执行以下操作：

根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果，并生成该第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，并接收该社区应用的业务服务器反馈的提交结果，并根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

由以上本申请实施例提供的技术方案可见，本申请实施例通过将用户的评论结果直接显示并存储到离线数据库中，并在社区应用处于在线状态时将离线数据库的评论结果提交到该社区应用的服务器，并根据反馈的提交结果维护离线数据库中的评论结果，使得用户可以不依赖于网络环境对社区应用进行评论并得到显示的评论结果，从而能够保证用户评论操作的流畅性，为用户提供更好的用户体验。

附图说明

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

图1是本申请的一个实施例社区应用的评论处理方法的流程图。

图2是本申请的一个实施例社区应用的评论处理方法的交互流程图。

图3是本申请的一个实施例业务数据请求进入评论提交队列后的处理操作的场景示意图。

图4是本申请的另一个实施例业务数据请求进入评论提交队列后的处理操作的场景示意图。

图5是本申请的再一个实施例业务数据请求进入评论提交队列后的处理操作的场景示意图。

图6是本申请的另一个实施例社区应用的评论处理方法的交互流程图。

图7是本申请的一个实施例电子设备的结构示意图。

图8是本申请的一个实施例评论处理装置的结构示意图。

具体实施方式

本申请实施例提供一种社区应用的评论处理方法、装置和应用***。

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

图1是本申请的一个实施例社区应用的评论处理方法的流程图。图1的方法由评论处理装置执行。在具体的应用中，该评论处理装置可以是社区应用的一个功能模块。图1的方法可包括：

S101，根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果，并生成该第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作。

该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数。

应理解，在本申请实施例中，该条目内容可以是社区应用中当前用户或其它用户发表的某个观点，或者是当前用户或其它用户对该观点的回复内容，等等。

应理解，在本申请实施例中，第一评论操作是对社区应用的某个条目内容的评论操作。具体地，该评论操作可包括如点赞、取消点赞、关注、取消关注、喜欢、不喜欢等只需要进行简单的点击操作即可实现的简短评论操作，或者是对条目内容的文本回复等评论操作。

S102，当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，并接收该社区应用的业务服务器反馈的提交结果，并根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

本申请实施例中，通过将用户的评论操作的结果直接显示，生成评论操作对应的业务数据请求，并存储业务数据请求的参数，然后在社区应用处于在线状态时提交业务数据请求，并根据反馈的提交结果维护离线数据库中业务数据请求对应的参数，使得用户可以不依赖于网络环境的质量对社区应用的条目内容进行评论并迅速得到显示的评论结果，从而能够保证用户评论操作的流畅性，为用户提供更好的用户体验。

此外，本申请实施例的方法，根据反馈结果维护离线数据库中业务数据请求对应的参数，而不是直接根据反馈结果更新对用户的显示结果，能够避免因提交失败导致对用户的显示结果回退到用户进行评论操作之前，为用户提供了更好的用户体验。

可选地，在步骤S101中，在生成该第一评论操作对应的第一业务数据请求之后，该方法还包括：将该第一业务数据请求添加到该社区应用的评论提交队列，该评论提交队列为该社区应用提交评论结果的处理队列；

其中，在步骤S102中，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，具体可实现为：按照业务数据请求在该评论提交队列中的顺序，将该至少一个业务数据请求发送给该社区应用的业务服务器。

本申请实施例中，通过将业务数据请求添加到评论提交队列，使得用户可以不需要接收前一次评论操作对应的业务数据请求的提交结果，即可进行下一个评论操作并显示，能够进一步保证用户进行评论操作的流畅性，为用户提供更好的用户体验。

特别地，在社区应用处于离线状态时，或者社区应用的网络延迟大于预定阈值时，通过以队列的形式提交业务数据请求，可以大大加强用户评论操作的流畅性，获得更好的用户体验。

可选地，第一维护操作包括：添加操作、删除操作和修改操作中的一种或多种。

下面，将根据第一维护操作的具体类型，说明如何在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作。

可选地，作为一个实施例，在步骤S101中，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体可实现为：在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数。

进一步地，在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数，包括：如果该评论提交队列中不存在与该第一评论操作互斥或相互抵消的评论操作对应的业务数据请求，则在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数。

本申请实施例中，通过在评论提交队列中不存在与所述第一评论操作互斥或相互抵消的评论操作对应的业务数据请求时直接添加第一业务数据请求对应的参数，可以避免在离线数据库中添加第一业务数据请求对应的参数后，再对离线数据库进行合并操作，提高了离线数据库的操作效率。可选地，在步骤S101中，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体可实现为：对第一条目内容中第一业务数据请求对应的参数进行合并处理；在将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器之前，该方法还可包括：对评论提交队列进行合并处理。

进一步地，在本实施例的一种具体实现方式中，如果该评论提交队列中存在第二业务数据请求，且该第二业务数据请求是该用户在对该第一条目内容进行第二评论操作后生成的业务数据请求，且第二评论操作与第一评论操作是相互抵消的评论操作，则在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体可实现为：在该评论提交队列中删除该第二业务数据请求和该第一业务数据请求；

其中，在步骤S101中，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体可实现为：在该第一条目内容的评论记录中删除该第二业务数据请求对应的参数。

应理解，第二评论操作与第一评论操作是相互抵消的评论操作，具体地，第二评论操作是取消第一评论操作的评论操作，或者第一评论操作是取消第二评论操作的评论操作。例如，当该第一评论操作为点赞操作时，该第二评论操作为取消点赞操作；当该第一评论操作为取消关注操作时，该第二评论操作为关注操作，等等。假设用户在离线状态下对条目内容1点赞，然后又对条目内容1取消点赞，则两个操作相互抵消，相当于对条目内容1即不执行点赞，也不执行取消点赞操作。

本申请实施例中，通过对同一条目内容的指定评论操作与取消指定评论操作进行合并，能够不需要提交条目内容的评论操作过程而只提交最近的一次评论操作的评论结果，从而能够减少上传的数据流量，减小社区应用的后台负载。

或者，进一步地，在本实施例的一种具体实现方式中，如果该评论提交队列中存在第三业务数据请求，且该第三业务数据请求是该用户在对该第一条目内容进行第三评论操作后生成的业务数据请求，且该第三评论操作是与该第一评论操作属于互斥的评论操作，则在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体可实现为：在该评论提交队列中删除该第三业务数据请求并保留该第一业务数据请求；

其中，在步骤S101中，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体可实现为：将所述第一条目内容的评论记录中所述第三业务数据请求对应的参数修改为所述第一业务数据请求对应的参数。

当然，应理解，修改操作也可以用删除操作和添加操作两步实现，此时，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，具体实现为：在该第一条目内容的评论记录中删除该第三业务数据请求对应的参数，并添加该第一业务数据请求对应的参数。

应理解，该第三评论操作与该第一评论操作的关系为互斥的评论操作关系，互斥的评论操作中的最后一次评论操作会覆盖前面的评论操作。例如，喜欢和不喜欢就是一对互斥的评论操作。假设用户当前对条目内容2的评论为中性(尚未评价)，如果用户先点击喜欢条目内容2的评论操作，再点击不喜欢条目内容2的评论操作，则最终评论结果为不喜欢条目内容2；如果用户先点击不喜欢条目内容2的评论操作，再点击喜欢条目内容2的评论操作，则最终评论结果为喜欢条目内容2。

本申请实施例中，通过对同一条目内容的互斥的两个评论操作进行合并，使用后一个评论操作的评论结果覆盖前一个评论操作的评论结果，能够不需要提交条目内容的评论操作过程而只提交最近的一次评论操作的评论结果，从而能够减少上传的数据流量，减小社区应用的后台负载。

应理解，评论处理装置可在离线数据库中确定存在第二业务数据请求或第三业务数据请求的参数后，对评论提交队列进行合并操作；或者，评论处理装置可在维护离线数据库之前，先在评论提交队列中查找是否存在与第一业务数据请求相对应的第二业务数据请求或第三业务数据请求，并在确定评论提交队列中存在对应的第二业务数据请求或第三业务数据请求后，维护离线数据库中对应的第二业务数据请求或第三业务数据请求对应的参数；或者，评论处理装置维护离线数据库的操作与合并评论提交队列的操作可以不互相依赖，单独判断。

可选地，第二维护操作包括：删除操作、修改操作和保留操作中的一种或多种。

下面，将根据第二维护操作的具体类型，说明如何根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

可选地，作为一个实施例，在步骤S102中，根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，具体可实现为：如果第二条目内容的第四业务数据请求的提交结果为提交成功，则在该离线数据库中删除该第二条目内容的评论记录中该第四业务数据请求对应的参数。

应理解，在本申请实施例中，第二条目内容与第一条目内容可以是同一个条目内容，或者是不同的条目内容，本申请实施例对此不作限制。类似地，第四业务数据请求与第一业务数据请求可以是同一业务数据请求，也可以是不同的业务数据请求，本申请实施例对此也不作限制。

本申请实施例中，通过在条目内容的评论结果提交成功之后删除离线数据库中业务数据请求对应的参数，可以有效减小离线数据库，避免离线数据库的无限制增长。此外，本申请实施例的方法，还可避免离线数据库重复提交，以提高社区应用的后台资源利用率。

可选地，作为另一个实施例，在步骤S102中，根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，具体可实现为：如果该第二条目内容的第四业务数据请求的提交结果为提交失败，则在该离线数据库该第二条目内容的评论记录中保留该第四业务数据请求对应的参数。

本申请实施例中，通过在条目内容的评论结果提交失败之后保留离线数据库中业务数据请求对应的参数，使得社区应用能够在后续的时间里继续上传业务数据请求。

可选地，在本申请实施例的一个具体实现方式中，在根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，该方法还包括：在第一预定时间之后，基于该离线数据库中各业务数据请求的参数重新生成业务数据请求，并发送给该社区应用的业务服务器。

在本实现方式中，通过在预定时间之后基于该离线数据库中保留的业务数据请求对应的参数提交业务数据请求，可以增强业务数据请求的提交成功率。

可选地，在本申请实施例的一个具体实现方式中，在步骤S102之后，该方法还包括：

显示重新上传的菜单选项；

当检测到该用户点击该菜单选项时，基于当前时刻该离线数据库中各业务数据请求的参数重新生成业务数据请求，并发送给该社区应用的业务服务器。

在本实现方式中，通过向用户显示重新上传的菜单选项，并在检测到该用户点击该菜单选项后，基于该离线数据库中保留的业务数据请求对应的参数提交业务数据请求，使得用户能够对是否重新上传业务数据请求进行决策，为用户提供更好的用户体验。

当然，应理解，在本实施例的上述两种具体实现方式中，社区应用在重新生成业务数据请求并发送给该社区应用的业务服务器之后，还可接收该社区应用的服务器反馈的提交结果，并根据该提交结果维护该离线数据库中各条目内容的评论记录，具体实现可参考步骤S102。

可选地，步骤S102中，在将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器之后，该方法还可包括：

对该至少一个业务数据请求在该离线数据库中对应的评论记录进行第三维护操作，以将该至少一个业务数据请求对应的状态参数修改为提交状态，和/或将该至少一个业务数据请求对应的时间戳参数修改为发送该至少一个业务数据请求的时间。

应理解，在该离线数据库中业务数据请求对应的参数中，时间戳可用于标记业务数据请求的提交时间，状态可用于标记业务数据请求的状态，具体可包括等待状态、提交状态、完成状态和失败状态等。在本申请中，时间戳和状态都是可选地。

作为一个实施例，当该第三维护操作用于将该至少一个业务数据请求对应的状态参数修改为提交状态时，根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，包括：

如果第二条目内容的第四业务数据请求的提交结果为提交成功，则在该离线数据库该第二条目内容的评论记录中，将该第四业务数据请求的状态参数修改为完成状态；或者

如果第二条目内容的第四业务数据请求的提交结果为提交失败，则在该离线数据库该第二条目内容的评论记录中，将该第四业务数据请求的状态参数修改为失败状态。

进一步地，在本实施例中，在根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，该方法还可包括：周期性删除该离线数据库中状态为完成状态的业务数据请求对应的参数。通过周期性删除状态为完成状态的业务数据请求对应的参数，可以避免离线数据库无限制增长，有利于社区应用对离线数据库的维护。

可选地，作为一个实施例，当第三维护操作用于将该至少一个业务数据请求对应的时间戳参数修改为发送该至少一个业务数据请求的时间时时，在根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，该方法还包括：

如果该离线数据库中第五业务数据请求对应的时间戳与当前时间间隔大于预定时间，则

根据该离线数据库中该第五业务数据请求对应的参数重新生成该第五业务数据请求并发送给该社区应用的业务服务器；或者

将该第五业务数据请求的超时错误信息发送给该社区应用的业务服务器，该超时错误信息用于该社区应用的业务服务器进行统计。

可选地，作为一个实施例，在该用户退出该社区应用并重新登录后，该方法还可包括：根据该离线数据库中各业务数据请求对应的参数，生成业务数据请求并发送给该社区应用的业务服务器。

本申请实施例中，通过在登录社区应用后根据离线数据库生成业务数据请求并发送，可以使得用户在当前移动终端前次登录社区应用中尚未提交的至少一个业务数据请求可以得到再次提交的机会。

下面，将结合具体的实施例，对本申请实施例的方法作进一步的描述。

图2是本申请的一个实施例社区应用的评论处理方法的交互流程图。在图2所示的交互流程图中，离线模块和UI模块是社区应用的功能模块，Sync网关、虫洞服务器、业务前置服务端和业务后台服务端是属于社区应用服务端的服务器或功能模块。应理解，在本申请实施例中，虫洞服务器是用于处理离线化相关操作的服务器，图6所示实施例中的虫洞服务器与此类似，不再赘述。

201，社区应用接收用户的评论操作。

社区应用可接收用户对社区应用的评论操作。

应理解，在本申请实施例中，在社区应用处于离线状态或在线状态时，社区应用都可接收用户对社区应用的用户接口(User Interface，UI)界面的评论操作，本申请实施例对此不作限制。

应理解，用户的评论操作所评论的条目内容，可以是在某个社区应用中当前用户或其它用户发表的某个观点，或者是当前用户或其它用户对该观点的回复内容，等等。

应理解，在实际的应用中，该评论操作可包括如点赞、取消点赞、关注、取消关注、喜欢、不喜欢等只需要进行简单的点击操作即可实现的简短评论操作，或者是对条目内容的文本回复等评论操作。

202，社区应用展示评论成功界面。

本申请实施例中，社区应用在接收UE的评论操作之后，可直接在UI上展示评论成功界面。

例如，用户在对条目内容1进行点赞后，社区应用可直接显示对条目内容1点赞的评论结果，而不需要在向社区应用服务端提交点赞评论并得到反馈结果后再显示用户点赞的评论结果。

203，社区应用生成业务数据请求并发送。

具体地，社区应用可根据用户的评论操作，构造业务数据参数，生成业务数据请求。该业务数据请求用于请求提交评论操作的评论结果。

具体地，该业务数据请求中，可包括条目内容的标识和评论操作的类型。

可选地，当评论操作的类型为文本回复时，该业务数据请求中还可包括文本内容等。

社区应用生成业务数据请求后，可通过Sync网关，向社区应用服务端发送业务数据请求。

如果社区应用处于离线状态，社区应用可将业务数据请求排队放入评价提交队列中，等待提交。业务数据请求作为Sync上行的数据，会在社区应用处于在线状态时，通过Sync网关向社区应用服务端提交。

如果用户进行评论操作时社区应用处于在线状态，则社区应用可直接根据用户评论操作的评论结果生成业务数据请求并发送。

当然，应理解，如果社区应用处于在线状态，社区应用也可将业务数据请求排队放入评价提交队列中，等待提交。当社区应用的网络延迟大于预定阈值时，通过将业务数据请求放入评价提交队列，可以不需要等待业务数据请求是否完成提交即可进行下一次的评论操作。

此外，当一个新的业务数据请求进入评价提交队列时，社区应用可根据业务数据请求中的条目内容的标识和评论操作的类型，确定是否进行合并操作。该合并操作可以在社区应用处于离线状态时进行。

不妨假设新进入评价提交队列的第一业务数据请求是对第一条目内容的第一评价操作。

如果该评论提交队列中存在第二业务数据请求，且该第二业务数据请求是该用户在对该第一条目内容进行第二评论操作后生成的业务数据请求，且第二评论操作与第一评论操作是相互抵消的评论操作，则社区应用可在该评论提交队列中删除该第二业务数据请求和该第一业务数据请求。

图3是本申请的一个实施例业务数据请求进入评论提交队列后的处理操作的场景示意图。如图3所示，当前队列中包括CommentId为1-5的5个ID的业务数据请求，其对应的评论操作类型分别是1(点赞)、1(点赞)、0(取消点赞)、0(取消点赞)、1(点赞)。

如图3所示，当新的业务数据请求(CommentId：2，type：0)进入评论提交队列后，由于评论提交队列中存在的业务数据请求(CommentId：2，type：1)与新进入的业务数据请求是一对可相互抵消的评论操作，因此社区应用对这两个业务数据请求的合并操作，即删除这两个业务数据请求。此时评论提交队列中剩余的业务数据请求包括CommentId为1、3、4、5的条目内容对应的业务数据请求。

如果该评论提交队列中存在第三业务数据请求，且该第三业务数据请求是该用户在对该第一条目内容进行第三评论操作后生成的业务数据请求，且第三评论操作与第一评论操作是互斥的评论操作，则社区应用可在该评论提交队列中删除该第三业务数据请求并保留该第一业务数据请求。

图4是本申请的另一个实施例业务数据请求进入评论提交队列后的处理操作的场景示意图。如图4所示，当前队列中包括CommentId为1-5的5个ID的业务数据请求，其对应的评论操作类型分别是1(喜欢)、1(喜欢)、0(不喜欢)、0(不喜欢)、1(喜欢)。

如图4所示，当新的业务数据请求(CommentId：2，type：0)进入评论提交队列后，由于评论提交队列中存在的业务数据请求(CommentId：2，type：1)与新进入的业务数据请求是一对互斥的评论操作，对同一条目内容的后一个评论操作会覆盖前一个评论操作。此时评论提交队列中剩余的业务数据请求包括CommentId为1、2、3、4、5的条目内容对应的业务数据请求，但CommentId为2的条目内容对应的业务数据请求的评论类型为0(不喜欢)，覆盖了原来的结果，并移动到评论提交队列的最后。

如果该评论提交队列中存在第四业务数据请求，且该第四业务数据请求是该用户在对该第一条目内容进行第四评论操作后生成的业务数据请求，且第四评论操作与第一评论操作既不是互斥的评论操作，也不是相互抵消的评论操作，则社区应用可在该评论提交队列中保留该第四业务数据请求和该第一业务数据请求。

图5是本申请的再一个实施例业务数据请求进入评论提交队列后的处理操作的场景示意图。当前队列中包括CommentId为1-5的5个ID的业务数据请求，其对应的评论操作类型分别是1(喜欢)、1(喜欢)、0(不喜欢)、0(不喜欢)、1(喜欢)。

如图5所示，当新的业务数据请求(CommentId：2，type：2)进入评论提交队列后，由于评论提交队列中存在的业务数据请求(CommentId：2，type：1)与新进入的业务数据请求既不是互斥的评论操作，也不是相互抵消的评论操作，社区应用会保留两个业务数据请求。当然，社区应用也可对这两个业务数据请求进行合并，一个业务数据请求中可包括两个评论操作类型。

当社区应用处于在线状态时，社区应用可通过向Sync网关发送业务数据请求，经由Sync网关与社区应用服务端的虫洞服务器建立长连接。然后，社区应用可按照业务数据请求在评论提交队列中的顺序，通过Sync提交业务数据请求。

当然，应理解，社区应用也可不对评论提交队列中的业务数据请求进行合并操作。

204，社区应用更新离线数据库。

应理解，在生成业务数据请求的同时，社区应用还可将该业务数据请求在离线数据库中该条目内容对应的评论记录中进行维护。该评论记录可存储着业务数据请求对应的参数。

可选地，业务数据请求对应的参数可包括条目内容的标识和评论操作的类型。

可选地，业务数据请求对应的参数还可包括业务数据请求的对象所转换的数据。

此外，在社区应用提交业务数据请求时，社区应用也可根据已经提交的业务数据请求，维护离线数据库中该业务数据请求对应的参数。

可选地，业务数据请求对应的参数还可包括用户进行评论操作时的时间戳，社区应用可在业务数据请求提交后，将离线数据库中对应的业务数据请求的时间戳标记为提交时间。

可选地，业务数据请求对应的参数还可包括业务数据请求的状态，例如等待状态、提交状态、完成状态和失败状态等，其中

等待状态用于表示业务数据请求正在等待提交；

提交状态用于表示业务数据请求已经提交，正在等待反馈结果；

完成状态用于表示业务数据请求已经提交并接收到提交成功的反馈结果；

失败状态用于表示业务数据请求已经提交并接收到提交失败的反馈结果。

社区应用根据用户的评论操作维护离线数据库中对应的业务数据请求的参数时，可将该业务数据请求的状态标记为等待状态。

社区应用可在业务数据请求提交后，将离线数据库中对应的业务数据请求的状态标记为提交状态。

为便于理解，表格1示出了离线数据库格式的一种示意性的数据结构。

表格1：

离线数据库的一个具体例子如表格2所示。

表格2：

属性	类型	说明
			ID	int	1000061650
Type	int	0
			SubType	String	FOLLOW
Content Data	String	“follow_type:0”
			Create Time	String	1488202985590
Status	String	COMPLETE

其中，类型TYPE为0，表示虫洞类型。

当然，应理解，离线数据库中业务数据请求对应的参数还可包括其它字段。可选地，例如，当评论操作的类型为文本回复时，业务数据请求对应的参数还可包括评论操作对应的文本内容，等等。

可选地，在离线数据库中存储第一业务数据请求时，如果离线数据库中存在第二业务数据请求，该第二业务数据请求的条目内容的标识与第一业务数据请求的条目内容的标识相同，且第二业务数据请求的评论操作与第一业务数据请求是相互抵消的评论操作，则社区应用可删除第二业务数据请求的参数，同时不存储第一业务数据请求的参数。

或者，可选地，在离线数据库中存储第一业务数据请求时，如果离线数据库中存在第三业务数据请求，该第三业务数据请求的条目内容的标识与第一业务数据请求的条目内容的标识相同，且第三业务数据请求的评论操作与第一业务数据请求是互斥的评论操作，则社区应用可用第三业务数据请求的参数覆盖第一业务数据请求的参数。

当然，如果不存在与第一业务数据请求对应的第二业务数据请求或第三业务数据请求，社区应用可直接在离线数据库中存储该第一业务数据请求的参数。

此外，如果离线数据库中存在第四业务数据请求，该第四业务数据请求的条目内容的标识与第一业务数据请求的条目内容的标识相同，且第四业务数据请求第一业务数据请求既不是相互抵消的评论操作也不是互斥的评论操作，则社区应用可将第二业务数据请的参数和第三业务数据请的参数合并到一个评论记录中。当然，社区应用也可分成多个评论记录存储。

当然，如果社区应用在步骤203中不对评论提交队列中的业务数据请求进行合并操作，则社区应用在步骤204中可直接将业务数据请求对应的参数添加到离线数据库的评论记录中。

205，Sync网关发送业务数据请求。

当社区应用处于在线状态时，社区应用可通过向Sync网关业务数据请求，从而建立与虫洞服务器的长连接。

206，虫洞服务器访问虚拟RPC接口。

虫洞服务器通过虚拟远程过程调用(Remote Procedure Call，RPC)接口访问业务前置服务端(mFinSnsProd)。

207，业务前置服务端访问业务后台评论接口。

业务前置服务端(mFinSnsProd)进一步可访问业务数据请求对应的业务后台评论接口。例如，当业务数据请求为点赞操作时，业务前置服务端(mFinSnsProd)可访问业务后台点赞接口，等等。

208，业务后台服务端反馈评论操作结果。

业务后台服务端(seccommunity)根据业务前置服务端(mFinSnsProd)对业务后台评论接口的访问，反馈评论操作结果给业务前置服务端(mFinSnsProd)。

209，业务前置服务端通过虚拟RPC接口反馈评论操作结果。

业务前置服务端(mFinSnsProd)根据业务后台服务端(seccommunity)反馈的评论操作结果，通过虚拟RPC接口反馈给虫洞服务器。

210，虫洞服务器下发评论操作结果。

虫洞服务器将评论操作结果反馈给Sync网关。

应理解，步骤205至步骤210中的具体实现可参考现有技术，本申请实施例对此不作限制。此外，社区应用也可采用其它的方式将业务数据请求发送至社区应用服务端，并接收社区应用服务端对业务数据请求的反馈，本申请实施例对此不作限制。

211，社区应用更新离线数据库。

社区应用可根据Sync网关反馈的评论操作结果，直接更新离线数据库。

具体地，如果评论操作结果表明对业务数据请求的提交结果为提交成功，则社区应用可在该离线数据库中删除该业务数据请求对应的参数。

或者，如果评论操作结果表明对业务数据请求的提交结果为提交失败，则在该离线数据库中，保留该业务数据请求对应的参数。

可选地，当该业务数据请求对应的参数中包括业务数据请求的状态时，如果评论操作结果表明对业务数据请求的提交结果为提交成功，则社区应用可在该离线数据库中将该业务数据请求的状态标记为完成状态；或者，如果评论操作结果表明对业务数据请求的提交结果为提交失败，则社区应用可在该离线数据库中将该业务数据请求的状态标记为失败状态。

进一步地，社区应用还可周期性删除所述离线数据库中状态为完成状态的业务数据请求对应的参数。

图6是本申请的另一个实施例社区应用的评论处理方法的交互流程图。在图6所示的交互流程图中，离线模块和UI模块是社区应用的功能模块，Sync网关、虫洞服务器、业务前置服务端和业务后台服务端是属于社区应用服务端的服务器或功能模块。

601，社区应用根据离线数据库生成业务数据请求并发送。

在本申请实施例中，离线数据库的具体格式参考图2所示实施例。

可选地，在一种应用场景中，当社区应用因各种原因退出，在该用户重新登录该社区应用后，根据该离线数据库中各条目内容的评论记录，生成业务数据请求。

或者，可选地，在另一种应用场景中，社区应用可在接收到提交失败的反馈结果后，可向用户显示重新上传的菜单选项，并在检测到所述用户点击所述菜单选项时，基于当前时刻该离线数据库中各业务数据请求的参数重新生成业务数据请求。

或者，可选地，在另一种应用场景中，社区应用还可周期性检查离线数据库中业务数据请求对应的参数中的时间戳。如果该离线数据库中业务数据请求对应的时间戳与当前时间间隔大于第二预定时间，则社区应用根据该离线数据库中该业务数据请求对应的参数重新生成该业务数据请求。

社区应用生成业务数据请求后，可发送至Sync网关。

602，Sync网关发送业务数据请求。

603，虫洞服务器访问虚拟RPC接口。

604，业务前置服务端访问业务后台评论接口。

605，业务后台服务端反馈评论操作结果。

606，业务前置服务端通过虚拟RPC接口反馈评论操作结果。

607，虫洞服务器下发评论操作结果。

608，社区应用更新离线数据库。

步骤602-608的具体实现可参考图2所示实施例的步骤205-211，本申请实施例在此不再赘述。

图7是本申请的一个实施例电子设备的结构示意图。请参考图7，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，该程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成剪短评论处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果，并生成该第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，并接收该社区应用的业务服务器反馈的提交结果，并根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

上述如本申请图1、图2、图6所示实施例揭示的评论处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central ProcessingUnit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1的方法，并实现评论处理装置在图1、图2、图6所示实施例的功能，本申请实施例在此不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1所示实施例的方法。

图8是本申请的一个实施例评论处理装置800的结构示意图。请参考图8，在一种软件实施方式中，评论处理装置800可包括：显示单元810、生成单元820、维护单元830、发送单元840和接收单元850。

显示单元810，根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果；

生成单元820，生成该第一评论操作对应的第一业务数据请求；

维护单元830，在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

发送单元840，当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器；

接收单元850，接收该社区应用的业务服务器反馈的提交结果；

该维护单元830，还根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

本申请实施例中，评论处理装置800通过将用户的评论结果直接显示并存储到离线数据库中，并在社区应用处于在线状态时将离线数据库的评论结果提交到该社区应用的服务器，并根据反馈的提交结果维护离线数据库中的评论结果，使得用户可以不依赖于网络环境对社区应用进行评论并得到显示的评论结果，从而能够保证用户评论操作的流畅性，为用户提供更好的用户体验。

可选地，作为一个实施例，发送单元840还将该第一业务数据请求添加到该社区应用的评论提交队列，该评论提交队列为该社区应用提交评论结果的处理队列；其中，发送单元840按照业务数据请求在该评论提交队列中的顺序，将该业务数据请求发送给该社区应用的业务服务器。

可选地，第一维护操作包括：添加操作、删除操作和修改操作中的一种或多种。

可选地，作为一个实施例，维护单元830在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数，具体包括：维护单元830在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数。

进一步地，维护单元830在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数，具体包括：如果该评论提交队列中不存在与该第一评论操作互斥或相互抵消的评论操作对应的业务数据请求，则维护单元830在该第一条目内容的评论记录中添加该第一业务数据请求对应的参数。

评论处理装置800还可包括合并处理单元860。

可选地，作为一个实施例，如果该评论提交队列中存在第二业务数据请求，且该第二业务数据请求是该用户在对该第一条目内容进行第二评论操作后生成的业务数据请求，且该第二评论操作与该第一评论操作是相互抵消的评论操作，则在发送单元840将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器之前，合并处理单元860可在该评论提交队列中删除该第二业务数据请求和该第一业务数据请求；维护单元830可在该第一条目内容的评论记录中删除该第二业务数据请求对应的参数。

可选地，作为另一个实施例，如果该评论提交队列中存在第三业务数据请求，且该第三业务数据请求是该用户在对该第一条目内容进行第三评论操作后生成的业务数据请求，且该第三评论操作是与该第一评论操作属于互斥的评论操作，则发送单元840在将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器之前，合并处理单元860可在该评论提交队列中删除该第三业务数据请求并保留该第一业务数据请求；维护单元830可在该第一条目内容的评论记录中将该第三业务数据请求对应的参数修改为该第一业务数据请求对应的参数。当然，应理解，维护单元830也可在该第一条目内容的评论记录中删除该第三业务数据请求对应的参数，并添加该第一业务数据请求对应的参数。

可选地，第二维护操作包括：删除操作、修改操作和保留操作中的一种或多种。

可选地，作为一个实施例，如果第二条目内容的第四业务数据请求的提交结果为提交成功，则维护单元830根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，可包括：维护单元830在该离线数据库中删除该第二条目内容的评论记录中该第四业务数据请求对应的参数。

可选地，作为另一个实施例，如果该第二条目内容的第四业务数据请求的提交结果为提交失败，则维护单元830根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，可包括：维护单元830在该离线数据库该第二条目内容的评论记录中保留该第四业务数据请求对应的参数。

进一步地，生成单元820还可在第一预定时间之后，基于该离线数据库中各业务数据请求的参数重新生成业务数据请求，并通过发送单元840发送给该社区应用的业务服务器。

可选地，作为一个实施例，在维护单元830根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，显示单元810还可显示重新上传的菜单选项；生成单元820还可在检测到该用户点击该菜单选项后，基于当前时刻该离线数据库中各业务数据请求的参数重新生成业务数据请求，并通过发送单元840发送给该社区应用的业务服务器。

可选地，作为一个实施例，在发送单元840将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器之后，维护单元830还对该至少一个业务数据请求在该离线数据库中对应的评论记录进行第三维护操作，以将该至少一个业务数据请求对应的状态参数修改为提交状态，和/或将该至少一个业务数据请求对应的时间戳参数修改为发送该至少一个业务数据请求的时间。

进一步地，当该第三维护操作用于将该至少一个业务数据请求对应的状态参数修改为提交状态时，维护单元830根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作，可包括：，如果第二条目内容的第四业务数据请求的提交结果为提交成功，则维护单元830可在该离线数据库该第二条目内容的评论记录中，将该第四业务数据请求的状态参数修改为完成状态；或者，如果第二条目内容的第四业务数据请求的提交结果为提交失败，则维护单元830可在该离线数据库该第二条目内容的评论记录中，将该第四业务数据请求的状态参数修改为失败状态。

进一步地，在维护单元830根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，维护单元830还可周期性删除该离线数据库中状态为完成状态的业务数据请求对应的参数。

进一步地，当第三维护操作用于将该至少一个业务数据请求对应的时间戳参数修改为发送该至少一个业务数据请求的时间时，如果该离线数据库中第五业务数据请求对应的时间戳与当前时间间隔大于第二预定时间，则生成单元820可根据该离线数据库中该第五业务数据请求对应的参数重新生成该第五业务数据请求，并通过发送单元840发送给该社区应用的业务服务器。

或者，进一步地，当第三维护操作用于将该至少一个业务数据请求对应的时间戳参数修改为发送该至少一个业务数据请求的时间时，如果该离线数据库中第五业务数据请求对应的时间戳与当前时间间隔大于第二预定时间，则发送单元840可将该第五业务数据请求的超时错误信息发送给该社区应用的业务服务器，该超时错误信息用于该社区应用的业务服务器进行统计。

可选地，作为一个实施例，生成单元820还可在该用户退出该该社区应用并重新登录后，根据该离线数据库中各业务数据请求对应的参数，生成业务数据请求，并通过发送单元840发送给该社区应用的业务服务器。

本申请实施例中，评论处理装置800还可执行图1的方法，并实现评论处理装置在图1、图2、图6所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提供了一种社区应用***，包括图8所示实施例的评论处理装置800，或图7是本申请的一个实施例电子设备所存储的评论处理装置。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，使得该电子设备执行以下操作：

根据用户对社区应用的第一条目内容的第一评论操作，显示该第一评论操作的评论结果，并生成该第一评论操作对应的第一业务数据请求，并在该社区应用的离线数据库中对该第一条目内容的评论记录进行第一维护操作，该评论记录用于记录该第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当该社区应用处于在线状态时，将该社区应用中尚未提交的至少一个业务数据请求发送给该社区应用的业务服务器，并接收该社区应用的业务服务器反馈的提交结果，并根据该提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (18)

1.一种社区应用的评论处理方法，包括：

根据用户对社区应用的第一条目内容的第一评论操作，显示所述第一评论操作的评论结果，并生成所述第一评论操作对应的第一业务数据请求，并在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作，所述评论记录用于记录所述第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当所述社区应用处于在线状态时，将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器，并接收所述社区应用的业务服务器反馈的提交结果，并根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

2.如权利要求1所述的方法，

在生成所述第一评论操作对应的第一业务数据请求之后，所述方法还包括：将所述第一业务数据请求添加到所述社区应用的评论提交队列，所述评论提交队列为所述社区应用提交评论结果的处理队列；

其中，将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器包括：按照业务数据请求在所述评论提交队列中的顺序，将所述至少一个业务数据请求发送给所述社区应用的业务服务器。

3.如权利要求2所述的方法，所述第一维护操作包括：添加操作、删除操作和修改操作中的一种或多种。

4.如权利要求3所述的方法，其特征在于，

在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作包括：

在所述第一条目内容的评论记录中添加所述第一业务数据请求对应的参数。

5.如权利要求4所述的方法，在所述第一条目内容的评论记录中添加所述第一业务数据请求对应的参数，包括：

如果所述评论提交队列中不存在与所述第一评论操作互斥或相互抵消的评论操作对应的业务数据请求，在所述第一条目内容的评论记录中添加所述第一业务数据请求对应的参数。

6.如权利要求3所述的方法，

如果所述评论提交队列中存在第二业务数据请求，且所述第二业务数据请求是所述用户在对所述第一条目内容进行第二评论操作后生成的业务数据请求，且所述第二评论操作与所述第一评论操作是相互抵消的评论操作，则在将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器之前，所述方法还包括：在所述评论提交队列中删除所述第二业务数据请求和所述第一业务数据请求；

其中，在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作，包括：在所述第一条目内容的评论记录中删除所述第二业务数据请求对应的参数。

7.如权利要求3所述的方法，

如果所述评论提交队列中存在第三业务数据请求，且所述第三业务数据请求是所述用户在对所述第一条目内容进行第三评论操作后生成的业务数据请求，且所述第三评论操作是与所述第一评论操作属于互斥的评论操作，则在将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器之前，所述方法还包括：在所述评论提交队列中删除所述第三业务数据请求并保留所述第一业务数据请求；

其中，在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作，包括：将所述第一条目内容的评论记录中所述第三业务数据请求对应的参数修改为所述第一业务数据请求对应的参数。

8.如权利要求1所述的方法，

所述第二维护操作包括：删除操作、修改操作和保留操作中的一种或多种。

9.如权利要求8所述的方法，

根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作包括：

如果第二条目内容的第四业务数据请求的提交结果为提交成功，则在所述离线数据库中删除所述第二条目内容的评论记录中所述第四业务数据请求对应的参数；或者

如果所述第二条目内容的第四业务数据请求的提交结果为提交失败，则在所述离线数据库所述第二条目内容的评论记录中保留所述第四业务数据请求对应的参数。

10.如权利要求8所述的方法，在根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，所述方法还包括：

在第一预定时间之后，基于所述离线数据库中各业务数据请求的参数重新生成业务数据请求并发送给所述社区应用的业务服务器。

11.如权利要求8所述的方法，

在将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器之后，所述方法还包括：

对所述至少一个业务数据请求在所述离线数据库中对应的评论记录进行第三维护操作，以将所述至少一个业务数据请求对应的状态参数修改为提交状态，和/或将所述至少一个业务数据请求对应的时间戳参数修改为发送所述至少一个业务数据请求的时间。

12.如权利要求11所述的方法，

当所述第三维护操作用于将所述至少一个业务数据请求对应的状态参数修改为提交状态时，根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作包括：

如果第二条目内容的第四业务数据请求的提交结果为提交成功，则在所述离线数据库所述第二条目内容的评论记录中，将所述第四业务数据请求的状态参数修改为完成状态；或者

如果第二条目内容的第四业务数据请求的提交结果为提交失败，则在所述离线数据库所述第二条目内容的评论记录中，将所述第四业务数据请求的状态参数修改为失败状态。

13.如权利要求12所述的方法，根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，所述方法还包括：

周期性删除所述离线数据库中状态为完成状态的业务数据请求对应的参数。

14.如权利要求11所述的方法，

当第三维护操作用于将所述至少一个业务数据请求对应的时间戳参数修改为发送所述至少一个业务数据请求的时间时，在根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作之后，所述方法还包括：

如果所述离线数据库中第五业务数据请求对应的时间戳与当前时间间隔大于第二预定时间，则

根据所述离线数据库中所述第五业务数据请求对应的参数重新生成所述第五业务数据请求并发送给所述社区应用的业务服务器；或者

将所述第五业务数据请求的超时错误信息发送给所述社区应用的业务服务器，所述超时错误信息用于所述社区应用的业务服务器进行统计。

15.如权利要求1-14中任一项所述的方法，在所述用户退出所述社区应用并重新登录后，所述方法还包括：

根据所述离线数据库中各业务数据请求对应的参数，生成业务数据请求并发送给所述社区应用的业务服务器。

16.一种社区应用的评论处理装置，包括：

显示单元，根据用户对社区应用的第一条目内容的第一评论操作，显示所述第一评论操作的评论结果；

业务数据请求单元，生成所述第一评论操作对应的第一业务数据请求；

维护单元，在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作，所述评论记录用于记录所述第一条目内容尚未得到提交确认的业务数据请求对应的参数；

发送单元，当所述社区应用处于在线状态时，将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器；

接收单元，接收所述社区应用的业务服务器反馈的提交结果；

所述维护单元，还根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

17.一种社区应用的评论处理装置，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

根据用户对社区应用的第一条目内容的第一评论操作，显示所述第一评论操作的评论结果，并生成所述第一评论操作对应的第一业务数据请求，并在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作，所述评论记录用于记录所述第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当所述社区应用处于在线状态时，将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器，并接收所述社区应用的业务服务器反馈的提交结果，并根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。

18.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

根据用户对社区应用的第一条目内容的第一评论操作，显示所述第一评论操作的评论结果，并生成所述第一评论操作对应的第一业务数据请求，并在所述社区应用的离线数据库中对所述第一条目内容的评论记录进行第一维护操作，所述评论记录用于记录所述第一条目内容尚未得到提交确认的业务数据请求对应的参数；

当所述社区应用处于在线状态时，将所述社区应用中尚未提交的至少一个业务数据请求发送给所述社区应用的业务服务器，并接收所述社区应用的业务服务器反馈的提交结果，并根据所述提交结果对离线数据库中各条目内容的评论记录进行第二维护操作。