交易处理方法和装置

技术领域

本申请涉及互联网和大数据技术领域，尤其涉及一种交易处理方法和装置。

背景技术

热点账户是指被高频更新的账户，比如，当短时间内大量的账户余额更新请求集中在某个账户上时，该账户可被称为热点账户。其中，热点账户可以包括加频账户、减频账户和双频账户，加频账户为余额增加频繁的账户，减频账户为余额减少频繁的账户，双频账户为余额增加、扣减均频繁的账户。

相关技术中，由于热点账户的交易请求的数量较多，为了保证每一笔交易请求均被受理，可以通过缓冲方案，对热点账户的交易请求进行处理。比如，在热点账户的交易请求的数量小于100笔/秒时，金融机构(如银行)的核心业务系统可以对热点账户的各个交易请求进行正常处理，而在热点账户的交易请求的数量大于100笔/秒(如120笔/秒)时，核心业务系统可以对热点账户的100个交易请求进行正常处理，并将剩余的20个交易请求添加至处理队列中，等交易请求的并发数量较小时，再对处理队列中的各个交易请求进行处理。

虽然上述方式能够保证每笔交易请求均被处理，但是处理队列中的交易请求是核心业务系统异步处理的，异步处理方式对于减频账户而言，容易出现账户透支的风险。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

本申请提出一种交易处理方法和装置，以通过在分布式共享内存中存储各个热点账户的实际账户余额，可以实现在分布式共享内存中实现原子性的账户余额的检查与更新，借助分布式共享内存的高速读写能力，可以解决高并发场景下数据库行锁带来的性能问题，同时也可以避免高并发场景下，缓冲方案扣减账户余额带来的金额透支问题。

本申请第一方面实施例提出了一种交易处理方法，包括：

获取第一交易请求；其中，所述第一交易请求中携带第一账户标识和第一交易信息；

在所述第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态；其中，所述分布式共享内存中存储有至少一个热点账户的账户余额；

在所述分布式共享内存处于可用状态，且所述分布式共享内存中所述第一目标账户的第一账户余额大于或等于所述第一交易信息中的第一交易金额时，根据所述第一交易金额对所述第一账户余额进行更新；

对所述第一交易请求所涉及的第一交易业务进行处理，并响应于所述第一交易业务处理完毕，确定所述第一交易请求处理成功。

本申请第二方面实施例提出了一种交易处理装置，包括：

获取模块，用于获取第一交易请求；其中，所述第一交易请求中携带第一账户标识和第一交易信息；

判断模块，用于在所述第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态；其中，所述分布式共享内存中存储有至少一个热点账户的账户余额；

更新模块，用于在所述分布式共享内存处于可用状态，且所述分布式共享内存中所述第一目标账户的第一账户余额大于或等于所述第一交易信息中的第一交易金额时，根据所述第一交易金额对所述第一账户余额进行更新；

第一处理模块，用于对所述第一交易请求所涉及的第一交易业务进行处理，并响应于所述第一交易业务处理完毕，确定所述第一交易请求处理成功。

本申请第三方面实施例提出了一种电子设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本申请第一方面实施例提出的交易处理方法。

本申请第四方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请第一方面实施例提出的交易处理方法。

本申请第五方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如本申请第一方面实施例提出的交易处理方法。

本申请上述实施例提供的技术方案至少带来以下有益效果：

1、通过在分布式共享内存中存储各个热点账户的实际账户余额，可以实现在分布式共享内存中实现原子性的账户余额的检查与更新，借助分布式共享内存的高速读写能力，可以解决高并发场景下数据库行锁带来的性能问题，同时也可以避免高并发场景下，缓冲方案扣减账户余额带来的金额透支问题。

2、基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对交易请求进行处理，可以降低金融机构的核心业务系统的风险，提升交易成功率。并且，在分布式共享内存中没有热点账户的账户余额的情况下，对采用余额同步机制，对分布式共享内存中热点账户的账户余额进行更新，不仅可以提升交易请求的处理效率，还可以提升交易成功率。

3、基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对余额查询请求进行处理，以提升账户余额的查询效率。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例所提供的一种交易处理方法的流程示意图；

图2为本申请实施例所提供的另一种交易处理方法的流程示意图；

图3为本申请实施例所提供的另一种交易处理方法的流程示意图；

图4为本申请实施例所提供的另一种交易处理方法的流程示意图；

图5a为本申请实施例所提供的热点账户的创建和更新流程示意图；

图5b为本申请实施例所提供的一种交易请求的处理流程示意图；

图6为本申请实施例所提供的另一种交易处理方法的流程示意图；

图7为本申请实施例所提供的另一种交易请求的处理流程示意图；

图8为本申请实施例所提供的另一种交易处理方法的流程示意图；

图9为本申请实施例所提供的热点账户的余额查询流程示意图；

图10为本申请实施例所提供的一种交易处理装置的结构示意图；

图11是本申请一示例性实施例所示出的电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

由于一个账户在同一时间只能被一个进程占有做账务更新，当短时间内大量进程请求更新时，就会出现锁等待导致锁冲突、交易超时等问题。在一些常用高频交易并发处理过程中，账户撞锁逐渐成为约束交易成功率和吞吐量的瓶颈。此类账户被视为热点账户，此类交易被视为热点账户交易。

相关技术中，主要通过以下两种交易方案，对热点账户和非热点账户进行账务处理：

第一种，限流：通过压测等手段找出账务系统能够正常处理的极限值，然后允许正常处理范畴内的交易请求(即，交易请求的数量小于极限值)进入账务系统，并丢弃超出正常处理能力的交易请求。

上述方案的本质是牺牲了一部分业务体验，以保障账户系统的正常运行。但该方案存在的技术问题是，不能保障每一笔交易请求均被受理，导致热点账户的处理速度和成功率较低。

第二种，缓冲：假如账务系统对同一个账户的处理阈值为100笔/秒，24小时不间断服务一天能处理8640000笔，并且，当业务高峰期来临时，热点账户的交易请求的数量会达到200笔/秒。若某个账户的交易请求的数量低于100笔/秒，则账务系统几乎还是能够实时地处理该账户的各个交易请求，而当某个账户的交易请求的数量大于100笔/秒时，账务系统先返回结果，将各个交易请求添加至可靠的处理队列中，等交易请求的并发数量不大时，再对处理队列中的各个交易请求进行处理。

虽然该方案能够保证每笔交易请求均可被处理，但是该方案不适用于减频账户场景，容易出现账户透支的风险。

比如，对于银证转账的保证金账户(券商开立在银行的保证金账户)，在证券交易火热时，如果采用缓冲方案，则可能会出现客户转入资金的交易请求(或业务请求)不能被及时处理，导致客户无法买入证券，影响客户体验。

针对上述存在的至少一项问题，本申请提出一种交易处理方法和装置。

下面参考附图描述本申请实施例的交易处理方法和装置。

