掌桥专利:专业的专利平台
掌桥专利
首页

一种余额管理方法及系统

文献发布时间:2023-06-19 12:14:58


一种余额管理方法及系统

技术领域

本申请实施例数据处理技术领域,尤其涉及一种余额管理方法及系统。

背景技术

随着技术的发展,使用各种支付系统进行在线支付成为越来越多人的选择。余额管理功能是各支付系统不可或缺的功能之一,但支付系统在分布式环境下的余额管理比单体架构环境下的余额管理复杂,其中一种体现是在分布式环境下多个线程同时操作同一份资源时,很容易出现线程安全问题。

例如,假设A、B线程同时向C账户转钱,C账户余额为N。A、B线程在转钱给C账户时,都会先获取C账户的余额。在分布式环境下,A、B线程的获取操作可能同时到达,即A、B线程都获取到C账户的余额为N。此时,若A线程给C账户转a元,则A线程执行C账户的余额增加操作,得余额为:N+a;B线程同时也给C账户转b元,则B线程执行C账户的余额增加操作,得余额为N+b。余额增加执行完成后,A、B线程分别提交自己的更改,如果A线程先提交,B线程后提交,则C账户的余额变成了N+b,并不是N+a+b,这就是出现了线程安全问题,因为B线程操作的C账户的余额,不是当前用户的真实余额。

为了解决上述技术问题,在相关技术中,可以对余额进行加锁,即在同一时刻,只有一个线程持有操作余额加减的权限。例如对余额加锁后,上述的转账场景会变为:A、B线程同时申请获取操作C账户余额的权限,A线程获取到后,立马对C账户的余额加锁,此时B线程发现C账户的余额被锁住了,则需要进行等待,直到A线程处理完成转账操作,C账户的余额更新成功后,A线程对余额释放锁,此时B线程才能获取到操作C账户的余额的权限。对余额加锁,可以保证同一时刻只有一个线程操作余额,从而将并行操作转变成串行操作,有效避免了线程安全问题。但是这种方式的弊端也很明显,即限制了一个操作只能在上一个操作完成后才能进行,降低了并发度,大大降低了处理效率。如果在高并发,或者是其中一个操作处理时间较长的业务背景下,这种处理方式在一定程度上是不可被接受的。

发明内容

本申请提供一种余额管理方法及系统,以解决相关技术中采用对余额进行加锁的方案造成的并发度降低、处理效率降低的问题。

第一方面,本申请实施例提供了一种余额管理方法,所述方法包括:

确定目标账户的账户余额,以及针对所述目标账户预先设置的余额分片策略;

采用所述余额分片策略对所述账户余额进行分片处理,获得多个余额分片;

响应于一个或多个消费者线程针对所述目标账户发起的余额操作请求,分别对所述目标账户的账户余额进行余额处理;

其中,所述余额操作请求包括操作类型和/或预估操作金额,所述操作类型包括余额减少操作;所述余额处理包括:

若当前余额操作请求的操作类型为余额减少操作,则确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额;

将所述目标余额发放至发出该余额操作请求的消费者线程。

第二方面,本申请实施例还提供了一种余额管理系统,所述系统包括:

余额及分片策略确定模块,用于确定目标账户的账户余额,以及针对所述目标账户预先设置的余额分片策略;

余额分片模块,用于采用所述余额分片策略对所述账户余额进行分片处理,获得多个余额分片;

余额处理模块,用于响应于一个或多个消费者线程针对所述目标账户发起的余额操作请求,分别对所述目标账户的账户余额进行余额处理;

其中,所述余额操作请求包括操作类型和/或预估操作金额,所述操作类型包括余额减少操作;所述余额处理模块包括:

余额减少处理子模块,用于若当前余额操作请求的操作类型为余额减少操作,则确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额;将所述目标余额发放至发出该余额操作请求的消费者线程。

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

第四方面,本申请实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述的方法。

本申请具有如下有益效果:

在本实施例中,在对目标账户的账户余额进行余额管理时,可以采用针对目标账户预先设置的余额分片策略、将该账户余额划分成多个余额分片。当接收到一个或多个消费者线程针对目标账户发起的余额操作请求时,如果存在余额减少操作的请求,则可以从多个余额分片中确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额,并将目标余额发放至发出该余额操作请求的消费者线程中。本实施例采用余额分片作为余额单位来响应针对同一账户余额的余额操作,可以实现同时响应针对目标账户的、并发的余额操作请求,使得多个消费者线程可以同时操作同一目标账户的余额,能最大限度提高并发度,提高系统的吞吐能力,并由此避免多个线程同时操作一份资源时引起的线程安全问题,提高了余额管理的准确率和处理效率。

