赶过去看了一眼他们的云ECS配置，果然是新手容易踩的雷——用的是T6突发性能实例，之前业务量小的时候靠CPU积分攒的够，秒杀流量一冲积分直接归零，性能瞬间被锁死。本来想先限流救急，但客户说预热第一天好不容易攒的种子用户，不能放掉，赶紧扩容是最稳妥的。
说实话中小团队遇到临时负载飙高，别纠结什么架构重构、代码优化，先快速扩容稳住服务是第一要务，那些优化都是事后复盘的事。先分享一套当天我用的阿里云ECS的通用扩容流程，其他云厂商（腾讯云CVM、华为云ECS）大同小异，操作面板的按钮位置不同，但逻辑差不多。
先看看云盘有没有空间限制扩容？不对那次他们的盘没问题，是CPU和内存不够。先临时升级现有实例规格，因为不需要重新部署服务环境，是最快的。操作很简单：先在云控制台把实例状态改成“停止”——别直接重启实例面板，一定要选“停止”！然后找到“实例规格变更”，选一个适配秒杀场景的通用型实例g6e，这次直接从2核4G升到了8核16G，配置完成后点“启动”。
这里一定要敲黑板第一个新手避坑提醒：停止突发性能实例升级规格的时候，别选“强制停止”！除非服务器完全卡死进不去SSH或者控制台操作界面，强制停止会导致内存里的临时数据丢失，比如用户正在支付的订单如果还没同步到数据库，就可能变成“空支付”“待发货但无库存”的问题，那次我反复确认了SSH还能勉强连上去发个ping包，才选了“正常停止”。
启动之后大概2分钟不到，服务就恢复正常了？不对兼管后端说后台有部分Redis缓存失效了？哦对了忘记第二个避坑点了！升级现有规格后，ECS的公网IP地址（如果是临时IP的话） 可能会变，还有Redis这种非持久化或半持久化的缓存服务，如果是直接部署在实例本地的，正常停止再启动后可能会丢失最近没有刷盘的数据——那次他们的Redis没有开AOF持久化的appendfsync always，只开了everysec，丢了大概5分钟的秒杀商品浏览量和未支付订单缓存，还好没有同步到数据库的硬数据，后来重新预热了一下商品缓存就没事了。
那如果是不想升级现有规格，或者现有实例绑定了不能解绑的本地SSD或者公网EIP绑定了重要域名备案，怎么办？可以临时添加一台同配置的同地域ECS，挂载到现有负载均衡SLB后面。这个流程稍微复杂一点，但不会影响现有实例的服务。
先准备好部署环境的镜像快照——哦如果之前没有拍过，临时拍一张现有实例的系统盘快照大概需要5-10分钟，中小团队平时一定要养成每天凌晨自动拍一张系统盘和数据盘快照的习惯！不然遇到这种临时扩容的情况，临时拍快照耽误事。那次老客户运气好，他们之前听我的 开了阿里云的自动快照策略，保留最近7天的，直接用了前一天凌晨2点的系统盘快照，挂载了一块和现有实例一样的云数据盘，然后创建了一台同地域同可用区的g6e 8核16G实例，创建完成后自动安装好SLB的后端健康检查脚本，然后登录负载均衡控制台，把新实例的内网IP添加到SLB的后端服务器组里，权重设成和现有实例一样的100，健康检查通过后大概1分钟，流量就自动分到新实例上了。
大概10分钟左右，SLB监控面板里的平均负载就降到了3-4，秒杀活动顺利完成，当天晚上新客首单量达到了预期的120%。事后复盘的时候，除了提醒他们把T6突发性能实例换成g6e通用型基线实例（平时业务量小的时候成本也不高），还把Redis的AOF持久化改成了appendfsync always + auto-aof-rewrite-min-size 64mb，避免下次再丢重要缓存数据。
最后 一下，中小团队遇到临时负载飙高，快速扩容的核心思路是“先稳后优”：优先升级现有同实例规格（速度最快，适合绑定本地资源的情况），或者临时添加同镜像同配置的ECS到SLB后面（不影响现有服务，适合流量峰值预计较长的情况）。平时一定要养成拍自动快照、监控CPU积分（如果用突发性能实例）、给缓存服务开合理持久化的习惯。
你们在运维工作中有没有遇到过类似的临时负载飙高扩容踩坑？欢迎在评论区分享你的排查和解决经验。
评论列表 (0条)：
加载更多评论 Loading...