CN110033250B - 减少单元化拆分部署记账耗时的方法和系统 - Google Patents

Abstract

本公开涉及一种减少单元化拆分部署的记账耗时的系统，包括：第一机房(1)，包括存储第一用户的账户的第一数据库(DB1)；第二机房(2)，包括存储第二用户的账户的第二数据库(DB2)；其中第一机房被配置为：接收来自所述第一用户的向第二用户进行转账款转账的转账请求；执行冻结操作以在所述第一用户的账户上冻结转账款；根据所述转账请求从所述第一机房上的读库中检索出所述第二用户的账户的有效性信息，并基于所述有效性信息对所述第二用户的账户有效性进行校验以确定所述第二用户的账户是否正常；以及当所述第二用户的账户校验为正常时，对所述第一数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作；并且同时通知所述第二机房对所述第二数据库中的所述第二用户的所述账户执行相应的增加所述转账款的操作。

Description

减少单元化拆分部署记账耗时的方法和系统

技术领域

本公开涉及电子记账领域，特别是单元化拆分部署记账技术。

背景技术

随着数据业务的迅速发展，在单机房不能满足容量要求的背景下，按照某个数据业务要素进行机房的单元化拆分成为了常规的做法，例如按照uid维度将原来的一个机房拆分成为两个机房。在拆分后，数据业务按照路由规则将数据流量指向正确的机房，这样就可以完成机房容量的加倍。并且在理论上只要拆分合理，一个机房可以被拆分成任意个机房，因此，容量也可以水平无限扩展。但所述单元化拆分部署也给具体的数据业务系统带来了复杂度的增加，进而增加了数据业务的耗时。

为此，对于用户来说存在一种对既能通过单元化拆分部署增加容量同时又没有跨机房耗时问题的解决方案的需求。。

发明内容

本公开涉及一种减少单元化拆分部署的记账耗时的技术。通过所述技术，可以在通过单元化拆分部署增加系统容量的同时，巧妙解决记账类业务的跨机房耗时问题，并且同时不会对用户产生任何不利影响。

根据本公开的第一方面，提供了一种减少单元化拆分部署的记账耗时的方法，包括：第一机房(1)接收来自第一用户(A)的向第二用户(B)进行转账款转账的转账请求，其中，所述第一用户的账户处于所述第一机房的第一数据库(DB1)中，而所述第二用户的账户处于第二机房(2)的第二数据库(DB2)中；所述第一机房执行冻结操作以在第一用户的账户上冻结转账款；所述第一机房根据所述转账请求从部署在所述第一机房上的读库中检索出所述第二用户的账户的有效性信息，并基于所述有效性信息对所述第二用户的账户有效性进行校验以确定所述第二用户的账户是否正常；以及当所述第二用户的账户校验为正常时，所述第一机房对所述第一数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作，并且同时通知所述第二机房对所述第二数据库中的所述第二用户的所述账户执行相应的增加所述转账款的操作。

根据本公开的第二方面，提供了一种减少单元化拆分部署的记账耗时的系统，所述系统包括：一种减少单元化拆分部署的记账耗时的系统，其特征在于，所述系统包括：第一机房(1)，包括存储第一用户(A)的账户的第一数据库(DB1)；第二机房(2)，包括存储第二用户(B)的账户的第二数据库(DB2)；其中所述第一机房被配置为：接收来自所述第一用户的向第二用户进行转账款转账的转账请求；执行冻结操作以在所述第一用户的账户上冻结转账款；根据所述转账请求从所述第一机房上的读库中检索出所述第二用户的账户的有效性信息，并基于所述有效性信息对所述第二用户的账户有效性进行校验以确定所述第二用户的账户是否正常；以及当所述第二用户的账户校验为正常时，对所述第一数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作；并且同时通知所述第二机房对所述第二数据库中的所述第二用户的所述账户执行相应的增加所述转账款的操作。。

根据本公开的第三方面，提供了在包括多个机房的单元化拆分部署中的一个机房，包括：处理器；与所述处理器相连的存储器，所述存储器包括第一数据库和读库，所述第一数据库存储有第一用户的账户，而所述读库存储有在其他机房的其他数据库中的所有其他用户的账户的有效性信息；其中，所述处理器被配置为：接收来自所述第一用户的向所述其他用户之一进行转账款转账的转账请求；执行冻结操作以在所述第一用户的账户上冻结转账款；根据所述转账请求从所述机房上的所述读库中检索出要被转账的所述其他用户的账户的有效性信息，并基于所述有效性信息对所述要被转账的其他用户的账户有效性进行校验以确定所述账户是否正常；以及当所述要被转账的其他用户的账户校验为正常时，对所述数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作；并且同时通知所述其他机房对所述其他数据库中的所述要被转账的其他用户的账户执行相应的增加所述转账款的操作。