附图说明

图1是本申请实施例一提供的一种余额管理方法实施例的流程图;

图2是本申请实施例一提供的一种余额管理者与余额消费者的连接框架图;

图3是本申请实施例二提供的一种余额管理方法实施例的流程图;

图4是本申请实施例三提供的一种余额管理方法实施例的流程图;

图5是本申请实施例四提供的一种余额管理系统实施例的结构框图;

图6是本申请实施例五提供的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本申请,而非对本申请的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本申请相关的部分而非全部结构。

实施例一

图1为本申请实施例一提供的一种余额管理方法实施例的流程图,本实施例可以应用于支付系统中,该支付系统可以包括单独的支付平台,也可以包括具有支付功能的其他产品,本实施例对此不作限制。

在本申请实施例中,如果将消费者线程作为余额消费者,则本实施例还可以包括余额管理者这一角色。如图2所示,在支付系统中,余额管理者可以是一个,余额消费者可以有多个。余额消费者可以包括各个需要操作余额的服务线程,例如,转账服务的一次转账请求线程,就是一个余额消费者。余额管理者中存储有当前系统(或者是某一个用户)的真实的余额,且负责对余额进行管理。余额管理者与各余额消费者之间可以通过心跳机制维持连接。每个余额消费者在接入余额管理者时需要首先向余额管理者注册,注册信息可以包括但不限于余额消费者的标识、需要消费的服务标识以及需要消费的账户信息等。

本实施例由余额管理者执行,可以包括如下步骤:

步骤110,确定目标账户的账户余额,以及针对所述目标账户预先设置的余额分片策略。

在一种例子中,目标账户可以为当前支付系统的账户(如公司账户,或者某种业务的账户),或者是某个用户的账户,本实施例对此不作限制。余额管理者可以获得目标账户的真实的账户余额,并对该账户余额进行实时余额管理。

在本实施例中,可以针对目标账户预先定义余额分片策略。在实现时,该余额分片策略可以为目标账户的拥有者根据实际情况设置的,例如,可以在支付系统中提供余额分片的功能,用户(即余额拥有者)可以通过支付系统提供的UI(User Interface,用户交互)界面,触发该余额分片的功能来对余额进行余额分片策略的设置。在其他实现中,该余额分片策略还可以是支付系统的开发人员预先定义的策略,例如,目标账户为当前支付系统的账户,则开发人员在进行余额管理开发时可以指定具体的余额分片策略。

作为一种示例,余额分片策略可以包括余额分片数量、各余额分片的比例等。其中,余额分片数量用于指示将账户余额分成多少个余额分片;各余额分片的比例用于表示各余额分片占账户余额的比例。例如,假设余额分片策略为1:2:3:4,则表示余额分片数量为4份,各余额分片的比例分别是10%、20%、30%和40%。

步骤120,采用所述余额分片策略对所述账户余额进行分片处理,获得多个余额分片。

在该步骤中,当余额管理者获得目标账户的账户余额以及确定该目标账户的余额分片策略以后,则可以按照余额分片策略对该账户余额进行分片处理,获得多个余额分片。

在实现时,余额管理者可以将账户余额按照余额分片数量以及各余额分片的比例进行分片,获得多个余额分片。例如,假设目标账户的账户余额为100USD,余额分片策略为1:2:3:4,则可以将该账户余额分成四个余额分片,各余额分片的金额分别是:10USD、20USD、30USD和40USD。又如,假设余额分片策略为1:1:1:1,则表示需要将100USD平均分成四份,每份余额分片的金额均为25USD。

在其他示例中,余额分片策略中也可以不指定余额分片数量以及各余额分片的比例,而是指定最小的余额分片金额以及分片间隔,然后按照分片间隔对账户余额进行分片。例如,对于100USD的账户余额,指定最小的余额分片金额为10USD,分片间隔是10,直到分完为止,则划分出的各余额分片为10USD、20USD、30USD和40USD。

需要说明的是,本实施例并不限于上述的余额分片策略的定义方式,用户可以根据实际业务需求,合理定制余额分片策略,使得余额分配达到最高效率。

步骤130,响应于一个或多个消费者线程针对所述目标账户发起的余额操作请求,分别对所述目标账户的账户余额进行余额处理。

在本实施例中,将账户余额划分成多个余额分片以后,以余额分片为操作单位,余额管理者可以同时响应针对目标账户的、并发的余额操作请求,使得多个消费者线程可以同时操作同一目标账户的余额,能最大限度提高并发度,提高系统的吞吐能力。

