CN113850664A - 一种数据异常检测方法及数据上报服务 - Google Patents

Abstract

本发明涉及金融科技(Fintech)领域，公开一种数据异常检测方法及数据上报服务，数据上报服务在启动后获取所在应用的历史服务信息；数据上报服务若确定历史服务信息中包括崩溃信息，则获取第一链接地址；数据上报服务若确定崩溃信息中存在至少一个函数地址属于第一链接地址，则获取在应用最近一次服务发生异常时数据上报服务对数据进行读发的数据标识；数据上报服务删除数据标识对应的数据。通过该方式可有效检测终端的本地数据库中是否被写入了脏数据，该脏数据在被数据上报服务读取到后将使得数据上报服务所在的应用发生崩溃，并在确定被写入脏数据时对脏数据进行删除，从而可有效避免数据上报服务因为再次读取到同一脏数据而导致的应用崩溃问题。

Description

一种数据异常检测方法及数据上报服务

技术领域

本申请实施例涉及金融科技(Fintech)领域，尤其涉及一种数据异常检测方法及数据上报服务。

背景技术

随着计算机技术的发展，越来越多的技术(例如：大数据、云计算或区块链)应用在金融领域，传统金融业正在逐步向金融科技转变，比如用户通过安装在终端上的网上银行等应用程序即可进行相关业务办理，如此可以免于在线下实体银行办理业务。在用户使用网上银行办理业务时，银行方为了不断优化网上银行这一应用程序带给用户的体验，其可以不断获取各用户对该应用程序中的各个服务的使用数据，从而通过对各个服务下的用户数据进行分析，将可以针对性地对各个服务进行优化，以不断完善网上银行这一应用程序，进而提升用户体验感。

该过程中，银行方在获取各用户对网上银行这一应用程序中的各个服务的使用数据时，可以在网上银行这一应用程序中设置一数据上报服务，该数据上报服务用于收集该应用程序中的各个服务的用户数据，以不断向银行方的服务器发送所收集的用户数据，从而便于银行方进行数据分析并提供相应的改进策略。

对于数据上报服务所上报的用户数据，可以由终端将所有待上报的用户数据先进行本地数据库入库操作，在需要上报时，便从本地数据库中取出相关数据进行上报；接着，在终端接收到服务器返回的成功响应报文后，可从本地数据库删除对应数据。

然而，上述数据上报方式存在安全隐患。例如，若本地数据库被破解，侵入方在当中写入脏数据，那么在网上银行这一应用程序启动后，其在对待上报数据进行解码、解析时容易发生异常，进而导致进程崩溃，并引发该应用程序被动退出的恶劣结果。

显然，目前亟需一种对异常数据进行捕获并对异常数据进行清理的方法。

发明内容

本申请提供一种异常检测方法及数据上报服务，用以捕获脏数据，以避免数据上报服务因为读取了脏数据而导致应用退出的问题，实现一种安全兜底。

第一方面，本申请实施例提供一种数据异常检测方法，该方法包括：数据上报服务在启动后获取所在应用的历史服务信息；所述数据上报服务若确定所述历史服务信息中包括崩溃信息，则确定所述数据上报服务在最近一次服务时被写入所述数据上报服务所在文件的各函数的第一链接地址；所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址；所述数据上报服务若确定所述崩溃信息中存在至少一个函数地址属于所述第一链接地址，则获取在所述应用最近一次服务发生异常时所述数据上报服务对数据进行读发的数据标识；所述数据上报服务删除所述数据标识对应的异常数据。

上述方案中，每次数据上报服务在启动时，它可以读取它所在应用的历史服务信息以确定当中是否含有崩溃信息；如果有，则可获取第一链接地址，并将崩溃信息中的各函数地址与第一链接地址进行匹配，如果确定崩溃信息中存在至少一个函数地址属于第一链接地址，则数据上报服务可以确定上一次应用发生服务异常是由于数据上报服务读取到有问题的数据(即脏数据)所导致的，进而数据上报服务可以根据应用在上一次发生服务异常时、数据上报服务当前正在进行读发的数据的数据标识获取到对应的数据并删除该数据，从而后续在使用数据上报服务时就不会受此条脏数据的影响了。通过该方式可以有效检测终端的本地数据库中是否被写入了脏数据，该脏数据在被数据上报服务读取到后将使得数据上报服务所在的应用发生崩溃，并在确定被写入脏数据时对脏数据进行删除，从而可以有效避免数据上报服务因为再次读取到同一脏数据而导致的应用崩溃问题。

在一种可能实现的方法中，所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址，包括：所述数据上报服务在前置层注册所述应用的异常通知服务；所述数据上报服务在接收到所述前置层发送的异常通知后，对所述应用当前运行的各函数地址进行记录；所述异常通知是在监测到发生各异常监听事件时发出的。

