账户并发处理方法及账户并发处理系统

摘要

一种账户并发处理方法，用于账户处理中心处理账户操作请求，包括：(1)将账户分成高并发账户和普通账户；(2)当接收到某一账户处理操作请求时，先判断该账户是否是高并发账户，若是高并发账户则进行步骤(3)，否则进行步骤(4)；(3)若账户被锁定，则将当前操作进入等待进程队列等待，直到执行当前操作；(4)进一步判断账户有没有被锁定，若账户已被锁定，则直接报错后返回，否则执行当前操作。通过这种方式可以对高并发账户提供更优质的服务，而对于普通账户，一旦某天普通账户上发生了大量的并发，通过报错可以有效的控制并发量，防止这类账户对系统造成危害。

说明书

技术领域

本申请涉及网络领域，尤其涉及账户并发处理方法及账户并发处理系统。

背景技术

请参阅图1，其为现有账户处理系统的原理示意图。该账户处理系统包括账户处理中心11和若干客户端12。账户处理中心11可以通过专线连接客户端12，也可以通过网络(因特网、内部网)等连接至客户端12。客户端12可以是多个。客户端12也可以是独立终端，也可以为若干终端组成的局域网络。账户处理中心11至少包括服务器21和数据库22。数据库22用于存储账户信息及各种处理信息。服务器21用于对账户进行各种操作和管理。

以账户处理中心11为第三方支付平台为例，当客户端12向账户处理中心11发送指令，该指令是指将A账户中的资金向若干其它账户(以账户B1、B2、B3...Bn)支付金额分别为S1、S2、S3...Sn，现有的支付流程为：

首先，账户处理中心11接收到客户端12发送的支付操作；

接着，账户处理中心11先处理一次支付操作：

服务器21锁住A账户，判断A账户中的金额是否超过S1金额，若账户中的金额大于等于S1金额，则将A账户的余额扣除S1金额后，释放A账户的锁，再锁住B1账户，在B1账户中增加S1金额，操作完毕后释放B1账户的锁。

如此，账户处理中心11需要进行n次上述支付操作。

也就是说，为了避免账户并发处理而有可能影响账户内金额，需要保证在同一时刻只允许对账户进行一次操作，通常是通过对账户进行加锁来实现的。即，每一个对账户的操作，先判断能否获得这个账户的锁，若能，则说明对同一账户没有其它操作正在处理，当前能对该账户进行本操作。若不能，说明对同一账户有其它操作正在处理，需要等待。当等待的操作有多个时，就形成了等待进程队列。这个等待进程队列中每一个操作都需要对账户进行加锁和释放锁的操作，并且服务器只能串行处理该些操作，占用比较多的资源。特别是，当这样的账户(即该账户有等待进程队列)有多个或者账户的等待进程队列中需要处理的操作个数庞大时，就造成整个系统的处理效率低下，而且很容易造成系统的瘫痪。假设数据库的最大连接数是100个。也就是说，数据库能承受最大并发访问数据量为100个。当等待进程队列中有100个操作时，整个系统就不能接受新的账户操作请求，由此造成后续新账户操作的效率低，甚至容易造成整个系统瘫痪。

然而，由于存在一些突发事件而导致某个或某些账户的操作异常，比较常见的操作异常为对账户的操作暴增，使得账户的等待进程队列中需要处理的操作个数暴增，由此造成整个系统的处理效率降低。

这些突发事件有些是由于系统的不稳定或技术原因造成的，有些是由于人为造成的，比如，网上交易过程中商户都有本商户的信用等级，信用等级是购买者或其它用户对商户服务及其出售商品的满意度评价的体现，网上交易过程中无法真实感受到商品，因此信用等级对商户来说非常重要。以得到更高信用等级为直接目的，而进行的一些虚假交易，我们称之为信用炒作。当一些商户组成信用炒作团体时，这些商户相关的账户就可能出现频繁的操作，由于出现某时刻发生在这些账户上的操作特别大，使得系统需要消耗大量的资源来处理该些操作，由此也使其它账户的正常操作受到影响。

