流量高峰前的预警与应急

前提

  1. 本案前提服务器为 Ubuntu Server 16.04 LTS,Web Server 为 Nginx,Application Server 为 PHP7.0-FPM。

概述

  1. 本案用于概述当前服务器架构方案以及业务预警、应急方案;
  2. 本案不考虑云 ECS、RDS、REDIS挂掉的问题;
  3. 本案仅适合无资源池的部署方案;

服务器通信

  1. 当前服务器集群包含:ECS、RDS、REDIS;
  2. 服务器间可能存在的通信:ECS 与 RDS、ECS 与 REDIS;
  3. 服务器内可能存在的通信(ECS):nginx 与 php-fpm、nginx-master 与 nginx-worker、php-master 与 php-pool;

ECS 可能出现的问题

  1. 连接数过多,主要特征:CPU 与 内存的消耗过高、文件句柄过多;
  2. 计算量过大,主要特征:CPU 占用率高,内存使用率其次;
  3. 服务崩溃(NGINX 或 PHP),主要特征:
    • 当 NGINX 崩溃时,具体体现为直接访问该 ECS 的 IP,返回 refused to connect 类错误;

    • 当 PHP 崩溃时,具体体现为直接访问该 ECS 的 IP,500 系列 Bad Gateway 类错误;

ECS 部分应急方案

  1. 连接数过多与计算量过大:扩充集群,扛过流量高峰;
  2. 服务崩溃:重启对应崩溃服务;
    • NGINX 重启:sudo nginx
    • PHP 重启:service php7.0-fpm start

REDIS 可能出现的问题及应急方案

  1. 使用量过大,主要特征:内存不足、CPU负载过高,应急方案:扩充集群;

RDS 可能出现的问题

  1. 主节点过载,主要原因:写入数据过多,主要特征:CPU 占用率居高不下;
  2. 从节点过载,主要原因:查询数据过多,主要特征:CPU 占用率居高不下;

RDS 部分应急方案

  1. 主节点过载:
    • 对业务层进行紧急降级,减少无谓的写请求;
    • 对主节点进行紧急升级,升级机器配置;
  2. 从节点过载:
    • 记录在案,blame 开发并要求充分利用 REDIS;
    • 紧急扩充从节点;

 

ECS 监控及预警

  1. 采用外部监控和内部监控:
    • 外部监控:360 网站监控服务、平台(阿里云)自带监控等;
    • 内部监控:使用 SHELL 脚本实时监控 ECS 使用情况;
  2. 监控的监控及预警策略:
    • 外部监控:每 30 秒一次,ECS 出现80、443 端口无法访问时累计错误次数,累计三次进行预警;
    • 内部监控:每 10 秒一次,ECS CPU、内存使用超过80%时,缩短监控频次为每 3 秒一次并累积错误次数,累计三次进行预警;
  3. 预警通知:采用短信平台进行实时通知,并同步邮件,同时考虑使用自有微信公众号进行预警;

流量高峰前的准备

  1. 预估流量:根据之前案例预估本次流量高峰;
  2. 压力测试脚本:统计页面请求数,模拟用户路径,编写压力测试脚本;
  3. 压力测试:使用自动化压力测试工具,测试当前集群负载;
  4. 调整集群规模:根据压力测试阈值调整集群规模为预估流量的 1.618 倍,重复压力测试步骤;

自动化应急

  1. 辅助业务:
    • ECS CPU、内存使用率达到预警标准,SHELL 脚本自动抢夺 NGINX 对 80、443 端口的监听,并全局返回成功;
    • ECS CPU、内存使用率达到解除预警标准,SHELL 脚本释放 80、443 端口的监听并重启 NGINX 与 PHP-FPM 服务。
  2. 主要业务:
    • ECS CPU、内存使用率达到预警标准,减少读取 IO(数据库等)的频次,主要从 REDIS 中返回经过计算的延时数据;
    • ECS CPU、内存使用率达到解除预警标准,恢复对 IO(数据库等)的实时读取和计算;

人工应急

  1. 用尽一切方式联系运维;
  2. 用尽一切方式联系运维;
  3. 用尽一切方式联系运维;

共有 1 条评论

  1. c

    大佬大佬

Top