CN111062723B - 一种虚拟账户转账方法、装置、系统及存储介质 - Google Patents

Abstract

本申请公开了一种虚拟账户转账方法、装置、系统及存储介质，具体包括：交易服务端在接收到用户的转账请求后，将转账请求的转账事务消息发送至消息中间件；交易服务端接收到所述消息中间件反馈的发送成功的信息，标记转账请求的状态为初始状态，初始状态表示已受理转账请求，交易服务端将标记为初始状态的转账事务消息发送至消息中间件；账务服务端根据预先配置的消费消息参数，从消息中间件拉取转账事务消息，并在执行拉取的转账事务消息后向交易服务端反馈转账成功通知；交易服务端变更转账请求的状态为转账成功状态，完成转账，基于上述方案，可以减轻账务服务端数据处理的压力，以保障账务服务端正常运行。

Description

一种虚拟账户转账方法、装置、系统及存储介质

技术领域

本申请涉及互联网支付技术领域，尤其涉及一种虚拟账户转账方法、装置、系统及存储介质。

背景技术

目前，在互联网支付业务中，可通过虚拟账户支付模式提供支付服务，用户在网上的支付交易可在用户的虚拟账户之间完成，虚拟账户之间进行转账交易的明细以及余额都会记录在账务系统中，账务系统记录虚拟账户之间转账交易的明细以及余额，转账双方的账户数据要一致、准确，余额变更无误。

目前，现有技术中的账务系统之间接收交易系统发送的转账请求，不对转账请求进行事务处理并记录转账信息，然而，当一段时间内有大量转账请求发送到账务系统时，现有的账务系统接收和处理转账请求方式可能会因为转账单积压，导致账务系统的数据库因无法承受大量的转账请求而崩溃，账务系统无法正常工作。

虽然现有技术中可以通过定时读取转账单的方式，一定程度地解决大量转账请求压垮账务系统的数据库的问题，但定时任务的执行时间间隔设置仍存在一些问题，如果设置的定时的时间间隔过大，用户的转账请求不能及时处理，可能导致用户转账过慢，则会影响用户体验，如果时间间隔设置的过小，则会给账务系统的数据库带来数据处理的压力，影响系统正常运行。

发明内容

针对上述现有技术，本发明实施例公开一种虚拟账户转账方法，通过在交易服务端和账务服务端之间设置消息中间件，消息中间件作为转账请求的缓冲，可以减轻账务服务端数据处理的压力、降低账务服务端数据库崩溃的风险，该方法包括：

交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件；

所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

可选地，所述账务服务端执行拉取的所述转账事务消息的步骤包括：

校验转账账户的参数信息与业务状态，所述转账事务消息的信息包括所述转账账户的参数信息与业务状态，所述转账账户包括出金账户和入金账户；

当校验结果为正常时，则将所述转账账户的账号进行排序；

根据所述排序的结果和预设的加锁顺序，锁定所述账号对应的转账账户；

获取所述出金账户的余额，确定所述出金账户的余额是否可用；

当所述出金账户的余额可用时，根据所述转账事务消息，分别更新所述出金账户的余额与所述入金账户的余额；

保存所述转账账户的转账记录，完成执行所述转账事务消息。

可选地，所述方法进一步包括：当所述交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件失败时，所述消息中间件向所述交易服务端发送转账事务消息回查请求；

所述交易服务端接收到所述转账事务消息回查请求，查询所述转账事务消息；

当所述转账事务消息的状态为初始状态时，所述交易服务端将所述转账事务消息发送至所述消息中间件。

可选地，当所述账务服务端从所述消息中间件拉取被标记为初始状态的所述转账事务消息失败时，所述方法进一步包括：

根据预设的消息重试策略，所述账务服务端重新从所述消息中间件拉取所述转账事务消息。

可选地，所述方法进一步包括：

当所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息时，所述交易服务端向所述用户返回转账请求受理成功的信息；

当所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息失败的信息时，所述交易服务端向所述用户返回转账请求受理失败的信息。

