生产环境全链路压测建设历程 12：通过生产压测发现的问题摘录

前面有提到，全链路压测的出现，是因为在活动开始的瞬间，从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力，这个时候系统服务除了受自生的影响，还依赖于其他关联系统的情况，并且影响会一直蔓延，只要有一个节点出现故障，那么故障在上下游系统经过层层累加后会造成的影响谁都说不清楚。



今天这一篇，要讲的就是在生产压测中，各个环节出现的问题摘录



1.应用部分



1.调用量：评价中心对用户中心的调用量每秒上升了1万多，远远超过预期。

2.购物车中心按5万的qps压，目前是压到了load 10，达到了预期容量，但由于无线是cm10的机器多，导致机房的压力不均。



整体交易核心几个应用本身几乎无压力， 购物车的压测符合预期，load压到了10。按创建支付中心单台VM最高达到800多算，大概是有1.3万的创建，但也暴露出几个问题，特别是下单路径依赖了非关键系统的问题。

2.中间件问题

部分应用目前运行的中间件版本参差不齐，有些低版本不支持双11中间件流控降级的功能。



3.数据库问题

1.交易超时业务 数据库的查询压力多于预期 

2.全链路压测的时候，DB压力过高，触发了MySQL的高可用自动切换阈值，引发了切换 

3.全链路压测的时候，DB单实例写入1万TPS，产生大量的redo log、binlog ，SAS盘写入响应变慢，TPS有波动 。最后的预案例，把数据库的redo log，binlog从直接刷盘到刷内存。

4.交易消息分发中心MySQL ， 从一台物理机4个Master，变成2M2S，提升了性能。

5.商品数据库，在全链路压测过程中，当MySQL 的活跃线程数(threads_running 瞬间达到120+,并持续超过20秒，MySQL会hang死超过10分钟。 



6.某个索引字段未配置，通过压测监控，研发人员发现请求订单列表请求RT过高，经过排查发现单号索引在生产环境未配置，导致查询rt比较高。



4.硬件问题

三星SSD在长达1小时的压测过程中，会出现坏块的问题。

5.缓存问题



1.通用cache型redis持久化策略与规划不符，cache型不应开启RDB。



2.测试环境有设置key过期，但生产环境的业务代码在判断是否设置key过期这块有bug，导致业务系统在请求key的时候，请求出一大堆未过期的数据，在高并发的情况下会请求大量数据，最终影响redis的带宽打满。