CN110889687A - 分布式架构下账户余额的处理方法及装置 - Google Patents

Abstract

本发明实施例涉及云计算领域，公开了一种分布式架构下账户余额的处理方法及装置。在本发明中，接收用户发送的业务请求；根据业务请求，判断是否需要减少用户的账户余额；若需要减少账户余额，则根据业务请求直接更新账户余额。通过一阶段的操作即可实现账户余额的处理，相对于现有技术中通过两阶段或三阶段操作实现账户余额的处理而言，两阶段或三阶段的操作，在每个阶段均会产生相应的处理记录，而一阶段的操作则大大减少了处理记录的数量，节省存储空间。另外，财务人员需要通过处理记录来核对账户余额是否准确无误，减少了处理记录的数量可以减轻财务人员核对过程的工作量，提高了财务人员的工作效率。

Description

分布式架构下账户余额的处理方法及装置

技术领域

本发明实施例涉及云计算领域，特别涉及一种分布式架构下账户余额的处理方法及装置。

背景技术

随着互联网技术的发展，网上支付已经逐步替代现金支付，用户或企业可以在各个银行或网络支付工具开设个人或企业账户，并将货币存储至所开设的账户的余额中，以便可以直接通过账户的余额进行货币交易。随着注册网上账户的用户人数的增加，每时每刻都会进行大量的货币交易，为了满足大数据的计算需求，目前通常采用分布式计算的数据构架来实现大量数据的计算，将货币交易所需的大量计算才能解决的问题拆分成多个小问题，利用多个服务器分别对各个小问题进行计算，例如，可以把货币交易服务划分为库存服务、积分服务、账户余额服务等，每个服务即是一个需要计算的小问题，通过多个服务器对货币交易服务的各个小问题分散计算处理，从而可以增加处理的用户请求数量。

在利用分布式计算的数据架构进行货币交易服务的处理时，多个不同服务器共同对一个货币交易请求进行处理，而货币交易服务输出的结果是唯一的，不是交易成功就是交易失败，若各个服务器的结果不统一，会造成交易结果无法确定。为了实现多个服务器处理结果的统一，通常利用分布式一致性协议(TCC协议)对货币交易请求拆分的各个服务进行处理，TCC协议主要分为三个阶段，在TCC协议的第一阶段对各个服务器的处理能力进行判断，如果服务器可以正常处理需要计算的问题部分，则进行记录。在各个服务器均判定可以正常处理需要计算的问题部分时，进入TCC协议的第二阶段，各个服务器分别对服务中需要计算的部分进行处理，输出处理结果。若在第一阶段中任一个服务器无法正常处理需要计算的问题部分，则进入第三阶段，将所有的服务器第一阶段产生的数据回滚，撤销各个服务器第一阶段已完成的记录内容，输出处理失败。从而实现了对不同服务器的服务状态进行统一，使各个服务器处理请求的结果同为处理成功或同为处理失败。

发明人发现相关技术中至少存在如下问题：在采用TCC协议对分布式架构下的货币交易服务进行处理时，通常会采用三个阶段的处理来实现一次货币交易服务，在每个阶段的处理过程中均会产生相应的处理记录，业务人员通过各个服务器的处理记录对该服务器的各个阶段的处理结果进行核对，也就是说一次货币交易服务的每个服务器均会产生三个阶段对应的处理记录，大量的处理记录会占用过多的存储空间。另外，在业务人员核对时，大量的处理记录会增加业务人员的工作量，降低了业务人员的工作效率。

发明内容

本发明实施方式的目的在于提供一种分布式架构下账户余额的处理方法及装置，从而减少了账户余额服务中的处理记录，节省存储空间，也减少了财务人员检查用户账户余额收支情况的工作量，提高了财务人员的工作效率。

为解决上述技术问题，本发明的实施方式提供了一种分布式架构下账户余额的处理方法，包括：接收用户发送的业务请求；根据业务请求，判断是否需要减少用户的账户余额；若需要减少账户余额，则根据业务请求直接更新账户余额。

本发明的实施方式还提供了一种分布式架构下账户余额的处理装置，包括：接收模块，判断模块，更新模块；接收模块用于接收用户发送的业务请求；判断模块用于根据业务请求，判断是否需要减少用户的账户余额；更新模块用于在需要减少账户余额时，根据业务请求直接更新账户余额。

本发明的实施方式还提供了一种服务器，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述分布式架构下账户余额的处理方法。

