晚上 8 点开放报名，7 点 40 我们三个人已经在客户会议室了。投影上开着两个窗口：一个是 Nginx 的 access log，一个是后端的 QPS 曲线。之前这类活动吃过单台顶不住的亏，这次提前扩了一台。
扩之前
原来一台 4 核 8G 的 ECS，跑 PHP-FPM，MySQL 在另一台。压测的时候 300 并发往上，响应时间开始飘。加了一台 2 核 4G 的备用机，同样的代码、同样的配置，前面挂 Nginx，upstream 两个 server 权重都是 1。
会话这一块提前动了：原来 PHP 的 session 存本地文件，两台机器一分流，用户这次落到 A、下次落到 B，登录状态就丢。提前改存 Redis，两台共用。这一步是 8 点之前唯一还改过的代码。
8 点 02 分
请求量上得比预想快。头两分钟每分钟 400 多次提交，QPS 曲线一根直线往上。看 log，两台都在接请求，数量差不多。
问题也在这时候出来：A 机的响应时间一直 100 毫秒上下，B 机偶尔到 500 毫秒，慢的时候还冒泡 502。查了下机器，B 是 2 核，A 是 4 核，核数差一倍，权重却给的一样。等于把一半的活派给了只有一半力气的人。
现场改配置，权重调成 3 比 2，reload。B 机的 502 少了，但还有零星几个。又给 upstream 补了两行：max_fails=3、fail_timeout=10s，让 Nginx 暂时把连续出错的节点摘掉，别一直往坑里送。
一个没料到的地方
真正让我们忙了十分钟的不是 Nginx，是短信。报名成功要发一条确认短信，第三方接口有限速，峰值时排队堆了几百条，用户那边收到得晚了两三分钟，有人在群里问「是不是没报上」。
后来把发短信从同步改成丢进队列，慢慢发，页面不等它。这个改动是活动结束后补的，当晚只是先把队列长度打在监控上，盯着它别涨穿。
收尾
9 点 20 之后量下来了。两台机器都没崩，Nginx 一共转发了 1 万多次请求，B 机被临时摘掉过 2 次，每次 10 秒后又自己回来了。
散会前把权重那行配置截了图发到群里，配了一句：下次扩机器先看核数。
