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

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

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

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

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

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

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

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

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

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

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

（完）

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