本发明的实施方式还提供了一种存储介质，存储有计算机程序，计算机程序被处理器执行时实现上述分布式架构下账户余额的处理方法。

本发明实施方式相对于现有技术而言，分布式架构下的服务器在接收到用户发送的业务请求时，根据业务请求判断在该业务请求下，需要对用户的账户余额进行怎样的变动，需要增加用户的账户余额还是需要减少用户的账户余额，如果需要减少用户的账户余额，则直接扣除用户账户余额中相应的金额，通过一阶段的操作即可实现账户余额的处理，相对于现有技术中通过两阶段或三阶段操作实现账户余额的处理而言，两阶段或三阶段的操作，在每个阶段均会产生相应的处理记录，而一阶段的操作则大大减少了处理记录的数量，节省存储空间。另外，财务人员需要通过处理记录来核对账户余额是否准确无误，减少了处理记录的数量可以减轻财务人员核对过程的工作量，提高了财务人员的工作效率。

另外，根据业务请求，判断是否需要减少用户的账户余额，包括：确定业务请求产生的扣费金额和退费金额；若退费金额小于扣费金额，则需要减少用户的账户余额。用户发送的业务请求可能会产生扣费或者退费的情况，另外，还可能同时存在扣费和退费的情况，所以针对每个业务请求均需要确定其是否产生退费金额和扣费金额，并比较退费金额和扣费金额的大小，判定是否需要减少用户的账户余额。

另外，在根据业务请求直接更新账户余额之后，还包括：若接收到业务请求的数据回滚指令，则根据业务请求对账户余额进行调整。由于在处理的业务请求是需要减少用户的账户余额的情况下，对账户余额直接进行调整，在接收到回滚指令时则需要将所减少的用户的余额重新添加，恢复成调整之前的账户余额。因为业务请求对账户余额的处理是扣费处理，所以在回滚阶段只需增加账户余额，而不会在回滚过程中出现由于账户余额不足而回滚失败的情况，保证了该业务请求的回滚指令的正常执行。

另外，在判断是否需要减少用户的账户余额之后，还包括：若不需要减少账户余额，则记录业务请求产生的扣费金额和退费金额；在接收到业务请求的结算指令时，获取记录的业务请求产生的扣费金额和退费金额；根据扣费金额和退费金额更新账户余额。针对不需要减少账户余额的业务请求，首先需要记录业务请求所产生的扣费金额和退费金额，在接收到结算指令时，再更新账户余额，以两阶段的操作实现账户余额的变动，避免了在回滚操作下账户余额不足导致回滚失败。在第一阶段分别记录业务请求产生的扣费金额和退费金额，在第二阶段的操作下可以直接获取第一阶段的记录，无需再次通过业务请求获取所需的金额，提高了账户余额的更新效率。

另外，记录业务请求产生的扣费金额和退费金额，包括：通过余额账本变动日志中的第一预设字段和第二预设字段分别记录业务请求产生的扣费金额和退费金额；余额账本变动日志还包括：第三预设字段和第四预设字段；其中，第三预设字段用于记录用户的账户余额中冻结的应扣除的总金额，预加金额字段用于记录冻结的应增加至用户的账户余额中的总金额；根据业务请求产生的扣费金额和退费金额更新余额账本变动日志中的第三预设字段和第四预设字段。以余额账本变动日志的形式记录每次业务请求所产生的扣费金额和退费金额，便于财务人员根据余额账本变动日志对账户余额进行核对。另一方面，余额账本变动日志不仅记录每一次业务请求中产生的金额变动，还记录有每次金额变动时账户余额中的冻结的总金额和预加的总金额，从而可以通过余额账本变动日志反映出该用户当前的可用余额。

另外，在根据业务请求产生的扣费金额和退费金额更新余额账本变动日志中的第三预设字段和第四预设字段之后，还包括：在接收到余额查询指令时，获取预先设置的余额查询指令的权限；根据权限对返回的余额账本变动日志中包含的字段的显示状态进行修改；将修改后的余额账本变动日志返回至余额查询指令的发送终端。通过设置字段的显示状态，使查看余额账户变动日志的用户可以看到不同的内容，在字段的显示状态为显示时，用户可以查看到该字段下的内容，而在字段的显示状态为不显示时，用户则无法查看到该字段下的内容。向不同类型的用户展示不同的余额账本变动日志的内容，从而使展示的内容为用户提供有用的价值，避免多余的信息影响用户的查看体验。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。

