CN109493230B - 一种单边交易的补录方法及装置 - Google Patents

Abstract

本申请公开了一种单边交易的补录方法及装置，其中方法包括：接收交易请求；在服务的状态表示异常状态的情况下，记录所述交易请求对应的交易报文；检测所述服务的状态是否恢复；在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录。通过本申请公开的单边交易的补录方法及装置，无需人工进行补录，减少工作人员的工作量。

Description

一种单边交易的补录方法及装置

技术领域

本申请涉及信息处理领域，尤其涉及一种单边交易的补录方法及装置。

背景技术

在银行系统中，为了减少交易整体耗时提高交易性能，对于风险水平低的交易，上游服务通常通过不等待返回交易的方式调用下游服务。如果下游服务出现异常，不等待返回交易执行失败，此时，不等待返回交易就变成了单边交易，服务方将出现大量单边交易。

目前，在服务方的系统恢复后，由业务人员或运维人员对单边交易进行补录。给业务人员或运维人员带来了大量重复繁琐的工作。

发明内容

本申请提供了一种单边交易的补录方法及装置，目的在于解决的人工对单边交易进行补录工作量大且繁琐的问题。

为了实现上述目的，本申请提供了以下技术方案：

本申请公开了一种单边交易的补录方法，包括：

接收交易请求；

在服务的状态为异常状态的情况下，记录所述交易请求对应的交易报文；

检测所述服务的状态是否恢复；

在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录。

优选的，所述在服务的状态表示异常状态的情况下，记录所述交易请求对应的交易报文，包括：

在服务的状态表示异常状态的情况下，判断是否存在满足预设条件用于记录所述交易报文的记录文本；所述预设条件包括：已记录的交易报文对应的交易的数量不超过预设上限阈值；

在不存在满足所述预设条件的记录文本时，创建记录文本；

在所创建的记录文本中，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文；

在存在满足所述预设条件的记录文本时，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文。

优选的，所述记录文本采用时间戳的方式命名；

所述检测所述服务的状态是否恢复，包括：

从所述记录文本中确定时间戳最早的记录文本为测试记录文本；

对所述测试记录文本中的交易报文对应的交易进行补录；

如果所述测试补录文本中的交易报文都补录成功，则确定所述服务的状态恢复；

如果所述测试补录文本的交易报文中存在补录失败的交易报文，则确定所述服务的状态未恢复。

优选的，在所述确定所述服务的状态未恢复之后，还包括：

对所述测试记录文本中的补录成功的交易报文进行回滚；

在预设时长后，检测所述服务的状态是否恢复。

优选的，在所述服务的状态恢复的情况下，依据所述交易报文对所述交

易报文对应的交易进行补录，包括：

将所述服务的状态设置为补录状态；

循环执行以下步骤，直至不存在未补录的补录文本，在不存在未补录的补录文本时，将所述服务的状态设置为正常状态：

按照未补录的记录文本的时间戳，确定时间戳最早的未补录记录文本为待处理补录文本；

按照所述待处理补录文本中交易报文对应的交易的先后顺序，依次进行补录；

若所述待处理补录文本中存在补录失败的交易报文，则将对所述待补录文本的交易报文中补录成功的交易报文进行回滚。

优选的，确定所述服务的状态，包括：

在所述服务的状态为正常状态的情况下，对所接收的交易请求进行处理，得到结果标识；所述结果标识包括表示处理成功的标识或者表示处理失败的标识；

依据所述结果标识确定监控指标的取值；所述监控指标为用于判断服务器的异常运行状况的参数；

在所述监控指标的取值大于预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为正常状态。

优选的，所述确定所述服务的状态，还包括：

在所述服务的状态为所述补录状态的情况下，依据补录结果标识确定所述监控指标的取值，所述补录结果标识用于表示补录是否成功；

在所述监控指标的取值大于所述预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为补录状态。

本申请还公开了一种单边交易的补录装置，包括：

接收单元，用于接收交易请求；

记录单元，用于在服务的状态为异常状态的情况下，记录所述交易请求对应的交易报文；