图1为本申请实施例所提供的一种交易处理方法的流程示意图。

本申请实施例以该交易处理方法被配置于交易处理装置中来举例说明，该交易处理装置可以应用于任一电子设备中，以使该电子设备可以执行交易处理功能。

其中，电子设备可以为任一具有计算能力的设备，例如可以为个人电脑、服务器、移动终端等，移动终端例如可以为手机、平板电脑、个人数字助理、穿戴式设备、智能机器人等具有各种操作系统、触摸屏和/或显示屏的硬件设备。

如图1所示，该交易处理方法可以包括以下步骤：

步骤S101，获取第一交易请求；其中，第一交易请求中携带第一账户标识和第一交易信息。

在本申请实施例中，第一账户标识，用于唯一标识对应的账户(本申请中记为第一目标账户)，比如，第一账户标识可以为第一目标账户的账户账号。

在本申请实施例中，第一交易信息可以包括交易流水号、交易金额、交易时间、交易序号(或称为序列号，用于指示该第一交易请求是第一目标账户的第几笔交易请求)等等。

以该交易处理方法应用于金融机构(如银行)的核心业务系统进行示例性说明，第一交易请求可以为客户端(如手机银行、支付宝、淘宝等)通过不同的渠道发送至核心业务系统的，或者，也可以为清算平台或结算平台发送至核心业务系统的。

步骤S102，在第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态。

在本申请实施例中，分布式共享内存(例如Redis(Remote Dictionary Server，远程字典服务))中存储有至少一个热点账户的账户余额。

在本申请实施例中，在获取到第一交易请求后，可以根据第一交易请求中的第一账户标识，判断该第一账户标识对应的第一目标账户是否为热点账户，若该第一目标账户是热点账户，则可以进一步判断分布式共享内存是否处于可用状态(或有效状态)。

步骤S103，在分布式共享内存处于可用状态，且分布式共享内存中第一目标账户的第一账户余额大于或等于第一交易信息中的第一交易金额时，根据第一交易金额对第一账户余额进行更新。

在本申请实施例中，在分布式共享内存处于可用状态时，可以进一步从分布式共享内存中获取第一目标账户的账户余额(本申请中记为第一账户余额)，并判断第一账户余额是否大于或等于第一交易信息中的第一交易金额。

如果第一账户余额大于或等于第一交易金额，则表明第一目标账户的可用余额充足，此时，可以根据第一交易金额对分布式共享内存中的第一账户余额进行更新，例如，可以将分布式共享内存中的第一目标账户的第一账户余额减去第一交易金额，以得到分布式共享内存中该第一目标账户对应的更新后的第一账户余额。

而如果第一账户余额小于第一交易金额，则表明第一目标账户的可用余额不足，此时，可以确定第一交易请求处理失败(或称为交易失败)，以及处理失败原因(或称为交易失败原因)为余额不足。由此，可以避免余额不足而导致金额透支的情况发生。

步骤S104，对第一交易请求所涉及的第一交易业务进行处理，并响应于第一交易业务处理完毕，确定第一交易请求处理成功。

在本申请实施例中，在对分布式共享内存中第一目标账户的第一账户余额进行更新之后，还可以对第一交易请求进行正常业务处理，即，对第一交易请求所涉及的第一交易业务进行处理，例如，当第一交易请求的交易类型为借记(如支取账户金额)时，还可以在账务系统的数据库或分布式共享内存中添加交易明细信息(或称为账户明细信息，如扣减金额、扣减时间、扣减前的金额、扣减后的金额等)等。

在本申请实施例中，当第一交易业务处理完毕时，可以确定第一交易请求处理成功。

本申请实施例的交易处理方法，通过获取第一交易请求；其中，第一交易请求中携带第一账户标识和第一交易信息；在第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态；其中，分布式共享内存中存储有至少一个热点账户的账户余额；在分布式共享内存处于可用状态，且分布式共享内存中第一目标账户的第一账户余额大于或等于第一交易信息中的第一交易金额时，根据第一交易金额对第一账户余额进行更新；对第一交易请求所涉及的第一交易业务进行处理，并响应于第一交易业务处理完毕，确定第一交易请求处理成功。由此，通过在分布式共享内存中存储各个热点账户的实际账户余额，可以实现在分布式共享内存中实现原子性的账户余额的检查与更新，借助分布式共享内存的高速读写能力，可以解决高并发场景下数据库行锁带来的性能问题，同时也可以避免高并发场景下，缓冲方案扣减账户余额带来的金额透支问题。

为了清楚说明本申请上述实施例，本申请还提出一种交易处理方法。

图2为本申请实施例所提供的另一种交易处理方法的流程示意图。

如图2所示，该交易处理方法可以包括以下步骤：

步骤S201，获取第一交易请求；其中，第一交易请求中携带第一账户标识、第一交易类型和第一交易信息。

其中，第一交易类型为借记(如支取金额)，第一交易信息中至少包括第一交易金额。

步骤S201的解释说明可以参见本申请任一实施例中的相关描述，在此不做赘述。

步骤S202，根据第一账户标识查询标识表，以确定第一账户标识是否位于标识表。

其中，标识表中包括至少一个热点账户的账户标识。其中，标识表可以存储于数据库中，或者，也可以存储于独立于数据库的存储设备中。

其中，数据库和分布式共享内存可以为金融机构的核心业务系统侧的两个互相独立的存储空间。

其中，标识表中的各个热点账户的账户标识可以由相关人员根据人工经验设置，或者，也可以根据各个账户的交易量设置(比如，可以将一段时间内发送交易请求的数量相对较大的账户作为热点账户)，或者，也可以根据各个账户的抢锁失败的次数设置(比如，可以将抢锁失败次数相对较多的账户作为热点账户)，或者，可以根据各个账户的锁等待时长设置，等等，本申请对此并不作限制。

在本申请实施例中，可以根据第一账户标识查询标识表，以确定该第一账户标识是否位于标识表中，若第一账户标识位于该标识表中，则确定该第一目标账户为热点账户，而若第一账户标识未位于该标识表中，则确定该第一目标账户不为热点账户。

步骤S203，若第一账户标识位于标识表，则确定第一目标账户为热点账户，并根据第一交易信息，在数据库中的未入账明细表中插入第一未入账明细，并设置第一未入账明细的状态为在途状态。

在本申请实施例中，未入账明细表中包括多个账户的未入账明细，其中，每个未入账明细的状态可以包括在途状态(用于指示对应未入账明细处于联机处理的过程中，或者，用于指示未入账明细对应的交易请求(或交易业务)处于处理进行中)、待补账状态(或称为待入账状态)和入账状态(或称为已入账状态)。

在本申请实施例中，在第一目标账户为热点账户时，可以根据第一交易信息，在数据库中的未入账明细表中插入第一未入账明细，比如，可以根据第一交易信息中的交易序号(或称为序列号、自增序列号)，在未入账明细表中插入第一未入账明细(可包括交易金额、交易时间等信息)。并且，还可以将未入账明细表中的第一未入账明细的状态设置为在途状态。