图1是根据本发明第一实施例中的分布式架构下账户余额的处理方法的流程图；

图2是根据本发明第一实施例中的余额账本变动日志的示意图；

图3是根据本发明第二实施例中的分布式架构下账户余额的处理方法的流程图；

图4是根据本发明第三实施例中的分布式架构下账户余额的处理装置的示意图；

图5是根据本发明第四实施例中的服务端的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。

以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本发明的第一实施例涉及一种分布式架构下账户余额的处理方法，包括：接收用户发送的业务请求；根据业务请求，判断是否需要减少用户的账户余额；若需要减少账户余额，则根据业务请求直接更新账户余额。下面对本实施例的分布式架构下账户余额的处理方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。

具体流程如图1所示，第一实施例涉及一种分布式架构下账户余额的处理方法，包括：

步骤101，接收用户发送的业务请求。

具体地说，在分布式架构下，用于处理账户余额服务的服务器接收管理服务器发送的用户的业务请求，管理服务器是对分布式机构下各个服务器进行管理的服务器，管理服务器可以将获取的用户的请求分发至不同的服务器，并从各个服务器中获取处理结果，实现分布式架构下的统一管理。

处理账户余额服务的服务器所接收到的业务请求可以根据业务请求中携带的信息，分为购买请求和退款请求和服务变更请求。购买请求可以在用户购买某件物品或订阅某项虚拟服务时接收；退款请求可以在用户撤销订单或退回所购买的物品时接收；服务变更请求可以在用户对所订阅的服务进行修改时接收。

步骤102，根据业务请求，判断是否需要减少用户的账户余额。若判定结果为是，则进入步骤103；若判定结果为否，则进入步骤104。

具体地，用户的业务请求中包含本次请求产生的扣费金额和退费金额，若接收到的业务请求中扣费金额为零，而退费金额不为零，则说明本次业务请求为退费请求，需要增加用户的账户余额；若接收到的业务请求中扣费金额不为零，而退费金额为零，则说明本次业务请求为扣费请求，需要减少用户的账户余额；若接收到的业务请求中扣费金额不为零且退费金额不为零，则说明本次业务请求为服务变更请求，需要比较业务请求中扣费金额和退费金额的大小，若扣费金额大于退费金额，则需要减少用户的账户余额，若扣费金额小于退费金额，则需要增加用户的账户余额，若扣费金额和退费金额相等，则无需对用户的账户余额进行更改。

步骤103，根据业务请求直接更新账户余额。

具体地说，在确定需要减少用户的账户余额时，服务器直接计算需要减少的金额，并将减少的金额从用户的账户余额中扣除。在扣除账户余额之后通知管理服务器，完成账户余额的更新。在减少用户的账户余额之后，可以将变动的账户余额记录在余额账本变动日志中，如图2列表中第四行所示，将账户余额中减少的金额记录在余额账本变动日志的变动金额字段中，以便财务人员对账户余额进行核对。

若步骤102判定结果为否，则进入步骤104，记录业务请求产生的扣费金额和退费金额。

具体地说，在记录业务请求产生的扣费金额和退费金额时，可以通过预先设置的余额账本变动日志进行记录，如图2所示余额账本变动日志，假设业务1所产生的扣费金额为10，产生的退费金额为50，退费金额大于扣费金额，所以需要增加该用户的账户余额，在接收到业务请求且判定需要增加该用户的账户余额之后，如图2列表中第二行和第三行所示，在余额账本变动日志的业务阶段字段记录为准备，且在余额账本变动日志的变动冻结金额字段(第一预设字段)记录业务1产生的扣费金额10，在余额账本变动日志的变动预加金额字段(第二预设字段)记录业务1产生的退费金额50。另外，余额账本变动日志中还包括冻结余额字段(第三预设字段)和预加余额字段(第四预设字段)，冻结余额字段用于记录用户的账户余额中冻结的应扣除的总金额，预加金额字段用于记录冻结的应增加至用户的账户余额中的总金额。

