本期作者
1.布景
会员购是B站2017年推出的IP消费体会服务途径，在售产品以手办、漫画、JK制服等贴合途径生态的产品为主。跟着事务发展，会员购从最开端的预售，现货拓展到全款预售，盲盒，众筹等多种售卖办法，销售途径也遍布 猫耳（现已下线），QQ小程序，漫画等多个事务途径，再加上不断添加的营销活动玩法，每年几回大促活动的迸发式流量，关于会员购买卖体系来说，无疑是一个巨大的应战。
2.功用
每年的拜年岁，626（公司周年庆），919（会员购周年庆），会员购都会搞大促活动，运营会挑选一些比较抢手的手办进行首发，加上提前发放红包优惠券，各种优惠活动的影响，每次大促0点开售流量便是几百倍的迸发，前期也因为压力太多出过几回事故，所以怎么优化功用，进步买卖的吞吐量是首要的。
2.1调用链路优化
面临问题：
在最初版的体系中，下单接口有显着的等候时刻，用户体会不是很好，能支撑的最大qps也有限
如图 2-1 所示 通看剖析下单调用链路发现，存在多个接口重复调用，接口满是串行调用的情况，下单接口耗时太长，抵达400+ms，现已严峻影响体系功用及用户体会
图 2-1 初版下单链路图
从链路上可有看出下单是IO密集型应用，CPU 利用率低，代码串行履行的话同步等候时刻较长，停止咱们从头整理下单事务逻辑，对下单流程进行职责链形式改造，如2-2图所示
2-2 下单链路简略示意图
同时咱们对体系做了以下优化
-
对没有依靠的服务进行并发调用（产品/店铺/活动/用户信息等一起并发调用），如图2-3所示
-
优化调用链削减冗余调用，推进下游服务接口改造及兼并，确保一次恳求下来，每个基础接口只会被调用一次，如图2-3所示
-
设置合理的超时时刻和及衔接重试（200ms, 部分接口99分位上浮100%,connect衔接重试）
-
扫除事务内的外部调用（服务依靠，mq，缓存）
-
对弱依靠接口进行mq或异步调用（设置关注/缓存手机号/回滚库存优惠券等）
2-3 优化后的调用链路
经过优化后的接口耗时如2-4图所示，从原来300ms下降100ms左右，效果比较显著，用户的下单体会得到较大提高
2-4 下单耗时比照图
2.2异步下单优化
面临问题：电商活动离不开秒杀场景，通常情况下小库存秒杀做好限流的话问题不大，但拜年祭手办通常有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 异步下单示例图
其他优化细节
- 下单限频/限流
- 其中关于一些弱依靠的操作直接进行降级，比方设置商铺关注，缓存手机号，记录操作日志等
- 批量操作反常时（接口超时则fail fast），会分解为单个订单从头进行调用(库存操作会试探单库存扣减 单库存扣减成功 并发恳求剩下订单，单库存扣减失败 剩下订单悉数置为失败)
- 下单成果查询走redis，反常情况降级为数据库
- databus反常时，直接降级为同步下单（库存服务也会做限流）
- databus消费者会做幂等及超时判断（订单投递时刻跟当时时刻差值），超越必定时刻会自动抛弃，下单失败
经过改造，压测下单支撑4000+tps，终究也顺畅利用异步下单支撑了前期的拜年祭手办抢购，如图2-11所示
2-11 活动抢购qps图
2.3分库分表
首要并不是一切表都需求进行切分，首要仍是看数据的增长速度。切分后会在某种程度上提高事务的复杂度，防止”过度规划”和”过早优化”。分库分表之前，不要为分而分，先尽力去做量力而行的事情，例如：晋级硬件、晋级网络、笔直拆分、读写分离、索引优化等等。当数据量抵达单表的瓶颈时分，再考虑分库分表。
数据量过大的危险如下：
1）高负载下主从推迟严峻，影响用户体会，并且对数据库备份，假如单表太大，备份时需求很多的磁盘IO和网络IO。例如1T的数据，网络传输占50MB时分，需求20000秒才干传输完毕，整个过程的危险都是比较高的
2）对一个很大的表进行DDL修改时，MySQL会锁住全表，这个时刻会很长，这段时刻事务不能拜访此表，影响很大。假如运用pt-online-schema-change，运用过程中会创立触发器和影子表，也需求很长的时刻。在此操作过程中，都算为危险时刻。将数据表拆分，总量削减，有助于下降这个危险。
3）大表会常常拜访与更新，就更有可能呈现锁等候，一旦呈现慢查询，危险很大，容错性很低。将数据切分，用空间换时刻，变相下降拜访压力，并且利用水平切分，当一个数据库呈现问题时，不会影响到100%的用户，每个库只承当事务的一部分数据，这样全体的可用性就能进步
这儿咱们清晰下分库 分表究竟能处理什么问题
-
分表：处理单表过大导致的查询效率下降(海量存储,即使索引正确也会很慢) MySQL 为了进步功用，会将表的索引装载到内存中。InnoDB buffer size 足够的情况下，其能完满足加载进内存，查询不会有问题。但是，当单表数据库抵达某个量级的上限时，导致内存无法存储其索引，使得之后的 SQL 查询会产生磁盘 IO，然后导致功用下降。当然，这个还有具体的表结构的规划有关，终究导致的问题都是内存约束。这儿，添加硬件装备，可能会带来立竿见影的功用提高。
-
分库：处理Master服务器无法承受读写操作压力(高并发拜访,吞吐量)
在2020年的时分，会员购跟着事务发展，订单数据快速增长，基本每半年数据量就会翻倍，一切中心表均抵达千万级别 大表的DDL，查询效率，健壮性都有问题 ，并且高负载下，会有较为显着的主从推迟，影响到用户体会。
首要是技能选型：
站在巨人的膀子上能省力很多，现在分库分表现已有一些较为老练的开源处理计划：
- 阿里的TDDL，DRDS和cobar
- 开源社区的sharding-jdbc（3.x开端现已更名为sharding-sphere）
- 民间组织的MyCAT
- 360的Atlas
- 美团的zebra
这么多的分库分表中心件悉数能够归结为两大类型：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查询该怎么办？
-
建立非sharding column属性到sharding column的映射联系
-
双写冗余全量数据(不需求二次查询)
-
数据异构（TIDB，ES，HIVE等，应对复杂条件查询，近实时或离线查询）
-
基因交融（比方订单号里交融mid基因，最新的订单号规矩：orderId+mid%512 比方4004164057659338）
切分战略：
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）
库表数量：4个集群(主从)，每个集群4个库，每个库16张表，总计256张表
库路由战略：mid %16
表路由战略：(mid%512)/32
公式：
中心变量 = MID % (库数量*表数量)
库路由 = 中心变量 % 库数量
表路由 = 取整(中心变量 /库数量)
3-3 库表战略示意图
咱们选用的是不清洗老数据的办法，好处是老的订单数据依然走老库，这样能节约一部分清洗数据的工作量
整理sql：
项目中的sql有些是不满足分片条件的，所以咱们是要提前整理项目中的sql的
1.经过 druid 界面 能够统计到一切运行的 sql
2.配合静态扫描sql东西
3.DBA 拉取 SQL
4.人工检查代码 当整理出对应一切 SQL
针对没有分片键的SQL进行改造，不确定的SQL进行验证，不支撑的SQL给出处理办法
当然怎么进行搬迁也是很重要的过程，咱们是选用下面的过程，如图3-4所示
-
历史数据归档，不做搬迁，老数据修改仍旧路由到老库
-
切读写恳求，行将读写流量恳求引入到新体系中
-
回写数据，binlog 监听新数据库回写到老体系中，并进行校验
3-4 不停机搬迁示意图
最终总结下整个分库分表的过程
1.依据容量（当时容量和增长量）评估分库分表个数
2.选key（均匀）
3.分表规矩（hash或range等）
4.整理sql并验证
5.履行（一般双写）
在整个买卖体系完成分库分表后，彻底处理了数据库的瓶颈问题，历经多次大促压测突发流量等场景都没有出问题，保证了整个途径体系的稳定性。
3.总结
在经过调研链路优化，异步下单改造，数据库分库分表后，整个买卖体系的功用得到了较大的提高，也较为顺畅得支撑了历次大促活动，后续咱们也会继续对一些历史体系（比方票务体系）进行改造晋级来提高用户体会。