上述方案中，数据上报服务所在应用通过向所在终端的系统注册触发回调的各异常监听事件，从而在终端的系统监测到发生了各异常监听事件中的至少一项内容时，可向数据上报服务所在应用中的前置层发送异常通知，由于数据上报服务在前置层中预先注册过所在应用的异常通知服务，从而此时前置层可以向数据上报服务发送异常通知，相应的，数据上报服务可以接收到该异常通知，并在接收到异常通知后，可对它(指数据上报服务)所在应用当前运行的各函数地址进行记录，该记录的各函数地址即为崩溃信息。该方式通过在前置层记录需要注册各异常监听事件的回调的各服务，而避免让各服务直接注册各异常监听事件的回调，则可以避免正处于注册回调状态的数据上报服务被新的需要注册回调的其他服务覆盖的风险，进而导致的数据上报服务无法获取它所在应用发生异常时候的状态数据。

在一种可能实现的方法中，所述数据上报服务将所述异常数据更新至异常数据临时库；所述异常数据临时库用于所述应用对待写入数据进行验证；所述数据上报服务根据所述异常数据更新服务端的异常数据持久库；所述异常数据持久库用于所述应用更新所述异常数据临时库。

上述方案中，提供了一种对数据进行保护的机制，比如在数据上报服务得到异常数据(即脏数据)后，可将该异常数据存储在终端的本地数据库(即异常数据临时库)，当后续在对待写入数据进行写入时，通过将其与该异常数据进行比较，如此可以快速确定该待写入数据是否允许被写入终端的本地数据库中；以及，数据上报服务在得到异常数据后，可以基于该异常数据更新服务端的异常数据持久库，该异常数据持久库可以用于对异常数据临时库进行更新，从而当后续在对待写入数据进行写入时，可以基于历史各次被识别出来的各异常数据来判别该待写入数据是否真的可以被写入终端的本地数据库中。通过该方式，可以有效地从源头杜绝脏数据的写入，极大程度上可使数据上报服务免于读取脏数据，减少了数据上报服务所在应用因为数据上报服务的原因而导致的应用发生异常的情况。

在一种可能实现的方法中，所述数据上报服务向所述应用发送指示信息；所述指示信息用于指示所述应用注册读发数据拦截服务，所述读发数据拦截服务用于在检测到所述应用退出时对当前读发数据进行拦截。

上述方案中，可以保证同一数据不会被重复发送。

在一种可能实现的方法中，所述数据上报服务设置有第一数目的数据写入线程和第二数目的数据读发线程；任一数据写入线程用于将接收到的待写入数据写入数据写入标识指示的存储位置并更新所述数据写入标识，任一数据读发线程用于根据数据读发标识从对应的存储位置读取待发送数据发送至服务端并更新所述数据读发标识，所述第二数目大于所述第一数目。

上述方案中，通过将数据的读发线程设置的比数据的写入线程多，将可以提升数据上报的效率；此外，读发线程和写入线程在使用的过程中，通过不断更新待读发数据的数据标识和待写入数据的数据标识，如此将可以有序的进行数据的读发和写入，避免发生数据的重发与写入混乱的问题。

在一种可能实现的方法中，所述数据上报服务设置数据栈；所述数据栈用于记录已读发数据在数据存储队列中的存储位置标识；所述数据上报服务接收到各待写入数据后，按照所述数据栈指示的各存储位置标识在所述数据存储队列中逐一对应写入，直至清空所述数据栈。

上述方案中，可以保证数据存储队列的高效利用。

在一种可能实现的方法中，所述数据上报服务若确定所述数据写入标识小于所述数据读发标识，则通过所述数据读发线程、按照从头到尾的顺序，对所述数据存储队列中的各待读发数据依序进行数据读发处理。

上述方案中，可以保证存储于数据存储队列的各数据百分百被发送。

第二方面，本申请实施例提供一种数据上报服务，该数据上报服务包括：历史服务信息获取单元，用于在启动后获取所在应用的历史服务信息；第一链接地址获取单元，用于若确定所述历史服务信息中包括崩溃信息，则确定所述数据上报服务在最近一次服务时被写入所述数据上报服务所在文件的各函数的第一链接地址；所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址；数据标识获取单元，用于若确定所述崩溃信息中存在至少一个函数地址属于所述第一链接地址，则获取在所述应用最近一次服务发生异常时所述数据上报服务对数据进行读发的数据标识；处理单元，用于删除所述数据标识对应的异常数据。

第三方面，本申请实施例提供了一种计算设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行如第一方面任一实现方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如第一方面任一实现方法。

附图说明

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

图1为本申请实施例提供的一种系统架构的示意图；

图2为本申请实施例提供的一种数据异常检测方法的示意图；

图3为本申请实施例提供的一种双线程发送数据的示意图；

图4为本申请实施例提供的一种双线程发送数据的示意图；

图5为本申请实施例提供的一种双线程发送数据的示意图；

图6为本申请实施例提供的一种数据发送示意图；

图7为本申请实施例提供的一种双线程发送数据的示意图；

图8为本申请实施例提供的一种数据上报服务的示意图；

图9为本申请实施例提供的一种计算设备。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

目前，应用程序的开发商为了不断优化所开发的应用程序带给用户的体验，其可以在应用程序中同时配置一项数据上报服务，该项服务用户无感知，主要用于采集用户对应用程序中的其他各项服务进行使用时的用户行为数据，并将所采集的用户行为数据发送至应用程序对应的服务器，从而应用程序的开发商可以从服务器中获取到各用户的用户行为数据，如此应用程序的开发商可以基于所获取的用户行为数据来对应用程序中的各项服务进行数据分析，确定相应的服务优化方案。