步骤S204，判断分布式共享内存是否处于可用状态，若是，则执行步骤S205，若否，则执行步骤S209。

其中，分布式共享内存中存储有至少一个热点账户的账户余额。

需要说明的是，步骤S205与步骤S209为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S205，判断分布式共享内存中第一目标账户的第一账户余额是否大于或等于第一交易金额，若是，则执行步骤S206至S207，若否，则执行步骤S208。

需要说明的是，步骤S206至S207与步骤S208为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S206，根据第一交易金额对分布式共享内存中的第一账户余额进行更新，并对第一交易请求所涉及的第一交易业务进行处理。

步骤S206的解释说明可以参见本申请任一实施例中的相关描述，在此不做赘述。

步骤S207，响应于第一交易业务处理完毕，确定第一交易请求处理成功，响应于第一交易业务处理失败，确定第一交易请求处理失败，以及处理失败原因为非余额不足。

可以理解的是，当第一账户余额大于或等于第一交易金额时，表明第一目标账户的可用余额充足，如果第一交易业务处理失败，则可能发生网络异常、故障等异常情况而导致交易失败，此时，可以确定处理失败原因(或交易失败原因)为非余额不足。

步骤S208，确定第一交易请求处理失败，以及处理失败原因为余额不足。

在本申请实施例中，在第一账户余额小于第一交易金额时，表明第一目标账户的可用余额不足，此时，为了避免账户余额透支的情况发生，可以确定第一交易请求处理失败，以及处理失败原因为余额不足。

步骤S209，从未入账明细表中与第一目标账户关联的各个未入账明细中，确定第三未入账明细。

在本申请实施例中，在分布式共享内存为不可用状态(或失效状态)时，可以从数据库的未入账明细表中确定与第一目标账户关联的各个未入账明细(比如，各个未入账明细中可以包括账户标识，可以根据第一目标账户的第一账户标识，从未入账明细表中确定与第一账户标识匹配的各个未入账明细)，并从与第一目标账户关联的各个未入账明细中确定第三未入账明细，其中，第三未入账明细的状态包括在途状态和待补账状态。

步骤S210，根据第三未入账明细确定第二发生额，并从数据库的账户余额表中获取第一目标账户的第三账户余额。

在本申请实施例中，可以对各个第三未入账明细中的交易金额进行汇总，以得到第二发生额，并从数据库的账户余额表中，获取第一目标账户的账户余额(本申请中记为第三账户余额)。

步骤S211，在第三账户余额和第二发生额，确定第一目标账户的第二可用余额。

在本申请实施例中，可以将第三账户余额和第二发生额，确定第一目标账户的第二可用余额。例如，第二可用余额＝第三账户余额-第二发生额。

步骤S212，判断第二可用余额是否为负值，若否，则执行步骤S213，若是，则执行步骤S208。

需要说明的是，步骤S213与步骤S208为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S213，对第一交易请求所涉及的第二交易业务进行处理，并响应于第二交易业务处理完毕，确定交易成功，响应于第二交易业务处理失败，确定第一交易请求处理失败，以及处理失败原因为非余额不足。

在本申请实施例中，在第二可用余额不为负值时，表明第一目标账户的可用余额充足，此时，可以对第一交易请求所涉及的第二交易业务进行处理，其中，第二交易业务的处理方式与第一交易业务的处理方式类似，在此不做赘述。

在本申请实施例中，在第二交易业务处理完毕时，可以确定交易成功，而在第二交易业务处理失败时，可确定第一交易请求处理失败，以及处理失败原因为非余额不足。

在本申请的任意一个实施例之中，当第二可用余额不为负值，且分布式共享内存从不可用状态恢复为可用状态时，还可以根据第二可用余额对分布式共享内存中第一目标账户的账户余额进行更新。

本申请实施例的交易处理方法，可以实现基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对交易请求进行处理，可以降低金融机构的业务系统的风险，提升交易成功率。

为了清楚说明上述实施例，本申请还提出一种交易处理方法。

图3为本申请实施例所提供的另一种交易处理方法的流程示意图。

如图3所示，该交易处理方法可以包括以下步骤：

步骤S301，获取第一交易请求；其中，第一交易请求中携带第一账户标识、第一交易类型和第一交易信息。

其中，第一交易类型为借记。

步骤S302，在第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态。

其中，分布式共享内存中存储有至少一个热点账户的账户余额。

步骤S301至S302的解释说明可以参见本申请任一实施例中的相关描述，在此不做赘述。

步骤S303，在分布式共享内存处于可用状态时，判断分布式共享内存中是否存在第一目标账户对应的账户余额，若是，则执行步骤S304，若否，则执行该步骤S306。

需要说明的是，步骤S304与步骤S306为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S304，将第一目标账户对应的账户余额作为第一账户余额，并判断第一账户余额是否大于或等于第一交易金额，若是，则执行步骤S305，若否，则执行步骤S311。

在本申请实施例中，在分布式共享内存中存在第一目标账户对应的账户余额时，可以将分布式共享内存中该第一目标账户对应的账户余额，作为第一账户余额，并判断第一账户余额是否大于或等于第一交易金额，若是，则执行步骤S305，若否，则执行步骤S311。

需要说明的是，步骤S305与步骤S311为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S305，根据第一交易金额，对分布式共享内存中的第一账户余额进行更新。

步骤S306，从数据库的账户余额表中获取第一目标账户的第二账户余额，并从未入账明细表中与第一目标账户关联的各个未入账明细中，确定第二未入账明细。

需要说明的是，虽然分布式共享内存中包括各个热点账户的账户余额，但是一些异常情况可能导致分布式共享内存中仅有某些热点账户的账户信息(如账户标识等)，而丢失账户余额，此时，需要采用余额同步机制，对分布式共享内存中热点账户的账户余额进行更新。

具体地，在分布式共享内存中不存在第一目标账户对应的账户余额时，可以从数据库的账户余额表中获取第一目标账户的账户余额(本申请中记为第二账户余额)，并从未入账明细表中获取与第一目标账户关联的各个未入账明细，以及从与第一目标账户关联的各个未入账明细中，确定第二未入账明细。其中，第二未入账明细的状态包括在途状态和待补账状态。

步骤S307，根据第二未入账明细确定第一发生额，并根据第一发生额和第二账户余额，确定第一目标账户的第一可用余额。

之后，可以对各个第二未入账明细中的交易金额进行汇总，得到第一发生额，并根据第一发生额和第二账户余额，确定第一目标账户的可用余额(本申请中记为第一可用余额)。比如，第一可用余额＝第二账户余额-第一发生额。

步骤S308，判断第一可用余额是否为负值，若是，则执行步骤S311，若否，则执行步骤S309。

需要说明的是，步骤S309与步骤S311为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S309，根据第一可用余额，对分布式共享内存中第一目标账户的账户余额进行更新。