提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

为了描述可获得本发明的上述和其它优点和特征的方式，将通过参考附图中示出的本发明的具体实施例来呈现以上简要描述的本发明的更具体描述。可以理解，这些附图只描绘了本发明的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本发明，在附图中：

图1是传统的将一个机房拆分成两个机房的示例环境方案。

图2是未进行单元化拆分的情况下在单个机房中的传统的记账操作的基本流程。

图3是进行单元化拆分的情况下在多个机房中的传统的记账操作的基本流程。

图4是传统的多机房支付的示例流程。

图5是根据本公开的一个实施例的机房1的示例框图。

图6是根据本公开的一个实施例的用于减少单元化拆分部署记账耗时的方案的流程图。

具体实施方式

在传统技术中，为了解决单个机房的容量已经越来越难以满足日益增长的用户数的问题，采用了一种名为“单元化拆分”的部署机制。单元化拆分是指：把数据业务按照一定维度拆分成多个不同的单元，所述单元可以部署在不同地理位置的通过网络互连的各个机房中，例如可以按照用户ID、存储时间、数据大小等将众多的用户账户拆分成两个或更多个单元。例如，如图1所示，当原来的机房1部署有用户00-99(共100个用户)，也即在其数据库中存储有100个用户的账户的信息时，这些账户信息导致了机房1的容量不堪重负。因此，为了解决所述容量问题，通过单元化，将用户00-99拆分为：将用户00-49还是部署到原来的机房1，而将用户50-99部署到新的机房2。这样，通过单元化拆分引入新机房2，减轻了机房1的一半容量压力。但应该理解，尽管在图1中所示出的传统的“单元化拆分”的示例是将一个机房拆分成两个机房的示例方案，但是所拆分的机房的数目可以根据实际需要而变化，而不是局限于两个。同样，在图1中以用户00-99(共100个用户)为例来描述所述单元化拆分，但应该理解，所述用户的数目仅仅是一种示例，其可以根据需要而变得更多或者更少。所有这些变化都在本公开的保护范围内。

在一个实施例中，所述机房可以是包含处理器和存储器的服务器、工作站、数据库系统、数据中心等等的能够分析和处理数据信息的系统。所述机房可以处于同一地点(例如同一房间内)，或分散在世界各地。而在各个机房之间通过网络互连，所述网络包括各种类型的有线和无线网络，包括但不局限于互联网、局域网、WIFI、WLAN、蜂窝通信网络(GPRS、CDMA、2G/3G/4G/5G蜂窝网络)、卫星通信网络等等。

在图1中，单元化拆分可以通过不断引入新的机房来水平扩展系统的容量。并且在理论上只要拆分合理，一个机房可以被拆分成任意多个机房，因此，容量也可以水平无限扩展。当然，这种容量扩展并非没有代价，拆分所涉及的机房越多，则数据业务在这些机房之间的执行就越复杂。因此，所述单元化拆分也给具体的数据业务系统带来了复杂度的增加，进而导致数据业务的执行更加耗时。

具体而言，在单个机房的场景中，原来用户账户信息、数据库和应用完全都在一个机房中，因此，应用对与用户账户信息相关联的数据库的访问几乎是零延迟(即基本没有耗时)，但在将该机房拆分之后与用户相关联的账户信息随着该用户被部署到另一个机房也同时被迁移到该另一个机房，例如用户50-99的账户信息被转移到机房2。所以，原先在一个机房就可以完成的用户间的业务操作，现在很可能由于其中一个用户部署到了另一个机房而需要两个机房相互配合才能够完成这些操作。这势必会带来一些对数据业务的处理速度的影响，这种影响将在下面通过比对图2和3来具体进行说明。而且，这种耗时影响随着拆分机房的数目的增加而呈几何数量级增长。因此，尽管单元化拆分为数据业务系统的扩容带来了极大的便利性，但同时也导致数据业务处理速度的显著下降。这种下降对于对数据业务处理速度有很高要求的业务来说尤其不能接受。例如电子支付中的转账业务，无论是转账人还是收款人都希望能够在第一时间获得转账成功的确认，显然，传统的单元化拆分技术难以满足所述用户的需求。在本公开的各个实施例中，将以用户之间的记账业务(例如转账)来进行具体说明，但应该理解本公开的方案也同样适应于其它对时间敏感的各种数据业务，例如涉及多个账户的各种数字化交易，如虚拟币、游戏道具、充值卡等等。