在一种实施例中,余额操作请求可以包括操作类型和/或预估操作金额,操作类型进一步可以包括余额减少操作;则步骤130进一步可以包括如下子步骤:

步骤130-1,若当前余额操作请求的操作类型为余额减少操作,则确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额;将所述目标余额发放至发出该余额操作请求的消费者线程。

在该实施例中,对于减少账户余额的操作请求,即余额操作请求的操作类型为余额减少操作,则余额管理者可以以余额分片为操作单位对消费者线程进行余额发放。具体的,在给账户余额进行减少时,为了达到余额的最大限度利用,余额消费者请求余额分配时,可以说明自己预期需要操作的余额(即预估操作金额)。余额管理者收到余额操作请求以后,根据操作类型判定当前请求为余额减少操作的请求,然后从该余额操作请求中提取出预估操作金额。确定预估操作金额以后,余额管理者可以选取与该余额管理者预估操作金额适配的余额分片作为目标余额,并将该目标余额发放至发出该余额操作请求的消费者线程中。

在一种实施例中,上述确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额的步骤,进一步可以包括如下步骤:

从所述余额分片中确定未加锁的、且额度比所述预估操作金额大的余额分片,作为候选余额分片;分别计算各候选余额分片与所述预估操作金额的差值;将差值最小的候选余额分片作为与该余额操作请求的预估操作金额适配的余额分片。

具体的,对于已被分配的余额分片,本实施例可以对其进行加锁处理,使得在同一时刻,仅有一个线程持有操作该余额分片加减的权限。因此,本实施例在确定与当前余额操作请求的预估操作金额适配的余额分片时,可以首先排除已被加锁的余额分片。然后,从未加锁的余额分片中,选取额度比当前预估操作金额大的余额分片作为候选余额分片,并计算各候选余额分片与预估操作金额的差值,然后将差值最小的候选余额分片作为与该余额操作请求的预估操作金额适配的余额分片。

例如,对于100USD的账户余额,划分出的各余额分片分别为10USD、20USD、30USD和40USD,其中,20USD这个余额分片已被加锁。假设当前余额操作请求需要扣减的预估操作金额为15USD,则比当前预估操作金额大的未加锁的余额分片为30USD和40USD,这两者与15USD的差值分别是15USD和25USD,则可以选取差值小的余额分片,即30USD作为与当前预估操作金额适配的余额分片,即待发放的目标余额为30USD。

在一种实施例中,在步骤130-1之后,本实施例的余额处理还可以包括如下步骤:

对所述适配的余额分片进行加锁处理。

在该实施例中,当将与当前预估操作金额适配的余额分片发放出去以后,则可以对该适配的余额分片进行加锁处理,以标志该余额分片已被分配,其他线程不能再对该余额分片进行操作,有效避免了线程安全问题。例如,在上述例子中,30USD作为与当前预估操作金额适配的余额分片发放出去以后,则可以对30USD这一余额分片进行加锁处理。

在一种实施例中,在步骤130-1之后,本实施例的余额处理还可以包括如下步骤:

接收所述消费者线程返还的剩余余额,所述剩余余额为所述消费者线程进行余额操作后,根据所述目标余额计算的剩余余额;将所述剩余余额作为余额分片进行存储。

在该实施例中,当余额消费者获得的余额分片过剩时,余额管理者有权回收过剩的余额。具体的,当消费者线程申请到目标余额以后,则可以将目标余额保存在本地供自身的消费使用。当消费者线程需要余额操作时,则可以操作本地存储好的余额,本地存储的这个余额由于是每个消费者线程独享的,故可以不考虑线程安全问题,可以直接操作。消费者线程进行余额操作后,还可以根据目标余额计算的剩余余额,然后向余额管理者返还该剩余余额。余额管理者收到该剩余余额以后,则将剩余余额作为余额分片进行存储。例如,余额管理者将30USD作为与当前预估操作金额适配的余额分片发放给转账服务线程以后,转账服务线程消费了25USD,则剩余余额为5USD,此时转账服务线程可以将该剩余余额5USD返还至余额管理者。余额管理者则可以将该5USD作为新的余额分片在本地进行存储以供后续分配使用。

需要说明的是,消费者线程在向余额管理者返还剩余余额时,可以首先判断余额管理者是否在线或者是否发生故障。例如,如果通过心跳机制判断与余额管理者的通信断开,则可以判定余额管理者不在线或者发生故障,则消费者线程可以暂停返还剩余余额,等到确定余额管理者在线后再返还剩余余额。

在一种进一步的实施例中,在上述将剩余余额作为余额分片进行存储之后,本实施例的余额处理还可以包括如下步骤:

