不同架构下，压测需要注意的地方：
- 使用临时缓存的服务，压测时最好能使用线上真实流量，避免一直用相同参数压测后流量全走缓存，而实际运行过程中缓存命中率低导致压测失去作用。
- 使用并行请求多个子服务+最后合并结果的服务，压测时最好先对依赖服务进行压测，获得依赖服务的 QPS，进而再估算当前服务的 QPS。
- 例如 Redis 集群的分片式架构，避免 key 太少或者 hash 算法不合理，导致缓存数据集中个别分片上，其他分片没有数据存储而资源造成浪费。
在压测前的数据准备环节，我们通常要考虑的因素包括这些方面：
- 压测环境前后要一致：尽量用同一套服务器及配置环境验证优化效果。
- 避免缓存干扰：建议在每次压测时，缓一段时间让服务和缓存过期后再进行压测，这样才能验证测试的准确性。
- 数据状态一致：要尽量保证服务用的数据量、压测用户量以及缓存的状态是一致的。
Linux 常用的内核优化配置选项：本地可用端口个数限制、文件句柄限制、长链接超时时间、网卡软中断负载均衡、各种 IO 缓存大小等。
虽然线上压测更真实，但这样会在短时间内会产生大量垃圾数据，比如大量的日志、伪造的业务数据，可能有大量堆积的队列，占用服务器的资源，甚至直接引起各种线上故障，人工清理起来非常困难。因此，为了确保测试不会影响线上正常服务，我更推荐用影子库的方式做压测。该方式会在压测的请求里带上一个特殊的 header，这样所有的数据读写请求都会转为请求压测数据库，而不是线上库。
全链路压测来发现整个系统服务的性能上限。若压测一段时间都稳定后，可以考虑加大压测线程数，尝试压垮系统，以此观察系统可能出现的缺陷以及预警系统是否及时预警。不过这样做，需要做好修复数据库的准备。
回放线上真实用户请求进行压测，可以减轻人工写压测脚本的困难度，也可以用于特殊故障的请求场景还原。具体可以使用tcpcopy这个工具录制线上的流量请求，生成请求记录文件后，模拟搭建录制时线上数据时的全量数据镜像，然后回放即可。