目前而言，应用程序中的非数据上报服务的其他各项服务中的任一项服务在检测到用户的行为满足该项服务预先设定的可进行数据上报的数据上报要求后，可对用户的行为数据进行采集并将其发送给应用程序中的数据上报服务；相应的，数据上报服务可以接收到用户行为数据，并在接收到用户行为数据后直接将其上传至服务器。然而该种数据上报方式在弱网条件下容易导致数据丢失，即服务器最终获取到的用户行为数据往往并不完整，这样一来将会导致所确定的服务优化方案也并非是最优的，也即并不能将用户体验真的进行提升。

针对该问题，本申请提供一种数据上报的系统架构。如图1所示，为本申请实施例提供的一种系统架构的示意图，该架构中包括终端110和服务器120。其中，终端110可以为手机、电脑、iPad等智能设备；终端110中可以安装各种各样的应用程序，每一个应用程序对应一个为该应用程序提供服务的服务器。作为示例，图1中示出终端110中安装有2个应用程序，分别为应用程序1和应用程序2；相应的，图1中示出的服务器120的数目为2，分别为服务器1201和服务器1202，其中，服务器1201用于向终端110中的应用程序1提供服务，服务器1202用于向终端中的应用程序2提供服务。说明的是，服务器1201可以为一台独立的服务器，也可以为由多台服务器搭建而成的服务器集群，服务器1202可以为一台独立的服务器，也可以为由多台服务器搭建而成的服务器集群，本申请对此不做限定。

可选的，终端110中设置有永久性数据存储区域。作为示例，图1中示出终端110包括1个本地数据库3。

在数据上报场景下，作为示例，继续令图1所示的终端110中的应用程序1包括2项服务，分别为服务1和服务2。可选的，服务1可以为数据上报服务，其可以用于对应用程序1中的非数据上报服务的其他各项服务产生的用户行为数据进行上报；可选的，服务2可以为应用程序1中的非数据上报服务的一个服务，如此服务1(即数据上报服务)可以用于对服务2产生的用户行为数据进行上报。

基于图1所示的数据上报的系统架构，本申请实施例提供一种数据上报方法，具体如下：

首先，终端110中的应用程序1中的服务1在接收到服务2产生并发送的用户行为数据后，可将接收到的用户行为数据存储在终端110的本地数据库3中；接着，在服务1需要对用户行为数据进行上报时，其可以从本地数据库3中读取数据并发送至服务器1201；最后，当服务1接收到服务器1201返回的成功响应报文后，服务1可以从本地数据库3中对应删除该已上报数据。其中，服务1需要对用户行为数据进行上报的条件可以是服务1主动向服务器1201上报本地数据库3中存储的用户行为数据，具体又可包括服务1周期性的上报数据和实时上报数据两种情况，也可以是在服务1接收到服务器1201发出的数据获取请求后而向服务器1201进行发送的，本申请对此不做限定。

显然，上述本申请实施例提供的先进行数据存储后进行数据上报的数据上报方式可以保证数据百分百被发送。然而，该种数据上报方式存在一些安全隐患。例如如果本地数据库3被侵入方破解，并在当中写入脏数据，那么可能会导致服务1在其提供服务的某一个时刻因为读取到无法被解码、解析的脏数据、而使得应用程序1发生崩溃并被强制退出的恶劣结果。

针对上述本申请实施例提供的数据上报方式可能存在安全隐患的问题，本申请实施例为此可以提供一种数据异常检测方法，该方法可以用于对异常数据进行捕获并清理，实现一种安全兜底。如图2所示，为本申请实施例提供的一种数据异常检测方法的示意图，该方法可以由图1所示的服务1，即数据上报服务予以执行，该方法包括以下步骤：

步骤201，数据上报服务在启动后获取所在应用的历史服务信息。

在本步骤中，终端中的任一应用可包括数据上报服务；其中，数据上报服务可用于对它所在应用中的非数据上报服务的其他各项服务产生并发送的数据在终端本地的数据库进行存储并按需上报至其所在应用对应的服务器。数据上报服务在每次启动后，可以自我检测其所在应用历史最近一次的退出是否是由于自己读取到脏数据而使其被强制退出的；对此，数据上报服务首先可在启动后获取所在应用的历史服务信息，进行可根据所获取的历史服务信息进行检测。

终端中的应用在每次退出之前，可以对自己本次提供服务时的状态做一个记录，该记录即为服务信息。其中，服务信息的内容可以包括应用在本次的退出是属于正常退出还是因为遭遇异常而被动退出的结论性意见。其中，可通过下述两种方式对服务信息进行记录：

方式1，直接记录。

若终端中的应用某次退出是属于正常退出，则本次的服务信息可以被记录为应用属于正常退出；若终端中的应用某次退出是属于被动退出，则本次的服务信息可以被记录为应用属于异常退出，并同时记录应用被动退出当时该应用下所运行的各函数对应的地址信息。

方式2，标识位记录。

