高并发系统保护

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。

当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。

系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。本文将介绍一些在实际工作中遇到的或见到过的一些降级方案。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。

雪崩效应常见场景

• 硬件故障：如服务器宕机，机房断电，光纤被挖断等。
• 流量激增：如异常流量，重试加大流量等。
• 缓存穿透：一般发生在应用重启，所有缓存失效时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。
• 程序BUG：如程序逻辑导致内存泄漏，JVM长时间FullGC等。
• 同步等待:服务间采用同步调用模式，同步等待造成的资源耗尽。

降级预案

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅;从而梳理出哪些必须誓死保护，哪些可降级;比如可以参考日志级别设置预案:
一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级;
警告：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警;
错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级;
严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

降级的类别

• 降级按照是否自动化可分为：自动开关降级和人工开关降级。
• 降级按照功能可分为：读服务降级、写服务降级。
• 降级按照处于的系统层次可分为：多级降级。

降级的功能点

降级的功能点主要从服务端链路考虑，即根据用户访问的服务调用链路来梳理哪里需要降级:

页面降级：在大促或者某些特殊情况下，某些页面占用了一些稀缺服务资源，在紧急情况下可以对其整个降级，以达到丢卒保帅;

页面片段降级：比如商品详情页中的商家部分因为数据错误了，此时需要对其进行降级;

页面异步请求降级：比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级;

服务功能降级：比如渲染商品详情页时需要调用一些不太重要的服务：相关分类、热销榜等，而这些服务在异常情况下直接不获取，即降级即可;

读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景;

写降级：比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。

爬虫降级：在大促活动时，可以将爬虫流量导向静态页或者返回空数据从而降级保护后端稀缺资源。

降级策略

1、自动开关降级

自动降级是根据系统负载、资源使用情况、SLA等指标进行降级。

超时降级

当访问的数据库/http服务/远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话可以在超时后自动降级;

对于这种服务是可以超时降级的。如果是调用别人的远程服务，和对方定义一个服务响应最大时间，如果超时了则自动降级。

在实际场景用一定主要配置好超时时间和超时重试次数和机制。

统计失败次数降级

有时候依赖一些不稳定的API，比如调用外部机票服务，当失败调用次数达到一定阀值自动降级;然后通过异步线程去探测服务是否恢复了，则取消降级。

故障降级

比如要调用的远程服务挂掉了(网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异 常)，则可以直接降级。

降级后的处理方案有:

限流降级

当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级;

降级后的处理方案可以是:

• 排队页面(将用户导流到排队页面等一会重试)
• 无货(直接告知用户没货了)
• 错误页(如活动太火爆了，稍后重试)

2、人工开关降级

• 在大促期间通过监控发现线上的一些服务存在问题，这个时候需要暂时将这些服务摘掉;
• 还有有时候通过任务系统调用一些服务，但是服务依赖的数据库可能存在:网卡被打满了、挂掉了，或者很多慢查询，此时需要暂停下任务系统让服务方进行处理;
• 还有发现突然调用量太大，可能需要改变处理方式(比如同步转换为异步);

此时就可以使用开关来完成降级。

开关可以存放到配置文档、存放到数据库、存放到Redis/ZooKeeper;如果不是存放在本地，可以定期同步开关数据(比如1秒同步一次)。然后通过判断某个KEY的值来决定是否降级。

另外对于新开发的服务想上线进行灰度测试;但是不太确定该服务的逻辑是否正确，此时就需要设置开关，当新服务有问题可以通过开关切换回老服务。

还有多机房服务，如果某个机房挂掉了，此时需要将一个机房的服务切到另一个机房，此时也可以通过开关完成切换。

还有一些是因为功能问题需要暂时屏蔽掉某些功能，比如商品规格参数数据有问题，数据问题不能用回滚解决，此时需要开关控制降级。

3、读服务降级

对于读服务降级一般采用的策略有:

暂时切换读(降级到读缓存、降级到走静态化)
暂时屏蔽读(屏蔽读入口、屏蔽某个读服务)

接入层缓存→应用层本地缓存→分布式缓存→RPC服务/DB

我们会在接入层、应用层设置开关，当分布式缓存、RPC服务/DB有问题自动降级为不调用。当然这种情况适用于对读一致性要求不高的场景。

页面降级、页面片段降级、页面异步请求降级都是读服务降级，目的是丢卒保帅(比如因为这些服务也要使用核心资源、或者占了带宽影响到核心服务)或者因数据问题暂时屏蔽。