在本申请实施例中，在第一可用余额不为负值时，可以根据第一可用余额，对分布式共享内存中第一目标账户的账户余额进行更新，即，可以将第一可用余额作为分布式共享内存中第一目标账户对应的更新后的账户余额。

步骤S310，对第一交易请求所涉及的第一交易业务进行处理，并响应于第一交易业务处理完毕，确定第一交易请求处理成功，响应于第一交易业务处理失败，确定第一交易请求处理失败，以及处理失败原因为非余额不足。

步骤S311，确定第一交易请求处理失败，以及处理失败原因为余额不足。

步骤S308至S311的解释说明可以参见本申请任一实施例中的相关描述，在此不做赘述。

需要说明的是，在本申请的任意一个实施例之中，在对数据库中的账户余额表执行查询、更新等操作时，需要将该账户余额表进行锁定或加锁，以避免其他进程对账户余额表进行更新，或者，根据账户余额表，对分布式共享内存中的账户余额进行更新时，也需要锁定该账户余额表，以避免其他进程对账户余额表进行更新，而导致分布式共享内存中的账户余额与实际账户的可用余额不匹配的情况发生。

本申请实施例的交易处理方法，在分布式共享内存中没有第一目标账户的账户余额的情况下，对采用余额同步机制，对分布式共享内存中热点账户的账户余额进行更新，不仅可以提升交易请求的处理效率，还可以提升交易成功率。

为了清楚说明上述实施例，本申请还提出一种交易处理方法。

图4为本申请实施例所提供的另一种交易处理方法的流程示意图。

如图4所示，该交易处理方法可以包括以下步骤：

步骤S401，获取第一交易请求；其中，第一交易请求中携带第一账户标识和第一交易信息。

其中，第一交易信息中至少包括第一交易金额，第一交易请求中还包括第一交易类型，第一交易类型为借记。

步骤S401的解释说明可以参见本申请任一实施例中的相关描述，在此不做赘述。

步骤S402，在第一账户标识对应的第一目标账户不为热点账户时，从数据库的账户余额表中获取第一目标账户的第四账户余额。

需要说明的是，对于普通账户(即非热点账户)而言，由于普通账户的交易请求的数量不大，账户系统能够及时地对普通账户的交易请求进行处理，数据库的未入账明细表中将不包含与普通账户关联的处于在途状态和待补账状态的未入账明细，此时，普通账户的实际账户余额或可用账户余额即为账户余额表中的账户余额。

因此，在本申请实施例中，在第一账户标识对应的第一目标账户不为热点账户时，可以从数据库的账户余额表中获取第一目标账户的账户余额(本申请中记为第四账户余额)。

步骤S403，判断第四账户余额是否大于或等于第一交易金额，若是，则执行步骤S404至S406，若否，则执行步骤S407。

需要说明的是，步骤S404至S406与步骤S407为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S404，根据第一交易金额，对账户余额表中的第一目标账户的第四账户余额进行更新。

在本申请实施例中，在第四账户余额大于或等于第一交易金额时，表明第一目标账户的可用余额充足，此时，可以根据第一交易金额，对账户余额表中的第一目标账户的第四账户余额进行更新，其中，更新后的第四账户余额＝更新前的第四账户余额-第一交易金额。

步骤S405，对第一交易请求所涉及的第三交易业务进行处理。

需要说明的是，第三交易业务的处理方式与第一交易业务的处理方式类似，在此不做赘述。

步骤S406，响应于第三交易业务处理完毕，确定第一交易请求处理成功，响应于第三交易业务处理失败，确定第一交易请求处理失败，以及处理失败原因为非余额不足。

可以理解的是，当第四账户余额大于或等于第一交易金额时，表明第一目标账户的可用余额充足，如果第三交易业务处理失败，则可能发生网络异常、故障等情况而导致交易失败，此时，可以确定处理失败原因(或交易失败原因)为非余额不足。

步骤S407，确定第一交易请求处理失败，以及处理失败原因为余额不足。

在本申请实施例中，在第四账户余额小于第一交易金额时，表明第一目标账户的可用余额不足，此时，为了避免账户余额透支的情况发生，可以确定第一交易请求处理失败，以及处理失败原因为余额不足。

在本申请的任意一个实施例之中，还可以异步执行以下操作：在第一交易请求处理成功时，可以将数据库中的未入账明细表中的第一未入账明细的状态从在途状态更新为待补账状态。

在本申请的任意一个实施例之中，还可以异步执行以下操作：在第一交易请求处理失败时，可以删除数据库中的未入账明细表中的第一未入账明细，并判断第一交易请求的处理失败原因是否为非余额不足，若处理失败原因为非余额不足，则可以将本次交易扣除的第一交易金额返还至分布式共享内存中的第一目标账户，而若处理失败原因为余额不足，由于本次交易没有扣除第一交易金额，则可以无需将第一交易金额返还至分布式共享内存中的第一目标账户。

在本申请的任意一个实施例之中，还可以异步执行以下操作：在满足设定条件时，根据数据库中未入账明细表中第二目标账户的第四未入账明细，对数据库中账户余额表中第二目标账户的账户余额进行更新；其中，第二目标账户为热点账户，第四未入账明细的状态包括待补账状态。

其中，设定条件包括以下任意一项：

第一项，到达设定周期。比如，可以日终对账户余额表中各个热点账户的账户余额进行更新。

第二项，到达目标时刻，其中，目标时刻所处的时段(如非交易高峰期、交易低峰期)内接收到交易请求的数量小于设定阈值。

综上，上述延时记账方式或延时记账模式，是变更新(updata)为插入(insert)，由于同一热点账号的更新操作只能有一个线程或进程完成，所有的借记、贷记或者冲正等交易类型的交易信息，都以插入待记账明细的形式进行insert，延时记账进程通过快速的将同一热点账户的多笔交易请求的未入账明细进行汇总等机制，来准实时完成热点账户的余额更新。对于金融机构的内部账或客户账都比较适合此种延时记账模式，管理方便且可控。

进一步地，在根据第四未入账明细对账户余额表中第二目标账户的账户余额进行更新后，还可以将第四未入账明细的状态从待补账状态更新为入账状态。

本申请实施例的交易处理方法，对于普通账户(即非热点账户)，由于分布式共享内存中没有普通账户的账户余额，此时，可以基于数据库中的账户余额表和未入账明细表，来对普通账户的交易请求进行处理，可以提升交易成功率。

在本申请的任意一个实施例之中，以分布式共享内存(如Redis)为核心，对热点账户的账户余额在分布式共享内存中建立余额副本，实时记账对分布式共享内存中的余额副本进行检查与操作，同时在数据库中登记未入账明细。在联机批量异步处理中，对数据库中的账户余额表中的账户余额按照未入账明细进行补账，延时更新数据库中的账户余额表中的账户余额(即余额主本)，即延时记账。