可选地，所述方法还包括：

根据所述账务服务端的数据库的性能，设置所述消费消息参数，其中，所述消费消息参数包括消费线程数。

根据本申请一个方面，提供一种虚拟账户转账装置，该装置包括：

发送模块，用于交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件；

第一标记模块，用于所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

执行模块，用于账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

第二标记模块，用于所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

根据本申请一个方面，提供一种虚拟账户转账系统，所述系统包括：交易服务端、消息中间件、账务服务端以及用户终端，其中：

交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件；

所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

根据本申请一个方面，提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现上述实施例中所述的虚拟账户转账方法中的步骤。

根据本申请一个方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中所述的虚拟账户转账方法。

综上所述，本申请实施例方案以消息中间件作为交易服务端向账务服务端发送转账请求的缓冲，可以减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，账务服务端可以支持大并发转账请求下的虚拟账户转账的实现。

附图说明

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

图1示出了根据本申请一些实施例的应用场景100的示意图；

图2示出了根据本申请一些实施例的虚拟账户转账方法200的流程图；

图3示出了根据本申请一些实施例的方法300的流程图；

图4示出了根据本申请一些实施例的方法400的流程图；

图5示出了根据本申请一些实施例的方法500的流程图；

图6示出了本申请一些实施例的虚拟账户转账系统中虚拟账户转账执行的示意性时序图；

图7示出了本申请一实施例的虚拟账户转账装置700的示意图；

图8为本发明一些实施例中电子设备800的结构示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

请参照图1所示，图1示出了根据本申请一些实施例的应用场景100的示意图。在本申请的一些实施例中，应用场景100可以包括用户终端设备110、交易服务端120、消息中间件130和账务服务端140。这里，用户终端设备110、交易服务端120、消息中间件130和账务服务端140可以通过网络150进行通信。网络150例如可以包括局域网(LAN)和广域网(WAN)。本申请的实施例可以使用任意公知的网络协议来实现网络150，包括各种有线或无线协议，诸如，以太网、FIREWIRE、全球移动通讯系统(GSM)、增强数据GSM环境(EDGE)、码分多址(CDMA)、时分多址(TDMA)、蓝牙、WiFi、IP语音(VoIP)，Wi-MAX，或任意其他适合的通信协议。

用户终端设备110例如可以包括但不限于掌上型计算机、平板计算机、笔记本电脑、台式计算机、智能手机或任意两个或更多的这些数据处理设备或其他数据处理设备的组合。用户终端设备110可以通过通用浏览器、即时通讯应用、短视频应用或者电商客户端等应用，向交易服务端120提交转账请求等。

交易服务端120可以包括一个或多个服务器。交易服务端120可以响应于来自用户终端设备110的访问请求，向消息中间件130发送事务消息，交易服务端120可以为消息生产者。账务服务端140可以包括一个或多个服务器，账务服务端140可以用于处理虚拟账户的转账请求，记录用户的虚拟账户的交易明细和余额等信息，账务服务端140可以从消息中间件130拉取事务消息，账务服务端140可以为消息的消费者或者订阅者。在电子支付的应用场景中，交易服务端120可以是支付交易系统，账务服务端140可以是后台账务系统。

综上，本申请实施例可以通过在交易服务端和账务服务端之间设置消息中间件，以消息中间件作为交易服务端向账务服务端发送转账请求的缓冲。这样，本申请实施例的虚拟账户转账的方法可以减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，支持大并发转账请求下的虚拟账户转账的实现。

如图2所示，图2示出了根据本申请一些实施例的虚拟账户转账方法200的流程图。在本申请实施例中，该虚拟账户转账方法包括：

步骤S201：交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件。

这里，用户通过用户终端设备进行了转账操作，向交易服务端发起转账请求，在电子支付的应用场景中，交易服务端可以是支付交易系统。消息中间件是一种利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，消息中间件可以适用于需要可靠的数据传送的分布式环境。

步骤S202：所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件。

