银行采用分库应对高并发的实际案例

上次介绍了腾讯在抢红包场景下应对高并发的方案,主要用的是分库方案。这次来看一下我们银行在实际生产上,如何采用分库方案应对高并发场景。

首先我们银行的业务模式是和T公司合作开办业务,而T公司属于较为大型的互联网公司。业务模式很简单,就是将银行的某类业务,包装一下在T公司的渠道上销售。销售后的交易会准实时送到银行侧系统进行记账处理。

由于T公司客户数量较大,并且逢年过节会搞一些活动,交易量会大增,交易送到银行后,如果造成积压排队,就会影响银行系统的性能。银行侧如何进行应对呢?

随着T公司交易量的增大,银行系统的压力越来越明显

首先,银行系统使用了分集群分库的方式处理交易。分库方式为,根据客户的ID通过hash散列方式,把处理请求分配到不同的集群中去。所以当从T公司拿到交易后,将是多个集群一起处理交易。

其次,由于银行对系统的灾备能力要求很高,因此,每个集群的数据库都要有响应的异地灾备及同城灾备环境。

分库方案最终的效果如何呢?

1、为了应对今年春节到来的业务高峰,共进行了2次扩容,增加到了8个集群。通过调优,单集群的处理能力由300TPS提升到400TPS。8集群TPS在3200左右。

2、数据库拆分后,增加了很多备机的物理设备,因此实际数据库硬件成本投入为集群数量的3倍。

3、由于数据库的拆分有业务逻辑,因此拆分方案较为复杂。应用服务器已入云,因此拆分较为简单。同时,度过春节高峰后,为了节省资源又进行了缩容,为了降低缩容的难度,并未采用调整业务逻辑方式进行缩容。而是调整了灾备策略,将两个集群的主数据库互相作为同城备份数据库。

(完)

保护原创,未经许可禁止通过自媒体刊载,已委托“维权骑士”(http://rightknights.com)为文章进行维权行动~分享到您的朋友圈才是义举哦~

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180924G179DY00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券