交互数据处理方法及装置与流程

本发明涉及计算机领域，尤其是涉及一种交互数据处理方法及装置。

背景技术：

交互数据在后台处理时，前端页面会处于锁死状态，特别是系统处于交互数据的高并发状态下，前端页面很可能会出现等待超时，从而导致交互数据处理失败，此外，系统后台也可能出现数据库、应用等雪崩的情况。

技术实现要素：

本发明的目的在于提供一种交互数据处理方法及装置。

为实现上述发明目的之一，本发明一实施方式提供了一种交互数据处理方法，所述方法包括：

判断系统内交互数据的频率和/或流量是否超出预设的安全区间；

若判断结果为是，则先将交互数据存储为后台数据，并在交互数据的频率和/或流量小于预设阈值时，再读取所述后台数据进行处理；若判断结果为否，则实时地处理所述交互数据。

作为本发明一实施方式的进一步改进，所述判断系统内交互数据的频率和/或流量是否超出预设的安全区间，具体包括：

判断产生交互数据的账户类型；

若产生交互数据的账户类型为第一类账户，则实时地处理所述交互数据；

若产生交互数据的账户类型为第二类账户，则判断系统内交互数据的频率和/或流量是否超过预设的安全区间；

其中，所述第一类账户对交互数据处理的实时性要求高于所述第二类账户。

作为本发明一实施方式的进一步改进，所述方法还包括：

若产生交互数据的账户类型为第三类账户，则将交互数据存储为后台数据，并在预定周期结束时对所述后台数据进行处理；

其中，所述第二类账户对交互数据处理的实时性要求高于第三类账户。

作为本发明一实施方式的进一步改进，所述第一类账户为买家账户，所述第二类账户为卖家账户，所述第三类账户为支付平台账户。

作为本发明一实施方式的进一步改进，所述交互数据为记账明细数据，所述方法还包括：

在交互数据过程中，将与产生所述交互数据相应账户的账户信息加载至内存中，并根据所述交互数据实时地更新所述账户信息中的余额信息。

作为本发明一实施方式的进一步改进，所述判断系统内交互数据的频率和/或流量是否超出预设的安全区间，具体包括：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务，则实时地处理所述交互数据；

若所述交互数据对应的业务类型为账户收入业务，则判断所述账户支出业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则判断系统内交互数据的频率和/或流量是否超过预设的安全区间。

作为本发明一实施方式的进一步改进，所述判断系统内交互数据的频率和/或流量是否超出预设的安全区间，具体包括：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务，则实时地处理所述交互数据；

若所述交互数据在指定时间区间内产生，且所述交互数据对应的业务类型为账户收入业务，则判断所述账户支出业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则判断系统内交互数据的频率和/或流量是否超过预设的安全区间。

作为本发明一实施方式的进一步改进，所述判断系统内交互数据的频率和/或流量是否超出预设的安全区间，具体包括：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务，则实时地处理所述交互数据；

若所述交互数据在指定时间区间内产生，且所述交互数据对应的业务类型为账户收入业务，则判断系统内交互数据的频率和/或流量是否超过预设的安全区间。。

为实现上述发明目的之一，本发明一实施方式提供了一种交互数据处理装置，所述装置包括：

计算模块，用于判断系统内交互数据的频率和/或流量是否超出预设的安全区间；

处理模块，用于若系统内交互数据的频率和/或流量是超出预设的安全区间，则先将交互数据存储为后台数据，并在交互数据的频率和/或流量小于预设阈值时，再读取所述后台数据进行处理；若系统内交互数据的频率和/或流量未超出预设的安全区间，则实时地处理所述交互数据。

作为本发明一实施方式的进一步改进，所述处理模块用于：

判断产生交互数据的账户类型；

若产生交互数据的账户类型为第一类账户，则实时地处理所述交互数据；

若产生交互数据的账户类型为第二类账户，则通过计算模块判断系统内交互数据的频率和/或流量是否超过预设的安全区间；

其中，所述第一类账户对交互数据处理的实时性要求高于所述第二类账户。

作为本发明一实施方式的进一步改进，所述处理模块还用于：

若产生交互数据的账户类型为第三类账户，则将交互数据存储为后台数据，并在预定周期结束时对所述后台数据进行处理；

其中，所述第二类账户对交互数据处理的实时性要求高于第三类账户。