这里，交易服务标记转账请求的状态为初始状态，该转账请求对应的转账事务消息为初始状态，初始状态表示已受理所述转账请求。

步骤S203：账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知。

这里，账务服务端可以用于处理虚拟账户的转账请求，记录用户的虚拟账户的交易明细和余额等信息。账务服务端从消息中间件拉取转账事务消息后，执行该转账事务消息，账务服务端可以将转账事务消息的相关转账数据进行更新和保存，执行成功后向所述交易服务端反馈转账成功通知。

步骤S204：所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

综上，本申请实施例通过在交易服务端和账务服务端之间设置消息中间件，交易服务端将接收到的转账请求先发送至消息中间件，账务服务端可以有控制的从消息中间件拉取相关的转账事务消息执行消费，以消息中间件作为交易服务端向账务服务端发送转账请求的缓冲，可以减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，支持大并发转账请求下的虚拟账户的转账实现。

如图3所示，图3示出了根据本申请一些实施例的方法300的流程图。在本申请一些实施例中，步骤203中账务服务端执行拉取的转账事务消息的方法可以实施为方法300。

步骤S301：校验转账账户的参数信息与业务状态。

这里，账务服务端拉取的转账事务消息的信息包括转账账户的参数信息与业务状态，其中，转账账户包括出金账户和入金账户。

转账账户的参数信息可以包括转账账户的账号，校验转账双方账户账号是否为空，账号长度是否正常；转账账户的业务状态包括出金账户和入金账户业务状态，校验转账双方账户，即出金账户和入金账户是否为被注销状态，出金账户的余额是否可用。

步骤S302：当校验结果为正常时，则将所述转账账户的账号进行排序。

这里，上述校验结果为正常时，转账账户的参数信息和业务状态均为正常，对转账账户的账号进行排序，转账账户包括转账双方的账户，根据转账双方的账号的大小进行排序，确定账号顺序。根据账号顺序可以按顺序对相应地转账账户进行加锁操作，以便于避免账务服务端执行转账操作时发生死锁状况。可以理解的是，排序是根据转账双方的账号，不区分出金账户或者入金账户，仅区分账号的大小。

步骤S303：根据所述排序的结果和预设的加锁顺序，锁定所述账号对应的转账账户。

具体地，预设的加锁顺序可以是先对账号小的转账账户进行加锁，后对账号大的转账账户进行加锁，或者先对账号大的转账账户，后对账号小的转账账户进行加锁，在实际应用中可以根据程序设计需求进行设置加锁顺序。步骤S302中确定了转账双方的账户账号的大小排序，结合预设的加锁顺序，依次对转账双方的账户进行加锁操作，以减少账务服务端执行转账操作时死锁状况的发生。

步骤S304：获取所述出金账户的余额，确定所述出金账户的余额是否可用。

这里，账务服务端获取到出金账户的余额，该余额为执行转账操作前的余额，确定出金账户的余额是否可用。由于转账请求为并发，在执行转账操作前确认出金账户的余额，以防止出金账户的余额为负数。

步骤S305：当所述出金账户的余额可用时，根据所述转账事务消息，分别更新所述出金账户的余额与入金账户的余额。

具体地，账务服务端根据转账事务消息，更新账务服务端的数据库中的出金账户的余额，再更新入金账户的余额。

步骤S306：保存所述转账账户的转账记录，完成执行所述转账事务消息。

具体地，账务服务端保存转账账户的转账记录至账务服务端的数据库中，完成执行该转账事务消息。

综上，在本申请中，上述方法300可以为账务服务端执行拉取的转账事务消息的方法，但是不限于此。在虚拟账户转账的业务场景中，可以应用现有的账务服务端执行转账事务消息的方法，此处不再赘述。

如图4所示，图4示出了根据本申请一些实施例的方法400的流程图。在本申请一些实施例中，该方法400包括：

步骤S401：交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件。