若终端中的应用某次退出是属于正常退出，则可以不对本次的服务信息进行任何记录，即默认不记录任何服务信息这一行为就表示应用本次的退出属于正常退出；若终端中的应用某次退出是属于异常退出，则可以直接记录应用被动退出当时该应用下所运行的各函数对应的地址信息。

步骤202，所述数据上报服务若确定所述历史服务信息中包括崩溃信息，则确定所述数据上报服务在最近一次服务时被写入所述数据上报服务所在文件的各函数的第一链接地址。

其中，所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址，也即终端中的应用在遭遇异常退出时而被记录下来的该应用当时所运行的各函数对应的地址信息即为崩溃信息。

在本步骤中，在数据上报服务获取到历史服务信息后，可对历史服务信息中是否包含崩溃信息进行检查。若确定历史服务信息中包括崩溃信息，则数据上报服务可以确定其所在应用最近一次的退出是由于服务发生异常导致的，对此情况，数据上报服务可以获取第一链接地址；若确定历史服务信息中不包括崩溃信息，则数据上报服务可以确定其所在应用最近一次的退出是由用户主动发起的正常退出，对此情况，数据上报服务将可以直接投入使用。

其中，第一链接地址是数据上报服务在最近一次提供服务时被终端的系统分配的用于写入数据上报服务所在文件具有的各函数的地址段。

例如，以终端的操作系统为iOS系统为例，对第一链接地址进行说明。iOS系统从4.3版本即开始引入了地址空间配置随机加载(ASLR)技术，其主要通过对堆、栈、共享库映射等线性区布局的随机化，以增加攻击目的地址的难度。因此，当本申请实施例的数据上报服务所在的应用为安装在以iOS系统作为操作系统的终端上时，则在定位数据上报服务启动时需要加载的内存地址时，一方面需要找到文件加载到终端运行内存的地址，以及还需要找到ASLR随机产生的偏移地址。有了上面的定位函数地址方法后，接下来可以定位数据上报服务启动时需要加载的地址段了。由于文件的编译顺序可以通过修改Compile Source内容来实现，所以需要保证函数所在的文件在Compile Source首尾。如此，在数据上报服务启动时根据上述方法，则可以得到文件地址及ASLR随机产生的偏移地址，比如得到的首地址为b_address＝0x104ec384c，尾地址为e_address＝0x104edcb78，从而自首地址到尾地址之间的各函数地址即为第一链接地址。在得到第一链接地址之后，就需要进行本地持久化了，持久化可以通过写内存或者写文件的方式实现，iOS系统可以使用内部数据接口NSUserDefault来缓存第一链接地址，但是NSUserDetault在内存不足时会自动清理一些数据，即写内存的方式存在数据丢失的可能。为此，通过写文件的方式则可以避免第一链接地址被自动清理，比如通过iOS系统提供的NSFileManager，在写入前先进行检查，如果本地数据库没有该文件(该文件指的是用于写数据上报服务运行时需要占用的终端内存的文件)，则创建一个文本文件，接着通过NSFileHandle进行文本覆盖写入，如果本地数据有该文件，在直接通过NSFileHandle进行文本覆盖写入。

步骤203，所述数据上报服务若确定所述崩溃信息中存在至少一个函数地址属于所述第一链接地址，则获取在所述应用最近一次服务发生异常时所述数据上报服务对数据进行读发的数据标识。

在本步骤中，在数据上报服务确定历史服务信息中含有崩溃信息时，可以将崩溃信息中的各函数地址与第一链接地址进行比较，以确定崩溃信息中是否存在至少一个函数地址属于第一链接地址。若数据上报服务确定崩溃信息中存在至少一个函数地址属于第一链接地址，则数据上报服务可以确定其所在应用历史最近一次服务发生异常、导致退出的原因至少有自己一部分因素，原因在于数据上报服务在进行数据上报时读取到了脏数据，而使得数据上报服务所在的应用服务发生异常并被退出。对此，数据上报服务可在确定崩溃信息中存在至少一个函数地址属于第一链接地址时，可以获取其所在应用服务发生异常时自己对数据进行读发的数据标识，该数据标识对应的数据即为数据上报服务所读取的脏数据，也正是由于数据上报服务读取到了该脏数据，才使得数据上报服务所在应用发生异常而被退出。

步骤204，所述数据上报服务删除所述数据标识对应的异常数据。

在本步骤中，在数据上报服务获取到它所在的应用最近一次服务发生异常时自己正在进行读发的数据的数据标识时，则数据上报服务可以凭借该数据标识找到该数据标识对应的数据并将其删除，从而本次数据上报服务在读发数据至服务器时将不会因为再次读到该脏数据而使得它所在的应用发生崩溃而被退出了。