确定本地存储的额度小于预设阈值的余额分片的数量;若该数量大于1,则将额度小于预设阈值的余额分片进行合并。

在该实施例中,有时余额消费者返还的剩余余额过小,导致余额管理者本地出现较多额度比较小的余额分片,且额度比较小的余额分片无法再次被分配使用,则此时余额管理者可以对这些小分片进行合并操作。具体的,可以设定一个预设阈值,当余额分片的金额小于该预设阈值时,则可以将该余额分片作为待合并的分片,若待合并的分片的数量大于1时,则可以将这些待合并的分片进行合并处理,得到一个金额较大的余额分片。

在本实施例中,在对目标账户的账户余额进行余额管理时,可以采用针对目标账户预先设置的余额分片策略、将该账户余额划分成多个余额分片。当接收到一个或多个消费者线程针对目标账户发起的余额操作请求时,如果存在余额减少操作的请求,则可以从多个余额分片中确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额,并将目标余额发放至发出该余额操作请求的消费者线程中。本实施例采用余额分片作为余额单位来响应针对同一账户余额的余额操作,可以实现同时响应针对目标账户的、并发的余额操作请求,使得多个消费者线程可以同时操作同一目标账户的余额,能最大限度提高并发度,提高系统的吞吐能力,并由此避免多个线程同时操作一份资源时引起的线程安全问题,提高了余额管理的准确率和处理效率。

实施例二

图3为本申请实施例二提供的一种余额管理方法实施例的流程图,本实施例在实施例一的基础上进行说明,除了实施例一的步骤130-1以外,本实施例的余额处理还可以包括如下步骤:

步骤130-2,若当前余额操作请求的操作类型为余额增加操作,则将预设的余额变量发放至该余额操作请求的消费者线程;接收该消费者线程针对所述余额变量进行余额增加操作后返回的新增余额,并在所述账户余额中添加所述新增余额。

在本实施例中,对于增加账户余额的操作请求,即余额操作请求的操作类型为余额增加操作,其实余额消费者并不需要确切知道目标账户的具体余额,则余额管理者可以将预设的余额变量发放至该余额操作请求的消费者线程中。该消费者线程在接收到该余额变量以后,可以在该余额变量的基础上增加余额,然后将新增余额同步到余额管理者中,由余额管理者执行真正的数值增加逻辑,即在账户余额中添加该新增余额。这样,如果余额管理者同时处理并发的多个余额增加操作的请求,可以根据每个余额消费者返回的携带余额变量的新增余额,进行逐一的余额增加逻辑,每次进行余额增加时,许哟啊确保余额变量的值是最新的余额,从而避免多个线程同时操作一份资源时引起的线程安全问题,提高了余额管理的准确率和处理效率。

实施例三

图4为本申请实施例三提供的一种余额管理方法实施例的流程图,本实施例在实施例一和实施例二的基础上进行说明,可以包括如下步骤:

步骤410,调用指定接口来获取余额管理封装数据;接入所述余额管理封装数据,以实现余额管理功能。

步骤420,确定目标账户的账户余额,以及针对所述目标账户预先设置的余额分片策略。

步骤430,采用所述余额分片策略对所述账户余额进行分片处理,获得多个余额分片。

步骤440,响应于一个或多个消费者线程针对所述目标账户发起的余额操作请求,分别对所述目标账户的账户余额进行余额处理。

其中,所述余额操作请求包括操作类型和/或预估操作金额,所述操作类型包括余额减少操作;所述余额处理包括:

步骤440-1,若当前余额操作请求的操作类型为余额减少操作,则确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额;将所述目标余额发放至发出该余额操作请求的消费者线程。

在本实施例中,如实施例一和实施例二所述的余额管理的功能,开发人员在实现时,可以通过支付系统调用指定接口来获取余额管理封装数据,并在支付系统中接入该余额管理封装数据,从而在支付系统中实现余额管理功能。这种将余额管理封装数据封装起来提供给开发人员的方式,可以实现将多线程的操作对业务侧屏蔽,业务开发无需具备高水平的多线程开发经验,就可以开发出安全可靠,且处理效率高的余额管理功能,降低了系统开发成本和代码维护成本。

实施例四

图5为本申请实施例四提供的一种余额管理系统实施例的结构框图,可以包括如下模块:

余额及分片策略确定模块510,用于确定目标账户的账户余额,以及针对所述目标账户预先设置的余额分片策略;

余额分片模块520,用于采用所述余额分片策略对所述账户余额进行分片处理,获得多个余额分片;

余额处理模块530,用于响应于一个或多个消费者线程针对所述目标账户发起的余额操作请求,分别对所述目标账户的账户余额进行余额处理;