这里，消息中间件接收到转账事务消息，对该转账事务消息进行持久化处理，保存该转账事务消息。其中，该转账事务消息对账务服务端不可见，账务服务端无法拉取该转账事务消息，该转账事务消息可以看作预转账事务消息。消息中间件可以向交易服务端反馈发送转账事务消息是否成功的信息。

在步骤S402中：当交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息时，交易服务端标记所述转账请求的状态为初始状态，将标记为初始状态的转账事务消息发送至所述消息中间件。

这里，初始状态表示已受理所述转账请求，当交易服务端接收到所述消息中间件反馈的发送成功的信息时，交易服务端可以在本地执行该转账事务消息，具体地，交易服务端保存转账请求的数据至交易服务端的数据库，并向提交转账请求的用户即用户终端设备返回转账请求受理成功的信息，用户可以及时了解其账户转账的状态，优化了用户体验。

同时，交易服务端标记该转账请求的转账事务消息为初始状态，将标记为初始状态的转账事务消息发送至消息中间件。可以理解的是，这里，交易服务端为第二次发送转账事务消息至消息中间件，该转账事务消息为已被交易服务端执行后的转账事务消息，再次发送至消息中间件后，该转账事务消息为对账务服务端可见的。

步骤S403：当所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息失败的信息时，执行交易服务端向所述用户返回转账请求受理失败的信息。

这里，该转账请求受理失败后，此次用户转账操作不成功，在实际应用中，用户可以根据自身需要重新进行转账操作，在此不再赘述。

步骤S404：账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知。

这里，预先配置的用于控制拉取消息的消费消息参数，可以在消息中间件预先设置的配置文件中进行配置，其中，根据账务服务端的数据库服务器处理数据的性能，设置相关的消费消息参数，消费消息参数包括消费线程数、最优消费线程数。消息中间件根据账务服务端的数据库服务器处理数据能力，开启最优消费线程数来处理消息中间件中的转账事务消息，在实际应用中，如果账务服务端的数据库服务器处理能力一般，并且因存在多个账户向热点账户转账，数据库锁等待严重等状况，则消息中间件的消费线程数可以适度调小，例如可以设置40个消费线程数；如果账务服务端数据库使用的是大型数据库，服务器性能较高，且不存在热点账户，则可将消息中间件的消费线程数调大，例如100个消费线程数。

此外，当账务服务端从消息中间件拉取转账事务消息失败时，根据预设的消息重试策略，账务服务端可以重新从消息中间件拉取所述转账事务消息。具体地，在实际应用中，账务服务端可能由于自身冲突或者网络不稳定等原因，不能成功从消息中间件拉取转账事务消息，这时，通过预设的消息重试策略，账务服务端可以重新从消息中间件拉取所述转账事务消息，该消息重试策略可以包括但不限于重新拉取转账事务消息的延迟时间以及剩余次数。如果转账事务消息重试多次后仍失败，则会将该转账事务消息放入到消息中间件的死信队列中，账务服务端恢复正常后，人工在消息中间件控制台点击重新消费即可。以确保消息中间件的所有转账事务消息都可以被成功消费执行。

可以理解的是，预设的消息重试策略可以通过现有技术的进行配置，用户可以根据实际需要进行配置消息重试策略，在此不再赘述。

此外，这里，账务服务端执行拉取的所述转账事务消息的方法可以实施为如图3所示的方法300。

步骤S405：所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

综上，本申请实施例中，以消息中间件作为交易服务端向账务服务端发送转账请求的缓冲，可以减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，可以支持大并发转账请求下的虚拟账户的转账实现，同时，交易服务端对已经成功提交至消息中间件的转账请求先进行本地事务处理，并向用户终端反馈转账请求状态，可以使用户及时了解其账户转账状态，提升了用户体验。

如图5所示，图5示出了根据本申请一些实施例的方法500的流程图。在本申请一些实施例中，该虚拟账户转账方法500具体包括：

步骤S501：交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件。

