1.
准备与基线测量
步骤1:确认环境:uname -a;cat /etc/os-release;nginx -v 或 apache2 -v;mysql --version;php -v。
步骤2:收集基线指标:top、vmstat 1 5、iostat -x 1 5、free -m。
步骤3:应用层基线:ab/hey 或 wrk 做压测(示例:hey -n 1000 -c 50 http://域名/),并开启 MySQL 慢查询:在 my.cnf 中设置 slow_query_log=1、slow_query_log_file=/var/log/mysql/slow.log、long_query_time=1。记录基线以便对比。
2.
启用并调优 PHP 层缓存(OPcache)
步骤1:确认 php.ini 已启用 opcache(opcache.enable=1)。
步骤2:示例配置(php.ini):opcache.memory_consumption=256;opcache.interned_strings_buffer=16;opcache.max_accelerated_files=10000;opcache.validate_timestamps=0(生产环境需配合部署策略,若要自动刷新设置为1并降低频率)。
步骤3:重启 php-fpm 或 apache(systemctl restart php-fpm;systemctl restart nginx)。使用 phpinfo() 或 php -i | grep opcache 验证。
3.
页面/片段缓存与 CDN 策略
步骤1:对静态资源设置合理 Cache-Control(nginx 示例:location ~* \.(css|js|jpg|jpeg|png|gif|svg)$ { expires 30d; add_header Cache-Control "public, max-age=2592000"; })。
步骤2:对动态页面使用片段缓存或全页缓存(WordPress 用 WP Super Cache/Redis Object Cache;自研应用可以在输出层缓存完整页面并返回 X-Cache 标识)。
步骤3:部署 CDN(或云厂商自带加速)并配置回源与缓存失效(purge)API,确保更新时可即时清空缓存。
4.
使用 Redis / Memcached 做对象与会话缓存
步骤1:安装并启动 Redis:apt install redis-server;systemctl enable --now redis-server。
步骤2:示例 Redis.conf 关键配置:maxmemory 2gb(根据内存比例),maxmemory-policy allkeys-lru,save ""(若不需要 RDB 快照可禁用),appendonly yes(视持久化需求)。
步骤3:在应用中替换数据库频繁读取的热点数据为 Redis 缓存:设置合理 TTL(短变动数据如会话 30 分钟,热点查询 5-10 分钟)。对于 PHP 会话,使用 session.save_handler = redis 并设置 redis://127.0.0.1:6379。
5.
使用 Varnish 或 Nginx FastCGI Cache 做反向代理缓存
步骤1:若频繁返回相同 HTML,部署 Varnish(默认端口 6081)或启用 nginx fastcgi_cache。
步骤2:nginx fastcgi_cache 示例(nginx.conf):fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MYCACHE:100m inactive=60m max_size=1g; 在 server/location 中加入 fastcgi_cache MYCACHE; fastcgi_cache_valid 200 60m; fastcgi_cache_key "$scheme$request_method$host$request_uri";。
步骤3:注意缓存失效策略(按 URI、Cookie、Query 字段决定缓存与否),并实现缓存清理脚本(使用 purge 模块或自定义脚本调用 nginx -s reload 后清理缓存文件)。
6.
MySQL/MariaDB 主要参数调优(实操步骤)
步骤1:安装 mysqltuner.pl 并运行:wget mysqltuner.pl && perl mysqltuner.pl,获取建议。
步骤2:关键参数示例(在 my.cnf 中调整并重启 mysqld):innodb_buffer_pool_size = 60% ~ 70% 可用内存;innodb_log_file_size = 256M~1G(配合 checkpoint);innodb_flush_log_at_trx_commit = 1(安全)或 2(性能折中);tmp_table_size = 256M;max_connections 根据并发设置,例如 200。
步骤3:变更步骤:修改 my.cnf -> systemctl restart mysql -> 监控 slow log 与 SHOW GLOBAL STATUS;若修改 innodb_log_file_size 需要安全流程(停库、移动 ib_logfile*、重启)。
7.
索引与查询优化流程
步骤1:启用慢查询日志并用 pt-query-digest(或 mysqldumpslow)分析:pt-query-digest /var/log/mysql/slow.log > report.txt。
步骤2:对高耗时查询先 EXPLAIN 分析,查看 type、rows、Extra(注意 Using temporary/Using filesort),若 full table scan 则考虑加索引。
步骤3:添加索引示例:ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at); 并观察执行计划变更。避免在高写表上盲目加过多索引,测试影响。
8.
连接池与应用层并发控制
步骤1:启用数据库连接池(Java 用 HikariCP,PHP 用 pdo persistent 或连接池 ProxySQL/MaxScale)。
步骤2:设置连接池最大值小于或等于数据库能承受的 max_connections,防止连接风暴(例如 DB max_connections=500,应用池大小设置 100~200 并配合队列)。
步骤3:使用限流(nginx rate_limit、应用限流中间件)和队列(RabbitMQ/Redis Queue)平滑突发流量。
9.
监控与报警(必做)
步骤1:部署基础监控:Prometheus + Grafana 或云监控,监控指标:CPU、内存、IO、InnoDB Buffer Pool 命中率、Redis hit/miss、慢查询数。
步骤2:设置报警阈值:一分钟内 slow_queries > 10、innodb_buffer_pool_reads rate 上升、redis memory_used 接近 maxmemory 的 80%。
步骤3:定期生成报告并保留历史基线,以便对比调优前后效果(使用 grafana dashboard、mysqltuner 周报脚本)。
10.
回滚与测试策略(安全第一)
步骤1:在测试环境复现生产配置,先在 staging 做完整压测并对比响应与资源使用。
步骤2:任何数据库变更(如索引、参数)先备份:mysqldump 或 LVM 快照,若线上改动需在低峰时段并通知相关人员。
步骤3:变更后 24-72 小时内密切观察慢查询、错误率与页面时延,必要时快速回滚并分析原因。
11.
问:Redis 内存满了怎么处理?
答:先查看配置与占用:redis-cli INFO memory;若接近 maxmemory,临时可提高 maxmemory 并重启(注意服务器内存),长期方案:清理不必要键(使用键过期)、调整数据结构(使用更紧凑类型)、改 eviction 策略为 allkeys-lru,或横向扩容 Redis(Cluster 或分片)。
12.
问:如何快速定位 MySQL 慢查询的根因?
答:启慢查询并用 pt-query-digest 生成报告,找出耗时/频率最高的 SQL;对这些 SQL 执行 EXPLAIN,检查是否使用索引、是否发生 filesort/temporary,针对性添加复合索引或重写 SQL(避免 SELECT *、分页用 SEEK 方法),并测试效果。
13.
问:缓存失效策略如何设计以保证数据一致性?
答:常见做法是读写分离与写时双写或消息队列异步失效:修改数据库时同步删除/更新缓存,或将变更写入队列由消费者逐步清理缓存。使用短 TTL + 主动失效组合可降低不一致窗口,关键数据可以采用强一致性策略(事务内更新 DB 后同步清除缓存,再返回)。