其中，通过对账户余额在分布式共享内存中建立余额副本的方式，可在分布式共享内存中实现原子性的账户余额检查与更新，借助分布式共享内存的高速读写能力，可以解决高并发场景下数据库行锁带来的性能问题，同时也可以避免高并发扣减带来的金额透支问题。

其中，延时记账模式是变更新(update)为插入(insert)的解决方案。一个基本原则是保证同一账户的更新操作只能有一个线程完成，所有的借记、贷记或者冲正等交易类型的交易信息，都以插入未入账明细形式进行insert，延时记账进程通过快速的多笔汇总等机制来准实时完成热点账户的余额更新。对于内部账或客户账都比较适合此种延时记账模式，管理方便且可控。

作为一种示例，热点账户的创建和更新流程可以如图5a所示，可以在与账户相关的表(本申请中记为标识表)中增加热点账户的标志字段(本申请中记为账户标识)，若新增热点账户，则可以在标识表中增加该新增热点账户的标志字段。从而本申请中，可以通过标志字段判断当前账户是否为热点账户。

在将某一个账户设置为热点账户时，需要对数据库中的账户余额表进行锁定，同时，将系统日期、账户余额、上日余额(用于计息等)、上次业务日期等字段更新到分布式共享内存中。

需要说明的是，锁住账户余额表的目的为：防止在更新分布式共享内存中热点账户的账户余额时，有进程修改账户余额表，而导致分布式共享内存中的账户余额与账户余额表中的实际账户余额不一致的情况发生。

在将热点账户设置为普通账户时，即将热点账户删除，此时，同时需要对账户余额表进行锁定，并将标识表中该热点账户的账户标志修改为普通账户的账户标志。

作为一种示例，以分布式共享内存为Redis进行示例，当交易请求的交易类型为借记时，交易请求的处理流程可以如图5b所示，主要包括以下步骤：

1、在交易开始时，如接收到交易请求时，开启一个事务；

2、根据交易请求中借方账户的账户账号，判断该借方账户是否为热点账户，若该借方账户不是热点账户，则锁住并查询账户余额表，并根据交易请求中的交易金额，对账户余额表中该借方账户的账户余额进行更新，之后，可以执行正常的业务处理，如添加交易明细信息(或称为账户明细信息，如扣减金额、扣减时间、扣减前的金额、扣减后的金额等)等，在业务处理完成后，提交事务，交易完成。

3、在借方账户为热点账户时，启动热点账户处理。

4、获取交易请求中的自增序列(即交易序号(或称为序列号)，用于指示交易请求是该借方账户的第几笔交易请求)，并在独立事务(与上述开启的事务不同)中根据自增序列，在未入账明细表中插入未入账明细(状态为在途状态)。

5、判断Redis是否可用，若Redis可用，则对Redis中该借方账户加锁，并查询Redis中是否存在该借方账户的账户余额，若Redis中不存在该借方账户的账户余额，则汇总未入账明细表中该借方账户的未入账明细(在途状态和待补账状态)，得到发生额，并根据发生额和账户余额表中的该借方账户的账户余额，计算该借方账户的可用余额，若可用余额不为负值，则根据该可用余额对Redis中该借方账户的账户余额进行更新，若可用余额不为负值，则余额不足，事务回滚，交易失败。

若Redis中存在该借方账户的账户余额，则判断该账户余额是否大于或等于交易请求中的交易金额，若该账户余额大于或等于交易金额，则计算新的账户余额(即查询的账户余额-交易请求中的交易金额)，并根据新的账户余额重新设置Redis中的该账户余额。对Redis中该借方账户解锁，之后，可以在PUBCOM(全局变量)中放入该借方账户的标识信息(后续称为热点账户标识)，该热点账户处理结束，之后，可以执行正常的业务处理，在业务处理完成后，提交事务，交易完成。

若该账户余额小于交易金额，则余额不足，事务回滚，交易失败。

6、若Redis不可用，则汇总未入账明细表中该借方账户的未入账明细(在途状态和待补账状态)，得到发生额，并根据发生额和账户余额表中的该借方账户的账户余额，计算该借方账户的可用余额，并判断该借方账户的可用余额是否为负值，如果可用余额为负值，则事务回滚，交易失败，如果可用余额不为负值，则在业务处理完成后，提交事务，交易完成。

7、在交易完成后，由异步任务根据Redis中PUBCOM中的热点账户标识，将未入账明细表中该借方账户的未入账明细的在途状态更新为待补账状态。

8、借方账户明细、动账通知、核算明细等处理全部略过，由异步的延时批量处理。

9、若交易失败、异常，释放借方止付：在未入账明细表中删除本次交易添加的未入账明细(本操作在主事务回滚后处理)。

交易处理完成之后需要对未入账明细表中的未入账明细进行入账，按照账户+日期+自增序列的方式，从未入账明细表中查询与账户匹配的各个未入账明细，排序入账，即根据查找的各个未入账明细对账户余额表中的账户余额进行更新。由此，可以防止一次性入账数据量过大，降低处理负担。此外，还可以执行冲正及回退的过程。

在本申请实施例的一种可能的实现方式中，还可以基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对交易类型为贷记的交易请求进行处理，以降低金融机构的业务系统的风险，提升交易成功率。下面结合图5，对上述过程进行详细说明。

图6为本申请实施例所提供的另一种交易处理方法的流程示意图。

如图6所示，在上述任一实施例的基础上，该交易处理方法还可以包括以下步骤：

步骤S601，获取第二交易请求；其中，第二交易请求中携带第二账户标识、第二交易信息和第二交易类型，第二交易类型为贷记。

在本申请实施例中，第二账户标识，用于唯一标识对应的账户(本申请中记为第三目标账户)，比如，第二账户标识可以为第三目标账户的账户账号。

在本申请实施例中，第二交易信息可以包括交易流水号、交易金额、交易时间、交易序号(或称为序列号，用于指示该第二交易请求是第三目标账户的第几笔交易请求)等等。

在本申请实施例中，第二交易类型为贷记(如存入金额)。

步骤S602，根据第二账户标识，确定第二账户标识对应的第三目标账户是否为热点账户，若是，则执行步骤S603至S604，若否，则执行步骤S605至S607。

在本申请实施例中，可以根据第二账户标识，确定第二账户标识对应的第三目标账户是否为热点账户，比如，在第二账户标识位于标识表时，可确定第三目标账户为热点账户，在第二账户标识未位于标识表时，可确定第三目标账户不为热点账户。

需要说明的是，步骤S603至S604与步骤S605至S607为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S603，根据第二交易信息中的第二交易金额，对数据库的账户余额表中第三目标账户的第五账户余额进行更新，并对第二交易请求所涉及的第四交易业务进行处理。