这里，消息中间件接收到转账事务消息，对该转账事务消息进行持久化处理，保存该转账事务消息。其中，该转账事务消息对账务服务端不可见，账务服务端无法拉取该转账事务消息，该转账事务消息可以看作预转账事务消息。消息中间件可以向交易服务端反馈发送转账事务消息是否成功的信息。

步骤S502：当交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息时，交易服务端标记所述转账请求的状态为初始状态，将标记为初始状态的转账事务消息发送至所述消息中间件。

这里，当交易服务端接收到所述消息中间件反馈的发送成功的信息时，交易服务端保存转账请求的数据至交易服务端的数据库，并向提交转账请求的用户即用户终端设备返回转账请求受理成功的信息，用户可以及时了解其账户转账的状态，优化了用户体验。

此外，当所述交易服务端接收到所述消息中间件反馈的发送失败的信息时，执行交易服务端向所述用户返回转账请求受理失败的信息。

步骤S503：当所述交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件失败时，所述消息中间件向所述交易服务端发送转账事务消息回查请求。

步骤S504：所述交易服务端接收到所述转账事务消息回查请求，查询所述转账事务消息的状态。

步骤S505：当查询所述转账事务消息的状态为初始状态时，所述交易服务端将所述转账事务消息发送至所述消息中间件。

这里，在实际应用中，交易服务端发生故障重启，导致没有将已标记的转账事务消息发送至消息中间件时，消息中间件可以通过消息回查，发现遗漏的转账事务消息，重新将该转账事务消息发送至消息中间件，以供账务服务端消费执行，保证交易服务端和账务服务端对该转账事务消息的可见一致性，保证所有转账请求可以被处理并记录。

步骤S506：账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知。

这里，预先配置的用于控制拉取消息的消费消息参数，可以在消息中间件预先设置的配置文件中进行配置，其中，根据账务服务端的数据库服务器处理数据的性能，设置相关的消费消息参数，消费消息参数包括消费线程数、最优消费线程数。具体地，通过修改最优消费线程数以调节账务服务端拉取转账事务消息。

此外，当账务服务端从消息中间件拉取转账事务消息失败时，根据预设的消息重试策略，账务服务端可以重新从消息中间件拉取所述转账事务消息。具体地，在实际应用中，账务服务端可能由于自身冲突或者网络不稳定等原因，不能成功从消息中间件拉取转账事务消息，这时，通过预设的消息重试策略，账务服务端可以重新从消息中间件拉取所述转账事务消息，该消息重试策略可以包括但不限于重新拉取转账事务消息的延迟时间以及剩余次数。如果转账事务消息重试多次后仍失败，则会将该转账事务消息放入到消息中间件的死信队列中，账务服务端恢复正常后，人工在消息中间件控制台点击重新消费即可。以确保消息中间件的所有转账事务消息都可以被成功消费执行。

可以理解的是，预设的消息重试策略可以通过现有技术的进行配置，用户可以根据实际需要进行配置消息重试策略，在此不再赘述。

此外，这里，账务服务端执行拉取的所述转账事务消息的方法可以实施为如图3所示的方法300。

步骤S507：所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

综上，本申请实施例中，消息中间件作为交易服务端向账务服务端发送转账请求的缓冲，可以减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，同时，交易服务端发生故障重启，导致没有将已标记的转账事务消息发送至消息中间件是，消息中间件可以通过消息回查，发现遗漏的转账事务消息，重新将该转账事务消息发送至消息中间件，以供账务服务端消费执行，保证交易服务端和账务服务端对该转账事务消息的可见一致性，保证所有转账请求可以被处理并记录。

在本申请实施例中，如图6所示，图6示出了本申请一些实施例的虚拟账户转账系统中虚拟账户转账执行的示意性时序图。

