如何做大促稳定性保障

如何做好大促的一个稳定性的一个保障？接下来，我会从 容量 预案 预热 限流 四个模块来系统性说明

1 容量

容量这一块，首先我们要评估到我们的业务的变化，业务容量会有多少的增长，业务增长率是多少，根据业务的增长来倒逼评估我们大促期间系统的水位是多少，如系统接口的QPS与吞吐率，缓存等中间件容量，DB的算力和存储还有多少增长空间。

2 预案

预案 分为 前置预案和紧急预案，前置预案是提前执行一些预案来关闭非核心链路，集中资源保障核心业务。 

     紧急预案是线上发生问题，我们要进行快速的业务止血和问题恢复

3 预热

预热 分为 数据预热  链接预热  应用预热

数据预热：DB 预热（热点数据加载到buffrepool，尽量避免物理读）

                  缓存预热 数据提前刷到缓存

 链接预热：更多是长链接的预热

 应用预热：就是应用的核心链路先跑起来 通常是线上压测把代码提前预热起来。

4 限流

    为什么要限流 限流又是什么？假设上游突然一个流量脉冲过来我们如何能扛过去（约定是5K 突然来了10K）？为了应对不确定性的突发条件 我们需要进行流量的限流来保障业务稳定的输出。

然后就是怎么把这四个模块联动起来。第一个步是梳理链路的梳理，那么链路的梳理，首先要从业务上开始，我们要梳理我们的业务是什么，我们的业务的业务环境又是什么样的，我们业务上下文是什么样的，我们的业务的整个公司的业务生态里面属于什么样的位置，然后再去梳理。我们的产品功能，因为梳理业务的时候还是很抽象，到产品功能的时候，你可以实际的去了解我们的产业务是什么，有哪些业务功能，通过APP来操作，点击一下大概能知道，对业务有更加稍微更加框架性的一个了解，具象的了解

然后再到技术层面的梳理，要梳理我们域内的系统有多少个系统，多少个服务应用，然后这些服务跟服务之间又是如何串联的，事件又是如何如何驱动的？上下文的依赖关系又是什么？然后域内分析完之后，再是我的上游服务又是谁，我为谁的应用服务，我跟他之间的接口约定又是什么？Sla约定又是多少？QPS又是多少？我的下游谁又是为我提供技术服务的？我对他又又要提提出哪些要求？他又要达到多少的QPS的性能才能支撑我的技术服务？

这些处理完之后就是预估，预估更多层面是一个基于业务来预估我们的系统的一个接口的阀值分值，业务容量来预估我们的接口的分值，中间件的存储，DB的算力与存储的能力，够不够，更多是这样的。然后压测压测的话是基于我们核心电路的，更多是核心电路的一个压测，当然如果时间够的话，是全电路压测是最好的。那我之前更多是300KPS以下，也就不做重点关照，更多是保障我们的接口，核心电压测过程中可能会出现各种各样的问题，那我要把这个问题记录下来去分析。至于为什么出现了这样的问题，在整个电路中。是不是合理的，那我们整个链路该怎么去优化，或者说单一的模块的功能我们怎么去优化，这是压测中的概括处理，能优化的做系统的优化，不能优化的做预案处理，紧急预案和前置预案。

最后就是组织协调与演练，你需要制定一些值班计划和值班人，以及，我们域内的对外接口人。大促期间要怎么去操作，该记录哪些问题，关注系统的哪些核心指标系统的峰值数据库的。峰值数据库的压力系统的接口表现，还有工单要哪些工单出来，哪些工单能反映什么问题，问一下工单要多少时间之内给它处理掉工单的处理时效问题，然后还要组织演练，假设演练我们出现了问题，客户，客户有大量的工单上来。我们的应对机制是什么？如何回报 评估 执行 反馈 恢复。