检测单元，用于检测所述服务的状态是否恢复；

补录单元，用于在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录。

优选的，所述记录单元记录所述交易请求对应的交易报文的具体实现方式包括：

在服务的状态表示异常状态的情况下，判断是否存在满足预设条件用于记录所述交易报文的记录文本；所述预设条件包括：已记录的交易报文对应的交易的数量不超过预设上限阈值；

在不存在满足所述预设条件的记录文本时，创建记录文本；

在所创建的记录文本中，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文；

在存在满足所述预设条件的记录文本时，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文。

优选的，所述检测单元检测所述服务的状态是否恢复的具体实现方式，包括：

从所述记录文本中确定时间戳最早的记录文本为测试记录文本；

对所述测试记录文本中的交易报文对应的交易进行补录；

如果所述测试补录文本中的交易报文都补录成功，则确定所述服务的状态恢复；

如果所述测试补录文本的交易报文中存在补录失败的交易报文，则确定所述服务的状态未恢复。

优选的，所述检测单元检测所述服务的状态是否恢复的具体实现方式，还包括：

对所述测试记录文本中补录成功的交易报文进行回滚；

在预设时长后，检测所述服务的状态是否恢复。

优选的，所述补录单元依据所述交易报文对所述交易报文对应的交易进行补录的具体实现方式，包括：

将所述服务的状态设置为补录状态；

循环执行以下步骤，直至不存在未补录的补录文本，在不存在未补录的补录文本时，将所述服务的状态设置为正常状态：

按照未补录的记录文本的时间戳，确定时间戳最早的未补录记录文本为待处理补录文本；

按照所述待处理补录文本中交易报文对应的交易的先后顺序，依次进行补录；

若所述待处理补录文本中存在补录失败的交易报文，则将对所述待补录文本的交易报文中补录成功的交易报文进行回滚。

优选的，还包括：状态确定单元，

所述状态确定单元，用于在所述服务的状态为正常状态的情况下，对所接收的交易请求进行处理，得到结果标识；所述结果标识包括表示处理成功的标识或者表示处理失败的标识；

依据所述结果标识确定监控指标的取值；所述监控指标为用于判断服务器的异常运行状况的参数；

在所述监控指标的取值大于预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为正常状态。

优选的，所述状态确定单元，还用于：

在所述服务的状态为所述补录状态的情况下，依据补录结果标识确定所述监控指标的取值，所述补录结果标识用于表示补录是否成功；

在所述监控指标的取值大于所述预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为补录状态。

本申请所述的单边交易的补录方法及装置中，接收交易请求，在服务的状态表示异常状态的情况下，记录交易请求对应的交易报文；检测服务的状态是否恢复；在服务的状态恢复的情况下，依据交易报文对交易报文对应的交易进行补录。由于在本申请公开的单边交易的补录方法及装置中，通过自动检测服务的状态是否恢复，并在检测到服务的状态恢复的情况下，依据所记录的交易报文对交易报文对应的交易进行补录，进而无需人工进行补录。

附图说明

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

图1为本申请提供的一种单边交易的补录装置的应用场景示例图；

图2为本申请实施例公开一种单边交易的补录方法的流程图；

图3为本申请实施例公开的一种单边交易的补录装置的结构示意图。

具体实施方式

图1为本申请提供的一种单边交易的补录装置的应用场景示例图，图1包括：本发明提供的单边交易的补录装置和现有技术的前端系统。其中，单边交易的补录装置与前端系统连接，前端系统用于产生交易请求，单边交易的补录装置用于自动对单边交易进行补录。

单边交易的补录装置可以设置在服务器。

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

图2为本申请实施例公开的一种单边交易的补录方法，包括以下步骤：

S201、接收交易请求。

在本步骤中，实时接收前端系统发送的交易请求。具体的，在本步骤中所接收的交易请求可以是不等待返回交易的交易请求。其中，不等待返回交易是指：请求方向服务方发送交易请求后，不等待服务方返回执行结果，而是直接认为服务方交易执行成功。

