当服务发生故障不可用后，限定传播范围和影响范围，防止出现雪球效应。

3.1 线程隔离

　　将请求分类，交给不同的线程池处理（RocketMQ的broker各种线程池）。当一个业务请求发生问题时，不会将故障扩散到其他线程池。

3.2 进程隔离

　　将系统按业务拆分成多个子系统实现物理隔离。

3.3 集群隔离

　　同一服务部署多个相同实例，分担压力和在单个实例故障时使用负载均衡保障整体服务可用

3.4 机房隔离

　　多机房部署，每个机房的服务只应该调用本机房服务。当某个机房中某个服务发生故障，整个机房对外不可用。

3.5 读写隔离

　　读服务只读Redis，写服务写库

3.6 动静隔离

　　将静态资源放在CDN上

3.7 爬虫隔离

　　在负载均衡层面将爬虫流量路由到单独集群，比如使用Nginx或者OpenResty过滤爬虫和恶意IP

3.8 热点隔离

　　秒杀，抢购等做成系统单独部署，防止影响其他正常流程

3.9 资源隔离

3.10 使用Hystrix实现隔离

　　1. 提供线程池隔离和信号量隔离

　　2. 提供降级机制：超时降级、资源不足（线程或信号量）降级，降级后配合降级接口返回托底数据

　　3. 提供熔断机制：当失败率打到阈值自动触发，熔断器触发的快速失败会进行快速恢复

　　4. 提供请求缓存、请求合并

3.11 基于Servlet3实现请求隔离

　　Tomcat收到HTTP请求后，按照如下流程处理请求

　　1. 容器负责接收并解析请求为HttpServletRequest

　　2. 交给Servlet进行业务处理

　　3. 最后通过HttpServletResponse写响应

　　在Servlet2.x规范中，所有这些处理都是同步进行，也就是说必须在一个线程中完成从接收请求、业务处理到响应。

　　在Servlet3中将请求异步化，Tomcat线程收到任务后丢到任务队列，由自定义的业务线程池处理。自定义的线程池由开发者控制，开发自由度大幅提升。

　　1. 基于NIO能处理更高的并发连接数

　　2. 请求解析和业务处理线程池分离

　　3. 根据业务重要性对业务分级，并分级业务线程池

　　4. 对业务线程池进行监控、运维、降级等处理

　　当发现请求过多，负载较高，最简单的方法是清空线程池，防止出现服务器雪崩。