还有一种是页面静态化场景:

动态化降级为静态化：比如平时网站可以走动态化渲染商品详情页，但是到了大促来临之际可以将其切换为静态化来减少对核心资源的占用，而且可以提升性能;其他还有如列表页、首页、频道页都可以这么玩;可以通过一个进程定期的推送静态页到缓存或者生成到磁盘，出问题时直接切过去;

静态化降级为动态化：比如当使用静态化来实现商品详情页架构时，平时使用静态化来提供服务，但是因为特殊原因静态化页面有问题了，需要暂时切换回动态化来保证服务正确性。

以上都保证出问题了有预案，用户还是可以使用网站，不影响用户购物。

4、写服务降级

写服务在大多数场景下是不可降级的，不过可以通过一些迂回战术来解决问题。比如将同步操作转换为异步操作，或者限制写的量/比例。

比如扣减库存一般这样操作:

方案1:
a、扣减DB库存;
b、扣减成功后更新Redis中的库存;

方案2:
a、扣减Redis库存;
b、同步扣减DB库存，如果扣减失败则回滚Redis库存;

前两种方案非常依赖DB，假设此时DB性能跟不上则扣减库存就会遇到问题;因此我们可以想到

方案3:
a、扣减Redis库存:
b、正常同步扣减DB库存，性能扛不住时降级为发送一条扣减DB库存的消息，然后异步进行DB库存扣减实现最终一致即可;

这种方式发送扣减DB库存消息也可能成为瓶颈;这种情况我们可以考虑

方案4:
a、扣减Redis库存;
b、正常同步扣减DB库存，性能扛不住时降级为写扣减DB库存消息到本机，然后本机通过异步进行DB库存扣减来实现最终一致性。

也就是说正常情况可以同步扣减库存，在性能扛不住时降级为异步;另外如果是秒杀场景可以直接降级为异步，从而保护系统。

还有如下单操作可以在大促时暂时降级将下单数据写入Redis，然后等峰值过去了再同步回DB，当然也有更好的解决方案，但是更复杂，不是本文的重点。

还有如用户评价，如果评价量太大，也可以把评价从同步写降级为异步写。当然也可以对评价按钮进行按比例开放(比如一些人的看不到评价操作按钮)。比如评价成功后会发一些奖励，在必要的时候降级同步到异步。

5、多级降级

缓存是离用户最近越高效;而降级是离用户越近越能对系统保护的好。因为业务的复杂性导致越到后端QPS/TPS越低。

页面JS降级开关：主要控制页面功能的降级，在页面中通过JS脚本部署功能降级开关，在适当时机开启/关闭开关;

接入层降级开关：主要控制请求入口的降级，请求进入后会首先进入接入层，在接入层可以配置功能降级开关，可以根据实际情况进行自动/人工降级; 尤其在后端应用服务出问题时，通过接入层降级从而给应用服务有足够的时间恢复服务;

应用层降级开关：主要控制业务的降级，在应用中配置相应的功能开关，根据实际业务情况进行自动 / 人工降级。

总结:

降级能保障系统在大促中活下来，而不是死去，达到丢卒保帅的作用。对用户提供有损服务，总比不服务要好。根据自己的场景设计相应的降级策略，保障系统在危机时刻能通过降级手段平稳度过。

分布式降级框架 Hystrix

初探Hystrix

Hystrix [hɪst’rɪks]，中文含义是豪猪，因其背上长满棘刺，从而拥有自我保护的能力。本文所说的 Hystrix是Netflix开源的一款容错框架，同样具有自我保护能力。为了实现容错和自我保护，下面我们看看Hystrix如何设计和实现的。

Hystrix设计目标:

• 对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的
• 阻止故障的连锁反应
• 快速失败并迅速恢复
• 回退并优雅降级
• 提供近实时的监控与告警

Hystrix遵循的设计原则:

• 防止任何单独的依赖耗尽资源(线程)
• 过载立即切断并快速失败，防止排队
• 尽可能提供回退以保护用户免受故障
• 使用隔离技术(例如隔板，泳道和断路器模式)来限制任何一个依赖的影响
• 通过近实时的指标，监控和告警，确保故障被及时发现
• 通过动态修改配置属性，确保故障及时恢复
• 防止整个依赖客户端执行失败，而不仅仅是网络通信

Hystrix如何实现这些设计目标?