在描述本公开的方案之前，先结合附图2和3来分别描述在未进行单元化拆分的情况下和在进行单元化拆分的情况下，传统的记账(例如转账)操作的交互过程，以便技术人员通过对比传统技术更好地理解本公开的改进和优点。

在图2中示出了未进行单元化拆分的情况下在单个机房中的传统的记账操作的基本流程。记账是指一种数据业务操作，用来完成账户之间的资金流动。所述记账主要包含下述几个要素。金额：账户之间流动的资金量；耗时：指记账从开始到完成所消耗的时间；流入类账户：指在一次记账操作中，资金流为流入的账户，本公开的示例主要是以用户B的账户作为流入类账户；流出类账户：指在一次记账操作中，资金流为流出的账户，本公开的示例主要是以用户A的账户作为流出类账户。其中耗时对用户的体验尤为重要。

在图2所述的单个机房的传统记账流程中，用户A请求向用户B进行一笔转账，在单机房(机房1)部署情况下，用户A和用户B的账户信息统一保存在数据库(DB1)中，因此，处理器所处理的转账请求中的对数据库的访问都是在同一个数据库DB1中完成，也即所述转账所涉及的所有操作完全在单个机房内完成。由于所述转账业务操作属于机房内部操作，并不涉及与外部的通信，这样，所述业务的实际耗时是最小的。但如上所述，单机房部署无法提供数据扩展，当存在大量用户的数据业务需要被服务时，显然，所述单机房部署是无法满足存储要求的。因此，尽管单机房部署的业务耗时最小，但随着互联网技术逐渐深入到千家万户以及各行各业所导致的信息大爆炸，其已经开始被慢慢淘汰。

为了解决图2所示的单机房部署的扩展困难的缺陷，越来越多的公司和用户开始选择使用单元化拆分将机房拆分成多个机房来存放和处理更多的数据(如图1中所示)。在进行了单元化拆分之后，先前的单机房部署情况下的记账业务(如图2中所示)也发生了变化，因为数据和应用都被相应地拆分成为了多份，所以，不可避免地涉及到跨机房请求耗时问题。传统的多机房部署情况下的记账业务的交互流程如图3所示。在图3中，用户A是流出类账户，其账户信息被存储在机房1的数据库DB1中，而用户B是流入类账户，其账户信息被存储在机房2的数据库DB2中。这样，对于一笔用户A向用户B的转账请求来说，请求由用户A发起，因此，在用户A所属的机房1上被处理器处理。如果用户A和用户B的账户同处于机房1中，则所述请求就如图2所示的情况那样在单个机房内就能处理完成。但由于在图3中的用户B不在机房1中，那么就会存在跨机房的调用(例如在机房1和机房2之间的远程过程调用RPC)以执行对远程存储在机房2上的数据库DB2中的用户B的账户信息的操作。每次跨机房的RPC调用都会增加一次跨机房的RPC耗时。这种耗时与机房1和机房2之间的网络状况紧密联系，例如网络的带宽、占用比等等，也可能受到机房之间的硬件性能差异的影响。尤其当在电子支付平台上同时存在巨大数量(例如每秒数万笔甚至更多的记账交易时)，由于机房之间的带宽、处理能力等限制，实际的每笔交易的耗时会比机房被拆分前要多得多。例如，在某些大型网购节日之类的集中消费的日子里，这种耗时可能会被无限放大(例如原本1-2秒就能转账或支付成功，由于交易数量剧增引起的RPC调用堵塞网络导致数分钟都没有成功反馈)，这会给用户带来非常不友好的用户体验，引发用户对电子支付平台的抱怨和不满。在更严重的情况下，甚至会导致整个系统的崩溃。因此，传统的多机房部署方案尽管扩展了容量但却带来了更多的问题。

要解决传统的多机房部署方案中的耗时增加的问题，就需要首先了解诸如转账之类的业务在多机房环境中所涉及的具体操作流程。下面以在图3所述的部署环境中用户A向用户B转账100元的一笔转账业务为例，如图4所示，在传统的多机房支付流程中主要经历了下述几个阶段：

1、账户A冻结100元；

2、账户B记录一笔100元未达款；

3、分别对账户A真实扣减100元,账户B真实增加100元。