上述方案中，每次数据上报服务在启动时，它可以读取它所在应用的历史服务信息以确定当中是否含有崩溃信息；如果有，则可获取第一链接地址，并将崩溃信息中的各函数地址与第一链接地址进行匹配，如果确定崩溃信息中存在至少一个函数地址属于第一链接地址，则数据上报服务可以确定上一次应用发生服务异常是由于数据上报服务读取到有问题的数据(即脏数据)所导致的，进而数据上报服务可以根据应用在上一次发生服务异常时、数据上报服务当前正在进行读发的数据的数据标识获取到对应的数据并删除该数据，从而后续在使用数据上报服务时就不会受此条脏数据的影响了。通过该方式可以有效检测终端的本地数据库中是否被写入了脏数据，该脏数据在被数据上报服务读取到后将使得数据上报服务所在的应用发生崩溃，并在确定被写入脏数据时对脏数据进行删除，从而可以有效避免数据上报服务因为再次读取到同一脏数据而导致的应用崩溃问题。

以下将结合示例分别对上述一些步骤进行详细说明。

在上述步骤202的一个实施中，所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址，包括：所述数据上报服务在前置层注册所述应用的异常通知服务；所述数据上报服务在接收到所述前置层发送的异常通知后，对所述应用当前运行的各函数地址进行记录；所述异常通知是在监测到发生各异常监听事件时发出的。

例如，为了获取应用崩溃信息，就需要捕获应用在崩溃时抛出的异常。基于终端采用iOS系统作为操作系统的场景，设数据上报服务所在应用服务发生异常时，可通过以下三种类型的异常进行表现，分别是BSD层异常、Mach层异常、以及原生Exception。

可选的，一种捕获应用在崩溃时抛出的异常的方式为数据上报服务向终端注册signal_handler_callback回调。

例如，对于BSD层的异常，数据上报服务可注册系统提供的SIGABRT、SIGBUS、SIGFPE、SIGILL、SIGSEGV、SIGTRAP六种信号，通过signal_handler_callback回调处理异常情况；对于Mach层，数据上报服务可注册系统提供的EXC_BAD_ACCESS、EXC_BAD_INSTRUCTION、EXC_SOFTWARE三种信号，通过signal_handler_callback回调处理异常情况；对于原生Exception，数据上报服务可通过设置NSSetUncaughtExceptionHandler()这一监听事件，即可对原生Exception可能发生的异常进行监听。

可选的，一种捕获应用在崩溃时抛出的异常的方式为通过前置层进行异常通知转发。

由于handler注册存在覆盖的风险，当其他服务也注册了callback时，会导致在它前面的服务所设置的callback失效。为了避免这种情况，可通过hook在注册callback时设置前置层，前置层有唯一监听，外部设置时不会走到实际callback处，前置层可对所有注册callback事件的服务进行记录，当异常发生时，逐一通知记录在册的各服务，这样就可以避免注册被覆盖的问题了。

本申请实施例中，数据上报服务为了能够及时捕获到它所在应用服务发生异常时的通知，以便于它根据该通知获取应用当前正在运行的各函数的地址信息，数据上报服务可以在前置层中对自己进行注册；从而当系统抛出应用发生服务异常的通知时，该通知可以被前置层接收到，前置层可以向记录在册各服务发送该通知；相应的，数据上报服务可捕获到前置层抛出的通知，立刻获取当前所有的线程以及堆栈并持久化存储。其中，数据上报服务所获取的当前所有的线程以及堆栈即为崩溃信息。

可以理解的是，在数据上报服务根据前置层发送的异常通知来对它所在应用当前运行的各函数地址进行记录的同时，数据上报服务还将对它当前正在进行读取的数据的数据标识进行持久化存储。其中，所存储的数据标识，在数据上报服务识别出崩溃信息中存在至少一个函数地址属于第一链接地址时，可以凭借该数据标识读取对应的异常数据并进行删除。

在上述步骤204的一个实施中，所述数据上报服务将所述异常数据更新至异常数据临时库；所述异常数据临时库用于所述应用对待写入数据进行验证；所述数据上报服务根据所述异常数据更新服务端的异常数据持久库；所述异常数据持久库用于所述应用更新所述异常数据临时库。

例如，由于外部传入数据对于数据上报服务内部逻辑来说具有不确定性，如果业务的数据是固定的，一次清理并不能解决问题，因为相同的路径会产生相同的数据，为此可建立一套异常学习保护机制，以避免已经被数据上报服务识别为异常数据的数据再次传入时又被写入到终端的本地数据库中。

对此，本申请实施例中数据上报服务一方面可在本地建立一个异常数据临时库，用于存储本次以及历史期间由自己识别出的各异常数据，从而可依据其对每次传入的数据进行校验，如果匹配成功，则直接将数据丢弃，避免走入后续流程。例如，当应用崩溃再次启动时，数据上报服务获取到异常数据之后，可对异常数据做md5，并将计算的md5存入本地数据库，这样可以对之后传入的每条数据做相同校验，可以迅速避免相同问题二次异常。

另一方面，本申请实施例中可以通过数据上报服务所在应用对应的服务器设置一个异常数据持久库，用于接收各个终端中数据上报服务反馈的异常数据并持久化存储，如此在应用崩溃再次启动时，数据上报服务可以从服务器获取全量的异常数据，据此对本地的异常数据临时库进行更新，从而可以保证应用可在很大程度上避免某一异常数据的二次写入。例如，当应用崩溃再次启动时，数据上报服务获取到异常数据之后，在对异常数据做md5的同时，还会对经过md5处理得到的数据进行base64编码，然后上报到服务器，其中，base64可以确保异常字段被编码为合规字符串。在服务器拿到数据后，对其做base64解码，获取原数据，定位到其中导致异常的字符，并将其更新到本地的异常数据持久库中，在每次数据上报服务启动时，通过拉取服务器中的异常数据持久库中的全量数据，更新本地库，对每次传入的数据做正则校验，如果命中则直接丢弃，这样就可以避免由于相同的原因而导致应用多次异常。

