大多数在线商店的年收入中，有很大一部分集中在少数几天。一个假日周末、一次产品发布或一场限时抢购，一小时内带来的流量就可能超过平常一周。
好消息是，峰值日是可以预测的。您知道日期，有去年的数据，而且推动高峰的促销活动由您掌控。
从负载预估出发，而不是凭猜测
从分析工具和服务器日志中提取去年的峰值，并查看最繁忙的那一分钟，而不是最繁忙的那一天。每日总量会掩盖真正压垮系统的尖峰，这种尖峰通常出现在邮件营销活动送达或倒计时结束的那一刻。
假设去年最繁忙的一小时有 60,000 次会话，而市场部门预计今年会翻倍。按 120,000 次会话、每次平均 10 次页面浏览计算，源站在这一小时内需要提供约 120 万次页面浏览，平均约每秒 330 次。一小时内的流量并不均匀，因此峰值分钟应乘以 2 至 3，按每秒约 1,000 次动态页面请求进行规划，另外还要加上来自购物车和搜索的 API 调用。
随后用 Little 定律将速率转换为并发：在途请求数等于到达速率乘以响应时间。在每秒 1,000 个请求、每个请求 300 ms 的情况下，任一时刻约有 300 个请求正在处理。如果每个应用 worker 一次只处理一个请求，整个集群至少需要 300 个 worker，并且还要更多，为慢请求和节点故障预留余量。
- 订单。按 3% 的转化率计算，12 万次会话在这一小时内约产生 3,600 个订单。平均每秒一单，但应按峰值分钟每秒 5 至 10 单进行规划。
- 带宽。一个 1 Gbps 端口每秒约传输 125 MB。如果未缓存的 HTML 页面平均为 100 KB，那么每秒 1,000 个页面在加上图片和脚本之前，就已占用该端口的大部分带宽。
- 余量。至少按估算值的 1.5 倍确定规格。预测通常会低估流量，而且机器人带来的负载从不会被分析工具统计在内。
尽可能将流量推向边缘
内容分发网络应当承担所有静态资源：图片、CSS、JavaScript 和字体。如果 CDN 从缓存中提供全部这些资源，源站负载就会下降一个数量级。
对于所有未登录且购物车为空的访客，分类页、商品页和首页往往完全相同。即使只在边缘缓存 30 到 60 秒，也能把每分钟数千个相同请求变成每个边缘节点每个页面一次源站请求。
- 缓存键。在缓存前去除 URL 中的跟踪参数，否则每一次营销活动点击都会变成缓存未命中。
- 缓存清除策略。提前决定价格和库存变更如何反映到缓存页面上：采用较短的 TTL、定向清除，或两者结合。
- 应用缓存。在源站内部，将会话、购物车数据和高开销查询的结果保存在 Redis 等内存存储中，避免数据库被成千上万次地问同一个问题。
- 搜索。通过专用的搜索索引提供搜索和筛选，而不是对商品表执行 SQL 查询。
按写入路径规划数据库容量
读流量可以缓存和复制，写操作则不行。每笔订单都会涉及订单表、订单明细、库存、支付记录、客户数据，通常还有审计日志，一笔订单很容易产生 20 到 50 次写入。
首先确保工作集能够放入内存。查看最近繁忙日的慢查询日志，现在就补上缺失的索引，因为一个在正常流量下耗时 200 ms 的查询，在峰值时可能会锁表数秒。
- 连接池。在数据库前部署连接池。数百个应用工作进程各自建立连接，会在 CPU 繁忙之前就耗尽数据库。
- 只读副本。将商品目录读取、报表和后台查询发往只读副本，让主库专注处理订单。
- 热点行。一件大幅折扣的商品就可能让一条库存记录成为锁竞争的焦点。可以在内存存储中用原子计数器预留库存，再与数据库进行对账，或者将库存拆分到多行。
- 后台任务。活动期间暂停或重新安排繁重的批处理任务、商品数据源导出和分析任务。
将结账与其他一切隔离
当商店在负载下性能下降时，目标是继续收款。浏览可以慢上几分钟，结账则不行。
在实践中，这意味着为购物车和结账路由配置独立的应用服务器池，或至少是独立的 worker，这样分类页请求的洪峰就不会挤占支付请求的资源。支付网关、税费计算、欺诈评分和运费服务都需要较短的超时、有上限的重试以及明确的降级方案，例如先接受订单，再异步执行欺诈检查。
- 功能开关。提前准备好可关闭推荐、评价、个性化组件和在线客服的开关。每个开关都能在不部署的情况下减轻负载。
- 第三方脚本。审查标签管理器。结账页面上的每一个分析和营销脚本，都是您无法控制的依赖项。
- 排队等候页面。按设定速率放行访客的虚拟队列，远胜于让所有人都无法访问的网站。请在需要之前完成配置和测试。
- 机器人流量控制。在购物车和登录端点按 IP 和会话进行限流，并保持 DDoS 缓解措施就位。抢购库存的机器人和撞库攻击往往会随促销活动一同到来。
按客户真实的购物方式进行负载测试
真实的购物者会浏览分类、搜索、打开商品页、加入购物车，其中只有一小部分会完成结账。请基于这些用户旅程构建测试，并使比例与您的分析数据相符，例如 70% 浏览、15% 搜索、10% 购物车操作和 5% 结账。
从您的网络外部发起测试，经过 CDN，针对规模和配置都与生产环境一致的环境进行。开始之前请通知您的 CDN、托管和 DDoS 缓解服务商，因为大规模测试看起来可能与攻击完全一样。
- 阶梯加压测试。逐级增加负载，直至达到估算值的 1.5 至 2 倍，并记录延迟开始上升的位置。这个点才是您真实的容量。
- 尖峰测试。在一分钟之内从正常流量跃升至峰值，模拟邮件营销活动带来的流量。需要五分钟才能增加容量的自动扩缩容在这里无济于事。
- 浸泡测试。将峰值负载保持两到四个小时，以暴露内存泄漏、连接泄漏以及会写满磁盘的日志量。
- 反复测试。每次测试都会发现第一个瓶颈。修复它，再次运行，如此循环，直到容量上限明显高于预测值。
编写运行手册并接入监控
事件发生时，人们做出的决定往往比在某个平静的下午坐在办公桌前时更糟。运行手册就是把决策提前到那个平静的下午。它应写明当天由谁负责指挥，谁与业务部门和客户沟通，谁可以批准变更，以及针对最可能出现的问题约定好的应对措施。
监控需要两个层面。技术层面覆盖每一层的延迟、错误率、饱和度和流量：CDN 命中率、应用响应时间、worker 利用率、数据库连接数、复制延迟和队列深度。业务层面往往更有用：每分钟订单数、结账成功率、支付授权率和购物车放弃率。
- 阈值。根据负载测试结果，写下每项指标在峰值时的正常水平，让团队能够区分系统是繁忙还是正在出故障。
- 预先约定的措施。例如：如果结账 p95 延迟连续 3 分钟超过 2 秒，则关闭推荐功能；如果超过 4 秒，则启用排队等候页面。
- 回滚。记录如何回退最近一次部署以及所需时间。至少测试一次。
- 联系人。列出托管服务商、CDN、支付网关及其他所有关键供应商的升级联系人，以及他们的支持渠道和服务时间。
活动前一周：检查清单
到了最后一周，工作重点应从构建转向确认。利用这段时间核实先前准备的一切都已就位，并消除意外因素。
- 变更冻结。冻结代码和基础设施变更，通过运行手册批准的修复除外。
- 证书与域名。检查 TLS 证书和域名的到期日期。调低 DNS TTL，以便在需要时快速切换流量。
- 容量。确认额外的服务器已经开通或预留，而不只是停留在计划中。活动当天从零开始扩容，会让您受制于服务商的容量限制和预热时间。
- 备份。通过实际恢复来验证最新的数据库备份，并确认时间点恢复可用。
- 促销活动。在预发布环境中，用真实的购物车组合测试每一个折扣码、组合规则和价格变更。
- 库存与商品目录。提前加载促销库存、图片和描述，并为热门商品预热缓存。
- 人员。公布值班表、沟通渠道和状态页流程。确保值班人员拥有所需的访问权限。
活动当天
在活动开始前数小时就完成扩容，而不是等到监控曲线开始攀升。通过请求热门分类页和商品页来预热缓存。
不改动运行手册以外的任何内容，并记录每项决定及其时间。如果出现故障，由事件负责人决策，团队执行既定的响应方案，业务联系人则持续向市场和客服团队通报情况，以便他们暂停推广活动或通知客户。一周之内趁数据还新鲜进行复盘，并记录真实数据。
Vonahost 能提供哪些帮助
Vonahost 托管云运行在自有平台、AWS 和 Google Cloud 上，包含 CDN、Redis、Elasticsearch、预发布环境、备份和监控，覆盖了上文所述的多个层级。对于数据库及其他受益于单租户硬件的组件，Vonahost 专用服务器提供 AMD EPYC 处理器、本地 NVMe 存储、不限流量的 1 Gbps 专用端口和 Arbor DDoS 防护，部署在您选择的区域。
如果您正在为峰值活动做准备，第一步最好是提供您的流量预估和现有架构。每份 Vonahost 方案都会注明配置、位置、职责划分以及以美元计的月度价格，并由您选择每台服务器运行的国家。