在请求方向服务方发送不等待返回交易后，如果服务方对该不等待返回交易执行失败，此时，该不等待返回交易就变成了单边交易，使得请求方与服务方对交易执行结果的判定不一致。

S202、判断服务的状态是否为正常状态，如果是，则执行S203，如果否，执行S207。

在本实施例中，服务的状态包括：正常状态、异常状态和补录状态。其中，正常状态表示服务器的运行状况良好；异常状态表示服务器运行状况异常；补录状态表示服务器当前正在对单边交易进行补录。

具体的，可以采用不同的标识来表示服务的不同状态。

S203、依据交易请求进行交易处理，得到表示是否处理成功的结果标识。

在本步骤中，结果标识包括两种，一种为表示处理成功的标识，一种为表示处理失败的标识。

S204、依据结果标识确定监控指标的取值。

在本步骤中，监控指标为用于判断服务器是否处于异常运行状况的参数。在本实施例中，监控指标可以为异常交易的次数，或者可以为异常交易率(异常交易的次数占总交易次数的比值)，当然，在实际应用中，监控指标还可以为其他参数，只要是可以反映服务器的运行状况的参数即可，本实施例不对监控指标的具体内容作限定。

S205、判断监控指标的取值是否大于预设指标阈值，如果是，则执行S206如果否，则执行S204。

在本实施例中，事先设定用于确定服务器的运行状况的正常还是异常的预设指标阈值。在监控指标表示异常交易次数时，预设指标阈值为异常交易次数阈值；在监控指标表示异常交易率时，预设指标阈值为异常交易率阈值。

在监控指标大于预设指标阈值时，表示服务器的运行状况异常，此时，表明服务的状态为异常状态；在监控指标不大于预设指标阈值时，表示服务器的运行状况正常，此时，服务的状态为正常状态。

S206、更新服务的状态为异常状态，并执行S212。

在本步骤中，将服务的状态更新为异常状态。

S207、判断服务的状态是否为异常状态，如果否，则执行S208，如果是，执行S209。

由于在本实施例中服务的状态包括：正常状态、异常状态和补录状态，因此，在判断出服务的状态不是正常状态的情况下，还是不能确定是异常状态还是补录状态。因此，在本步骤中，判断服务的状态是异常状态还是补录状态。

S208、将所接收的交易请求进行保存。

为了保证交易执行顺序的正确性，在服务的状态为补录状态时，将此时所接收的交易请求进行保存，待到补录成功后，再恢复处理。

S209、判断是否存在满足预设条件的补录文本，如果否，则执行S210，如果是，则执行S211。

由于数据库或消息队列异常往往是造成服务异常的原因之一，因此，在本实施例中，不采用数据库或消息队列的方式存储单边交易记录。具体的，本实施例中采用文本的形式存储单边交易记录；为了描述方便，将用于存储单边交易记录的文本称为补录文本。

在本实施例中，事先设置一个补录文本中所能存储的交易报文对应的交易数量。在本步骤中，预设条件为已记录的交易报文对应的交易数量小于预设上限阈值。

S210、创建补录文本。

在不存在满足预设条件的补录文本时，即当前没有补录文本，或者，已有的补录文本中所记录的交易报文对应的交易数量都已达到预设上限阈值，此时，在本步骤中，需要创建补录文本。

为了保证先产生的单边交易先进行补录，以保证交易处理顺序的正确性，在本实施例中，对所创建的补录文本以时间戳的方式进行命名。

S211、在补录文本中记录该交易请求对应的交易报文。

在本步骤中，按照交易请求的先后顺序，将单边交易的交易报文记录在补录文本中。

上述S201-S211的目的是，实时检测服务的状态是否变为异常状态，以及在补录文本中记录单边交易的交易报文。

S212、检测服务的状态是否恢复，如果否，则执行S213，如果是，则执行S214。

在本实施例中，当服务的状态为异常状态时，需要检测服务器的异常运行状况是否恢复。一般情况下，服务器的异常运行状况恢复的平均耗时为一个固定时间，因此，在本实施例中，可以每隔固定时长自动触发检测服务器的异常运行状况是否恢复，也可以手工触发检查检测服务器的异常运行状况是否恢复。

