分库分表流量倾斜的排查方法论

一、背景

2022年11.10号晚8点，月黑风高

各大电商公司正在等待着即将到来的大促…

而作为二手电商交易订单组的我们也不例外，此时我们在紧盯监控大盘，试图找到系统蛛丝马迹的问题，以便及时应对，如果这时候出了问题，那就关乎着团队的面子，关乎着今年的绩效，当然还关乎着今年的年终奖……，秃然，奇怪的现象发生了

注：本文是中大型互联网公司遇到的真实案例，其知识点的深度和广度拿来面试都足够，建议认真阅读并且熟悉涉及到的相关知识点。若有任何问题可在评论区指出~

二、现象

随着业务的发展，订单单库承载的压力越来越大，因此后续对数据库做了水平拆分，利用shardingjdbc的能力做了分库分表。

根据数据量增长预期进行预估，订单库总共分了16个库，每个库16个表，所以总共是256张表。简要的结构如下：

理论上，每个分库的请求QPS相差不大才是符合预期的，毕竟当时做数据库拆分也就是为了均分流量，均分压力。但奇怪的现象是不同的分库访问QPS竟然有5倍之差！如下图所示：

3库的QPS达到了16K以上，而11库的QPS仅仅只有3K，发生了严重的流量倾斜现象，按这种趋势下去，分库分表的带来的收益会因为某些库的压力过大而大为降低

三、猜想

先来猜想下为什么会发生这种现象？

猜想一：下单大账户

由于订单分库分表策略是采用的买家ID进行路由的，也就是同一个买家的订单都会存储到一个分库里，同样的，同一个买家的请求也都会打到同一个分库上，所以有可能是某位超级大买家疯狂买买买？