具体地，虚拟账户转账系统600包括交易服务端120、消息中间件130、账务服务端140以及用户终端110。交易服务端120用于接收和处理用户终端110提交或者发送的转账请求，并向用户终端110反馈转账请求处理状态等信息；账务服务端140用来记录用户的交易明细及余额，其中，虚拟账户之间的转账作为一种业务场景，在虚拟账户转账系统600的账务服务端的数据库的处理中，数据从一个账户转出，或者有数据转入一个账户，账户都会收到转账请求，并都有一个转账处理的过程。转账处理过程主要包括两部分，一是记录转账凭证，二是更新账户的余额。消息中间件130用于交易服务端120和账务服务端140之间的转账事务消息通信传递，消息中间件130可以选用支持数据落磁盘持久化、事务消息以及消息失败重试功能的消息中间件，例如，RokcetMQ等消息中间件。

具体地，交易服务端在接收到用户的转账请求后，将该转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件。消息中间件接收到转账事务消息，对该转账事务消息进行持久化处理，保存该转账事务消息。其中，该转账事务消息对账务服务端不可见，账务服务端无法拉取该转账事务消息，该转账事务消息可以看作预转账事务消息。消息中间件可以向交易服务端反馈发送转账事务消息是否成功的信息。

当交易服务端接收到所述消息中间件反馈的发送成功的信息时，交易服务端标记所述转账请求的状态为初始状态，将标记为初始状态的转账事务消息发送至所述消息中间件。初始状态表示已受理所述转账请求，当交易服务端接收到所述消息中间件反馈的发送成功的信息时，交易服务端可以在本地执行该转账事务消息，具体地，交易服务端保存转账请求的数据至交易服务端的数据库，并向提交转账请求的用户即用户终端设备返回转账请求受理成功的信息，用户可以及时了解其账户转账的状态，优化了用户体验。当所述交易服务端接收到所述消息中间件反馈的发送失败的信息时，执行交易服务端向所述用户返回转账请求受理失败的信息。

交易服务端将标记为初始状态的转账事务消息发送至消息中间件后，消息中间件可以将该转账事务消息标记为对账务服务端可见的转账事务消息，该转账事务消息可以供账务服务端拉取并执行。

另一方面，如果交易服务端因为设备重启或者网络不稳定等问题，未能将标记为初始状态的转账事务消息发送至消息中间件，即发送转账事务消息至消息中间件失败时，消息中间件向交易服务端发送转账事务消息回查请求。交易服务端接收到所述转账事务消息回查请求，查询该转账事务消息的状态。如果交易服务端已执行该转账事务消息，并标记该转账事务消息的状态为初始状态时，交易服务端将该转账事务消息发送至消息中间件。

这里，在实际应用中，交易服务端发生故障重启，导致没有将已标记的转账事务消息发送至消息中间件时，消息中间件可以通过消息回查，发现遗漏的转账事务消息，重新将该转账事务消息发送至消息中间件，以供账务服务端消费执行，保证交易服务端和账务服务端对该转账事务消息的可见一致性，保证所有转账请求可以被处理并记录。

进一步地，消息中间件接收到该转账事务消息，该转账事务消息可以供账务服务端拉取并执行。账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取所述转账事务消息。

预先配置的用于控制拉取消息的消费消息参数，可以在消息中间件预先设置的配置文件中进行配置，其中，根据账务服务端的数据库服务器处理数据的性能，设置相关的消费消息参数，消费消息参数包括最优消费线程数。消息中间件根据账务服务端的数据库服务器处理数据能力，开启最优消费线程数来处理消息中间件中的转账事务消息，在实际应用中，如果账务服务端的数据库服务器处理能力一般，并且因存在多个账户向热点账户转账，数据库锁等待严重等状况，则消息中间件的消费线程数可以适度调小，例如可以设置40个消费线程数；如果账务服务端数据库使用的是大型数据库，服务器性能较高，且不存在热点账户，则可将消息中间件的消费线程数调大，例如可以设置100个消费线程数。