在本申请实施例中，在第三目标账户不为热点账户时，可以直接根据第二交易信息中的第二交易金额，对数据库的账户余额表中第三目标账户的账户余额(本申请中记为第五账户余额)进行更新，例如，更新后的第五账户余额＝更新前的第五账户余额+第二交易金额。并且，还可以对第二交易请求所涉及的第四交易业务进行处理，其中，第四交易业务的处理方式与第一交易业务的处理方式类似，在此不做赘述。

步骤S604，响应于第四交易业务处理完毕，确定第二交易请求处理成功，响应于第四交易业务处理失败，确定第二交易请求处理失败。

在本申请实施例中，在第四交易业务处理完毕时，可以确定第二交易请求处理成功，而在第四交易业务处理失败时，可以确定第二交易请求处理失败。

步骤S605，根据第二交易信息，在数据库中的未入账明细表中插入第五未入账明细，并设置第五未入账明细的状态为在途状态。

在本申请实施例中，在第三目标账户为热点账户时，可以根据第二交易信息，在数据库中的未入账明细表中插入第五未入账明细，并设置第五未入账明细的状态为在途状态。

步骤S606，对第二交易信息所涉及的第五交易业务进行处理。

其中，第五交易业务的处理方式与第一交易业务的处理方式类似，在此不做赘述。

步骤S607，响应于第五交易业务处理完毕，确定第二交易请求处理成功，响应于第五交易业务处理失败，确定第二交易请求处理失败。

在本申请实施例中，在第五交易业务处理完毕时，可以确定第二交易请求处理成功，而在第五交易业务处理失败时，可以确定第二交易请求处理失败。

在本申请的任意一个实施例之中，还可以异步执行以下操作：在第二交易请求处理失败的情况下，可以删除未入账明细表中的第五未入账明细。

在本申请的任意一个实施例之中，还可以异步执行以下操作：在第二交易请求处理成功的情况下，将第五未入账明细从在途状态更新为待补账状态，并从未入账明细表中确定与第三目标账户关联的各个未入账明细，并从与第三目标账户关联的各个未入账明细中，确定第六未入账明细，其中，第六未入账明细的状态包括在途状态和待补账状态。

之后，可以对根据第六未入账明细中的交易金额进行汇总，以得到第四发生额，并根据第四发生额对分布式共享内存中第三目标账户的账户余额进行更新，比如，更新后的账户余额＝更新前的账户余额+第四发生额。

本申请实施例的交易处理方法，基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对交易类型为贷记的交易请求进行处理，可以降低金融机构的业务系统的风险，提升交易成功率。

在本申请的任意一个实施例之中，以分布式共享内存为Redis进行示例，当交易请求的交易类型为贷记时，交易请求的处理流程可以如图7所示，主要包括以下步骤：

1、在交易开始时，如接收到交易请求时，开启一个事务；

2、根据交易请求中贷方账户的账户账号，判断该贷方账户是否为热点账户，若该贷方账户不是热点账户，则锁住并查询账户余额表，并根据交易请求中的交易金额，对账户余额表中该贷方账户的账户余额进行更新，之后，可以执行正常的业务处理，如添加交易明细信息等，在业务处理完成后，提交事务，交易结束。

3、在借方账户为热点账户时，启动热点账户处理。

4、获取交易请求中的自增序列，并在独立事务(与上述开启的事务不同)中根据自增序列，在未入账明细表中插入未入账明细(状态为在途状态)。

5、在PUBCOM(全局变量)中放入该贷方账户的标识信息(后续称为热点账户标识)，该热点账户处理结束，之后，可以执行正常的业务处理，在业务处理完成后，提交事务，交易结束。

6、在交易完成后，可以判断交易是否成功，若交易成功，则由异步任务根据Redis中PUBCOM中的热点账户标识，将未入账明细表中该贷方账户的未入账明细的在途状态更新为待补账状态。

7、判断Redis是否可用，若Redis可用，则可以根据未入账明细表中该贷方账户的未入账明细，对Redis中该贷方账户的账户余额进行更新。

8、若交易失败，则删除未入账明细表中本次交易添加的该贷方账户的待入账明细。

在本申请实施例的一种可能的实现方式中，还可以基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对余额查询请求进行处理，以提升账户余额的查询效率。下面结合图8，对上述过程进行详细说明。

图8为本申请实施例所提供的另一种交易处理方法的流程示意图。

如图8所示，上述任一实施例的基础上，该交易处理方法还可以包括以下步骤：

步骤S801，接收余额查询请求，其中，余额查询请求中携带第三账户标识。

在本申请实施例中，第三账户标识，用于唯一标识对应的账户(本申请中记为第四目标账户)，比如，第三账户标识可以为第四目标账户的账户账号。

步骤S802，根据第三账户标识，确定第三账户标识对应的第四目标账户是否为热点账户，若是，则执行S803，若否，则执行S806至S807。

在本申请实施例中，可以根据第三账户标识，确定第三账户标识对应的第四目标账户是否为热点账户，比如，在第三账户标识位于标识表时，可确定第四目标账户为热点账户，在第三账户标识未位于标识表时，可确定第四目标账户不为热点账户。

需要说明的是，步骤S803与步骤S806至S807为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S803，判断分布式共享内存是否处于可用状态，若是，则执行S804至S805，若否，则执行S808-S811。

需要说明的是，步骤S804至S805与步骤S808-S811为并列的两种实现方式，实际应用时，仅需择一执行。

步骤S804，获取分布式共享内存中第四目标账户的第六账户余额。

在本申请实施例中，在第四目标账户为热点账户，且分布式共享内存处于可用状态时，可以获取分布式共享内存中第四目标账户的账户余额(本申请中记为第六账户余额)。

步骤S805，发送第一余额查询响应，其中，第一余额查询响应中携带第六账户余额。

在本申请实施例中，可以向发送余额查询请求的客户端或设备发送第一余额查询响应，其中，第一余额查询响应中携带第六账户余额。

步骤S806，从数据库的账户余额表中查询与第二目标账户对应的第七账户余额。

在本申请实施例中，在第四目标账户不为热点账户时，可以直接从数据库的账户余额表中查询与第二目标账户对应的第七账户余额。

步骤S807，发送第二余额查询响应，其中，第二余额查询响应中携带第七账户余额。

在本申请实施例中，可以向发送余额查询请求的客户端或设备发送第二余额查询响应，其中，第二余额查询响应中携带第七账户余额。

步骤S808，从数据库的未入账明细表中，查询与第四目标账户对应的第七未入账明细，其中，第七未入账明细处于在途状态和待补账状态。

在本申请实施例中，在第四目标账户为热点账户，且分布式共享内存处于不可用状态时，可以从数据库的未入账明细表中，查询与第四目标账户对应的第七未入账明细，其中，第七未入账明细处于在途状态和待补账状态。

步骤S809，从数据库的账户余额表中查询与第四目标账户对应的第八账户余额。

在本申请实施例中，还可以从数据库的账户余额表中查询与第四目标账户对应的账户余额(本申请中记为第八账户余额)。