其中，服务器状态检测的方式是对一个补录文本中的交易报文对应的交易进行补录，通过判断补录文本中所有的交易报文对应的交易是否都补录完成，检测服务器的异常运行状况是否恢复。

具体的，检测过程包括：

A1、在服务的状态为异常状态且存在待补录的补录文本的情况下，确定时间戳最早的补录文本为测试补录文本。

在本实施例中，采用时间戳对所创建的补录文本进行命名，在服务的状态为异常状态并且存在待补录的补录文本时，采用时间戳最早的补录文本作为检测服务器的运行状况是否恢复的补录文本。为了描述方便，将时间戳最早的待补录的补录文本称为测试补录文本。

A2、对测试补录文本中的交易报文对应的交易进行补录，并依据补录结果确定服务的状态是否恢复。

在本实施例中，以测试补录文本作为一个独立事务，即对测试补录文本中的所有交易报文对应的交易都进行补录，并依据补录结果确定服务器的运行状况是否恢复。具体的，如果测试补录文本中所有的交易报文都补录成功，则表示对测试补录文本补录成功，也表示服务器的运行状况已恢复，否则，表示服务器的运行状况没有恢复。

由于本实施例中，对补录文本中所能记录交易报文对应的交易的总数量进行了限制，因此，每个补录文本对应的交易数量不会大于预设上限阈值，使得在依据补录文本的补录结果确定服务的状态是否恢复时，可以较快的检测出是否存在补录失败的交易。并且，补录文本对应的交易数量上限值越小，依据补录结果确定服务的状态是否恢复的速度更快。

需要说明的是，交易数量上限值变小，补录文本数也将变多，补录的耗时也会变长，因此交易数量上限值不应设置的过小，具体的，交易数量的上限值的具体取值需要根据实际情况进行设置。

S213、对测试补录文本中补录成功的交易报文进行回滚，并在预设时长后执行S212。

在测试补录文本补录失败的情况下，表示测试补录文本中有的交易报文补录成功，有的交易报文补录失败。在本步骤中，对补录成功的交易报文进行回滚，表示对补录成功的交易报文恢复为未补录前的状态。

在本实施例中，如果对待补录的交易连续两次进行补录，并且两次的都补录成功，则对于该交易来说，两次补录成功的结果是错误的。例如，用户的账户余额需要减少1000，如果补录一次成功后，该用户的账户余额减少1000，如果两次补录都成功，则表示该用户的账户余额减少了2000。因此，多次补录成功会造成交易补录的结果出现错误。

在本实施例中，为了保证对测试补录文本中交易报文对应的交易的补录正确性，在测试文本中一部分交易报文补录成功，一部分交易报文补录失败的情况下，在对测试补录文本中的交易报文进行一次补录后，将补录成功的交易报文恢复为未补录前的状态。

在对测试补录文本中补录成功的交易报文进行回滚后，在预设固定时长后，重新进行补录以判断服务器的运行状况是否恢复正常，直至判断结果为服务器的运行状况恢复，执行S214。

其中，预设固定时长可以为服务器运行状况恢复正常的平均耗时时长。当然，在实际应用中，预设固定时长还可以为其他取值，本实施例不对预设固定时长的具体取值作限定。

由于本实施例中，设定了补录文本所能记录交易报文的交易数量上限值，使得对补录文本中交易失败的交易报文回滚的速度变快，并且，交易数量的上限值越小，对该补录文本中交易失败的交易报文回滚的速度越快。需要说明的是，交易数量上限值变小，补录文本数也将变多，补录的耗时也会变长，因此交易数量上限值不应设置的过小。

S214、更新服务的状态为补录状态。

上述S212-S214的目的是，检测服务器的运行状况是否恢复，以及在恢复的情况下，更新服务的状态为补录状态。

S215、按照未补录的补录文本的时间戳的先后顺序，将时间戳最早的补录文本确定待处理补录文本。