在本申请的某些实施中，所述数据上报服务设置有第一数目的数据写入线程和第二数目的数据读发线程；任一数据写入线程用于将接收到的待写入数据写入数据写入标识指示的存储位置并更新所述数据写入标识，任一数据读发线程用于根据数据读发标识从对应的存储位置读取待发送数据发送至服务端并更新所述数据读发标识，所述第二数目大于所述第一数目。

诚如本申请实施例前述例子中所提供的先进行数据存储后进行数据上报的数据上报方式可以具有数据百分百被发送的效果，本申请实施例仍可进一步对该种数据上报方式进行优化。比如，为了提升数据发送的效率，本申请实施例中可以将数据读发线程的数目(即第二数目)设置的比数据写入线程的数目(即第一数目)多一些。例如，本申请实施例中可以设置一个数据写入线程和两个数据读发线程为例，阐述数据的发送过程。其中，令一个数据写入线程为w1，两个数据读发线程分别为s1和s2。

如图3所示，为本申请实施例提供的一种双线程发送数据的示意图。其中，w1当前需要写入的数据为数据3，位于数据3之前的数据1和数据2为准备发送的数据。s1、s2双线程发送数据的过程中，在s1、s2同时处理同一数据时，将会导致数据重复发送，且删除数据时由于数据可能已经不存在而导致异常。为此，需要引入数据读发标识sid以及数据写入标识wid，s1、s2根据数据读发标识做顺序读取、发送操作，并在每次执行读取、发送数据这一操作之前，先将数据读发标识增加1，这样就可以避免数据的重复访问。如在图3中，当前的数据读发标识sid为2，在s1完成对数据1的读取、发送操作之后，需要操作的数据读发标识sid为3。

在本申请的某些实施中，所述数据上报服务设置数据栈；所述数据栈用于记录已读发数据在数据存储队列中的存储位置标识；所述数据上报服务接收到各待写入数据后，按照所述数据栈指示的各存储位置标识在所述数据存储队列中逐一对应写入，直至清空所述数据栈。

在本申请的某些实施中，所述数据上报服务若确定所述数据写入标识小于所述数据读发标识，则通过所述数据读发线程、按照从头到尾的顺序，对所述数据存储队列中的各待读发数据依序进行数据读发处理。

接着前述的使用一个数据写入线程(w1)对数据进行写入以及使用两个数据读发线程(s1和s2)对数据进行读取、发送的例子，该方式在对数据进行读发时，一个容易出现的问题为，当有数据发送失败，下次发送就要等到数据上报服务再次启动时才能进行，因为失败的sid已经被跳过了，sid只会进行加1，单次生命周期内无法二次访问；另一个问题就是随着进程的向前运行，数据存储队列中会产生许多空缺，这指示着在读发线程对已经被开辟出来的存储区域中的存储数据发送后，该存储区域无法被二次使用，也即内存的使用效率非常低。

如图4所示，为本申请实施例提供的一种双线程发送数据的示意图，结合图3，数据存储队列中的位置1(按照从上往下的顺序，位置依次增大)对应的数据1已经被成功发送了，同时当前的数据写入标识wid为4，也即数据存储队列中的位置1已经被空出来，此外数据存储队列中的位置2对应的数据2被发送失败，也无法再次被访问了。

为了解决上述数据发送过程中存在的内存使用效率低的问题，如图5所示，为本申请实施例提供的一种双线程发送数据的示意图，其中，图5中的(a)图表示数据的写入、读发过程，图5中的(b)图表示一个数据栈(stack)，该数据栈用来存储已经发送完成的数据在数据存储队列中的位置标识，每次数据插入时，先弹出栈顶位置标识，以进行数据的插入，直到栈顶无数据，再进行根据wid进行插入，这样可以保证单位内存的重复使用，提高使用效率。例如，在图5中，数据存储队列中的位置1上的数据1先于数据位置3数据3被发送出去，因此，可将位置1对应的位置标识“1”置于数据栈的栈底，位置3对应的位置标识“3”被置于数据栈的栈顶，从而w1在写完数据4后，准备写数据5时，可先从数据栈中取出栈顶数据“3”这一位置标识，然后在数据存储队列中的位置3中写入数据5，接着从数据栈中取出栈顶数据“1”这一位置标识，然后在数据存储队列中的位置1中写入数据6。当有数据继续插入时，重复上述操作，直到数据栈被清空，w1重新指向wid。如图6所示，为本申请实施例提供的一种数据发送示意图，当w1在数据存储队列中的位置1写入数据6后，此时数据詹被清空了，则w1重新开发出数据存储队列中的位置5用于写入数据7，并在数据7写入后，w1重新开发出数据存储队列中的位置6用于写入数据8。如此，通过数据栈用于存储已经空出来的数据存储队列中的位置的位置标识，可使内存使用率提高。