其中第一阶段的冻结操作：在机房1的处理器接收到用户A向用户B转账100元的转账情况后，所述处理器发起在用户A的账户中冻结100元的请求，机房1处理与该请求相关的用户A的账户信息，并操作数据库DB1在用户A的账户中冻结100元。在所述冻结之前，机房1的处理器可以先本地地判断用户A的账户中资金是否充裕。也即，如果用户A的账户的资金余额大于等于100元，则所述冻结成功，流程进入第二阶段。而如果所述用户A的账户的余额小于100元，则机房1可以返回一个“余额不足”的报告给用户并终止所述转账流程。上述所有操作均在机房1中完成。在冻结操作完成后，第一阶段结束。

在第二阶段的记录未达款操作：在冻结操作完成后，机房1的处理器发起在账户B中记录100元未达款的请求。机房1处理所述请求，由于与用户B有关的信息都存放在机房2上，因此，机房1随即发起对机房2的远程过程调用RPC以将所述记录未达款的请求发送给机房2，机房2的处理器处理与所述请求相关的用户B的账户信息，并操作数据库DB2在用户B的账户中记录100元未达款。在记录完成后，第二阶段结束。

在第三阶段中，根据记录的信息分别真实操作用户A的账户和用户B的账户，即分别从数据库DB1的用户A的账户中真实扣除冻结的100元(即在用户A的账户中将冻结的100元真实扣除)。同时，通知机房2在数据库DB2中将记录的未达款100元真实增加到用户B的账户中(即在用户B的账户中真实增加所记录的未达款100元)，从而完成了资金转账全过程。从上面的分析中不难理解，由于机房1和机房2之间存在远程过程调用RPC，因此，每次跨机房记录未达款的操作都会增加一次跨机房的RPC耗时。例如，在图4的示例中，一次跨机房的RPC耗时大约为30ms。所述耗时主要与业务繁忙程度和网络的带宽相关，可能更长或更短。当存在大量用户之间的跨机房交易时，由于系统的有限资源的限制(例如处理能力、存储速度和带宽等)，大量同一时段的交易所带来的并发的大量RPC调用所导致的交易耗时会呈现出几何式地增长，最终导致用户难以忍受的交易确认延迟，从而给用户带来非常差的用户体验。因此，要减少交易耗时，其关键之处主要着眼于减少在第二阶段中的跨机房RPC调用。

为了解决传统的多机房部署(单元化拆分)方案中的耗时增加问题，本公开在单元化拆分的背景下，结合账户业务的特点对现有方案进行了技术改进，将本来因为跨机房远程过程调用所带来的业务耗时尽量减少到最小,从而实现与单机房部署状态下相类似的业务效果。

在研究了如图4所示的传统的多机房(单元化拆分)部署的转账流程之后，可以发现，当用户A向用户B进行转账操作时，对于用户B的账户来说，这个转账过程实际上是一种必然成功的加钱的过程。也就是说，对一个用户账户做资金增加操作时，只要该用户的账户状态正常，那么这一笔加钱操作就一定可以成功，因为该操作不依赖该用户账户的余额。因此，在第二阶段的通过远程过程调用RPC在用户B的账户记录未达款操作实际上是无关紧要的，因为只要用户B的账户状态正常，则这样的转账操作必定成功，并不存在转账失败后需要根据未达款恢复原状的可能性。因此，即使没有第二阶段的通过远程过程调用RPC对用户B的账户的记录未达款的操作，只要能校验出用户B的账户的有效性，则在所述第三阶段的对用户A和用户B的真实操作也必然会成功。所以，实际上可以省略第二阶段，也即通过远程过程调用RPC对用户B的账户的记录未达款的操作，代之以在机房1部署一个读库RDB，如图5所示。

图5示出了根据本公开的一个实施例的机房1的示例框图。与传统机房不同的是，图5中的机房1还包括了一个读库RDB。读库指的是一种只向本地机房提供读取服务的数据库，该读库和与之相关联的主数据库时刻同步数据以保持数据的一致性。在本公开的示例中，读库和机房2处的数据库中的相应信息保持数据同步。读库存储有用户B的账户的有效性信息，该有效性信息与存储在机房2处的数据库DB2中的用户B的账户的有效性信息通过数据同步机制而始终保持一致性。这样，可以基于从机房1处的读库中检索出的用户B的账户的有效性信息执行对用户B的账户的有效性校验。只要用户B的账户校验为正常，就可认为这一笔转账对于用户B的账户来说一定可以成功。如果针对用户B的账户的加钱操作肯定能够成功，也即交易肯定成功，那就不需要再和机房2进行远程过程调用RPC来在数据库DB2的用户B的账户中记录一笔未达款，因为所述记录原本就是仅在交易失败时才用于恢复交易前的状态。如果能在机房1处就确定转账交易一定成功，那么所述记录阶段也就没有了存在的意义。