在本实施例中，为了保证按照原有交易请求的先后顺序对未补录的补录文本进行补录，在本步骤中，按照未补录的补录文本的时间戳的先后顺序，确定时间戳最早的补录文本，为了描述方便，将所确定出的时间戳最早的补录文本称为待处理补录文本。

S216、依据待处理补录文本中的交易报文，进行补录，得到对每个交易的结果标识，并执行S204和S217。

在本实施例中，以一个补录文本为一个事务，因此，在本步骤中，对待处理补录文本中的所有交易报文对应的交易进行补录。在本步骤中，结果标识包括待处理补录文本中每个交易的补录结果标识，包括表示补录成功的结果标识或表示补录失败的结果标识。

为了实时判断服务器的运行状况，在本步骤中，跳转到S204，即依据待处理补录文本每个交易的结果标识确定服务的状态，使得如果在补录过程中服务器的运行状况异常，本实施例可以实时检测到。

S217、判断待处理补录文本的结果标识中，所有的交易报文对应的交易是否都补录成功，如果否，则执行S218；如果是，则执行S219。

在本实施例中，当待处理补录文本中交易报文都补录成功，则表示该待处理补录文本补录成功，否则，表示补录失败。

S218、对待处理补录文本中补录成功的交易报文进行回滚。

为了保证对待处理补录文本中交易报文对应的交易的补录正确性，在待处理补录文本中一部分交易报文补录成功，一部分交易报文补录失败的情况下，在对待处理补录文本进行一次补录后，将补录成功的交易报文恢复为未补录前的状态。

S219、备份并删除待处理补录文本。

S220、判断是否存在未补录的补录文本，如果是，则执行S215，如果否，则执行S221。

在本步骤中，若存在未补录的补录文本，则执行S215，继续确定待处理补录文本，以及后续对待处理补录报文中的交易报文对应的交易进行补录，直至，所有的未补录的补录文本都补录成功后，执行S221。

S221、更新服务的状态为正常状态。

在本实施例中，在将服务的状态更新为正常状态后，继续对服务的状态为补录状态的时间段所保存的交易请求，以及当前所接收的来自前端系统的交易请求进行处理。

上述S215-S221的目的是，在服务的状态为补录状态时，对补录文本中的交易报文对应的单边交易进行补录，并在补录完成时，将服务的状态更新为正常状态。

综上所述，

1、通过反映服务器的运行状况的监控指标与预设指标阈值进行比较，确定服务器的运行状况(服务的状态)。

2、补录文本以时间戳命名，以及在补录文本中按照单边交易发生的先后顺序记录单边交易，为后续按照单边交易发生的先后顺序进行补录奠定基础，从而保证单边交易执行顺序的正确性。

3、在服务的状态为异常状态时，对补录文本中的交易报文对应的交易进行补录，通过补录文本中交易报文是否补录成功来判断服务器的运行状况是否恢复。

4、在服务器的运行状况恢复的情况下，对补录文本记录的交易报文对应的交易进行自动补录，该过程无需人工参与，减少业务人员或运维人员的工作量。

5、在补录期间，依据对每个单边交易补录的结果标识确定服务器的运行状况，使得在补录期间也可以确定服务的状态是否变为异常状态。

6、在补录期间，对前端系统发送的交易请求进行保存，待对补录文本中的交易报文对应的交易补录完成后，再对所保存的交易请求进行处理，以保证交易执行顺序的正确性。

图3为本申请实施例公开的一种单边交易的补录装置，包括以下单元：

接收单元301，用于接收交易请求；

记录单元302，用于在服务的状态为异常状态的情况下，记录所述交易请求对应的交易报文；

检测单元303，用于检测所述服务的状态是否恢复；

补录单元304，用于在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录。

其中，所述记录单元302记录所述交易请求对应的交易报文的具体实现方式，包括：

在服务的状态表示异常状态的情况下，判断是否存在满足预设条件用于记录所述交易报文的记录文本；所述预设条件包括：已记录的交易报文对应的交易的数量不超过预设上限阈值；