此外，当账务服务端从消息中间件拉取转账事务消息失败时，根据预设的消息重试策略，账务服务端可以重新从消息中间件拉取所述转账事务消息。具体地，在实际应用中，账务服务端可能由于自身冲突或者网络不稳定等原因，不能成功从消息中间件拉取转账事务消息，这时，通过预设的消息重试策略，账务服务端可以重新从消息中间件拉取所述转账事务消息，该消息重试策略可以包括但不限于重新拉取转账事务消息的延迟时间以及剩余次数。如果转账事务消息重试多次后仍失败，则会将该转账事务消息放入到消息中间件的死信队列中，账务服务端恢复正常后，人工在消息中间件控制台点击重新消费即可。以确保消息中间件的所有转账事务消息都可以被成功消费执行。

进一步地，账务服务端执行拉取的转账事务消息，处理转账请求，更新并记录账务服务端的数据库的转账账户数据。

具体地，首先，校验转账账户的参数信息与业务状态。转账账户的参数信息可以包括转账账户的账号，校验转账双方账户账号是否为空，账号长度是否正常；转账账户的业务状态包括出金账户和入金账户业务状态，校验转账双方账户，即出金账户和入金账户是否为被注销状态，出金账户的余额是否可用。

如果参数校验和业务校验的结果均为正常，则将转账双方账户的账号排序，转账事务消息中包括转账双方账户的账号，账务服务端获取到转账账户的账号后，根据转账双方的账户账号的大小进行排序，确定账号顺序。根据账号顺序可以按顺序对相应地转账账户进行加锁操作，以便于避免账务服务端执行转账操作时发生死锁状况。可以理解的是，排序是根据转账双方的账号，不区分出金账户或者入金账户，仅区分账号的大小。

进一步地，账务服务端根据排序的结果和预设的加锁顺序，锁定该账号对应的转账账户。为了保证账户不被其他请求影响数据的准确性，在进行转账处理时，会先对转账账户的数据加锁，转账处理完毕后会自动释放锁。具体地，确定了转账双方的账户账号的大小排序，结合预设的加锁顺序，依次对转账双方的账户进行加锁操作，以减少账务服务端执行转账操作时死锁状况的发生。

进一步地，账务服务端获取出金账户的余额，确定出金账户的余额是否可用。这里，账务服务端获取到出金账户的余额，该余额为执行转账操作前的余额，确定出金账户的余额是否可用。由于转账请求为并发，在执行转账操作前确认出金账户的余额，以防止出金账户的余额为负数。确定出金账户的余额可用后，根据转账事务消息，分别更新出金账户的余额与入金账户的余额。账务服务端保存转账账户的转账记录至账务服务端的数据库中，完成执行该转账事务消息。账务服务端完成执行该转账事务消息后向所述交易服务端反馈转账成功通知，交易服务端变更该转账请求的状态为转账成功状态，完成转账。

综上，本申请实施例中的虚拟账户转账系统，应用上述实施例中的虚拟账户转账方法，以使账务服务端可以应对大并发转账场景，通过将大量转账请求缓冲到消息中间件磁盘，交易服务端与账务服务端的通信使用了消息中间件的事务消息，根据账务服务端实际的处理能力，开启合适的消费线程数去处理转账请求，减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，同时，也可以避免账务服务端闲置情况出现。

如图7所示，图7示出了本申请一些实施例的虚拟账户转账装置700的示意图。本申请实施例中，一种虚拟账户转账装置700包括：

发送模块701，用于交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件；

第一标记模块702，用于所述交易服务端接收到所述消息中间件反馈的发送成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

执行模块703，用于账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

第二标记模块704，用于所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

本申请实施例中，上述虚拟账户转账装置可以执行虚拟账户转账方法，以使账务服务端可以应对大并发转账场景，通过将大量转账请求缓冲到消息中间件磁盘，交易服务端与账务服务端的通信使用了消息中间件的事务消息，根据账务服务端实际的处理能力，开启合适的消费线程数去处理转账请求，减轻大批量转账请求蜂拥至账务服务端而给账务服务端的数据库带来的数据处理的压力、降低账务服务端崩溃的风险，同时，也可以避免账务服务端闲置情况出现。

本申请实施例还提供一种计算机可读介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时使得所述处理器执行如上述实施例所述的虚拟账户转账的方法中的步骤。实际应用中，所述的计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或多个程序被执行时，实现根据参考图7所描述的虚拟账户转账装置进行虚拟账户转账的方法。