也就是说，现有的账户处理中心的账户处理操作存在以下的技术缺陷：

现有的支付流程需要对A账户进行频繁操作，每一次操作都需要锁住A账户，并在处理完毕后释放A账户。不仅造成服务器21的处理效率低，更为重要的是造成服务器21的处理能力急剧下降，甚至不能接收其它客户端发出的处理请求，严重的造成整个服务器21的瘫痪。

特别是，当接收到这类对账户进行批处理请求个数较多，或者这类对账户进行批处理请求中需要处理账户特别多时，对整个服务器21造成的运行压力非常大，容易造成服务器21请求处理的队列堵塞，容易造成请求处理的失败率增加。同时，也影响其它用户的体验。

发明内容

本申请的第一目的在于提供一种账户并发处理方法，以解决现有技术中由于突发事件引起同一账户上并行操作增加而导致整个系统的处理效率低下的技术问题。

本申请的第二目的在于提供一种账户并发处理系统，以解决现有技术中由于突发事件引起同一账户上并行操作增加而导致整个系统的处理效率低下的技术问题。

一种账户并发处理方法，用于账户处理中心处理账户操作，包括：

(1)将账户分成高并发账户和普通账户；

(2)当接收到某一账户处理操作请求时，先判断该账户是否是高并发账户，若是高并发账户则进行步骤(3)，否则进行步骤(4)；

(3)若账户被锁定，则将当前操作进入等待进程队列等待，直到执行当前操作；

(4)进一步判断账户有没有被锁定，若账户已被锁定，则直接报错后返回，否则执行当前操作。

步骤(4)还包括，当账户已被锁定时，延时预先设定的时间后再次判断当前操作是否被执行，若否，则直接报错后返回。

较优地，步骤(1)进一步包括：A1：根据高并发账户所占总账户数的百分比来设定高并发账户的数量Q；A2：统计预先设定的周期内各账户对应的本账户进行操作的操作数，并按照操作数依次进行排序；A3：取操作数高的前Q位账户做为高并发账户。并且，步骤(1)最好还包括，将所有高并发账户的账户号保存在内存中。

步骤(2)还包括通过将账户号和预先保存在内存中的所有高并发账户的账户号进行对比，如有相同，则该账户为高并发账户，否则，该账户为普通账户。

执行当前操作进一步包括：锁住账户；执行对账户的操作；执行完毕后，释放该账户对应的锁。

一种账户并发处理系统，包括账户处理中心，该账户处理中心进一步包括：

高并发账户库：用于存储所有高并发账户信息；

账户性质判断单元：用于接收到某一账户处理操作请求时，根据高并发账户库去判断该账户是否是高并发账户；

高并发账户处理单元：用于进一步判断账户有没有被锁定，若账户被锁定，则将当前操作进入等待进程队列等待，直到执行当前操作，否则直接执行当前操作；

普通账户处理单元：用于进一步判断账户有没有被锁定，若账户已被锁定，则直接报错后返回，否则执行当前操作。

所述高并发账户处理单元进一步包括：

高并发账户锁定判断子单元，用于判断该高并发账户当前是否被锁；

执行操作子单元，用于锁住账户，再执行对账户的操作，后释放该账户对应的锁。

所述普通账户处理单元进一步包括：

普通账户锁定判断子单元，用于判断该账户当前是否被锁；

执行操作子单元，用于锁住账户，再执行对账户的操作，后释放该账户对应的锁；

锁定处理子单元，用于该账户被锁后接收到对该账户的操作，采用直接报错后返回的处理。

一种账户并发处理方法，用于账户处理中心处理客户端发送的账户操作请求，包括：

(1)账户处理中心将账户分成若干种类型账户，每一种类型设置对应的账户被锁定后的处理操作；

(2)当接收到客户端发送的某一账户处理操作请求时，先确定该账户所属的类型；

(3)账户处理中心进一步判断账户有没有被锁定，若账户被锁定，就按照该账户所属类型对应的账户被锁定后的处理操作流程进行操作，否则执行当前操作。