• 使用命令模式将所有对外部服务(或依赖关系)的调用包装在HystrixCommand或 HystrixObservableCommand对象中，并将该对象放在单独的线程中执行;
• 每个依赖都维护着一个线程池(或信号量)，线程池被耗尽则拒绝请求(而不是让请求排队)。
• 记录请求成功，失败，超时和线程拒绝。
• 服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内停止对该服务的所有请求。
• 请求失败，被拒绝，超时或熔断时执行降级逻辑。
• 近实时地监控指标和配置的修改。

Hystrix入门

Hystrix简单示例

开始深入Hystrix原理之前，我们先简单看一个示例。

第一步，继承HystrixCommand实现自己的command，在command的构造方法中需要配置请求被执行需要的参数，并组合实际发送请求的对象，代码如下:

public class QueryOrderIdCommand extends HystrixCommand<Integer> {
	
	private final static Logger logger = LoggerFactory.getLogger(QueryOrderIdCommand.class);
    private OrderServiceProvider orderServiceProvider;
    
    public QueryOrderIdCommand(OrderServiceProvider orderServiceProvider) {
		super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("orderService"))
			.andCommandKey(HystrixCommandKey.Factory.asKey("queryByOrderId"))
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
			.withCircuitBreakerRequestVolumeThreshold(10)//至少有10个请求，熔断器才进行错误率的计算
			.withCircuitBreakerSleepWindowInMilliseconds(5000)//熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试
			.withCircuitBreakerErrorThresholdPercentage(50)//错误率达到50开启熔断保护
        	.withExecutionTimeoutEnabled(true))
			.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties
            .Setter().withCoreSize(10)));
		this.orderServiceProvider = orderServiceProvider;
	}
	
	@Override
    protected Integer run() {
        return orderServiceProvider.queryByOrderId();
	}

	@Override
    protected Integer getFallback() {
        return -1;
	} 
}

第二步，调用HystrixCommand的执行方法发起实际请求。

@Test
public void testQueryByOrderIdCommand() {
    Integer r = new QueryOrderIdCommand(orderServiceProvider).execute();
    logger.info("result:{}", r);
}

Hystrix处理流程

Hystrix流程图如下:

Hystrix整个工作流如下:

1. 构造一个 HystrixCommand或HystrixObservableCommand对象，用于封装请求，并在构造方法配置请求被执行需要的参数;
2. 执行命令，Hystrix提供了4种执行命令的方法，后面详述;
3. 判断是否使用缓存响应请求，若启用了缓存，且缓存可用，直接使用缓存响应请求。Hystrix支持请求缓存，但需要用户自定义启动;
4. 判断熔断器是否打开，如果打开，跳到第8步;
5. 判断线程池/队列/信号量是否已满，已满则跳到第8步;
6. 执行HystrixObservableCommand.construct()或HystrixCommand.run()，如果执行失败或者超时，跳到第8步;否则，跳到第9步;
7. 统计熔断器监控指标;
8. 走Fallback备用逻辑
9. 返回请求响应

从流程图上可知道，第5步线程池/队列/信号量已满时，还会执行第7步逻辑，更新熔断器统计信息，而第6步无论成功与否，都会更新熔断器统计信息。

执行命令的几种方法

Hystrix提供了4种执行命令的方法，execute()和queue() 适用于HystrixCommand对象，而observe()和 toObservable()适用于HystrixObservableCommand对象。

execute()
以同步堵塞方式执行run()，只支持接收一个值对象。hystrix会从线程池中取一个线程来执行run()，并等待返回值。

queue()
以异步非阻塞方式执行run()，只支持接收一个值对象。调用queue()就直接返回一个Future对象。可通过 Future.get()拿到run()的返回结果，但Future.get()是阻塞执行的。若执行成功，Future.get()返回单个返回值。当执行失败时，如果没有重写fallback，Future.get()抛出异常。

observe()
事件注册前执行run()/construct()，支持接收多个值对象，取决于发射源。调用observe()会返回一个 hot Observable，也就是说，调用observe()自动触发执行run()/construct()，无论是否存在订阅者。如果继承的是HystrixCommand，hystrix会从线程池中取一个线程以非阻塞方式执行run();如果继承 的是HystrixObservableCommand，将以调用线程阻塞执行construct()。

observe()使用方法:

1. 调用observe()会返回一个Observable对象
2. 调用这个Observable对象的subscribe()方法完成事件注册，从而获取结果

