线上系统调优，本身就是一项技术活，不仅需要强大的技术实战能力，强大的问题定位、问题识别、排查能力，还需要丰富的调优能力。图片来自Pexels。本文从实战角度出发，从问题识别、问题定位、问题分析、方案提出、方案实施、方案监控调优、调优后观察等角度与大家交流分享。优化整个高并发闭环流程。项目简介本项目是一个基于SSM架构的类商场单体架构项目，里面有一个重磅模块。下面是目前线上环境的简要架构部署图。大致描述一下：该项目是一个SSM架构。服务器类型：1台负载均衡服务器（F5），3台应用服务器，1台定时器服务器，1台Redis服务器，1台图片服务器，1台基于Pass架构的MySQL主从服务器（微软云）。调用逻辑：上图是一个简单的调用逻辑。什么是单体架构项目从架构发展的角度来看，软件项目经历了以下几个发展阶段：单体架构：可以理解为前后端不分离的传统架构。垂直架构：可以理解为前后端分离架构。SOA架构：可以理解为基于服务类别、业务流程、服务间依赖关系的面向服务的架构。比如之前的单体架构ERP项目，分为订单服务、采购服务、物料服务、销售服务。微服务：可以理解为小项目，比如之前的ERP大型项目，分为订单服务（orderitems）、采购服务（purchaseitems）、物料服务（materialitems）和销售服务（salesitems），以及服务之间的调用。本SSM项目导致的线上问题①闪购时，CPU暴涨。系统每天有三个闪购：10:00、13:00和20:00。以下是闪购的简要页面：②单服务器CPU③单应用服务器请求数④rdis连接数(infoclients)这个未保存的截图，记住是600左右：connected_clients:600⑤MySQL请求截图排查流程以及分析排查思路根据服务部署和项目架构，从以下几个方面进行排查：使用服务器：检查内存、CPU、请求数等文件图片服务器：检查内存、CPU、请求数等Timer服务器：查看内存、CPU、请求数等Redis服务器：查看内存、CPU、连接数等DB服务器：查看内存、CPU、连接数等秒杀后30分钟内排查过程：①应用服务器CPU、内存暴增。CPU和内存暴涨的根本原因是请求量太大，单台应用服务器达到3000多条。②Redis请求超时，如下图：③JDBC连接超时，如下图：④通过GC查看，发现24小时内发生了152次FullGC，如下图：⑤查看再次堆栈，发现部分线程被阻塞死锁。jstat-lpid也可以用VisualVM分析：⑥发现有2000多个线程请求无效资源，如下图：分析导致本次系统异常的主要因素如下：高，导致应用服务器负载太高了。Redis连接池已满，无法获取连接，无法从线程池获取连接。JDBC连接池已满，无法获取连接，超时。存在大对象代码，比如不断往List集合中添加对象，没有及时回收对象，导致内存增加，FullGC频繁发生。Tomcat并发参数、JVM优化参数、Jedis配置参数、JDBC配置参数不合理。不对请求量进行削峰限流。资源连接没有及时释放，比如Redis连接、JDBC连接没有及时释放。最终解决方案①增加应用服务，做流量调峰和分流由于本项目不增加MQ，只能使用硬负载和增加服务器水平扩展来实现流量调峰和分流：②优化JVM参数，如下子-优化参数：JAVA_OPTS="-server-Xmx9g-Xms9g-Xmn3g-Xss500k-XX:+DisableExplicitGC-XX:MetaspaceSize=2048m-XX:MaxMetaspaceSize=2048m-XX:+UseConcMarkSweepGC-XX:+CMSParallelRemarkEnabled-XXIn:LargePageSize=128m-XX:+UseFastAccessorMethods-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=70-Dfile.encoding=UTF8-Duser.timezone=GMT+08》关于这个JVM参数的优化，JVM理论是什么，官方建议是什么是的，实战到底是怎样的，下一篇会分析。③优化Tomcat并发相关参数主要有两个方面：修改bio协议为nio2。根据服务器配置、业务场景、业务流量等合理设置相关参数，尽量做到最优。关于Tomcat相关参数的优化，会在下一篇文章中分析。④Redis和JDBC参数优化，由于安全问题，这里不再一一列举。⑤代码优化代码优化如下：优化大对象。优化未及时释放的对象和连接资源。⑥解决000多个线程请求无效资源问题：在conf/context.xml中增加缓存