步骤(1)中每一种类型设置对应的账户被锁定后的处理操作进一步包括：

A1：账户被锁定后，判断M的次数是否为零，若是，则直接报错后返回，若否，过等待时间T后判断账户是否被锁定，如果被锁定，则M的次数减一，再进行步骤A1，如果未被锁定，则执行当前操作，

其中，M为每一种类型设定的对应的等待次数，M的范围可以为0至无限大。

与现有技术相比，本申请具有以下优点：

对于一个普通的账户，在账户上发生的业务是有规律的，在一段时间内有个固定的模式。以某个商务平台为例，一个普通的买家一天的交易量是有限的，每天不会发生太多的交易，也就是这个账户上的交易并发性不是很大，如果某天在这个账户上发生了大量的交易，很可能就是一些非法业务。而对于大的卖家，则在其上就可能有大量的并发，会有很多买家买这个卖家的商品，从而产生大的并发交易。根据以上特点，申请人把账户分为两类，高并发账户和普通账户。对于高并发账户，当账户余额发生变化，在锁定账户时如果发现账户已经被锁，那么一直等待而不报错返回。而对于普通账户发生余额变动，在锁定账户时如果发现账户被锁，直接报错返回，通过这种方式我们可以对高并发账户提供更优质的服务，而对于普通客户，这样一旦某天普通账户上发生了大量的并发，通过报错可以有效的控制并发量，防止这类账户对系统造成危害。

另外，本申请还可以对普通账户进行操作请求时，若该账户已被锁定时，延时预先设定的时间后再次判断当前操作是否被执行，若否，则直接报错后返回。这种延时处理，能够降低普通账户可能存在的并发处理的报错率。

附图说明

图1为现有账户处理系统的原理示意图；

图2为本申请的一种账户处理中心的原理结构示意图；

图3为账户处理方法的一种流程示意图；

图4为账户处理方法的另一种流程示意图。

具体实施方式

以下结合附图，具体说明本申请。

请参阅图1和图2，其为本申请的一种账户并发处理系统的原理结构示意图。它包括账户处理中心11和客户端12。客户端12提出对账户处理中心11上的某个账户或某些账户的操作请求，并接收账户处理中心11返回的处理结果。

该账户处理中心11进一步包括服务器31和数据库32。数据库32用于存储账户信息及各种处理信息。服务器31用于对账户进行各种操作和管理。在本申请中，数据库32除了包括用于存储账户信息的账户存储单元321、用来存储账户处理操作记录信息的账户操作记录存储单元322之外，还包括：

高并发账户库323：用于存储所有高并发账户信息。高并发账户信息主要是指能唯一识别高并发账户的账户号。本申请可以按照各种规则来设定本中心的高并发账户，比如，可以将重点账户设定为高并发账户。也可以将账户一定时间段内进行操作的操作数从高到低排序，取操作数高的若干账户作为高并发账户。

服务器31进一步包括账户性质判断单元311、高并发账户处理单元312和普通账户处理单元313。

账户性质判断单元311：用于接收到某一账户处理操作请求时，根据高并发账户库去判断该账户是否是高并发账户，如果是，就触发高并发账户处理单元312，如果否，则触发普通账户处理单元313。

高并发账户处理单元312：用于进一步判断账户有没有被锁定，若账户被锁定，则将当前操作进入等待进程队列等待，直到执行当前操作，否则直接执行当前操作。

高并发账户处理单元312进一步包括：

高并发账户锁定判断子单元3121，用于判断该高并发账户当前是否被锁；

等待进程队列管理子单元3122，用于管理等待进程队列的操作，管理等待进程队列包括对该些操作的进程如何进行处理的，比如按照先来先处理的原则，或者采用优先级处理的原则等。有些系统自带有这个管理子单元3122，此时申请人就无需自设定该管理子单元。

执行操作子单元3123，用于锁住账户，再执行对账户的操作，后释放该账户对应的锁。

普通账户处理单元313：用于进一步判断账户有没有被锁定，若账户已被锁定，则直接报错后返回，否则执行当前操作。普通账户处理单元313进一步包括：