另一方面，如果在对读库中的用户B的账户有效性信息的校验中发现该账户状态不正常(例如不存在、已被冻结或销户、存在风险等等)，则校验失败，整个记账交易流程就此关闭。这样，也无需对机房2进行跨机房的RPC调用。

所以，通过采用一个记录有在另外的机房上的用户B的账户信息中的有效性信息的读库来执行账户有效性校验，就消除了对跨机房的RPC调用的需求，从而减少了耗时。

并且，由于读库中的信息仅仅用于对用户账户的有效性进行校验，因此，所述读库中只需要存储与用户的账户的有效性相关的信息，而不需要将用户的所有账户信息都存储在读库中。具体而言，在数据库DB2上所存储的用户B的账户信息可以包括：例如，用户账号、密码、当前状态、余额、交易记录、交易明细、交易日子、交易过的对象账户、账户各类限制信息(例如交易限额、交易封顶限额、每天交易次数限制等)以及账户受限信息(如是否被司法限制,是否高风险账户)等信息，而读库仅仅需要存储与有效性校验有关的用户账户信息，例如上述的账户状态信息、账户各类限制信息以及账户受限信息等可以被作为有效性信息而被存储在读库中。而其他的诸如余额、交易记录、交易明细之类的账户信息并不需要被存储在读库中。应该理解，上述各种账户信息类型仅仅是出于说明的目的来描述的，并不是要将本公开的用户的账户信息和有效性信息局限于此。机房的数据库中所存储的用户的账户信息和读库中所存储的有效性信息可以根据实际应用场景进行相应的更改，这些更改都属于本公开的保护范围内。

而且，众所周知，用户的账户信息所占据的存储空间中的大部分字节实际上是被用于记录与交易相关的各种交易数据，而与账户有效性相关联的信息仅仅占据极少的字节，并且通常不会随着时间的流逝而显著增加。所以，可以理解，由于读库仅仅存储了用户的账户信息中的涉及有效性的信息，因此，读库的存在对机房1的容量的影响几乎可以忽略不计。而且，所述读库的容量也不会随着用户账户的数量增长而显著增加。同样，通过网络的机房之间的数据同步操作实际上也仅需要占据很少量的带宽资源。

另外，为了保护读库中的用户B的有效性信息的安全性，该读库对于本地机房1的用户(例如用户A)来说是只读的。因此，机房1上的用户只能读取读库中的数据却没有权利对其进行写入。而且，如果需要的话，可以规定即使机房1的管理员(例如开发人员、维护人员等等)也没有权限对读库中所存储的有效性信息进行任何更改。唯一有权能对机房1上的读库进行修改的是与机房2的数据库DB2的数据同步操作。

另一方面，可以理解的是，所述机房2的数据库DB2中的用户的账户信息中的有效性信息的变化并不局限于用户B的有效性信息的变化，而是只要有存储在数据库DB2的任何用户的账户信息中的有效性信息发生了变化，就自动执行所述数据同步操作，如此才能保证读库中存储的有效性信息始终与数据库DB2中的所有用户的账户信息中的相应数据保持一致。

而且，需要注意的是，如上所述，读库存储的是诸如账户状态信息、账户各类限制信息以及账户受限信息之类的有效性信息，因此，如果机房2的数据库DB2的任意用户的账户信息中发生变化的是例如交易类数据，则并不会触发所述数据同步操作。具体而言，如果用户B与其他用户完成了一笔交易，其在数据库DB2的账户信息中诸如余额、交易记录、交易明细、交易日子、交易过的对象账户之类的数据都会发生改变，但所述改变并不会影响用户B的账户有效性信息，因此，这些变化并不会触发与机房1的读库的数据同步操作。只有当例如用户B的账户被冻结时，才需要与机房1的读库的数据同步操作。

为了保持读库中的用户的有效性信息最新，所述读库中的用户有效性信息与其它机房中的数据库的用户账户信息中的对应有效性信息也可以通过定期数据同步机制来保持同步，例如将同步周期控制在ms级别内，这样，也能基本保证数据的一致性。当然，所述同步周期的长短可以根据实际需要来更改。例如，在交易并不是很活跃的消费淡季，由于用户的账户信息变化频率较低，因此，可以将该同步周期适当延长以节省资源，而在交易活跃的消费旺季，由于用户的账户信息可能比较频繁地发生变化，因此，可以适当缩短该同步周期以减少延迟。