步骤S810，根据第七未入账明细确定第五发生额，并根据第五发生额和第八账户余额，确定第四目标账户的第三可用余额。

在本申请实施例中，可以对第七未入账明细中的交易金额进行汇总，以得到第五发生额，并根据第五发生额和第八账户余额，确定第四目标账户的第三可用余额。例如，第三可用余额＝第五发生额+第八账户余额。

步骤S811，发送第三余额查询响应，其中，第三余额查询响应中携带第三可用余额。

在本申请实施例中，可以向发送余额查询请求的客户端或设备发送第三余额查询响应，其中，第三余额查询响应中携带第三可用余额。

本申请实施例的交易处理方法，基于两套机制(高效模式的分布式共享内存和托底模式的数据库)，对余额查询请求进行处理，以提升账户余额的查询效率。

在本申请的任意一个实施例之中，热点账户的余额查询流程可以如图9所示，可以采用对账户余额在分布式共享内存中建立余额副本，实时记账对分布式共享内存中的余额副本进行检查与操作，同时登记待补账明细。在日终批量中对数据库中的账户余额表中的各个热点账户的账户余额，按照未入账明细表中的各个未入账明细进行补账，延时更新账户余额表中的余额主本。

具体地，以分布式共享内存为Redis进行示例，在查询余额时，可以判断当前账户是否为热点账户，如果当前账户不是热点账户，则调用通用的查询组件，如果当前账户是热点账户，则根据Redis是否可用，调用不同的组件计算账户余额。

需要说明的是，以交易类型为借记进行示例，由于热点账户并发量较大，在Redis不可用时，查询的余额是账户余额扣减掉未入账明细中的金额。

综上，以交易类型为借记进行示例，通过独立事务，将本次交易的交易信息插入到未入账明细表中，当Redis可用时，通过分布式共享内存中的余额原子性的操作，极大地提高了热点账户的处理性能；当Redis不可用时，则查询数据库中账户余额表中的余额，减去未入账明细中的借方金额，判断该笔交易是否透支，至少具有以下优点：

1、Redis内存模式的高性能处理或高效模式。当Redis可用时，使用Redis的高性能处理模式。

2、未入账明细的托底模式。当Redis不可用时，通过数据库中账户余额表中的余额，减去未入账明细中的借方金额，保证账户不透支。

3、两种模式的动态切换。无需人工介入，通过判断Redis的状态，自动切换以上两种处理模式。

4、Redis内存中账户余额的动态刷新。当Redis崩溃后重启时，如果Redis内存中没有相应热点账户的信息，则自动将账户余额表的余额信息刷新到Redis内存的余额副本中。

5、提高金融机构对热点账户处理的能力。能够有效应对热点事件、突发事件、网络促销日、银证转账、资金募集等并发量较高的业务。

6、降低金融机构业务系统的风险。高效模式与托底模式并存，降低了金融机构业务系统的风险。在Redis雪崩等情况下，仍然能够有效应对热点账户业务。

与上述图1-图8实施例提供的交易处理方法相对应，本申请还提供一种交易处理装置，由于本申请实施例提供的交易处理装置与上述图1-图8实施例提供的交易处理方法相对应，因此在交易处理方法的实施方式也适用于本申请实施例提供的交易处理装置，在本申请实施例中不再详细描述。

图10为本申请实施例所提供的一种交易处理装置的结构示意图。

如图10所示，该交易处理装置1000可以包括：获取模块1010、判断模块1020、更新模块1030以及第一处理模块1040。

其中，获取模块1010，用于获取第一交易请求；其中，第一交易请求中携带第一账户标识和第一交易信息。

判断模块1020，用于在第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态；其中，分布式共享内存中存储有至少一个热点账户的账户余额。

更新模块1030，用于在分布式共享内存处于可用状态，且分布式共享内存中第一目标账户的第一账户余额大于或等于第一交易信息中的第一交易金额时，根据第一交易金额对分布式共享内存中的第一账户余额进行更新。

第一处理模块1040，用于对第一交易请求所涉及的第一交易业务进行处理，并响应于第一交易业务处理完毕，确定第一交易请求处理成功。

作为一种可能的实现方式，第一交易请求中携带有第一交易类型，第一交易类型为借记，判断模块1020，具体用于：根据第一账户标识查询标识表，以确定第一账户标识是否位于标识表；其中，标识表中包括至少一个热点账户的账户标识；在第一账户标识位于标识表时，确定第一目标账户为热点账户；根据第一交易信息，在数据库中的未入账明细表中插入第一未入账明细，并设置第一未入账明细的状态为在途状态；判断分布式共享内存是否处于可用状态。

作为一种可能的实现方式，更新模块1030，具体用于：在分布式共享内存处于可用状态时，判断分布式共享内存中是否存在第一目标账户对应的账户余额；若分布式共享内存中存在第一目标账户对应的账户余额，则将第一目标账户对应的账户余额作为第一账户余额；在第一账户余额大于或等于第一交易金额时，根据第一交易金额，对分布式共享内存中的第一账户余额进行更新。

更新模块1030，还用于：若分布式共享内存中不存在第一目标账户对应的账户余额，则从数据库的账户余额表中获取第一目标账户的第二账户余额，并从未入账明细表中与第一目标账户关联的各个未入账明细中，确定第二未入账明细；其中，第二未入账明细的状态包括在途状态和待补账状态；根据第二未入账明细确定第一发生额，并根据第一发生额和第二账户余额，确定第一目标账户的第一可用余额；在第一可用余额不为负值时，根据第一可用余额，对分布式共享内存中第一目标账户的账户余额进行更新。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第二处理模块，用于在分布式共享内存为不可用状态时，从未入账明细表中与第一目标账户关联的各个未入账明细中，确定第三未入账明细；其中，第三未入账明细的状态包括在途状态和待补账状态；根据第三未入账明细确定第二发生额，并从数据库的账户余额表中获取第一目标账户的第三账户余额；在第三账户余额和第二发生额，确定第一目标账户的第二可用余额；在第二可用余额不为负值时，对第一交易请求所涉及的第二交易业务进行处理，并响应于第二交易业务处理完毕，确定交易成功。

作为一种可能的实现方式，更新模块1030，还用于：在第二可用余额不为负值时，响应于分布式共享内存从不可用状态恢复为可用状态，根据第二可用余额对分布式共享内存中第一目标账户的账户余额进行更新。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第三处理模块，用于在第一目标账户不为热点账户时，从数据库的账户余额表中获取第一目标账户的第四账户余额；在第四账户余额大于或等于第一交易金额时，根据第一交易金额，对账户余额表中的第一目标账户的第四账户余额进行更新；对第一交易请求所涉及的第三交易业务进行处理；响应于第三交易业务处理完毕，确定第一交易请求处理成功；响应于第三交易业务处理失败，确定第一交易请求处理失败，以及处理失败原因为非余额不足。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第四处理模块，用于在第一可用余额为负值时，确定第一交易请求处理失败，以及处理失败原因为余额不足；或者，在第二可用余额为负值时，确定第一交易请求处理失败，以及处理失败原因为余额不足；或者，在第一账户余额小于第一交易金额时，确定第一交易请求处理失败，以及处理失败原因为余额不足；或者，在第四账户余额小于第一交易金额时，确定第一交易请求处理失败，以及处理失败原因为余额不足。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第五处理模块，用于在第一交易请求处理成功时，将数据库中的未入账明细表中的第一未入账明细的状态从在途状态更新为待补账状态；在第一交易请求处理失败时，删除数据库中的未入账明细表中的第一未入账明细；判断第一交易请求的处理失败原因是否为非余额不足；在处理失败原因为非余额不足的情况下，将第一交易金额返还至分布式共享内存中的第一目标账户。