根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

如图8所示，图8为本发明一些实施例中电子设备800的结构示意图。本申请实施例还提供一种电子设备，该电子设备包括上述计算机可读介质801，还包括可执行所述计算机可读存储介质的处理器802。实际应用中，该电子设备可以是一台或多台计算机，只要包括上述计算机可读介质和处理器即可。

另外，本申请所述的方法步骤除了可以用数据处理程序来实现，还可以由硬件来实现，例如，可以由逻辑门、开关、专用集成电路(ASIC)、可编程逻辑控制器和嵌微控制器等来实现。因此这种可以实现本申请所述方法的硬件也可以构成本申请。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种虚拟账户转账方法，其特征在于，所述方法包括：

交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件，所述消息中间件作为所述交易服务端向账务服务端发送转账请求的缓冲；

所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，所述交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

所述账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

2.根据权利要求1所述的方法，其特征在于，所述账务服务端执行拉取的所述转账事务消息的步骤包括：

校验转账账户的参数信息与业务状态，所述转账事务消息的信息包括所述转账账户的参数信息与业务状态，所述转账账户包括出金账户和入金账户；

当校验结果为正常时，则将所述转账账户的账号进行排序；

根据所述排序的结果和预设的加锁顺序，锁定所述账号对应的转账账户；

获取所述出金账户的余额，确定所述出金账户的余额是否可用；

当所述出金账户的余额可用时，根据所述转账事务消息，分别更新所述出金账户的余额与所述入金账户的余额；

保存所述转账账户的转账记录，完成执行所述转账事务消息。

3.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：当所述交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件失败时，所述消息中间件向所述交易服务端发送转账事务消息回查请求；

所述交易服务端接收到所述转账事务消息回查请求，查询所述转账事务消息；

当所述转账事务消息的状态为初始状态时，所述交易服务端将所述转账事务消息发送至所述消息中间件。

4.根据权利要求1所述的方法，其特征在于，当所述账务服务端从所述消息中间件拉取被标记为初始状态的所述转账事务消息失败时，所述方法进一步包括：

根据预设的消息重试策略，所述账务服务端重新从所述消息中间件拉取所述转账事务消息。

5.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

当所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息时，所述交易服务端向所述用户返回转账请求受理成功的信息；

当所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息失败的信息时，所述交易服务端向所述用户返回转账请求受理失败的信息。

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

根据所述账务服务端的数据库的性能，设置所述消费消息参数，其中，所述消费消息参数包括消费线程数。

7.一种虚拟账户转账装置，其特征在于，所述装置包括：

发送模块，用于交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件，所述消息中间件作为所述交易服务端向账务服务端发送转账请求的缓冲；

第一标记模块，用于所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，所述交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

执行模块，用于所述账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

第二标记模块，用于所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

8.一种虚拟账户转账系统，其特征在于，所述系统包括：交易服务端、消息中间件、账务服务端以及用户终端，其中：

交易服务端在接收到用户的转账请求后，将所述转账请求的转账事务消息发送至用于对消息传递进行控制的消息中间件，所述消息中间件作为所述交易服务端向账务服务端发送转账请求的缓冲；

所述交易服务端接收到所述消息中间件反馈的发送所述转账事务消息成功的信息，标记所述转账请求的状态为初始状态，所述初始状态表示已受理所述转账请求，所述交易服务端将标记为初始状态的转账事务消息发送至所述消息中间件；

所述账务服务端根据预先配置的用于控制拉取消息的消费消息参数，从所述消息中间件拉取被标记为初始状态的所述转账事务消息，并在执行拉取的所述转账事务消息后向所述交易服务端反馈转账成功通知；

所述交易服务端变更所述转账请求的状态为转账成功状态，完成转账。

9.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时可实现权利要求1至6任一项所述的虚拟账户转账方法中的步骤。

10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6中任一所述的虚拟账户转账方法。