作为本发明一实施方式的进一步改进，所述第一类账户为买家账户，所述 第二类账户为卖家账户，所述第三类账户为支付平台账户。

作为本发明一实施方式的进一步改进，所述交互数据为记账明细数据，所述处理模块还用于：

在交互数据过程中，将与产生所述交互数据相应账户的账户信息加载至内存中，并根据所述交互数据实时地更新所述账户信息中的余额信息。

作为本发明一实施方式的进一步改进，所述处理模块还用于：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务，则实时地处理所述交互数据；

若所述交互数据对应的业务类型为账户收入业务，则判断所述账户支出业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则通过计算模块判断系统内交互数据的频率和/或流量是否超过预设的安全区间。

作为本发明一实施方式的进一步改进，所述处理模块还用于：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务，则实时地处理所述交互数据；

若所述交互数据在指定时间区间内产生，且所述交互数据对应的业务类型为账户收入业务，则判断所述账户支出业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则通过计算模块判断系统内交互数据的频率和/或流量是否超过预设的安全区间。

作为本发明一实施方式的进一步改进，所述处理模块还用于：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务，则实时地处理所述交互数据；

若所述交互数据在指定时间区间内产生，且所述交互数据对应的业务类型为账户收入业务，则通过计算模块判断系统内交互数据的频率和/或流量是否超 过预设的安全区间。

相对于现有技术，本发明的技术效果在于：本发明根据系统内交互数据的具体情况，对不同情况下的交互数据采用不同的处理方式，避免在交互数据高并发状态下，出现的交互数据处理失败，系统后台雪崩等情况。

附图说明

图1是本发明一实施方式中交互数据处理方法的流程图；

图2是本发明一实施方式中交互数据处理装置的模块图。

具体实施方式

以下将结合附图所示的具体实施方式对本发明进行详细描述。但这些实施方式并不限制本发明，本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本发明的保护范围内。

为方便理解本发明的技术方案，以下将以在支付平台下的业务场景举例说明，在该业务场景下，其交互数据为记账明细数据，某账户的记账明细数据可经过计算处理后获得准确的账户余额。当然，本发明的交互数据处理方法及装置的应用场景可不局限于支付平台。

目前在支付平台下常用的记账方式都是实时记账，即用户在做相应业务(比如:充值，支付，转账，放款、收帐)时，实时地处理记账明细数据，并根据处理后的记账明细数据更新相关账户的账户余额。

然而，在记账明细数据的高并发情况下(例如大规模促销、双十一、双十二、黑色星期五等均可能导致记账明细数据的高并发)，上述处理记账明细数据的方式会引发大量的等待超时、业务处理失败问题，严重的甚至导致数据库、应用等雪崩。

如图1所示，在本发明一实施方式中，所述交互数据处理方法包括：

S1、判断系统内交互数据的频率和/或流量是否超出预设的安全区间；

S2、若判断结果为是，则先将交互数据存储为后台数据，并在交互数 据的频率和/或流量小于预设阈值时，再读取所述后台数据进行处理；若判断结果为否，则实时地处理所述交互数据。

在本发明一实施方式中，通过判断产生交互数据的账户类型，对账户类型进行区分，以根据不同的账户类型对记账明细数据处理要求的实时性和记账明细数据量，采用不同的处理方式。在本实施方式中，账户类型包括第一类账户、第二类账户和第三类账户。其中，所述第一类账户对数据处理要求的实时性较高，例如买家账户，所述第二类账户对数据处理要求的实时性较低，例如卖家账户，所述第三类账户对数据处理要求的实时性更低，例如支付平台账户。即是，所述第一类账户对交互数据处理的实时性要求高于所述第二类账户；所述第二类账户对交互数据处理的实时性要求高于所述第三类账户。

对每种账户类型的处理方式将在下述一一进行详细介绍。

对于账户类型为第一类账户，由于买家账户的特性，买家对记账明细数据处理要求的实时性很高，希望能够在业务处理过程中实时看到自己的余额变化，例如，用户充值100美元后希望马上可以查看到自己的账户余额里多了100美元，并且通常对于买家账户而言，其需要处理的记账明细数据量也较少。对于此类型账户，可以实时地处理所述记账明细数据。

对于账户类型为第二类账户，由于卖家账户特性，卖家对记账明细数据处理要求的实时性比买家要低，卖家账户一般不会实时的关注账户余额，另外，对于卖家账户，其需要处理的记账明细数据量也较大，这种账户类型的交互数据是产生记账明细数据的高并发的主要部分，尤其是在大规模促销、双11、双12、黑色星期五等情况。