普通账户锁定判断子单元3131，用于判断该账户当前是否被锁；

执行操作子单元3132，用于锁住账户，再执行对账户的操作，后释放该账户对应的锁；

锁定处理子单元3133，用于该账户被锁后接收到对该账户的操作，采用直接报错后返回的处理。

普通账户处理单元313还包括延时子单元3134，用于当账户已被锁定时，延时预先设定的时间后再次判断当前操作是否被执行，若否，则直接报错后返回。

上述公开的是单元仅仅是指逻辑上的单元，通常是用软件来实现的，但本申请并不排除用硬件来实现。

请参阅图3，其为一种账户并发处理方法的流程图。它用于账户处理中心处理账户操作，包括：

S110：将账户分成高并发账户和普通账户。在本实例中，现有的账户处理中心11已存在非常多的账户，由此额外设置一高并发账户库323，用以保存高并发账户信息。判断某一账户是高并发账户还是普通账户，只需要查找高并发账户库323即可获知。这种方式，无需要对现有的账户信息进行修改，减少对原有系统稳定性的影响。还有一种方式是，对账户设定一性质属性项，每一账户在性质属性项中保存本账户的属性：高并发账户还是普通账户。这种方式也是可以的，但是需要对现有账户进行修改，比较费时间。

将账户分为高并发账户和普通账户，可以通过以下步骤完成：

A1：根据高并发账户所占总账户数的百分比来设定高并发账户的数量Q；

A2：统计预先设定的周期内(如一周内)各账户进行操作的操作数，并按照操作数依次进行排序；

A3：取操作数高的前Q位账户做为高并发账户，并将高并发账户信息保存在高并发账户库323中。

并且，定周期根据操作数来更新高并发账户库323中的高并发账户信息。通过这种方式，能将本来操作数比较多的账户找出来。

为了提高后续处理的效率，可以将高并发账户库323中的所有高并发账户的账户号保存在服务器31的内存中。

S120：当接收到某一账户处理操作请求时，先判断该账户是否是高并发账户，若是高并发账户则进行步骤S130，否则进行步骤S140。

本申请是通过以下步骤判断该账户是否是高并发账户的：

将账户号和预先保存在内存或高并发账户库323中的所有高并发账户的账户号进行对比，如相同，则该账户为高并发账户，否则，该账户为普通账户。

S130：判断账户是否被锁定，若是，则将当前操作进入等待进程队列等待，直到执行当前操作(S131)，若否，则对账户执行当前操作(S132)。

S140：进一步判断账户有没有被锁定，若账户已被锁定，则直接报错后返回(S141)，否则执行当前操作(S132)。

S130的步骤可以通过oracle语句来实现“select*from account where accountNo＝′xxxxx′for update”

该语句表示：。对accountNo为xxxxx的账户进行操作，该命令隐含

“select*from account where accountNo＝′xxxxx′for update wait”

即，若该账户被锁后，一直等待，直到能执行该操作。

S140的步骤也可以通过JAVA语句来实现。

select*from account where accountNo＝′yyyyy′for update nowait

这条语句表示：如果对账户进行操作时发现该账户已经被锁，则报错。上述的仅是一种实现的范例，并非局限于此，任何实现本思想的实现方式，都应在本申请的保护范围内。

执行当前操作进一步包括：锁住账户；执行对账户的操作；执行完毕后，释放该账户对应的锁。

请参阅图4，其为另一种账户并发处理方法的流程图。

本实例中的S240的实施步骤与图3的S140的实施步骤不同，其他步骤与图3中的步骤大致相同。

S110：将账户分成高并发账户和普通账户。

S120：当接收到某一账户处理操作请求时，先判断该账户是否是高并发账户，若是高并发账户则进行步骤S130，否则进行步骤S240。

S130：判断账户是否被锁定，若是，则将当前操作进入等待进程队列等待，直到执行当前操作(S131)，若否，则对账户执行当前操作(S132)。