而且，还可以理解，尽管在本公开的示例中的机房1上的读库被描述为包括机房2的数据库DB2中的用户B的账户信息中的有效性信息，但应该理解这是因为示例转账操作涉及的是用户B的账户。实际上，所述读库包括了与机房2的数据库DB2中的所有用户的账户信息中的有效性信息相对应的有效性信息。并且，如果所述单元化拆分部署存在更多的机房，则所述读库包含了与所有其他机房的数据库中的所有用户的账户信息中的有效性信息相对应的有效性信息。通过将所有其他机房的数据库中的所有用户的账户信息中的有效性信息集中到机房1上的读库中以在机房1处本地校验部署在其他机房中的用户账户的有效性，机房1与其他机房之间的跨机房的RPC调用都可以被取消。同样，所有的其他机房的数据库中的任何用户的账户信息中的任何有效性信息的变化，也会通过如上所述的自动或定时的机房之间的数据同步操作来被及时更新到机房1上的读库中，进而使得所述机房1上的读库中的用户有效性信息与所有其他机房的数据库中的所有用户的有效性信息始终保持一致。

在一个实施例中，机房之间的数据同步操作可以采取全量更新机制，即当变化发生或周期到期时，将该机房中的数据库中的所有用户的账户信息中的有效性信息统统打包传输给其他机房的读库以对其进行全面更新，而不管数据库中的其他用户的有效性信息是否也发生了变化。这种全量更新机制，可以减轻机房维护数据库的负担，但却需要较大的网络带宽。好在本公开中的读库仅仅存储了用户账户信息中的有效性信息，因此，这种全量更新机制是可接受的。

在一个较佳实施例中，所述机房之间的数据同步操作可以采取增量更新机制，即在变化发生或周期到期时，仅将该机房的数据库中的发生变化的用户的账户信息中的有效性信息传输给其他机房的读库以对其进行增量更新，而其他没有变化的用户的账户信息中的有效性信息不会被传送。这种增量更新机制对机房的数据库维护要求较高，需要其记录哪些用户的有效性信息发生了变化，但却可以大大节省网络资源，提高同步操作的速度。是目前比较流行的数据同步方式。

尽管在上述实施例中，所述读库是处于机房1中，但应该理解，所述读库可以根据实际需要位于不同的机房中。在一个较佳的实施例中，可以为单元化拆分部署中的多个机房中的每个机房都建立一个读库，所述读库包含了所有其他机房的数据库中的所有用户的有效性信息。当每个机房都拥有了其自己的读库之后，可以理解，发生在任意机房之间的诸如转账之类的业务都不再需要在这些机房彼此之间的跨机房的RPC调用。这就从整体上大大提高了整个系统的业务处理速度，减少了业务处理耗时，进而提升用户的体验。

基于上述方案，在图6中示出了根据本公开的一个实施例的用于减少单元化拆分部署记账耗时的流程。

根据所述流程，首先，在步骤610，机房1接收来自用户A的向用户B进行转账的请求(例如记账100元)，其中用户A的账户信息处于机房1的数据库DB1中，而用户B的账户信息则处于机房2的数据库DB2中。

接着，在步骤620中，在接收到所述请求之后，机房1的处理器执行冻结操作以从在数据库DB1中的用户A的账户上冻结(预留)转账的转账款金额，即100元。在一个实施例中，如果用户A的账户上的余额小于所请求的转账金额，例如小于100元，则向用户A返回错误报告并终止所述转账流程。

在所述冻结操作之后，与传统技术通过远程过程调用RPC与机房2进行交互以确定用户2的账户的状况的RPC调用机制不同的是，在机房1中提供了一个读库RDB。如前所述，该读库包括了用户B的账户信息中的最新有效性信息，也即与机房2的数据库DB2中的用户B的账户信息中的有效性信息始终保持一致。因此，在步骤630，机房1根据所述请求从该读库中检索并读取用户B的账户有效性信息。

接着，在步骤640，基于所述有效性信息对用户B的账户的有效性进行校验以确定其状态是否正常。所述校验可以包括：1、账户是否存在的校验；2、账户状态是否可用(例如是否销户、冻结)的校验；3、账户是否在风控冻结、司法冻结限制列表之中的校验等等。

随后，如果用户B的账户有效性校验正常(即用户B的账户存在，且其状态正常并且不存在风险)，则在步骤650中机房1立刻对数据库DB1中的用户A的账户执行真实扣款(例如从账户中实际扣减所冻结的100元)的操作，同时通知机房2对数据库DB2中的用户B的账户执行真实加钱(例如向账户增加100元)的操作以即时完成记账。