对于账户类型为第三类账户，该类账户是用于统计整个平台上的资金流动情况的，由于账户特性，该类账户对记账明细数据处理要求的实时性比卖家账户还要低，且其需要处理的记账明细数据量也较卖家账户还要大。

本发明一实施方式中，对于上述的第二类账户的记账明细数据处理，可先判断支付系统内记账明细数据的频率和/或流量是否超出预设的安全区 间，再根据判断结果对此账户类型的记账明细数据进行处理。

记账明细数据的频率可为通过单位时间内的交易量获得，而预设的安全区间可分别对应的设有对频率和对流量的安全区间。

例如，当记账明细数据的频率和/或流量大于或等于该安全区间所设定的最大阈值时，认为记账明细数据的频率和/或流量超出了预设的安全区间；当记账明细数据的频率和/或流量小于或等于该安全区间所设定的最大阈值时，认为记账明细数据的频率和/或流量未超出预设的安全区间。这里可以选择的设定当记账明细数据的频率和/或流量等于该安全区间所设定的最大阈值时的判断结果。

当记账明细数据的频率和/或流量超出预设的安全区间时，对记账明细数据可采用异步记账，即是先将该记账明细数据存储到记账日志表中，形成后台数据，并不实时处理。同时，在记账明细数据的频率和/或流量未超出预设的安全区间时，才对所述后台数据进行处理，即是逐条捞取所述记账日志表中的数据进行处理，最后根据处理结果更新账户余额。如此，可避免在交互数据高并发状态下，出现的交互数据处理失败，系统后台雪崩等情况。

进一步地，为更加提升用户体验，在本实施方式中，所述方法还包括：

在交互数据过程中，将与产生所述交互数据相应账户的账户信息加载至内存中，并根据所述交互数据实时地更新所述账户信息中的余额信息，此时，可不对存储的后台数据进行处理，只更新内存加载账户的账户信息，以在前台实时展现该账户的余额信息。

如此，即便是在记账明细数据的频率和/或流量超出预设的安全区间时，客户仍可实时地看到账户的余额信息的变化，同时，也不会增加太多系统处理交互数据的压力，系统仍可如上述所述的在交互数据的频率和/或流量未超出预设的安全区间时，才对所述后台数据进行处理，并根据处理结果进一步的核对和更新账户信息中的余额信息。

进一步地，在本发明一实施方式中，还可根据业务类型和业务金额的具体情况对记账明细数据采用不同的处理方式。

对业务类型和业务金额的具体情况及对应的记账明细数据处理方式的判断过程，可优先于判断支付系统内交互数据的频率和/或流量是否超出预设的安全区间，具体包括：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务(例如退款、充值，支付，转账等)，则实时地处理所述交互数据；

若所述交互数据对应的业务类型为账户收入业务，则判断所述账户收入业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则执行S1、S2步骤，判断系统内交互数据的频率和/或流量是否超过预设的安全区间，并根据判断结果来处理所述交互数据。

一般地，卖家账户支出业务的记账明细数据较小，可以采用实时地处理记账明细数据的方式，而卖家账户收入业务的记账明细数据较大，则可根据每笔收入业务的金额记账明细数据，例如，预订金额阈值为1000美元，那么，当收入业务的金额大于等于1000美元时，则认为收入业务的金额达到预订金额标准，可实时地处理所述记账明细数据，这样，可对少部分业务金额较高的记账明细数据进行优先处理；

当收入业务的金额小于等于1000美元时，可按照上述方式先判断支付系统内记账明细数据的频率和/或流量是否超出预设的安全区间，再根据判断结果对此类账户的记账明细数据进行处理。这里可以选择的设定当收入业务的金额等于该预订金额阈值时的判断结果。

进一步地，在本发明一实施方式中，还可仅在指定时间区间内，对账户收入业务的金额是否达到预订金额标准进行判断，并根据判断结果对交互数据进行处理，即是在上述对业务类型和业务金额的判断中加入产生交互数据的时间区间的判断：

若所述交互数据在指定时间区间(如指定在双十一的时间区间为 2015/11/1021:00–2015/11/1209:00)内产生，则判断所述账户收入业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则执行S1、S2步骤，判断系统内交互数据的频率和/或流量是否超过预设的安全区间，并根据判断结果来处理所述交互数据。