S240：进一步判断账户有没有被锁定，若账户已被锁定，则等待预先设定的时间(S241)，进一步判断当前操作是否被执行(S242)，若否，直接报错后返回(S243)，若是，则执行当前操作(S132)。当账户未被锁定时，则也是执行当前操作(S132)。

对账户进行锁住有很多种实现方式，比如，一个常见的方式是，对账户设置一个标志位，标志位为1，表示这个账户是锁住的，标志位为0，表示这个账户未被锁住。检测该账户是否被锁住，就是检测该标志位。

本实例中，在接收到对普通账户的操作请求时，发现当前该账户有正在处理的操作，延时一预设时间再去判断能否进行处理。能够降低普通账户可能存在的并发处理的报错率。

本申请实施例将账户划分为高并发账户和普通账户两种类型进行说明，当然在具体实施过程中，可以不受本申请实施例的限制将账户划分多种类型，例如：第一类型账户、第二类型账户、第三类型账户......第N类型账户。具体可以通过以下步骤完成：

A1：根据第一类型账户所占总账户数的百分比来设定第一类型账户的数量Q1，根据第二类型账户所占总账户数的百分比来设定第二类型账户的数量Q2，以此类推，可设定第N类型账户的数量Qn；

A2：统计预先设定的周期内(如一周内)各账户进行操作的操作数，并按照操作数由低到高依次进行排序；

A3：取操作数最低的前Q1位账户做为第一类型账户，取接下来的Q2位账户做为第二类型账户，以此类推可获得各种类型的账户信息，并将各种类型的账户信息保存在数据库中。

对账户划分成多种类型，还可以通过以下步骤来实现：

B1：预先设定第一类型账户、第二类型账户、...第N类型账户各自在总账户数中所占的比例；

B2：统计预先设定的周期内(如一周内)各账户进行操作的操作数，并按照操作数由低到高依次进行排序成账户队列；

B3：统计当前的总账户数M；

B4：按照各类型账户所占的比例和总账户数M，计算出各类型账户所占的数量；

B5：每一类型账户依次从账户队列中取对应数量的账户作为本类型账户中的账户，并将该些账户信息保存至对应的数据库中。

本实施例的处理思想为：将账户划分为第一类型账户、第二类型账户、第三类型账户......第N类型账户，针对不同类型的账户设定不同的处理策略。比如，将不同的类型账户分成不同的优先级，优先级越高，当账户被锁定时，则等待预先设定的时间也就越长。

举个实例来说，所述处理策略可以为：对于第一类型的账户，若账户被锁定时，则直接报错返回；对于第二类型的账户，当账户被锁定时，则等待预先设定的时间t，判断该账户是否仍被锁定，若仍被锁定，则直接报错返回；对于第三类型的账户，当账户被锁定时，则等待预先设定的时间t进行判断后，发现该账户仍被锁定时，则再等待一个预先设定的时间t，若仍被锁定，则报错返回，以此类推可针对不同类型的账户设定不同的处理策略。

通过上述对账户分成若干种类型，为每一种类型的账户设定不同的处理策略，即，

一种账户并发处理方法，用于账户处理中心处理客户端发送的账户操作请求，包括：

(1)账户处理中心将账户分成若干种类型账户，每一种类型设置对应的账户被锁定后的处理操作；

(2)当接收到客户端发送的某一账户处理操作请求时，先确定该账户所属的类型；

(3)账户处理中心进一步判断账户有没有被锁定，若账户被锁定，就按照该账户所属类型对应的账户被锁定后的处理操作流程进行操作，否则执行当前操作。

步骤(1)中每一种类型设置对应的账户被锁定后的处理操作进一步包括：

K1：账户被锁定后，判断M的次数是否为零，若是，则直接报错后返回，若否，过等待时间T后判断账户是否被锁定，如果被锁定，则M的次数减一，再进行步骤K1，如果未被锁定，则执行当前操作，

其中，M为每一种类型设定的对应的等待次数，M的范围可以为0至无限大。

以上公开的仅为本申请的几个具体实施例，但本申请并非局限于此，任何本领域的技术人员能思之的变化，都应落在本申请的保护范围内。