作为一种可能的实现方式，更新模块1030，还用于：在满足设定条件时，根据数据库中未入账明细表中第二目标账户的第四未入账明细，对数据库中账户余额表中第二目标账户的账户余额进行更新；其中，第二目标账户为热点账户，第四未入账明细的状态包括待补账状态；其中，设定条件包括以下任意一项：到达设定周期；到达目标时刻，其中，目标时刻所处的时段内接收到交易请求的数量小于设定阈值。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第六处理模块，用于获取第二交易请求；其中，第二交易请求中携带第二账户标识、第二交易信息和第二交易类型，第二交易类型为贷记；根据第二账户标识，确定第二账户标识对应的第三目标账户是否为热点账户；在第三目标账户不为热点账户时，根据第二交易信息中的第二交易金额，对数据库的账户余额表中第三目标账户的第五账户余额进行更新；对第二交易请求所涉及的第四交易业务进行处理；响应于第四交易业务处理完毕，确定第二交易请求处理成功；响应于第四交易业务处理失败，确定第二交易请求处理失败。

作为一种可能的实现方式，第六处理模块，还用于：在第三目标账户为热点账户时，根据第二交易信息，在数据库中的未入账明细表中插入第五未入账明细，并设置第五未入账明细的状态为在途状态；对第二交易信息所涉及的第五交易业务进行处理；响应于第五交易业务处理完毕，确定第二交易请求处理成功；响应于第五交易业务处理失败，确定第二交易请求处理失败。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第七处理模块，用于在第二交易请求处理失败的情况下，删除未入账明细表中的第五未入账明细；在第二交易请求处理成功的情况下，将第五未入账明细从在途状态更新为待补账状态；从未入账明细表中与第三目标账户关联的各个未入账明细中，确定第六未入账明细；其中，第六未入账明细的状态包括在途状态和待补账状态；根据第六未入账明细，确定第四发生额；根据第四发生额对分布式共享内存中第三目标账户的账户余额进行更新。

作为一种可能的实现方式，该交易处理装置1000还可以包括：

第八处理模块，用于接收余额查询请求，其中，余额查询请求中携带第三账户标识；根据第三账户标识，确定第三账户标识对应的第四目标账户是否为热点账户；在第四目标账户为热点账户时，判断分布式共享内存是否处于可用状态；在分布式共享内存处于可用状态时，获取分布式共享内存中第四目标账户的第六账户余额；发送第一余额查询响应，其中，第一余额查询响应中携带第六账户余额。

作为一种可能的实现方式，第八处理模块，还用于：在第四目标账户不为热点账户时，从数据库的账户余额表中查询与第二目标账户对应的第七账户余额；发送第二余额查询响应，其中，第二余额查询响应中携带第七账户余额。

作为一种可能的实现方式，第八处理模块，还用于：在分布式共享内存处于不可用状态时，从数据库的未入账明细表中，查询与第四目标账户对应的第七未入账明细，其中，第七未入账明细处于在途状态和待补账状态；从数据库的账户余额表中查询与第四目标账户对应的第八账户余额；根据第七未入账明细确定第五发生额，并根据第五发生额和第八账户余额，确定第四目标账户的第三可用余额；发送第三余额查询响应，其中，第三余额查询响应中携带第三可用余额。

本申请实施例的交易处理装置，通过获取第一交易请求；其中，第一交易请求中携带第一账户标识和第一交易信息；在第一账户标识对应的第一目标账户为热点账户时，判断分布式共享内存是否处于可用状态；其中，分布式共享内存中存储有至少一个热点账户的账户余额；在分布式共享内存处于可用状态，且分布式共享内存中第一目标账户的第一账户余额大于或等于第一交易信息中的第一交易金额时，根据第一交易金额对第一账户余额进行更新；对第一交易请求所涉及的第一交易业务进行处理，并响应于第一交易业务处理完毕，确定第一交易请求处理成功。由此，通过在分布式共享内存中存储各个热点账户的实际账户余额，可以实现在分布式共享内存中实现原子性的账户余额的检查与更新，借助分布式共享内存的高速读写能力，可以解决高并发场景下数据库行锁带来的性能问题，同时也可以避免高并发场景下，缓冲方案扣减账户余额带来的金额透支问题。

为了实现上述实施例，本申请还提出一种电子设备，其中，电子设备可以为任一具有计算能力的设备，该电子设备包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本申请前述任一实施例提出的交易处理方法。

作为一种示例，图11是本申请一示例性实施例所示出的电子设备1100的结构示意图，如图11所示，上述电子设备1100，还可以包括：

存储器1110及处理器1120，连接不同组件(包括存储器1110和处理器1120)的总线1130，存储器1110存储有计算机程序，当处理器1120执行所述程序时实现本申请实施例所述的交易处理方法。

总线1130表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

电子设备1100典型地包括多种电子设备可读介质。这些介质可以是任何能够被电子设备1100访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储器1110还可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)1140和/或高速缓存存储器1150。服务器1100可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统1160可以用于读写不可移动的、非易失性磁介质(图11未显示，通常称为“硬盘驱动器”)。尽管图11中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM，DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线1130相连。存储器1110可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本申请各实施例的功能。

具有一组(至少一个)程序模块1170的程序/实用工具1180，可以存储在例如存储器1110中，这样的程序模块1170包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块1170通常执行本申请所描述的实施例中的功能和/或方法。

电子设备1100也可以与一个或多个外部设备1190(例如键盘、指向设备、显示器1191等)通信，还可与一个或者多个使得用户能与该电子设备1100交互的设备通信，和/或与使得该电子设备1100能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1192进行。并且，电子设备1100还可以通过网络适配器1193与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1193通过总线1130与电子设备1100的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1100使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

处理器1120通过运行存储在存储器1110中的程序，从而执行各种功能应用以及数据处理。

需要说明的是，本实施例的电子设备的实施过程和技术原理参见前述对本申请实施例的交易处理方法的解释说明，此处不再赘述。

为了实现上述实施例，本申请还提出一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请前述任一实施例提出的交易处理方法。

为了实现上述实施例，本申请还提出一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如本申请前述任一实施例提出的交易处理方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。