当然，在本发明另一实施方式中，也可将在指定时间区间内(如指定在双十一的时间区间为2015/11/1021:00–2015/11/1209:00)所产生的，且业务类型为账户收入业务的所有交互数据都按照S1、S2步骤处理，其余的技术方案和上述实施方式相同，在此不再赘述。

在本发明一实施方式中，对于账户类型为第三类账户的记账明细数据量处理方式为：

将交互数据存储为后台数据，并在预定周期结束(例如24小时为一预订周期)时对所述后台数据进行处理；并根据处理结果更新账户信息中的余额信息。

如图2所示，在本发明一实施方式中，所述交互数据处理装置包括：

计算模块100，用于判断系统内交互数据的频率和/或流量是否超出预设的安全区间；

处理模块200，用于若系统内交互数据的频率和/或流量是超出预设的安全区间，则先将交互数据存储为后台数据，并在交互数据的频率和/或流量小于预设阈值时，再读取所述后台数据进行处理；若系统内交互数据的频率和/或流量未超出预设的安全区间，则实时地处理所述交互数据。

在本发明一实施方式中，通过判断产生交互数据的账户类型，对账户类型进行区分，以根据不同的账户类型对记账明细数据处理要求的实时性和记账明细数据量，采用不同的处理方式。在本实施方式中，账户类型包括第一类账户、第二类账户和第三类账户。其中，所述第一类账户对数据处理要求的实时性较高，例如买家账户，所述第二类账户对数据处理要求的实时性 较低，例如卖家账户，所述第三类账户对数据处理要求的实时性更低，例如支付平台账户。即是，所述第一类账户对交互数据处理的实时性要求高于所述第二类账户；所述第二类账户对交互数据处理的实时性要求高于所述第三类账户。

对每种账户类型的处理方式将在下述一一进行详细介绍。

所述处理模块200用于：

判断产生交互数据的账户类型；

若产生交互数据的账户类型为第一类账户，则实时地处理所述交互数据；

若产生交互数据的账户类型为第二类账户，则根据系统内交互数据的频率和/或流量判断是否实时地处理所述交互数据；

若产生交互数据的账户类型为第三类账户，则将交互数据存储为后台数据，并在预定周期结束时对所述后台数据进行处理。

对于账户类型为第一类账户，由于买家账户的特性，买家对记账明细数据处理要求的实时性很高，希望能够在业务处理过程中实时看到自己的余额变化，例如，用户充值100美元后希望马上可以查看到自己的账户余额里多了100美元，并且通常对于买家账户而言，其需要处理的记账明细数据量也较少。对于此类型账户，可以实时地处理所述记账明细数据。

对于账户类型为第二类账户，由于卖家账户特性，卖家对记账明细数据处理要求的实时性比买家要低，卖家账户一般不会实时的关注账户余额，另外，对于卖家账户，其需要处理的记账明细数据量也较大，这种账户类型的交互数据是产生记账明细数据的高并发的主要部分，尤其是在大规模促销、双11、双12、黑色星期五等情况。

对于账户类型为第三类账户，该类账户是用于统计整个平台上的资金流动情况的，由于账户特性，该类账户对记账明细数据处理要求的实时性比卖家账户还要低，且其需要处理的记账明细数据量也较卖家账户还要大。

本发明一实施方式中，对于上述的第二类账户的记账明细数据处理，可先判断支付系统内记账明细数据的频率和/或流量是否超出预设的安全区 间，再根据判断结果对此账户类型的记账明细数据进行处理。

记账明细数据的频率可为通过单位时间内的交易量获得，而预设的安全区间可分别对应的设有对频率和对流量的安全区间。

例如，当记账明细数据的频率和/或流量大于或等于该安全区间所设定的最大阈值时，认为记账明细数据的频率和/或流量超出了预设的安全区间；当记账明细数据的频率和/或流量小于或等于该安全区间所设定的最大阈值时，认为记账明细数据的频率和/或流量未超出预设的安全区间。这里可以选择的设定当记账明细数据的频率和/或流量等于该安全区间所设定的最大阈值时的判断结果。

当记账明细数据的频率和/或流量超出预设的安全区间时，对记账明细数据可采用异步记账，即是先将该记账明细数据存储到记账日志表中，形成后台数据，并不实时处理。同时，在记账明细数据的频率和/或流量未超出预设的安全区间时，才对所述后台数据进行处理，即是逐条捞取所述记账日志表中的数据进行处理，最后根据处理结果更新账户余额。如此，可避免在交互数据高并发状态下，出现的交互数据处理失败，系统后台雪崩等情况。

