秒杀系统架构关键技术-设计兜底方案

高可用建设应该从哪里着手

1. 架构阶段 ：架构阶段主要考虑系统的可扩展性和容错性，要避免系统出 现单点问题。例如多机房单元化部署，即使某个城市的某个机房出现整体故障，仍然不会影响整体网站的运转

2. 编码阶段 ：编码最重要的是保证代码的健壮性，例如涉及远程调用问题时，要设置合理的超时退出机制，防止被其他系统拖垮，也要对调用的返回结果集有预期，防止返回的结果超出程序处理范围，最常见的做法就是对错误异常进行捕获，对无法预料的错误要有默认处理结果。

3. 测试阶段 ：测试主要是保证测试用例的覆盖度，保证最坏情况发生时，我们也有相应的处理流程。

4. 发布阶段 ：发布时也有一些地方需要注意，因为发布时最容易出现错误，因此要有紧急的回滚机制。

5. 运行阶段 ：运行时是系统的常态，系统大部分时间都会处于运行态，运行态最重要的是对系统的监控要准确及时，发现问题能够准确报警并且报警数据要准确详细，以便于排查问题。

6. 故障发生 ：故障发生时首先最重要的就是及时止损，例如由于程序问题导致商品价格错误，那就要及时下架商品或者关闭购买链接，防止造成重大资产损失。然后就是要能够及时恢复服务，并定位原因解决问题。

 

针对运行阶段如何在大流量下保证系统稳定运行

降级

所谓“降级”，就是当系统的容量达到一定程度时，限制或者关闭系统的某些非核心功能，从而把有限的资源保留给更核心的业务。它是一个有目的、有计划的执行过程，所以对降级我们一般需要有一套预案来配合执行。如果我们把它系统化，就可以通过预案系统和开关系统来实现降级。

降级的核心目标是牺牲次要的功能和用户体验来保证核心业务流程的稳定，是一个不得已而为之的举措。

限流

如果说降级是牺牲了一部分次要的功能和用户的体验效果，那么限流就是更极端的一种保护措施了。限流就是当系统容量达到瓶颈时，我们需要通过限制一部分流量来保护系统，并做到既可以人工执行开关，也支持自动化保护的措施。

客户端限流 ，好处可以限制请求的发出，通过减少发出无用请求从而 减少对系统的消耗。缺点就是当客户端比较分散时，没法设置合理的限流 阈值：如果阈值设的太小，会导致服务端没有达到瓶颈时客户端已经被限制；而如果设的太大，则起不到限制的作用。

服务端限流 ，好处是可以根据服务端的性能设置合理的阈值，而缺点就是被限制的请求都是无效的请求，处理这些无效的请求本身也会消耗服务器资源。

在限流的实现手段上来讲，基于 QPS 和线程数的限流应用最多，最大QPS很容易通过压测提前获取，例如我们的系统最高支持 1w QPS 时，可以设置8000 来进行限流保护。线程数限流在客户端比较有效，例如在远程调用时我们设置连接池的线程数，超出这个并发线程请求，就将线程进行排队或者直接超时丢弃。 限流无疑会影响用户的正常请求，所以必然会导致一部分用户请求失败，因此在 系统处理这种异常时一定要设置超时时间，防止因被限流的请求不能 fast fail（快速失败）而拖垮系统。

拒绝服务

如果限流还不能解决问题，最后一招就是直接拒绝服务了。 当系统负载达到一定阈值时，例如 CPU 使用率达到 90% 或者系统 load 值 达到 2*CPU 核数时，系统直接拒绝所有请求，这种方式是最暴力但也最有效的 系统保护方式。例如秒杀系统，我们在如下几个环节设计过载保护：

   在最前端的 Nginx 上设置过载保护，当机器负载达到某个值时直接拒绝；

   HTTP 请求并返回 503 错误码，在 Java 层同样也可以设计过载保护。