其中,所述余额操作请求包括操作类型和/或预估操作金额,所述操作类型包括余额减少操作;所述余额处理模块530包括:

余额减少处理子模块531,用于若当前余额操作请求的操作类型为余额减少操作,则确定与该余额操作请求的预估操作金额适配的余额分片作为目标余额;将所述目标余额发放至发出该余额操作请求的消费者线程。

在一种实施例中,所述余额处理模块530还可以包括如下子模块:

剩余余额处理子模块,用于接收所述消费者线程返还的剩余余额,所述剩余余额为所述消费者线程进行余额操作后,根据所述目标余额计算的剩余余额;将所述剩余余额作为余额分片进行存储。

在一种实施例中,所述余额处理模块530还可以包括如下子模块:

余额分片合并子模块,用于确定本地存储的额度小于预设阈值的余额分片的数量;若该数量大于1,则将额度小于预设阈值的余额分片进行合并。

在一种实施例中,所述余额处理模块530还可以包括如下子模块:

加锁子模块,用于对所述适配的余额分片进行加锁处理。

在一种实施例中,所述余额减少处理子模块531具体用于:

从所述余额分片中确定未加锁的、且额度比所述预估操作金额大的余额分片,作为候选余额分片;

分别计算各候选余额分片与所述预估操作金额的差值;

将差值最小的候选余额分片作为与该余额操作请求的预估操作金额适配的余额分片。

在一种实施例中,所述余额分片策略包括:余额分片数量以及各余额分片的比例;所述余额分片模块520具体用于:

将所述账户余额按照所述余额分片数量以及各余额分片的比例进行分片,获得多个余额分片。

在一种实施例中,所述操作类型还包括余额增加操作;所述余额处理模块530还可以包括如下子模块:

余额增加处理子模块,用于若当前余额操作请求的操作类型为余额增加操作,则将预设的余额变量发放至该余额操作请求的消费者线程;接收该消费者线程针对所述余额变量进行余额增加操作后返回的新增余额;在所述账户余额中添加所述新增余额。

在一种实施例中,所述系统还可以包括如下模块:

余额管理功能接入模块,用于调用指定接口来获取余额管理封装数据;接入所述余额管理封装数据,以实现余额管理功能。

需要说明的是,本申请实施例所提供的上述余额管理系统可执行本申请实施例一至实施例三所提供的余额管理方法,具备执行方法相应的功能模块和有益效果。

实施例五

图6为本申请实施例三提供的一种电子设备的结构示意图,如图6所示,该电子设备包括处理器610、存储器620、输入装置630和输出装置640;电子设备中处理器610的数量可以是一个或多个,图6中以一个处理器610为例;电子设备中的处理器610、存储器620、输入装置630和输出装置640可以通过总线或其他方式连接,图6中以通过总线连接为例。

存储器620作为一种计算机可读存储介质,可用于存储软件程序、计算机可执行程序以及模块,如本申请实施例中的方法对应的程序指令/模块。处理器610通过运行存储在存储器620中的软件程序、指令以及模块,从而执行电子设备的各种功能应用以及数据处理,即实现上述实施例一至实施例三的方法。

存储器620可主要包括存储程序区和存储数据区,其中,存储程序区

可存储操作系统、至少一个功能所需的应用程序;存储数据区可存储根据终端的使用所创建的数据等。此外,存储器620可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中,存储器620可进一步包括相对于处理器610远程设置的存储器,这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置630可用于接收输入的数字或字符信息,以及产生与电子设备的用户设置以及功能控制有关的键信号输入。输出装置640可包括显示屏等显示设备。

实施例六

本申请实施例六还提供一种包含计算机可执行指令的存储介质,所述计算机可执行指令在由服务器的处理器执行时用于执行实施例一中任一实施例中的方法。

通过以上关于实施方式的描述,所属领域的技术人员可以清楚地了解到,本申请可借助软件及必需的通用硬件来实现,当然也可以通过硬件实现,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述的方法。

值得注意的是,上述装置的实施例中,所包括的各个单元和模块只是按照功能逻辑进行划分的,但并不局限于上述的划分,只要能够实现相应的功能即可;另外,各功能单元的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。

注意,上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解,本申请不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此,虽然通过以上实施例对本申请进行了较为详细的说明,但是本申请不仅仅限于以上实施例,在不脱离本申请构思的情况下,还可以包括更多其他等效实施例,而本申请的范围由所附的权利要求范围决定。

相关技术
  • 网络连接的储值状态管理方法和系统及储值余额管理方法
  • 一种账户余额管理方法及系统
技术分类

06120113227753