会员购是B站2017年推出的IP消费体验服务平台，在售商品以手办、漫画、JK制服等贴合平台生态的商品为主。随着业务发展，会员购从最开始的预售、现货拓展到全款预售、盲盒、众筹等多种售卖方式，销售渠道也遍布猫耳（现已下线）、QQ小程序、漫画等多个业务渠道，再加上不断增加的营销活动玩法，每年几次大促活动的爆发式流量，对于会员购交易系统来说，无疑是一个巨大的挑战。

每年的拜年纪，626（公司周年庆），919（会员购周年庆），会员购都会搞大促活动，运营会挑选一些比较热门的手办进行首发，加上提前发放红包优惠券，各种优惠活动的刺激，每次大促0点开售流量就是几百倍的爆发，早期也因为压力太多出过几次事故，所以如何优化性能、提高交易的吞吐量是首要的。

面临问题：

在最初版的系统中，下单接口有明显的等待时间，用户体验不是很好，能支持的最大qps也有限

如图 2-1 所示 通看分析下单调用链路发现，存在多个接口重复调用，接口全是串行调用的情况，下单接口耗时太长，达到400+ms，已经严重影响系统性能及用户体验。

图 2-1 初版下单链路图

从链路上可以看出下单是IO密集型应用，CPU 利用率低，代码串行执行的话同步等待时间较长，为此我们重新梳理下单业务逻辑，对下单流程进行责任链模式改造，如2-2图所示。

2-2 下单链路简单示意图

同时我们对系统做了以下优化：

2-3 优化后的调用链路

经过优化后的接口耗时如2-4图所示，从原来300ms降低100ms左右，效果比较显著，用户的下单体验得到较大提升。

2-4 下单耗时对比图

面临问题：电商活动离不开秒杀场景，通常情况下小库存秒杀做好限流的话问题不大，但拜年祭手办通常有5000个左右的库存，如2-5如图所示，属于大库存秒杀 ， 限流值设得太小会严重影响用户体验 ，大库存抢购时下单qps遇到瓶颈 600+qps的时候库存服务行锁比较严重，耗时开始大幅上升，大量数据库操作占用连接数较高。

2-5 拜年纪商品

思考：服务器的处理能力是恒定的，就像早高峰一样，需要错峰限行，这就是我们说的削峰，对流量进行削峰不仅让服务器处理得更加平稳，也节省服务器资源。一般削峰的手段有验证码，排队等方式，这里我们主要是采用异步下单这种排队的做法。

说到排队，最容易想到的就是消息队列，可以通过消息队列把两个系统模块进行解耦，对于抢购场景来说也是非常合适的，可以有效把流量通过队列来承接，然后平滑地进行处理，如图2-6所示。

2-6 消息队列解耦

按照消息队列的排队方案，我们把整个下单流程调整为异步批量下单链路（图2-7所示） ，在合法校验过后生成订单号提交到databus消息队列 （图2-8所示），再监听databus批量拉取订单进行合并下单（图2-9所示），目前设置的是最多20个一消费，下单结果会在数据库及redis中保存。

2-7异步下单链路

2-8 提交下单请求至mq

2-9 从mq消费订单消息

如图2-10所示，在进入队列后，前端会提示活动火爆，正在努力下单中 ，同时在0~2秒内随机调用下单结果查询接口，轮询30秒（必须设置最大时间兜底，防止无限查询）。

对于合并的订单进行批量冻结库存，并行冻结优惠券，批量合并sql插入数据库，最大限度上减少性能消耗。

2-10 异步下单示例图

其他优化细节：

经过改造，压测下单支持4000+tps，最终也顺利利用异步下单支撑了早期的拜年祭手办抢购，如图2-11所示。

2-11   活动抢购qps图

首先并不是所有表都需要进行切分，主要还是看数据的增长速度。切分后会在某种程度上提升业务的复杂度，避免"过度设计"和"过早优化"。分库分表之前，不要为分而分，先尽力去做力所能及的事情，例如：升级硬件、升级网络、垂直拆分、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。 

数据量过大的风险如下：