在不存在满足所述预设条件的记录文本时，创建记录文本；

在所创建的记录文本中，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文；

在存在满足所述预设条件的记录文本时，按照所述交易请求的先后顺序

记录所述交易请求对应的交易报文。

其中，所述检测单元303检测所述服务的状态是否恢复的具体实现方式包括：

从所述记录文本中确定时间戳最早的记录文本为测试记录文本；

对所述测试记录文本中的交易报文对应的交易进行补录；

如果所述测试补录文本中的交易报文都补录成功，则确定所述服务的状态恢复；

如果所述测试补录文本的交易报文中存在补录失败的交易报文，则确定所述服务的状态未恢复。

其中，所述检测单元303检测所述服务的状态是否恢复的具体实现方式，还包括：

对所述测试记录文本中补录成功的交易报文进行回滚；

在预设时长后，检测所述服务的状态是否恢复。

其中，依据所述交易报文对所述交易报文对应的交易进行补录的具体实现方式，包括：

将所述服务的状态设置为补录状态；

循环执行以下步骤，直至不存在未补录的补录文本，在不存在未补录的补录文本时，将所述服务的状态设置为正常状态：

按照未补录的记录文本的时间戳，确定时间戳最早的未补录记录文本为待处理补录文本；

按照所述待处理补录文本中交易报文对应的交易的先后顺序，依次进行补录；

若所述待处理补录文本中存在补录失败的交易报文，则将对所述待补录文本的交易报文中补录成功的交易报文进行回滚。

其中，还包括：状态确定单元，

所述状态确定单元，用于在所述服务的状态为正常状态的情况下，对所接收的交易请求进行处理，得到结果标识；所述结果标识包括表示处理成功的标识或者表示处理失败的标识；

依据所述结果标识确定监控指标的取值；所述监控指标为用于判断服务器的异常运行状况的参数；

在所述监控指标的取值大于预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为正常状态。

其中，状态确定子单元，还用于：

在所述服务的状态为所述补录状态的情况下，依据补录结果标识确定所述监控指标的取值，所述补录结果标识用于表示补录是否成功；

在所述监控指标的取值大于所述预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为补录状态。

本申请实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (12)

1.一种单边交易的补录方法，其特征在于，包括：

接收交易请求；

在服务的状态为异常状态的情况下，记录所述交易请求对应的交易报文；

检测所述服务的状态是否恢复；

在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录；

所述在服务的状态表示异常状态的情况下，记录所述交易请求对应的交易报文，包括：

在服务的状态表示异常状态的情况下，判断是否存在满足预设条件用于记录所述交易报文的补录文本；所述预设条件包括：已记录的交易报文对应的交易的数量不超过预设上限阈值；

在不存在满足所述预设条件的补录文本时，创建补录文本；

在所创建的补录文本中，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文；

在存在满足所述预设条件的补录文本时，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文。

2.根据权利要求1所述的方法，其特征在于，所述补录文本采用时间戳的方式命名；

所述检测所述服务的状态是否恢复，包括：

从所述补录文本中确定时间戳最早的补录文本为测试补录文本；

对所述测试补录文本中的交易报文对应的交易进行补录；

如果所述测试补录文本中的交易报文都补录成功，则确定所述服务的状态恢复；

如果所述测试补录文本的交易报文中存在补录失败的交易报文，则确定所述服务的状态未恢复。

3.根据权利要求2所述的方法，其特征在于，在所述确定所述服务的状态未恢复之后，还包括：

对所述测试补录文本中的补录成功的交易报文进行回滚；

在预设时长后，检测所述服务的状态是否恢复。

4.根据权利要求2所述的方法，其特征在于，在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录，包括：

将所述服务的状态设置为补录状态；

循环执行以下步骤，直至不存在未补录的补录文本，在不存在未补录的补录文本时，将所述服务的状态设置为正常状态：

按照未补录的补录文本的时间戳，确定时间戳最早的未补录补录文本为待处理补录文本；

按照所述待处理补录文本中交易报文对应的交易的先后顺序，依次进行补录；