反之，如果用户B的账户有效性校验失败，例如，用户B的账户并不存在于读库中(也即机房2的数据库DB2中并不存在用户B这样一个用户)，或者用户B的账户的状态异常(例如已被销户或冻结)，或者用户B的账户存在风险隐患(例如被登记在风控或司法限制列表中)，则在步骤660中立刻向用户反馈转账失败的通知，同时可以将用户B的有效性校验失败的原因在通知中一并示出给用户A以便用户A了解转账失败原因。

综上所述，在本公开的方案中省去了对处于其他机房(例如机房2)中的用户B的账户的未达款记录操作(即跨机房的RPC调用)，同时在机房1上新建了与用户B的账户中的有效性信息对应的读库RDB以用于进行用户B的账户有效性的校验。这样，在增加了机房容量的同时，巧妙地解决了记账类业务的跨机房耗时问题，同时不会对用户产生不利的影响。

应该理解，除了作为示例描述的上述转账业务场景之外，本公开的方案还具有更加广阔的应用前景，例如在各种电子记账、银行网上交易、电子商务交易等领域，可以显著减少用户的记账和交易的等待时间。并且，需要进一步指出的是，尽管本公开是以记账业务方案为例来论述了技术方案，但应该理解，所述方案还适用于其它数据业务领域，只要所述数据业务的操作具有在账户状态正常时始终是成功的特性。例如各种有价值的充值卡、点卡、游戏装备道具、虚拟货币等等的电子业务交易。

虽然以上描述了不同的实施例，但应当理解的是它们只是作为示例而非限制。(诸)相关领域的技术人员将领会，在不偏离如所附权利要求书所定义的本公开的精神和范围的情况下，可以在形式和细节方面进行各种修改。因此，此处所公开的本公开的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。

Claims (26)

1.一种减少单元化拆分部署的记账耗时的方法，其特征在于，所述方法包括：

第一机房接收来自第一用户的向第二用户进行转账款转账的转账请求，其中，所述第一用户的账户处于所述第一机房的第一数据库中，而所述第二用户的账户处于第二机房的第二数据库中，所述转账请求是跨机房交易的转账请求；

所述第一机房执行冻结操作以在第一用户的账户上冻结转账款；

所述第一机房根据所述转账请求从部署在所述第一机房上的读库中检索出所述第二用户的账户的有效性信息；

基于所述有效性信息对所述第二用户的账户有效性进行校验以确定所述第二用户的账户是否正常；以及

当所述第二用户的账户校验为正常时，所述第一机房对所述第一数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作，并且同时通知所述第二机房对所述第二数据库中的所述第二用户的所述账户执行相应的增加所述转账款的操作；

其中所述读库是指只向所述第一机房提供读取服务的数据库，并且所述读库存储了所述第二用户的账户的有效性信息。

2.如权利要求1所述的方法，其特征在于，其中当所述第二用户的账户校验失败时，所述第一机房终止转账流程。

3.如权利要求1所述的方法，其特征在于，所述有效性信息包括账户状态信息、账户各类限制信息以及账户受限信息。

4.如权利要求3所述的方法，其特征在于，所述第二机房的所述第二数据库还包括其他用户的账户，并且所述读库包括所述第二机房的所述第二数据库中的所有用户的账户的有效性信息。

5.如权利要求4所述的方法，其特征在于，所述单元化拆分部署可以包括更多其他机房，并且所述读库还包括所述更多其他机房的数据库中的所有用户的账户的有效性信息。

6.如权利要求1所述的方法，其特征在于，所述读库与所述第二机房的所述第二数据库时刻同步数据以保持数据的一致性。

7.如权利要求5所述的方法，其特征在于，所述读库与所述第二机房和所述更多其他机房的数据库时刻同步数据以保持数据的一致性。

8.如权利要求7所述的方法，其特征在于，所述读库与其他机房的数据库的数据同步包括：

只要存储在所述其他机房的数据库的任何用户的账户中的有效性信息发生了变化，就自动执行数据同步操作；或者

定期执行数据同步操作来保持同步。

9.如权利要求8所述的方法，其特征在于，所述数据同步操作包括全量更新或增量更新。

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

在所述第一机房执行冻结操作之前，所述第一机房判断所述第一用户的账户中的余额是否充裕，包括：

如果所述第一用户的账户中的余额大于等于所述转账款，则在所述第一用户的账户上冻结所述转账款；

如果所述第一用户的账户中的余额小于所述转账款，则返回一个错误报告给所述第一用户并终止转账流程。

11.如权利要求5所述的方法，其特征在于，所述第二机房和更多其他机房中的每个机房都包含自己的读库，所述读库包括了所有其他机房的数据库中的所有用户的账户的有效性信息。