toObservable()
事件注册后执行run()/construct()，支持接收多个值对象，取决于发射源。调用toObservable()会返回 一个cold Observable，也就是说，调用toObservable()不会立即触发执行run()/construct()，必须有订阅者订阅Observable时才会执行。

如果继承的是HystrixCommand，hystrix会从线程池中取一个线程以非阻塞方式执行run()，调用线程不必等待run();如果继承的是HystrixObservableCommand，将以调用线程堵塞执行construct()，调用线程需等待construct()执行完才能继续往下走。

toObservable()使用方法:

1. 调用observe()会返回一个Observable对象
2. 调用这个Observable对象的subscribe()方法完成事件注册，从而获取结果

需注意的是，HystrixCommand也支持toObservable()和observe()，但是即使将HystrixCommand转换成Observable，它也只能发射一个值对象。只有HystrixObservableCommand才支持发射多个值对象。

几种方法的关系

• execute()实际是调用了queue().get()
• queue()实际调用了toObservable().toBlocking().toFuture()
• observe()实际调用toObservable()获得一个cold Observable，再创建一个ReplaySubject对象订阅Observable，将源Observable转化为hot Observable。因此调用observe()会自动触发执行 run()/construct()。

Hystrix总是以Observable的形式作为响应返回，不同执行命令的方法只是进行了相应的转换。

Hystrix容错

Hystrix的容错主要是通过添加容许延迟和容错方法，帮助控制这些分布式服务之间的交互。 还通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供回退选项来实现这一点，从而提高系统的整体弹性。Hystrix主要提供了以下几种容错方法:

• 资源隔离
• 熔断
• 降级

下面我们详细谈谈这几种容错机制。

资源隔离

资源隔离主要指对线程的隔离。Hystrix提供了两种线程隔离方式:线程池和信号量。

线程隔离-线程池

通过将发送请求线程与执行请求的线程分离，可有效防止发生级联故障。当线程池或请求队列饱和时， Hystrix将拒绝服务，使得请求线程可以快速失败，从而避免依赖问题扩散。

线程池隔离优缺点

优点:

• 保护应用程序以免受来自依赖故障的影响，指定依赖线程池饱和不会影响应用程序的其余部分。
• 当引入新客户端lib时，即使发生问题，也是在本lib中，并不会影响到其他内容。
• 当依赖从故障恢复正常时，应用程序会立即恢复正常的性能。
• 当应用程序一些配置参数错误时，线程池的运行状况会很快检测到这一点(通过增加错误，延迟， 超时，拒绝等)，同时可以通过动态属性进行实时纠正错误的参数配置。
• 如果服务的性能有变化，需要实时调整，比如增加或者减少超时时间，更改重试次数，可以通过线程池指标动态属性修改，而且不会影响到其他调用请求。
• 除了隔离优势外，hystrix拥有专门的线程池可提供内置的并发功能，使得可以在同步调用之上构建异步门面(外观模式)，为异步编程提供了支持(Hystrix引入了Rxjava异步框架)。

注意:尽管线程池提供了线程隔离，我们的客户端底层代码也必须要有超时设置或响应线程中断，不能无限制的阻塞以致线程池一直饱和。

缺点:

线程池的主要缺点是增加了计算开销。每个命令的执行都在单独的线程完成，增加了排队、调度和上下文切换的开销。因此，要使用Hystrix，就必须接受它带来的开销，以换取它所提供的好处。

通常情况下，线程池引入的开销足够小，不会有重大的成本或性能影响。但对于一些访问延迟极低的服务，如只依赖内存缓存，线程池引入的开销就比较明显了，这时候使用线程池隔离技术就不适合了，我们需要考虑更轻量级的方式，如信号量隔离。

线程隔离-信号量

上面提到了线程池隔离的缺点，当依赖延迟极低的服务时，线程池隔离技术引入的开销超过了它所带来的好处。这时候可以使用信号量隔离技术来代替，通过设置信号量来限制对任何给定依赖的并发调用量。下图说明了线程池隔离和信号量隔离的主要区别:

使用线程池时，发送请求的线程和执行依赖服务的线程不是同一个，而使用信号量时，发送请求的线程和执行依赖服务的线程是同一个，都是发起请求的线程。先看一个使用信号量隔离线程的示例:

public class QueryByOrderIdCommandSemaphore extends HystrixCommand<Integer> {
    
    private final static Logger logger = LoggerFactory.getLogger(QueryByOrderIdCommandSemaphore.class);

    private OrderServiceProvider orderServiceProvider;