1）高负载下主从延迟严重，影响用户体验，并且对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO。例如1T的数据，网络传输占50MB时候，需要20000秒才能传输完毕，整个过程的风险都是比较高的

2）对一个很大的表进行DDL修改时，MySQL会锁住全表，这个时间会很长，这段时间业务不能访问此表，影响很大。如果使用pt-online-schema-change，使用过程中会创建触发器和影子表，也需要很长的时间。在此操作过程中，都算为风险时间。将数据表拆分，总量减少，有助于降低这个风险。

3）大表会经常访问与更新，就更有可能出现锁等待，一旦出现慢查询，风险很大，容错性很低。将数据切分，用空间换时间，变相降低访问压力，而且利用水平切分，当一个数据库出现问题时，不会影响到100%的用户，每个库只承担业务的一部分数据，这样整体的可用性就能提高 

这里我们明确下分库、分表到底能解决什么问题：

在2020年的时候，会员购随着业务发展，订单数据快速增长，基本每半年数据量就会翻倍，所有核心表均达到千万级别大表的DDL，查询效率，健壮性都有问题 ，并且高负载下，会有较为明显的主从延迟，影响到用户体验。

首先是技术选型：

站在巨人的肩膀上能省力很多，目前分库分表已经有一些较为成熟的开源解决方案：

这么多的分库分表中间件全部可以归结为两大类型：CLIENT模式、PROXY模式。

无论是CLIENT模式，还是PROXY模式。几个核心的步骤是一样的：SQL解析，重写，路由，执行，结果归并。

经过讨论大家更倾向于CLIENT模式，架构简单，性能损耗较小，运维成本低，而且目前部分项目中都已经被引入shardingjdbc，并且部分模块已经在使用其分库分表功能，网上文档丰富，框架比较成熟 。

选择sharding key：

sharding column的选取是很重要的，sharding column选择的好坏将直接决定整个分库分表方案最终是否成功。

sharding column的选取跟业务强相关，选择sharding column的方法最主要分析你的API流量，优先考虑流量大的API，将流量比较大的API对应的SQL提取出来，将这些SQL共同的条件作为sharding column 例如一般的OLTP系统都是对用户提供服务，这些API对应的SQL都有条件用户ID，那么，用户ID就是非常好的sharding column。

非sharding column查询该怎么办？ 

切分策略：

1）范围切分

比如按照时间区间或ID区间来切分，如图3-1所示，优点：单表大小可控，天然水平扩展。缺点：无法解决集中写入瓶颈的问题。

3-1 范围切分

2）Hash切分

如图3-2所示，如果希望一劳永逸或者是易于水平扩展的，还是推荐采用mod 2^n这种一致性Hash 。

3-2 Hash切分

3）会员购交易切分策略

如图3-3所示，切分键选择：mid 和 order_id相关

根据 mid 分表，使用新的orderid 生成规则，orderid 融入（mid%512）

公式：

• 中间变量 = MID % (库数量*表数量)

• 库路由 = 中间变量 % 库数量

• 表路由 = 取整(中间变量 /库数量) 

3-3 库表策略示意图

我们采用的是不清洗老数据的方式，好处是老的订单数据依然走老库，这样能节省一部分清洗数据的工作量。

梳理sql：

项目中的sql有些是不满足分片条件的，所以我们是要提前梳理项目中的sql的。

针对没有分片键的SQL进行改造，不确定的SQL进行验证，不支持的SQL给出处理方式

当然如何进行迁移也是很重要的步骤，我们是采用下面的步骤，如图3-4所示

3-4 不停机迁移示意图

最后总结下整个分库分表的步骤：

在整个交易系统完成分库分表后，彻底解决了数据库的瓶颈问题，历经多次大促压测突发流量等场景都没有出问题，保障了整个平台系统的稳定性。

在经过调研链路优化、异步下单改造、数据库分库分表后，整个交易系统的性能得到了较大的提升，也较为顺利地支撑了历次大促活动，后续我们也会继续对一些历史系统（比如票务系统）进行改造升级来提升用户体验。