进一步地，为更加提升用户体验，在本实施方式中，所述处理模块200还用于：

在交互数据过程中，将与产生所述交互数据相应账户的账户信息加载至内存中，并根据所述交互数据实时地更新所述账户信息中的余额信息，此时，可不对存储的后台数据进行处理，只更新内存加载账户的账户信息，以在前台实时展现该账户的余额信息。

如此，即便是在记账明细数据的频率和/或流量超出预设的安全区间时，客户仍可实时地看到账户的余额信息的变化，同时，也不会增加太多系统处理交互数据的压力，系统仍可如上述所述的在交互数据的频率和/或流量未超出预设的安全区间时，才对所述后台数据进行处理，并根据处理结果进一步的核对和更新账户信息中的余额信息。

进一步地，在本发明一实施方式中，还可根据业务类型和业务金额的具 体情况对记账明细数据采用不同的处理方式。

对业务类型和业务金额的具体情况及对应的记账明细数据处理方式的判断过程，可优先于判断支付系统内交互数据的频率和/或流量是否超出预设的安全区间，具体的，所述处理模块200用于：

判断交互数据对应的业务类型；

若所述交互数据对应的业务类型为账户支出业务(例如退款、充值，支付，转账等)，则实时地处理所述交互数据；

若所述交互数据对应的业务类型为账户收入业务，则判断所述账户收入业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则判断系统内交互数据的频率和/或流量是否超过预设的安全区间，并根据判断结果来处理所述交互数据。

一般地，卖家账户支出业务的记账明细数据较小，可以采用实时地处理记账明细数据的方式，而卖家账户收入业务的记账明细数据较大，则可根据每笔收入业务的金额记账明细数据，例如，预订金额阈值为1000美元，那么，当收入业务的金额大于等于1000美元时，则认为收入业务的金额达到预订金额标准，可实时地处理所述记账明细数据，这样，可对少部分业务金额较高的记账明细数据进行优先处理；

当收入业务的金额小于等于1000美元时，可按照上述方式先判断支付系统内记账明细数据的频率和/或流量是否超出预设的安全区间，再根据判断结果对此类账户的记账明细数据进行处理。这里可以选择的设定当收入业务的金额等于该预订金额阈值时的判断结果。

进一步地，在本发明一实施方式中，还可仅在指定时间区间内，对账户收入业务的金额是否达到预订金额标准进行判断，并根据判断结果对交互数据进行处理，即所述处理模块还用于对产生交互数据的时间区间进行判断：

若所述交互数据在指定时间区间(如指定在双十一的时间区间为 2015/11/1021:00–2015/11/1209:00)内产生，则判断所述账户收入业务的金额是否达到预订金额标准；

若是，则实时地处理所述交互数据；若否，则判断系统内交互数据的频率和/或流量是否超过预设的安全区间，并根据判断结果来处理所述交互数据。

当然，在本发明另一实施方式中，所述处理模块也可用于：将在指定时间区间内(如指定在双十一的时间区间为2015/11/1021:00–2015/11/1209:00)所产生的，且业务类型为账户收入业务的所有交互数据都根据系统内交互数据的频率和/或流量判断是否实时地处理所述交互数据。其余的技术方案和上述实施方式相同，在此不再赘述。

在本发明一实施方式中，对于账户类型为第三类账户的记账明细数据量处理方式为：

将交互数据存储为后台数据，并在预定周期结束(例如24小时为一预订周期)时对所述后台数据进行处理；并根据处理结果更新账户信息中的余额信息。

综上所述，本发明根据系统内交互数据的具体情况，根据不同情况、不同账户类型、不同业务类型对交互数据采用不同的处理方式，在保障用户体验的情况下，有效地提升了交互数据的处理效率，避免在交互数据高并发状态下，出现的交互数据处理失败，系统后台雪崩等情况。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置，装置和模块的具体工作过程，可以参考前述方法实施方式中的对应过程，在此不再赘述。

在本发明所提供的几个实施方式中，应该理解到，所揭露的装置，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到 另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。

另外，在本发明各个实施方式中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以2个或2个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(processor)执行本发明各个实施方式所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施方式仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施方式对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施方式技术方案的精神和范围。