    public QueryByOrderIdCommandSemaphore(OrderServiceProvider orderServiceProvider) {
		
		super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("orderService"))
			.andCommandKey(HystrixCommandKey.Factory.asKey("queryByOrderId"))
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
			.withCircuitBreakerRequestVolumeThreshold(10)//至少有10个请求，熔断器才进行错误率的计算
			.withCircuitBreakerSleepWindowInMilliseconds(5000)//熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试
			.withCircuitBreakerErrorThresholdPercentage(50)//错误率达到50开启熔断保护 		
			.withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.SEMAPHORE)
			.withExecutionIsolationSemaphoreMaxConcurrentRequests(10)));//最大并发请求量 
		this.orderServiceProvider = orderServiceProvider;
	}
	
	@Override
	protected Integer run() {
        return orderServiceProvider.queryByOrderId();
	}

	@Override
    protected Integer getFallback() {
        return -1;
	} 
}

由于Hystrix默认使用线程池做线程隔离，使用信号量隔离需要显示地将属性 execution.isolation.strategy设置为ExecutionIsolationStrategy.SEMAPHORE，同时配置信号量个数， 默认为10。客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的 数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。

信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。

线程隔离总结

线程池和信号量都可以做线程隔离，但各有各的优缺点和支持的场景，对比如下:

线程池和信号量都支持熔断和限流。相比线程池，信号量不需要线程切换，因此避免了不必要的开销。 但是信号量不支持异步，也不支持超时，也就是说当所请求的服务不可用时，信号量会控制超过限制的请求立即返回，但是已经持有信号量的线程只能等待服务响应或从超时中返回，即可能出现长时间等待。线程池模式下，当超过指定时间未响应的服务，Hystrix会通过响应中断的方式通知线程立即结束并返回。

熔断

熔断器简介

现实生活中，可能大家都有注意到家庭电路中通常会安装一个保险盒，当负载过载时，保险盒中的保险丝会自动熔断，以保护电路及家里的各种电器，这就是熔断器的一个常见例子。Hystrix中的熔断器 (Circuit Breaker)也是起类似作用，Hystrix在运行过程中会向每个commandKey对应的熔断器报告成功、失败、超时和拒绝的状态，熔断器维护并统计这些数据，并根据这些统计信息来决策熔断开关是否打开。如果打开，熔断后续请求，快速返回。隔一段时间(默认是5s)之后熔断器尝试半开，放入一部分流量请求进来，相当于对依赖服务进行一次健康检查，如果请求成功，熔断器关闭。

熔断器配置

Circuit Breaker主要包括如下6个参数:

1、circuitBreaker.enabled
是否启用熔断器，默认是TRUE。

2 、circuitBreaker.forceOpen
熔断器强制打开，始终保持打开状态，不关注熔断开关的实际状态。默认值FLASE。

3、circuitBreaker.forceClosed
熔断器强制关闭，始终保持关闭状态，不关注熔断开关的实际状态。默认值FLASE。

4、circuitBreaker.errorThresholdPercentage
错误率，默认值50%，例如一段时间(10s)内有100个请求，其中有54个超时或者异常，那么这段时间内的错误率是54%，大于了默认值50%，这种情况下会触发熔断器打开。

5、circuitBreaker.requestVolumeThreshold
默认值20。含义是一段时间内至少有20个请求才进行errorThresholdPercentage计算。比如一段时间有了有19个请求，且这些请求全部失败了，错误率是100%，但熔断器不会打开，总请求数不满足20。

6、circuitBreaker.sleepWindowInMilliseconds
半开状态试探睡眠时间，默认值5000ms。如:当熔断器开启5000ms之后，会尝试放过去一部分流量进行试探，确定依赖服务是否恢复。

回退降级

降级，通常指服务高峰期，为了保证核心服务正常运行，需要停掉一些不太重要的业务，或者某些服务不可用时，执行备用逻辑从故障服务中快速失败或快速返回，以保障主体业务不受影响。Hystrix提供的降级主要是为了容错，保证当前服务不受依赖服务故障的影响，从而提高服务的健壮性。要支持回退或降级处理，可以重写HystrixCommand的getFallBack方法或HystrixObservableCommand的 resumeWithFallback方法。

Hystrix在以下几种情况下会走降级逻辑:

• 执行construct()或run()抛出异常
• 熔断器打开导致命令短路
• 命令的线程池和队列或信号量的容量超额，命令被拒绝
• 命令执行超时