在分布式架构下各个服务器均完成准备阶段且未出现异常之后，账户余额服务器接收到结算指令，进入第二阶段提交阶段。如图2列表第六行和第七行所示，根据准备阶段记录的业务1产生的扣费金额10和退费金额50，将扣费金额从账户余额中扣除，并将退费金额从账户余额中累加，账户余额中所扣除的金额及累加的金额可以记录在余额账本变动日志中的变动金额字段中。另外，在账户余额中扣除扣费金额之后，还需要在余额账本变动日志中的冻结余额字段中扣除相应的扣费金额，在账户余额中增加退费金额之后，还需要在余额账本变动日志中的预加余额字段中扣除相应的退费金额。

本发明实施方式相对于现有技术而言，分布式架构下的服务器在接收到用户发送的业务请求时，根据业务请求判断在该业务请求下，需要对用户的账户余额进行怎样的变动，需要增加用户的账户余额还是需要减少用户的账户余额，如果需要减少用户的账户余额，则直接扣除用户账户余额中相应的金额，通过一阶段的操作即可实现账户余额的处理，相对于现有技术中通过两阶段或三阶段操作实现账户余额的处理而言，两阶段或三阶段的操作，在每个阶段均会产生相应的处理记录，而一阶段的操作则大大减少了处理记录的数量，节省存储空间。另外，财务人员需要通过处理记录来核对账户余额是否准确无误，减少了处理记录的数量可以减轻财务人员核对过程的工作量，提高了财务人员的工作效率。

本发明的第二实施例涉及一种分布式架构下账户余额的处理方法。在本发明第二实施例涉及的分布式架构下账户余额的处理方法，还包括：若接收到业务请求的数据回滚指令，则根据业务请求对账户余额进行调整。

具体流程如图3所示，第二实施例涉及一种分布式架构下账户余额的处理方法，包括：

步骤301，接收用户发送的业务请求。

步骤302，根据业务请求，判断是否需要减少所述用户的账户余额。若判定结果为是，则进入步骤303；若判定结果为否，则进入步骤305。

步骤303，根据业务请求直接更新账户余额。

步骤301至303分别与第一实施例中步骤101至103一一对应，在此不再赘述。

步骤304，在接收到回滚指令时，根据业务请求对账户余额进行调整。

若步骤302判定结果为否，则进入步骤305，记录业务请求产生的扣费金额和退费金额。与第一实施例中步骤104一致，在此不再赘述。

步骤306，在接收到回滚指令时，将记录的业务请求产生的退费金额和扣费金额撤销。

具体地说，如图2列表第七行和第八行所示，业务1产生的扣费金额为10，退费金额为50。在接收到业务1的回滚指令时，进入该业务1的回滚阶段，在余额账本变动日志中查找业务1的准备阶段，并读取余额账本变动日志中记录的业务1产生的扣费金额和退费金额。将业务1准备阶段的变动冻结金额字段中记录的10从冻结金额字段中扣除，且将业务1准备阶段的变动预加金额字段中记录的50从预加金额字段中扣除，实现数据的回滚，撤销了准备阶段已完成的处理。

在实际应用中，记录对业务处理的各阶段数据的变动情况的余额账本变动日志可供用户调用并查看，由于用户或财务人员所需查看的是各阶段处理之后剩余的账户余额，对每次处理产生的扣费金额或是退费金额的具体数值并不关注，所以在将余额账本变动日志展示给用户时，可以不展示余额账本变动日志的变动金额字段、变动冻结金额字段及变动预加金额字段。而在技术人员为核查各阶段处理过程是否异常时，需查看各阶段处理过程变动的具体数值，所以在技术人员调用余额账本变动日志时需要将余额账本变动日志的所有字段下内容显示。这样做可以向不同类型的查看人员展示不同的余额账本变动日志的内容，从而使展示的内容为用户提供有用的价值，避免多余的信息影响用户的查看体验。

另外，在接收到业务请求时，还可以校验用户当前的可用余额是否足够支付所请求的业务，根据余额账本变动日志中的余额字段中记录的金额得到用户账户的实际余额，根据余额账本变动日志中的冻结余额字段中记录的金额得知用户账户中已经消费但是并未确认的冻结金额，将实际余额与冻结余额相减，即得到用户账户当前的可用余额。若可用余额小于本次用户业务请求所需扣除的金额，则说明用户当前账户无法支付该业务请求，提示用户进行充值，若可用余额大于本次用于业务请求所需扣除的金额，则说明用于账户余额足够支付本次业务请求，开始对本次业务请求进行处理。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第三实施例涉及一种分布式架构下账户余额的处理装置，如图4所示，包括：接收模块41，判断模块42，更新模块43；接收模块41用于接收用户发送的业务请求；判断模块42用于根据业务请求，判断是否需要减少用户的账户余额；更新模块43用于在需要减少账户余额时，根据业务请求直接更新账户余额。

