05 | 全链路压测：系统整体容量保障的“核武器”（上）

作者回复: 这个问题比较大，每个人的实践可能也不一样，我尽量简略解答，谈一下我的观点。首先，两者的数据隔离粒度不一样，如果是影子表，它与真实表一般位于同一个数据库实例上共享资源，影子库则彻底隔离；其次，实现方式不一样，或者说对业务服务的侵入性不同，业务服务在调用数据库时，一般是将库名随连接串写在配置文件或配置中心的，具体访问哪张表在程序内由ORM组件（如MyBatis）控制，如果采用影子表的方案，写一个interceptor就可以了，但如果采用影子库的方案就会比较麻烦，最好得有个数据库中间件，还会涉及到对另一个数据库的连接管理等等工作。 针对全链路压测一般使用影子表居多，原因主要有两点：1.真实的全链路压测往往不会也没必要覆盖所有链路，因此并不是所有数据表都需要建立对应的影子表，如果我们以「库」作为物理隔离维度就太粗了，也浪费资源；2.如上段所述，影子表对业务服务的侵入性更小，实现成本更低一些。

作者回复: 你好，不是很清楚“其他模块和线上共用”的含义，如果你指的是线上有背景流量（真实流量）对真实库存在一定的压力，而全链路压测对数据库的压力是作用在影子表的话，那是无妨的。 一方面，影子表和真实表一般位于同一个数据库实例上（即便分片也是如此），从库的视角来说，总的压力是基本一致的。 另一方面，全链路压测一般都选择在低峰期进行，背景流量几乎可以忽略不计。

作者回复: 你好，关于你提到的“放在一个线程组下面运行”，这是混合场景容量测试的一种具体可行的实施形式，但并不是唯一的形式（第7讲介绍的压测平台可以通过配置集的方式达到相同的效果），关键是要保证按照尽可能真实的流量比例以及场景去施压。 此外再多说一句，混合场景是单个业务场景的组合，但不一定是简单相加，需要整体检查一下各场景间有没有重复计算的流量，有没有流量峰值不一致的情况（单场景流量峰值的时刻不一定是混合场景流量峰值的时刻），各场景间的测试数据会不会有冲突等全局性的问题。

作者回复: 一般来说，影子表和真实表是位于同一个数据库上的（否则就是影子库了）。对于压测时的风险管控，可以回顾一下“容量测试与验证”一讲中“科学实施容量测试”的第4点测试执行的内容。在阿里本地生活的实践中，全链路压测期间有GOC团队和DBA团队共同监控数据库的各项指标，如出现负载过高、延迟过高等情况，会通知压测团队及时暂停止损。