为了解决上述数据发送过程中数据存储队列中靠前位置上的数据进行发送的问题，本申请实施例中可以采用循环发送的方法，当sid>wid时，说明当前数据读发线程已经取到数据存储队列末尾的数据了，这个时候，将sid指数据存储队列头部，从头开始取，就能使发送失败的数据以及新插入复用内存的数据得以发送。如图7所示，为本申请实施例提供的一种双线程发送数据的示意图，其中，结合图6，s2首先发送了数据存储队列中的位置5中的数据4，随后s1发送了数据存储队列中的位置5中的数据7，因此数据栈中栈底数据为位置4对应的位置标识“4”，栈顶数据为位置7对应的位置标识“7”，w1在数据存储队列中的位置6写入数据8后，暂时无新的数据需要写入，即wid为8，此时s2用于发送数据存储队列中的位置6中的数据8，则在s2发送数据8之前，s2将下一待读发数据的标识sid进行了加1，即sid为9，此时由于sid>wid了，从而，s1用于从数据存储队列的头部开始重新读发数据，即s1用于读取sid为9的、位于数据存储队列中的位置1的数据6。

在本申请的某些实施中，所述数据上报服务向所述应用发送指示信息；所述指示信息用于指示所述应用注册读发数据拦截服务，所述读发数据拦截服务用于在检测到所述应用退出时对当前读发数据进行拦截。

关于数据的发送过程，还可以使用重复率这一指标对其进行评价。比如，上述例子中描述的先进行数据存储后进行数据上报的数据上报方式还存在一个问题，就是数据在上传服务器之后，要收到发送成功的回调，该数据才能被删除，否则该数据还将会被重发。数据重发这种情况在用户对应用进行使用期间遭遇被动退出应用的时候容易出现，当数据还在发送的流程中时，被动退出应用之后，应用就无法收到响应的报文。这里有三种状况。第一种，数据还在发送流程中，在用户层。第二种，数据过了用户层，组成请求体，到了系统层。第三种，数据已经由系统层发出。本申请实施例中针对第一种和第二种情况进行拦截。针对第一种情况可以通过注册进程即将退出的通知，在退出之前，将请求拦截。针对第二种已经进入到系统级的请求，可以通过系统提供的网关对任务进行取消，撤回请求。

基于同样的构思，本申请实施例提供一种数据上报服务，如图8所示，为本申请实施例提供的一种数据上报服务的示意图，该数据上报服务包括历史服务信息获取单元801、第一链接地址获取单元802、数据标识获取单元803和处理单元804；

历史服务信息获取单元801，用于在启动后获取所在应用的历史服务信息；

第一链接地址获取单元802，用于若确定所述历史服务信息中包括崩溃信息，则确定所述数据上报服务在最近一次服务时被写入所述数据上报服务所在文件的各函数的第一链接地址；所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址；

数据标识获取单元803，用于若确定所述崩溃信息中存在至少一个函数地址属于所述第一链接地址，则获取在所述应用最近一次服务发生异常时所述数据上报服务对数据进行读发的数据标识；

处理单元804，用于删除所述数据标识对应的异常数据。

进一步的，对于该数据上报服务，第一链接地址获取单元802，还用于在前置层注册所述应用的异常通知服务；在接收到所述前置层发送的异常通知后，对所述应用当前运行的各函数地址进行记录，所述异常通知是在监测到发生各异常监听事件时发出的。

进一步的，对于该数据上报服务，还包括更新单元805；更新单元805，用于：将所述异常数据更新至异常数据临时库；所述异常数据临时库用于所述应用对待写入数据进行验证；根据所述异常数据更新服务端的异常数据持久库；所述异常数据持久库用于所述应用更新所述异常数据临时库。

进一步的，对于该数据上报服务，还包括发送单元806；发送单元806，用于：向所述应用发送指示信息；所述指示信息用于指示所述应用注册读发数据拦截服务，所述读发数据拦截服务用于在检测到所述应用退出时对当前读发数据进行拦截。

进一步的，对于该数据上报服务，所述数据上报服务设置有第一数目的数据写入线程和第二数目的数据读发线程；任一数据写入线程用于将接收到的待写入数据写入所述第一链接地址中数据写入标识对应的存储区并更新所述数据写入标识，任一数据读发线程用于从所述第一链接地址中数据读发标识对应的存储区读取发送数据至服务端并更新所述数据读发标识，所述第二数目大于所述第一数目。

进一步的，对于该数据上报服务，还包括数据栈设置单元807；数据栈设置单元807，用于：设置数据栈；所述数据栈用于记录已读发数据在所述第一链接地址中数据存储队列中的存储位置标识；处理单元804，还用于：接收到各待写入数据后，按照所述数据栈指示的各存储位置标识在所述数据存储队列中逐一对应写入，直至清空所述数据栈。

进一步的，对于该数据上报服务，处理单元804，还用于：若确定所述数据写入标识小于所述数据读发标识，则通过所述数据读发线程、按照从头到尾的顺序，对所述数据存储队列中的各待读发数据依序进行数据读发处理。