若所述待处理补录文本中存在补录失败的交易报文，则将对所述待处理补录文本的交易报文中补录成功的交易报文进行回滚。

5.根据权利要求4所述的方法，其特征在于，确定所述服务的状态，包括：

在所述服务的状态为正常状态的情况下，对所接收的交易请求进行处理，得到结果标识；所述结果标识包括表示处理成功的标识或者表示处理失败的标识；

依据所述结果标识确定监控指标的取值；所述监控指标为用于判断服务器的异常运行状况的参数；

在所述监控指标的取值大于预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为正常状态。

6.根据权利要求5所述的方法，其特征在于，所述确定所述服务的状态，还包括：

在所述服务的状态为所述补录状态的情况下，依据补录结果标识确定所述监控指标的取值，所述补录结果标识用于表示补录是否成功；

在所述监控指标的取值大于所述预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为补录状态。

7.一种单边交易的补录装置，其特征在于，包括：

接收单元，用于接收交易请求；

记录单元，用于在服务的状态为异常状态的情况下，记录所述交易请求对应的交易报文；

检测单元，用于检测所述服务的状态是否恢复；

补录单元，用于在所述服务的状态恢复的情况下，依据所述交易报文对所述交易报文对应的交易进行补录；

所述记录单元记录所述交易请求对应的交易报文的具体实现方式包括：

在服务的状态表示异常状态的情况下，判断是否存在满足预设条件用于记录所述交易报文的补录文本；所述预设条件包括：已记录的交易报文对应的交易的数量不超过预设上限阈值；

在不存在满足所述预设条件的补录文本时，创建补录文本；

在所创建的补录文本中，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文；

在存在满足所述预设条件的补录文本时，按照所述交易请求的先后顺序记录所述交易请求对应的交易报文。

8.根据权利要求7所述的装置，其特征在于，所述检测单元检测所述服务的状态是否恢复的具体实现方式，包括：

从所述补录文本中确定时间戳最早的补录文本为测试补录文本；

对所述测试补录文本中的交易报文对应的交易进行补录；

如果所述测试补录文本中的交易报文都补录成功，则确定所述服务的状态恢复；

如果所述测试补录文本的交易报文中存在补录失败的交易报文，则确定所述服务的状态未恢复。

9.根据权利要求8所述的装置，其特征在于，所述检测单元检测所述服务的状态是否恢复的具体实现方式，还包括：

对所述测试补录文本中补录成功的交易报文进行回滚；

在预设时长后，检测所述服务的状态是否恢复。

10.根据权利要求8所述的装置，其特征在于，所述补录单元依据所述交易报文对所述交易报文对应的交易进行补录的具体实现方式，包括：

将所述服务的状态设置为补录状态；

循环执行以下步骤，直至不存在未补录的补录文本，在不存在未补录的补录文本时，将所述服务的状态设置为正常状态：

按照未补录的补录文本的时间戳，确定时间戳最早的未补录补录文本为待处理补录文本；

按照所述待处理补录文本中交易报文对应的交易的先后顺序，依次进行补录；

若所述待处理补录文本中存在补录失败的交易报文，则将对所述待处理补录文本的交易报文中补录成功的交易报文进行回滚。

11.根据权利要求10所述的装置，其特征在于，还包括：状态确定单元，

所述状态确定单元，用于在所述服务的状态为正常状态的情况下，对所接收的交易请求进行处理，得到结果标识；所述结果标识包括表示处理成功的标识或者表示处理失败的标识；

依据所述结果标识确定监控指标的取值；所述监控指标为用于判断服务器的异常运行状况的参数；

在所述监控指标的取值大于预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为正常状态。

12.根据权利要求11所述的装置，其特征在于，所述状态确定单元，还用于：

在所述服务的状态为所述补录状态的情况下，依据补录结果标识确定所述监控指标的取值，所述补录结果标识用于表示补录是否成功；

在所述监控指标的取值大于所述预设指标阈值时，所述服务的状态为异常状态；

在所述监控指标的取值不大于所述预设指标阈值时，所述服务的状态为补录状态。

Images