12.如权利要求1所述的方法，其特征在于，所述对所述第二用户的账户有效性进行校验包括下述校验：

所述账户是否存在；

所述账户的状态是否可用；

所述账户是否在风控冻结、司法冻结限制列表之中。

13.如权利要求1所述的方法，其特征在于，所述方法还可以用于其他数据业务。

14.一种减少单元化拆分部署的记账耗时的系统，其特征在于，所述系统包括：

第一机房，包括存储第一用户的账户的第一数据库；

第二机房，包括存储第二用户的账户的第二数据库；

其中所述第一机房被配置为：

接收来自所述第一用户的向第二用户进行转账款转账的转账请求，所述转账请求是跨机房交易的转账请求；

执行冻结操作以在所述第一用户的账户上冻结转账款；

根据所述转账请求从所述第一机房上的读库中检索出所述第二用户的账户的有效性信息；

基于所述有效性信息对所述第二用户的账户有效性进行校验以确定所述第二用户的账户是否正常；以及

当所述第二用户的账户校验为正常时，对所述第一数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作；并且同时通知所述第二机房对所述第二数据库中的所述第二用户的所述账户执行相应的增加所述转账款的操作；

其中所述读库是指只向所述第一机房提供读取服务的数据库，并且所述读库存储了所述第二用户的账户的有效性信息。

15.如权利要求14所述的系统，其特征在于，其中当所述第二用户的账户校验为失败时，所述第一机房终止转账流程。

16.如权利要求14所述的系统，其特征在于，其中所述有效性信息包括账户状态信息、账户各类限制信息以及账户受限信息。

17.如权利要求16所述的系统，其特征在于，所述第二机房的所述第二数据库还包括其他用户的账户，并且所述读库包括所述第二机房的所述第二数据库中的所有用户的账户的有效性信息。

18.如权利要求17所述的系统，其特征在于，所述单元化拆分部署可以包括更多其他机房，并且所述读库还包括所述更多其他机房的数据库中的所有用户的账户的有效性信息。

19.如权利要求14所述的系统，其特征在于，所述读库与所述第二机房的所述第二数据库时刻同步数据以保持数据的一致性。

20.如权利要求18所述的系统，其特征在于，所述读库与所述第二机房和所述更多其他机房的数据库时刻同步数据以保持数据的一致性。

21.如权利要求20所述的系统，其特征在于，所述读库与其他机房的数据库的数据同步包括：

只要存储在所述其他机房的数据库的任何用户的账户中的有效性信息发生了变化，就自动执行数据同步操作；或者

定期执行数据同步操作来保持同步。

22.如权利要求21所述的系统，其特征在于，所述数据同步操作包括全量更新或增量更新操作。

23.如权利要求14所述的系统，其特征在于，所述第一机房还被配置为：

在所述第一机房执行冻结操作之前，所述第一机房判断所述第一用户的账户中的余额是否充裕，包括：

如果所述第一用户的账户中的余额大于等于所述转账款，则在所述第一用户的账户上冻结所述转账款；

如果所述第一用户的账户中的余额小于所述转账款，则返回一个错误报告给所述第一用户并终止转账流程。

24.如权利要求18所述的系统，其特征在于，所述第二机房和更多其他机房中的每个机房都包含自己的读库，所述读库包括了所有其他机房的数据库中的所有用户的账户的有效性信息。

25.如权利要求14所述的系统，其特征在于，所述对所述第二用户的账户有效性进行校验包括下述校验：

所述账户是否存在；

所述账户的状态是否可用；

所述账户是否在风控冻结、司法冻结限制列表之中。

26.在包括多个机房的单元化拆分部署中的一个机房，包括：

处理器；

与所述处理器相连的存储器，所述存储器包括第一数据库和读库，所述第一数据库存储有第一用户的账户，而所述读库存储有在其他机房的其他数据库中的所有其他用户的账户的有效性信息；

其中，所述处理器被配置为：

接收来自所述第一用户的向所述其他用户之一进行转账款转账的转账请求，所述转账请求是跨机房交易的转账请求；

执行冻结操作以在所述第一用户的账户上冻结转账款；

根据所述转账请求从所述机房上的所述读库中检索出要被转账的所述其他用户的账户的有效性信息；

基于所述有效性信息对所述要被转账的其他用户的账户有效性进行校验以确定所述账户是否正常；以及

当所述要被转账的其他用户的账户校验为正常时，对所述数据库中的所述第一用户的所述账户执行扣减所述冻结的转账款的操作，并且同时通知所述其他机房对所述其他数据库中的所述要被转账的其他用户的账户执行相应的增加所述转账款的操作。