本申请实施例还提供了一种计算设备，该计算设备具体可以为桌面计算机、便携式计算机、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)等。该计算设备可以包括中央处理器(Center Processing Unit，CPU)、存储器、输入/输出设备等，输入设备可以包括键盘、鼠标、触摸屏等，输出设备可以包括显示设备，如液晶显示器(Liquid Crystal Display，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。

存储器，可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器提供存储器中存储的程序指令和数据。在本申请实施例中，存储器可以用于存储数据异常检测方法的程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行数据异常检测方法。

如图9所示，为本申请实施例提供的一种计算设备的示意图，该计算设备包括：

处理器901、存储器902、收发器903、总线接口904；其中，处理器901、存储器902与收发器903之间通过总线905连接；

所述处理器901，用于读取所述存储器902中的程序，执行上述数据异常检测方法；

处理器901可以是中央处理器(central processing unit，简称CPU)，网络处理器(network processor，简称NP)或者CPU和NP的组合。还可以是硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，简称ASIC)，可编程逻辑器件(programmable logic device，简称PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，简称CPLD)，现场可编程逻辑门阵列(field-programmable gate array，简称FPGA)，通用阵列逻辑(generic array logic,简称GAL)或其任意组合。

所述存储器902，用于存储一个或多个可执行程序，可以存储所述处理器901在执行操作时所使用的数据。

具体地，程序可以包括程序代码，程序代码包括计算机操作指令。存储器902可以包括易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，简称RAM)；存储器902也可以包括非易失性存储器(non-volatile memory)，例如快闪存储器(flash memory)，硬盘(hard disk drive，简称HDD)或固态硬盘(solid-state drive，简称SSD)；存储器902还可以包括上述种类的存储器的组合。

存储器902存储了如下的元素，可执行模块或者数据结构，或者它们的子集，或者它们的扩展集：

操作指令：包括各种操作指令，用于实现各种操作。

操作系统：包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

总线905可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

总线接口904可以为有线通信接入口，无线总线接口或其组合，其中，有线总线接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线总线接口可以为WLAN接口。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行数据异常检测方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种数据异常检测方法，其特征在于，包括：

数据上报服务在启动后获取所在应用的历史服务信息；

所述数据上报服务若确定所述历史服务信息中包括崩溃信息，则确定所述数据上报服务在最近一次服务时被写入所述数据上报服务所在文件的各函数的第一链接地址；所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址；

所述数据上报服务若确定所述崩溃信息中存在至少一个函数地址属于所述第一链接地址，则获取在所述应用最近一次服务发生异常时所述数据上报服务对数据进行读发的数据标识；

所述数据上报服务删除所述数据标识对应的异常数据。

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

所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址，包括：

所述数据上报服务在前置层注册所述应用的异常通知服务；

所述数据上报服务在接收到所述前置层发送的异常通知后，对所述应用当前运行的各函数地址进行记录；所述异常通知是在监测到发生各异常监听事件时发出的。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述数据上报服务将所述异常数据更新至异常数据临时库；所述异常数据临时库用于所述应用对待写入数据进行验证；

所述数据上报服务根据所述异常数据更新服务端的异常数据持久库；所述异常数据持久库用于所述应用更新所述异常数据临时库。

4.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述数据上报服务向所述应用发送指示信息；所述指示信息用于指示所述应用注册读发数据拦截服务，所述读发数据拦截服务用于在检测到所述应用退出时对当前读发数据进行拦截。

5.如权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

所述数据上报服务设置有第一数目的数据写入线程和第二数目的数据读发线程；任一数据写入线程用于将接收到的待写入数据写入数据写入标识指示的存储位置并更新所述数据写入标识，任一数据读发线程用于根据数据读发标识从对应的存储位置读取待发送数据发送至服务端并更新所述数据读发标识，所述第二数目大于所述第一数目。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

所述数据上报服务设置数据栈；所述数据栈用于记录已读发数据在数据存储队列中的存储位置标识；

所述数据上报服务接收到各待写入数据后，按照所述数据栈指示的各存储位置标识在所述数据存储队列中逐一对应写入，直至清空所述数据栈。

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

所述数据上报服务若确定所述数据写入标识小于所述数据读发标识，则通过所述数据读发线程、按照从头到尾的顺序，对所述数据存储队列中的各待读发数据依序进行数据读发处理。

8.一种数据上报服务，其特征在于，包括：

历史服务信息获取单元，用于在启动后获取所在应用的历史服务信息；

第一链接地址获取单元，用于若确定所述历史服务信息中包括崩溃信息，则确定所述数据上报服务在最近一次服务时被写入所述数据上报服务所在文件的各函数的第一链接地址；所述崩溃信息是在所述应用最近一次服务发生异常时记录的各函数地址；

数据标识获取单元，用于若确定所述崩溃信息中存在至少一个函数地址属于所述第一链接地址，则获取在所述应用最近一次服务发生异常时所述数据上报服务对数据进行读发的数据标识；

处理单元，用于删除所述数据标识对应的数据。

9.一种计算机设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如权利要求1-7任一项所述的方法。

Images