热点和秒杀来临前要做的5件事

记得当年《甄嬛传》热播，调用了我们团队的媒体资讯接口。接口被调用挂了。当时虽然我不负责那一块，只是目睹了当时大家在临场解决问题的紧张一幕。但是这件事在我心里埋下了种子，从此追求高可用、高稳定成为职业发展的方向。

今天咱们就来聊一聊热点和秒杀前要做的5件事。这5件事是按时间顺序排列出场。

应急演练

应急演练可以定期举行。前提是对各种意外情况，提前准备好了预案。预案在演练过程中，可以发现系统问题、检验相关人员SOP/EOP的操作熟练情况。

举个例子：支付系统由于下游银行通道能力参差，需要制定关闭XX银行通道的SOP，并进行演练。

应急演练一般要求级别较高的人员进行组织，确保其对突发情况有一定的应变权利，同时也能敏锐的发现新问题，确保效果。应急演练我个人总结要分为4个步骤，实际上也是标准的PDCA方法的步骤：

1、提前通知，确保参加人员掌握了需要的知识。同时同步到应急演练的目标、相关文档、时间、地点、参加人员

2、演练开始时第一步是告知大家演练的目标、流程和检查项目，比如过程中会检查大家对SOP/EOP的操作熟练情况，如果不熟练则会进行通报。

3、按流程步骤进行演练

4、进行演练总结，制定改进计划

在我实际进行过的演练中，上面提到的第二步做的不是很好。可能是作为一项例行事务，演练组织人员习惯于这项工作，认为没有必要重复说明。实际上我认为这是最重要的一步。因为第一，每次演练可能会有一些新人加入，他们不了解背景。第二，大家最后可能只记得演练的一个目标，把优化流程、找问题这些事情忽视了，演练效果大打折扣。

SOP/EOP

SOP（Standard Operating Procedure三个单词中首字母的大写 ）即标准作业程序，就是将某一事件的标准操作步骤和要求以统一的格式描述出来，用来指导和规范日常的工作。

EOP（Emergency Operating Procedure三个单词中首字母的大写 ）即应急操作流程，用于规范应急操作过程中的流程及操作步骤。确保人员可以迅速启动，确保有序、有效的组织实施各项应对措施。

全链路压测

全链路压测是一个很好的数据说话的方法，下面要介绍的扩容和降级都要依赖于压测的结果进行。同时，它也是提前发现系统问题的有效手段。

挡板压测/联合压测/封版压测

挡板压测

挡板压测就是链路上需要与外部交互的地方使用mock模拟来进行压测。比如微信支付，要模拟使用银行卡支付，不能每次压测都先冲几个亿来做测试吧。这时候可以模拟银行侧的返回值进行模拟。这个环节主要用于发现内部问题。

联合压测

联合压测就是真的和交互的外部机构沟通好一起压测。如果测试微信支付，还真需要提前冲几个亿来做测试。当然，测试完可以退款。这个环节有个重要职责是验证合作方能力，比如合作方有三个银行，一个银行并发量不够，那大促时就少路由一些请求给它。

封版压测

封版压测其实和前面两个压测不在同一维度。封版压测既可以是挡板压测，也可以是联合压测。目的在于测试系统稳定性。

重启服务

Java服务如果长时间不发布，没有任何bug的情况下也会内存缓慢增长。因为JVM申请了的内存，只要进程不死就不会释放。虽然咱们JVM参数里指定了堆的大小和每个线程占用的大小。但是程序运行过程中还会不可避免的申请很多堆外内存。比如数据库操作就会产生很多堆外内存。我负责的服务就发生过一个服务近1年没有任何发布升级，内存比刚重启后一周增长5%的情况。

除了内存，重启还能避免很多慢性问题在一个关键点爆发。所以也热点和秒杀保护的一个重要举措之一。

VIRT/RES/SHR

这里既然提到了JVM内存，那就顺便说一下怎么观察。常见的是使用top命令。

关键列的数据含义如下：

VIRT(虚拟内存)

1、进程“需要的”虚拟内存大小，包括进程使用的库、代码、数据，以及malloc、new分配的堆空间和分配的栈空间等；

2、假如进程新申请10MB的内存，但实际只使用了1MB，那么它会增长10MB，而不是实际的1MB使用量。

3、VIRT = SWAP + RES

RES(常驻内存)

1、进程当前使用的内存大小，包括使用中的malloc、new分配的堆空间和分配的栈空间，但不包括swap out量；

2、包含其他进程的共享；

3、如果申请10MB的内存，实际使用1MB，它只增长1MB，与VIRT相反；

4、关于库占用内存的情况，它只统计加载的库文件所占内存大小。

5、RES = CODE + DATA

SHR(共享内存)

1、除了自身进程的共享内存，也包括其他进程的共享内存；

2、虽然进程只使用了几个共享库的函数，但它包含了整个共享库的大小；

3、计算某个进程所占的物理内存大小公式：RES – SHR；

4、swap out后，它将会降下来。

它们之间的关系用一张图来表示就是

扩容

微博历史上曾发生过许多次服务器崩溃的情况。这种情况大多可以通过提前扩容解决的。但是一直停留在扩容状态经费上有问题：一台服务器每年成本按3万来算，100台就是300W。热点流量带来的收益并没有高。

近几年容器技术突飞猛进，对于热点和秒杀等场景，有的公司已经做到了弹性伸缩。就是根据流量情况动态调整服务的集群机器数。公司还可以和云厂商合作，让厂商提供动态扩容能力。

对于大公司而言，其实像阿里云、腾讯云这种云服务器的成本要比自己管理服务器成本要高。当然最贵的是亚马逊云，这是题外话。像微博这种临时扩容场景，服务器费用收取是按秒来计费的。

微博在【马蓉事件】中，有次马蓉说希望给自己来次专访，微博提前租了阿里云机器。结果没有提供任何实质性证据，也没有什么流量。气的微博团队@马蓉让她结服务器的账。

不管怎么说，很多热点事件来临前，提前扩容是可以解决问题的。所以，容器技术的一个重要指标就是创建容器的耗时，有的团队已经做到30s可以创建一个容器。意思是点击申请容器到容器上的业务镜像启动提供服务只需要30s！

降级

写文章要注意逻辑闭环。回到开头“当年《甄嬛传》热播，调用了我们团队的媒体资讯接口。接口被调用挂了”这个问题。

当时最大的问题是媒体资讯核心服务上有获取视频和专辑两个主要接口。视频咨询内容很小。就是下图所示内容简介这些视频的主要信息。

而专辑如下图所示的花絮呀、正片呀所有的这些主要内容简介打包在一起。我记得当年《甄嬛传》一个专辑包含了几千个视频信息？

当时服务器就是因为调用专辑给调挂了。当时正确的做法应该是降级专辑，只返回单个视频信息。当然了，在架构上，这个量级是要拆分服务的，这是题外话。

而在热点秒杀来临时，降级一些非核心服务，比如：定时服务、批量程序等。以节省带宽、线程等资源给核心服务。据我了解，一般大公司秒杀之前都要走一套标准的降级流程。