【阿里在线技术峰会】何登成：AliSQL性能优化与功能突破的演进之路


http://blog.csdn.net/fei33423/article/details/47340675

1. 去并发--排队是解决这个问题的核心.

n个线程. 被分层n组. 通过库,表,行逐级hash,智能扩容缩https://yq.aliyun.com/edu/lesson/play/270 .

如果库层级不排序,那么就业务方通过redis分布式锁处理,做到mq通知. mq会是瓶颈.

   何登成-mysql库存最大500并发量.--- 4k --并发提交后4w

2. 批量提交 -登哥使用了这个技术

3. 切分帐户,库存字段. 分别抢购. 会导致获取总量较复杂.

并且要循环扣(每次扣1个),或者可能导致余额不足但不保证有少量余额.

(需要动态的缩减帐户数量.锁帐户然后操作转移钱款 ( 分布式锁,最好一条存储过程搞定,少一次网络交互.).  select num from update   set num-num where account_id=1;然后 update set id2.num+=id1.num where id=2;

4. 特殊场景,前端业务自行拦截(下沉到数据库服务端会导致无效逻辑判断过多. 功能越复杂,自然cpu计算就多.例如B+树降级为hash索引).总量就是4,那么一旦排队大于4*x (或者手动定死控制)个后就设置标志位拦截所有请求. (这个和客户端线程池有异曲同工之妙)

  

  

  支付宝需要有个账户记账，现在很多业务已经出现了很多热点账户。比如互联网大商家，打车业务，快的，滴滴。

      账号有余额，主要用于不能扣成负数。 大并发交易下余额快速变化，导致数据库竞争等待。

      原则: 不同的业务要求,不同的设计,同时会影响业务需求. 

三大需求,是否都容易满足:

1.减款

2.加款

3.读取总金额

最简单设计: 帐户表+流水表. 每次帐户加减款都需要增加流水,和帐户变动.

业务需求: 高并发帐户.

技术选择 1. 悲观锁(高并发帐户), 乐观锁(普通并发帐户).  3. 顺序化 同步转异步,mq 降低峰值.

存储选择: redis 还是 数据库. redis本身并发能力就是比数据库要好. 但是单机支持的数据量不如数据库大. 只存放account的值的话到还好.

账户转账分两个接口，一个可扣成负数,一个不能扣成负数.

 1 如何消除[b]余额竞争呢？[/b]

   方案一：变成两个账户   模仿 担保交易，设置两个账户    1. 扣款账户  2. 加款账户

  1.1.  商家都是频繁加款 ,加款账户只记流水,不计算余额. 避免频繁竞争

  1.2.  加款帐户的流水定时汇总到扣款帐户上.

  1.3   扣款账户用于退款和提现, 因为频率不高.  即保证余额控制,也没有并发问题.  退款有些业务能扣成负数,有些业务不能.

  缺点: 进入的钱不一定能时时能用. (对小商家不适用,比较计较)

  优点: 这样就避免了热点账户的余额计算。

  方案二： 账户分普通账户，加频账户，减频账户，双频账户

类型为加钱频繁账户，加钱不改变余额，定时任务收集改变。 捡钱操作时时进行。

减频账户，拆分子账户。

扣款只账户会有个问题，前面扣掉了，但是最后不够扣。

最佳方案，回滚，即逆操作，加款。

次佳方案， 使用只能扣成一次负数

双频账户：加款依然如此，减款同上。

 延迟提现问题：即2天内收入只允许某种业务扣款（内部消费，代驾现金抵扣），但不允许提现扣款。

        采用普通账户，但是要满足提现延迟方案？

        小商家加的钱必须时时能用. 又要求延迟提现怎么办?

  只能通过订单维度,目前这个订单现在有多少钱冻结中(已退款的钱不应该冻结). 展现哪些订单是冻结的,冻结金额是多少.

              一旦钱被消费了, 账户余额可能少于订单的冻结的金额,可提现余额可能为负数. 

       客户可能来投诉, 因为他自己意识不到钱被消费了(抵扣信息费)和提现金额变少有关联.

阅读全文

版权声明：本文为博主原创文章，未经博主允许不得转载。