精华内容
下载资源
问答
  • 热点账户系统中,被高频繁地进行资金的进出操作,频繁出现加锁解锁操作的账户。比如,B2C系统中的企业虚拟户,用户购买商品时,资金从用户虚拟户转到企业虚拟户;用户退款时,资金从企业虚拟户转到用户虚拟户;...

    原文链接:https://blog.csdn.net/itegel84/article/details/52622135

    何为热点账户?

    热点账户即系统中,被高频繁地进行资金的进出操作,频繁出现加锁解锁操作的账户。比如,B2C系统中的企业虚拟户,用户购买商品时,资金从用户虚拟户转到企业虚拟户;用户退款时,资金从企业虚拟户转到用户虚拟户;这时,对企业虚拟户的资金进出操作就会成为整个业务的瓶颈。

     

    基本解决思路

    1. 控制并发数:所有进出都先进到线程池中,以线程池的并发数控制实际对热点账户操作的并发数

    2. 缩小事务控制范围:对热点账户的操作放在尽量小的事务范围,减少时间分片,提高成功率

    3. 乐观锁:对热点账户的更新操作使用乐观锁,减少时间分片,提高成功率

     

    改进型解决思路

    资金进出账户分开设计,

    入账账户设计

    思路:先记流水,定时增加账户余额,减少锁竞争

    不足:账户余额更新不及时

     

    出账账户设计

    思路:出账账户拆分成多个子账户,具体使用的账户通过前置进行hash分配(具体的hash函数会有更多方案)

    不足:在子账户扣款到最后时,可能总余额是够的,但是子账户余额不足了

     

    更复杂的方案

    入账账户不变,

    出账账户动态平衡,优化hash方案


    展开全文
  • 交易系统热点账户问题(三)

    千次阅读 2018-08-26 19:50:26
    本篇着重介绍一下从数据库设计层面的热点账户的经验与实践,修改余额方式及业务层面见交易系统热点账户问题(一),交易系统热点账户问题(二)。 二、问题分析 热点账户的性能问题,除了修改余额方式的优化跟结合...

    一、概述

    本篇着重介绍一下从数据库设计层面的热点账户的经验与实践,修改余额方式及业务层面见交易系统热点账户问题(一)交易系统热点账户问题(二)

    二、问题分析

    热点账户的性能问题,除了修改余额方式的优化跟结合业务场景的优化,还有一方面可从DB资源上优化。

    打个比方(数据不准确,只是想说明数据库资源也会是一个可优化的地方):

    如果一个实体机数据库,对单条数据的更新tps可达到1000/s,那对10条不同的数据更新tps也就9500/s,对100条更新的tps就70000/s。因为数据库这个资源是共享的,而我们真正的业务场景不会是只有一个账户。

    因此总结了一下,存在共享资源的部分:

    1.数据库内存及CPU

    2.数据库连接

    3.表空间(单表数据量)

    三、一些方案及实践

    1.数据库内存及CPU

    常用方案:分库

    2.数据库连接

    常用方案:

    (1)通过压测设置适当的数据库最大连接

    (2)读写分离

    (3)加机器

    3.表空间

    常用方案:分表

    分库分表方案:

    分表一般按照账号进行hash分表,把与账户相关的都进行通规则的分表,例如账户信息表,账户余额表,账户变动历史表,账户冻结解冻表等等。这样查询操作该账户的相关信息都会在一个分库里,一个分表里,是对于连表查询,事务操作必须的。

    四、其他

    数据的冷热分离,账户的“冷数据”为账户、账户主体、开户时间、账户类型。“热数据”为账户余额、累计金额之类。将两类数据分别建表存储,也可提高tps,也降低扩展对交易的影响。

    展开全文
  • 交易系统热点账户问题(二)

    千次阅读 2018-07-19 20:54:59
    本篇着重介绍一下从业务层面的热点账户的经验与实践,修改余额的几种方式见上篇介绍交易系统热点账户问题(一) 二、业务场景分析 可将业务场景划分为如下: 高频入:B端收单账户(结算账户),业务中间账户...

    目录

    一、概述

    二、业务场景分析

    三、业务角度热点账户实践及其特点

    四、其他角度方案


    一、概述

    本篇着重介绍一下从业务层面的热点账户的经验与实践,修改余额的几种方式见上篇介绍交易系统热点账户问题(一)     

    二、业务场景分析

    可将业务场景划分为如下:

    高频入:B端收单账户(结算账户),业务中间账户(业务处理时记录在途资金)

    高频扣:B端代扣代发账户(B端支付账户),B端手续费账户(用于做收支分离)

     

    三、业务角度热点账户实践及其特点

          1.异步削峰入账

    适用场景:

    1.适用B端收单账户与业务中间账户,一般B端收单账户资金是在清结算场景时会扣除,不会影响正常的业务,且MQ处理一般也会在毫秒级别完成,高并发时延迟也是在秒级,所以异步入账对商户几乎无感知。

    2.异步削峰扣款

    适用场景:

    1.适用B端代付代发账户以及手续费账户,一般B端高频扣款对相应时间都有一定的要求,且存在余额不足这种不可抗拒的失败因素,所以采用优先判断余额(脏读余额),拒绝掉大部分账户余额不足的请求,其次是异步增加超时以及重试次数的判断,确保请求的有效处理时间保持在一定范围里(超时时间及重试次数可由业务传入)。

    3.批量入账(缓冲入账)

    适用场景:

    1.适用B端收单账户与业务中间账户,一般异步削峰入账可解决大部分高并发问题,但有一些超级B端商户的交易量超级大,可采用该种方式应对。同样,也不会影响该类商户的清结算。

    其中,批量入账需新增一种修改余额的方式,一次更新余额,批量插入账户历史

    4.子账户(拆分多账户)

    适用场景:

    1.适用与所有账户的扣款入账。

    但是其中存在一些问题解决起来需要多写点代码:

                       ①扣款入账实际操作的是子账户(就是一个单独的账户,只是存了与原本账户之间的关系),主账户不存放余额,余额都是存放在子账户,所以查询余额时,需要做特殊处理(求和子账户)。

                       ②因为分散到多个子账户去处理扣款入账,那么账户的发生后余额就会是个问题(如果不需要发生后余额的话那就很赞了),扣入账产生的账户历史都存放的是子账户的发生后余额(或者不存),要是必须要的话,那就异步计算生成。

                       ③多子账户扣款时会存在子账户余额不足的问题,但实际所有子账户的余额总和可能是充足的,所以需要在余额不足时做子账户资金归集。且若为代付代发的场景,那么对其进行充值时,需要做充值资金拆分,去加到每个子账户中。                  

    四、其他角度方案

    单热点账户常见问题及解决方案在上文已经说的差不多了,但是实际场景中并非为单个热点账户。例如,账户基数为1000W,其中高并发账户有1W-5W,在正常扣入账时,这些热点账户在数据库上产生的锁等以及占用的数据库连接都是共享资源,会相互影响,以至于性能很难提升。

    分库分表,是个很常见也很好的解决方案,下节单独详说一下。

        

        以上为本人一些粗浅的看法及实践,如有错误或者不恰当处,还望海涵,帮忙指出,也欢迎留言讨论,邮箱地址laoxilaoxi@foxmail.com,下次一起讨论一下账户的分库分表实践。

        环境:Spring + Mybatis + DB2

        欢迎转载,转载请注明出处,谢谢。

    展开全文
  • 交易系统热点账户问题(一)

    千次阅读 2018-07-08 23:10:12
    二、热点账户常见问题 三、纯修改余额方式及其特点 一、热点账户 热点账户就是高频进行扣款、入账的账户,也就是热点账户该条数据为热点数据,会被频繁更新。一般热点账户分为两种,一种是频繁扣款的热点账户,...

    目录

    一、热点账户

    二、热点账户常见问题

    三、纯修改余额方式及其特点


    一、热点账户

            热点账户就是高频进行扣款、入账的账户,也就是热点账户该条数据为热点数据,会被频繁更新。一般热点账户分为两种,一种是频繁扣款的热点账户,另外一种是频繁入账的热点账户。

     

    二、热点账户常见问题

            1、性能瓶颈问题

            2、数据库压力问题

            3、成功率问题

     

    三、纯修改余额方式及其特点

           1. 乐观锁

            操作方式:

                    查询账户数据:

                            SELECT  BALANCE, STATUS, VERSION, … FROM ACCOUNT WHERE ID = ?

                    计算余额:

                            POST_BALANCE = BALANCE + AMOUNT

                            或者

                            POST_BALANCE = BALANCE - AMOUNT

                    更新账户余额:

                            UPDATE …. BALANCE = POST_BALANCE,VERSION = VERSION +1 WHERE ID = ? AND VERSION = ?

                            更新返回1,更新成功,返回0,更新失败,需抛出异常,回滚事务

                    插入账户历史:

                            INSERT … 

     

            优点:

                    不会存在阻塞,响应时间快;

                    数据库没什么压力;

                    在内存里可以完成很多复杂操作;

            缺点:

                    成功率不高,真的存在并发时,失败的请求比较多;

                    有效的性能依然不高;

     

            一般应对方案:

                    采用重试的方式,立即重试三次,以提高成功率

            个人看法:

                    这种重试在真正的有量的时候基本没啥作用,相反会徒增数据库的请求量,鄙人觉得这种重试只能解决请求量较小的时候的并发,比如突然同时进来两笔同一个账户的请求,处理失败的话进行重试是可以解决问题的;但是一瞬间进来200笔,甚至更多的话,这种重试没啥作用了。

                

           2. 悲观锁    

            操作方式:

                    查询账户数据:

                        SELECT BALANCE … FROM ACCOUNT FOR UPDATE WITH RS

                     计算余额:

                            POST_BALANCE = BALANCE + AMOUNT

                            或者

                            POST_BALANCE = BALANCE - AMOUNT

                    更新账户余额:

                            UPDATE …. BALANCE = POST_BALANCE,VERSION = VERSION +1 WHERE ID = ? 

                    插入账户历史:

                            INSERT …

     

            优点:

                    成功率高;

                    性能好;

                    在内存里可以完成很多复杂操作(余额签名);

            缺点:

                    会存在阻塞,响应时间长;

                    数据库压力大;

     

            一般应对方案:

                    采用信号量做热点账户资源使用限制,可以控制数据库压力,为数据库分压,且保持在一个客观的性能水平。

            个人看法:

                    这种方式能解决大部分的热点账户问题,也是本人之前采取的方式,不过偶尔会存在的超时问题也仅仅是一两笔,其余的都会被信号量拒绝了。

            

            3.数据库行级锁1

            操作方式:

                   更新余额:

                        入账:

                                UPDATE BALANCE = BALANCE +AMOUNT WHERE ID = ?

                        扣款:

                                UPDATE BALANCE = BALANCE - AMOUNT WHERE ID = ? AND BALANCE > AMOUNT

                   读取账户数据:(读取数据是为了在账户历史插入的时候保留发生后余额)

                                SELECT * FROM ACCOUNT WHERE ID = ? WITH CS 

                   插入数据

                                INSERT ...

     

            优点:

                    成功率高;

                    性能好(相对于2);

                    数据库压力也会小(相对于2);

                    相应时间也小(相对于悲观锁);

            缺点:

                    一些复杂的操作无法在内存完成了(余额签名)

     

            一般应对方案:

                    复杂的操作异步化,延迟也就是毫秒级别,或者舍弃签名

     

            个人看法:

                    这种方式与悲观锁相比好了很多,数据库压力小,性能高了,许增加上单账户限流或者信号量,防止单账户暴涨的量把数据库压爆。

     

            4.数据库行级锁2

            操作方式:

                    更新余额:

                        入账:

                                UPDATE BALANCE = BALANCE +AMOUNT WHERE ID = ?

                        扣款:

                                UPDATE BALANCE = BALANCE - AMOUNT WHERE ID = ? AND BALANCE > AMOUNT

                    插入数据

                                INSERT …

                    异步更新发生后余额:(或者根据业务情况不需要该步骤)

                                UPDATE  ACCOUNT_HISTORY SET POST_BALANCE = ? WHERE  ACCOUNT_ID =?

            优点:

                    成功率高;

                    性能好(相对于3);

                    数据库压力也会小(相对3);

                    相应时间也小(相对3);

            缺点:

                    代码复杂度高,需要异步化一些处理;

     

            个人看法:

                    一些非核心部分的修改及操作,不需要就去掉,需要的话那就异步处理下。

                

     

        以上为本人一些粗浅的看法及实践,如有错误或者不恰当处,还望海涵,帮忙指出,也欢迎留言讨论,邮箱地址laoxilaoxi@foxmail.com,下次一起讨论一下更新余额方式之外的热点账户的一些看法。

        环境:Spring + Mybatis + DB2

        欢迎转载,转载请注明出处,谢谢。            

         

    展开全文
  • 交易系统中会出现某些账户高频进行扣款入账的行为。这些账户可以分为两种,一种是出账热点账户,另外一种使入账热点账户。单账户进行余额更新会出现各种性能瓶颈、数据库压力、成功率等各种性能问题。 目标 通过该...
  • 互金账户系统的特点是并发量大、响应快、交易金额大,热点账户问题突出。一个合格的账户系统既要解决上述问题,又必须绝对保证资金安全。作为这家互联网金融公司的支付结算中心,其账户系统也必须具备上述特征。 一...
  • 金融账户系统的特点是并发量大、响应快、交易金额大,热点账户问题突出。一个合格的账户系统既要解决上述问题,又必须绝对保证资金安全。 记账分录 充值 借方:三方支付待清算账户(+) 贷方:个人余额账户(+)...
  • 金融账户系统的特点是并发量大、响应快、交易金额大,热点账户问题突出。一个合格的账户系统既要解决上述问题,又必须绝对保证资金安全。作为宜信这家互联网金融公司的支付结算中心,其账户系统也必须具备上述特征。...
  • 互金账户系统的特点是并发量大、响应快、交易金额大,热点账户问题突出。一个合格的账户系统既要解决上述问题,又必须绝对保证资金安全。作为宜信这家互联网金融公司的支付结算中心,其账户系统也具备上述特征。 1、...
  • 尤其针对没有支付系统开发经验的程序员,如下咱们解读一下此类问题(拿支付宝举例):支付宝需要有个账户记账,现在很多第三方公司使用支付宝作为结账业务主要手段,故出现了很多热点账户。比如互联网大商家,打车业务...
  • 过度科目理解

    2016-12-02 12:05:00
    但是这样会使得 存管机构资金待清算(资金落地) 成为热点账户,即可能同时有进有出,需要复杂的设计来提高性能,为了规避这个问题 就设立过度科目,就是互联网资金待处理(过渡科目),该科目无内部账户,代发的时候...
  • 网站架构技术

    2016-10-09 21:00:53
    没有热点的访问 数据不一致和脏读 缓存可用性 缓存预热 缓存穿透 缓存架构 jboss cache为代表的需要更新同步的分布式级缓存 以memcached为代表的不互相通信的分布式缓存 异步操作 ...
  • 在Twitter上,排名前50的品牌官方账户都是有数十年甚至上百年历史的传统品牌,只有一两家是新兴品牌。对中国来讲也是一样,新品牌想进入微博是很困难的,因为缺乏用户基础。 服务行业,尤其是纯服务类的行业,比如...
  • 在Twitter上,排名前50的品牌官方账户都是有数十年甚至上百年历史的传统品牌,只有一两家是新兴品牌。对中国来讲也是一样,新品牌想进入微博是很困难的,因为缺乏用户基础。 服务行业,尤其是纯服务类的行业,比如...

空空如也

空空如也

1
收藏数 20
精华内容 8
关键字:

交易系统热点账户问题