不难发现，本实施方式为与第一实施例相对应的装置实施例，本实施例可与第一实施例互相配合实施。第一实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一实施例中。

另外，判断模块42具体用于确定业务请求产生的扣费金额和退费金额；若退费金额小于扣费金额，则需要减少用户的账户余额。

另外，接收模块41还用于接收业务请求的数据回滚指令；本实施例中分布式架构下账户余额的处理装置还包括：调整模块，用于在接收模块接收到业务请求的数据回滚指令时，根据业务请求对账户余额进行调整。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明第四实施例涉及一种服务器，如图5所示，包括至少一个处理器501；以及，与至少一个处理器501通信连接的存储器502；其中，存储器502存储有可被至少一个处理器501执行的指令，指令被至少一个处理器501执行，以使至少一个处理器501能够执行上述分布式架构下账户余额的处理方法。

其中，存储器502和处理器501采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器501和存储器502的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器501。

处理器501负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器502可以被用于存储处理器501在执行操作时所使用的数据。

本发明第五实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施例是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (10)

1.一种分布式架构下账户余额的处理方法，其特征在于，包括：

接收用户发送的业务请求；

根据所述业务请求，判断是否需要减少所述用户的账户余额；

若需要减少所述账户余额，则根据所述业务请求直接更新所述账户余额。

2.根据权利要求1所述的分布式架构下账户余额的处理方法，其特征在于，所述根据所述业务请求，判断是否需要减少所述用户的账户余额，包括：

确定所述业务请求产生的扣费金额和退费金额；

若所述退费金额小于所述扣费金额，则需要减少所述用户的账户余额。

3.根据权利要求1所述的分布式架构下账户余额的处理方法，其特征在于，在所述根据所述业务请求直接更新所述账户余额之后，还包括：

若接收到所述业务请求的数据回滚指令，则根据所述业务请求对所述账户余额进行调整。

4.根据权利要求1所述的分布式架构下账户余额的处理方法，其特征在于，在所述判断是否需要减少所述用户的账户余额之后，还包括：

若不需要减少所述账户余额，则记录所述业务请求产生的扣费金额和退费金额；

在接收到所述业务请求的结算指令时，获取所述记录的所述业务请求产生的扣费金额和退费金额；

根据所述扣费金额和所述退费金额更新所述账户余额。

5.根据权利要求4所述的分布式架构下账户余额的处理方法，其特征在于，所述记录所述业务请求产生的扣费金额和退费金额，包括：

通过余额账本变动日志中的第一预设字段和第二预设字段分别记录所述业务请求产生的扣费金额和退费金额；

所述余额账本变动日志还包括：第三预设字段和预设第四字段；其中，所述第三预设字段用于记录所述用户的账户余额中冻结的应扣除的总金额，所述预加金额字段用于记录冻结的应增加至所述用户的账户余额中的总金额；

根据所述业务请求产生的扣费金额和所述退费金额更新所述余额账本变动日志中的第三预设字段和第四预设字段。

6.根据权利要求5所述的分布式架构下账户余额的处理方法，其特征在于，在所述根据所述业务请求产生的扣费金额和所述退费金额更新所述余额账本变动日志中的第三预设字段和第四预设字段之后，还包括：

在接收到余额查询指令时，获取预先设置的所述余额查询指令的权限；

根据所述权限对返回的所述余额账本变动日志中包含的预设字段的显示状态进行修改；

将所述修改后的余额账本变动日志返回至所述余额查询指令的发送终端。

7.一种分布式架构下账户余额的处理装置，其特征在于，包括：接收模块，判断模块，更新模块；

所述接收模块用于接收用户发送的业务请求；

所述判断模块用于根据所述业务请求，判断是否需要减少所述用户的账户余额；

所述更新模块用于在需要减少所述账户余额时，根据所述业务请求直接更新所述账户余额。

8.根据权利要求7所述的分布式架构下账户余额的处理装置，其特征在于，

所述判断模块用于确定所述业务请求产生的扣费金额和退费金额；若所述退费金额小于所述扣费金额，则需要减少所述用户的账户余额。

9.一种服务器，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至6中任一所述的分布式架构下账户余额的处理方法。

10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的分布式架构下账户余额的处理方法。

Images