- 1.1 消息队列
-
1.2 搜索引擎
-
1.2.1 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)?
-
1.2.2 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?底层的 lucene 介绍一下呗?倒排索引了解吗?
-
1.2.3 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?
-
1.2.4 es 生产集群的部署架构是什么?每个索引的数据量大概有多少?每个索引大概有多少个分片?
-
1.3.1 在项目中缓存是如何使用的?缓存如果使用不当会造成什么后果?
-
1.3.2 Redis 和 Memcached 有什么区别?Redis 的线程模型是什么?为什么单线程的 Redis 比多线程的 Memcached 效率要高得多?
-
1.3.3 Redis 都有哪些数据类型?分别在哪些场景下使用比较合适?
-
1.3.4 Redis 的过期策略都有哪些?手写一下 LRU 代码实现?
-
1.3.5 如何保证 Redis 高并发、高可用?Redis 的主从复制原理能介绍一下么?Redis 的哨兵原理能介绍一下么?
-
1.3.6 Redis 的持久化有哪几种方式?不同的持久化机制都有什么优缺点?持久化机制具体底层是如何实现的?
-
1.3.7 Redis 集群模式的工作原理能说一下么?在集群模式下,Redis 的 key 是如何寻址的?分布式寻址都有哪些算法?了解一致性 hash 算法吗?如何动态增加和删除一个节点?
-
1.3.8 了解什么是 redis 的雪崩、穿透和击穿?Redis 崩溃之后会怎么样?系统该如何应对这种情况?如何处理 Redis 的穿透?
-
1.3.9 如何保证缓存与数据库的双写一致性?
-
1.3.10 Redis 的并发竞争问题是什么?如何解决这个问题?了解 Redis 事务的 CAS 方案吗?
-
1.3.11 生产环境中的 Redis 是怎么部署的?
-
1.4.1 为什么要分库分表(设计高并发系统的时候,数据库层面该如何设计)?用过哪些分库分表中间件?不同的分库分表中间件都有什么优点和缺点?你们具体是如何对数据库如何进行垂直拆分或水平拆分的?
-
1.4.2 现在有一个未分库分表的系统,未来要分库分表,如何设计才可以让系统从未分库分表动态切换到分库分表上?
-
1.4.3 如何设计可以动态扩容缩容的分库分表方案?
-
1.4.4 分库分表之后,id 主键如何处理?
-
1.5.1 如何实现 MySQL 的读写分离?MySQL 主从复制原理是啥?如何解决 MySQL 主从同步的延时问题?
-
1.6.1 如何设计一个高并发系统?
-
1.2.1 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)?
-
2.1 面试连环炮
-
2.2.1 为什么要进行系统拆分?如何进行系统拆分?拆分后不用 Dubbo 可以吗?
-
2.3.1 说一下 Dubbo 的工作原理?注册中心挂了可以继续通信吗?
-
2.3.2 Dubbo 支持哪些序列化协议?说一下 Hessian 的数据结构?PB 知道吗?为什么 PB 的效率是最高的?
-
2.3.3 Dubbo 负载均衡策略和集群容错策略都有哪些?动态代理策略呢?
-
2.3.4 Dubbo 的 spi 思想是什么?
-
2.3.5 如何基于 Dubbo 进行服务治理、服务降级、失败重试以及超时重试?
-
2.3.6 分布式服务接口的幂等性如何设计(比如不能重复扣款)?
-
2.3.7 分布式服务接口请求的顺序性如何保证?
-
2.3.8 如何自己设计一个类似 Dubbo 的 RPC 框架?
-
2.4.1 Zookeeper 都有哪些应用场景?
-
2.4.2 使用 Redis 如何设计分布式锁?使用 Zookeeper 来设计分布式锁可以吗?以上两种分布式锁的实现方式哪种效率比较高?
-
2.5.1 分布式事务了解吗?你们如何解决分布式事务问题的?TCC 如果出现网络连不通怎么办?XA 的一致性如何保证?
-
2.6.1 集群部署时的分布式 Session 如何实现?
-
3.1.1 Hystrix 介绍
-
3.1.2 电商网站详情页系统架构
-
3.1.3 Hystrix 线程池技术实现资源隔离
-
3.1.4 Hystrix 信号量机制实现资源隔离
-
3.1.5 Hystrix 隔离策略细粒度控制
-
3.1.6 深入 Hystrix 执行时内部原理
-
3.1.7 基于 request cache 请求缓存技术优化批量商品数据查询接口
-
3.1.8 基于本地缓存的 fallback 降级机制
-
3.1.9 深入 Hystrix 断路器执行原理
-
3.1.10 深入 Hystrix 线程池隔离与接口限流
-
3.1.11 基于 timeout 机制为服务接口调用超时提供安全保护
-
2.2.1 为什么要进行系统拆分?如何进行系统拆分?拆分后不用 Dubbo 可以吗?
-
4.1 关于微服务架构的描述
深入 Hystrix 执行时内部原理
前面我们了解了 Hystrix 最基本的支持高可用的技术:资源隔离 + 限流。
- 创建 command;
- 执行这个 command;
- 配置这个 command 对应的 group 和线程池。
这里,我们要讲一下,你开始执行这个 command,调用了这个 command 的 execute() 方法之后,Hystrix 底层的执行流程和步骤以及原理是什么。
在讲解这个流程的过程中,我会带出来 Hystrix 其他的一些核心以及重要的功能。
这里是整个 8 大步骤的流程图,我会对每个步骤进行细致的讲解。学习的过程中,对照着这个流程图,相信思路会比较清晰。
步骤一:创建 command
一个 HystrixCommand 或 HystrixObservableCommand 对象,代表了对某个依赖服务发起的一次请求或者调用。创建的时候,可以在构造函数中传入任何需要的参数。
- HystrixCommand 主要用于仅仅会返回一个结果的调用。
- HystrixObservableCommand 主要用于可能会返回多条结果的调用。
// 创建 HystrixCommand
HystrixCommand hystrixCommand = new HystrixCommand(arg1, arg2);
// 创建 HystrixObservableCommand
HystrixObservableCommand hystrixObservableCommand = new HystrixObservableCommand(arg1, arg2);
copy
步骤二:调用 command 执行方法
执行 command,就可以发起一次对依赖服务的调用。
要执行 command,可以在 4 个方法中选择其中的一个:execute()、queue()、observe()、toObservable()。
其中 execute() 和 queue() 方法仅仅对 HystrixCommand 适用。
- execute():调用后直接 block 住,属于同步调用,直到依赖服务返回单条结果,或者抛出异常。
- queue():返回一个 Future,属于异步调用,后面可以通过 Future 获取单条结果。
- observe():订阅一个 Observable 对象,Observable 代表的是依赖服务返回的结果,获取到一个那个代表结果的 Observable 对象的拷贝对象。
- toObservable():返回一个 Observable 对象,如果我们订阅这个对象,就会执行 command 并且获取返回结果。
K value = hystrixCommand.execute(); Future<K> fValue = hystrixCommand.queue(); Observable<K> oValue = hystrixObservableCommand.observe(); Observable<K> toOValue = hystrixObservableCommand.toObservable();
copy
execute() 实际上会调用 queue().get() 方法,可以看一下 Hystrix 源码。
public R execute() {
try {
return queue().get();
} catch (Exception e) {
throw Exceptions.sneakyThrow(decomposeException(e));
}
}
copy
而在 queue() 方法中,会调用 toObservable().toBlocking().toFuture()。
final Future<R> delegate = toObservable().toBlocking().toFuture();
copy
也就是说,先通过 toObservable() 获得 Future 对象,然后调用 Future 的 get() 方法。那么,其实无论是哪种方式执行 command,最终都是依赖于 toObservable() 去执行的。
步骤三:检查是否开启缓存
从这一步开始,就进入到 Hystrix 底层运行原理啦,看一下 Hystrix 一些更高级的功能和特性。
如果这个 command 开启了请求缓存 Request Cache,而且这个调用的结果在缓存中存在,那么直接从缓存中返回结果。否则,继续往后的步骤。
步骤四:检查是否开启了断路器
检查这个 command 对应的依赖服务是否开启了断路器。如果断路器被打开了,那么 Hystrix 就不会执行这个 command,而是直接去执行 fallback 降级机制,返回降级结果。
步骤五:检查线程池/队列/信号量是否已满
如果这个 command 线程池和队列已满,或者 semaphore 信号量已满,那么也不会执行 command,而是直接去调用 fallback 降级机制,同时发送 reject 信息给断路器统计。
步骤六:执行 command
调用 HystrixObservableCommand 对象的 construct() 方法,或者 HystrixCommand 的 run() 方法来实际执行这个 command。
- HystrixCommand.run() 返回单条结果,或者抛出异常。
// 通过command执行,获取最新一条商品数据
ProductInfo productInfo = getProductInfoCommand.execute();
copy
- HystrixObservableCommand.construct() 返回一个 Observable 对象,可以获取多条结果。
Observable<ProductInfo> observable = getProductInfosCommand.observe();
// 订阅获取多条结果
observable.subscribe(new Observer<ProductInfo>() {
@Override
public void onCompleted() {
System.out.println("获取完了所有的商品数据");
}
@Override
public void onError(Throwable e) {
e.printStackTrace();
}
/**
* 获取完一条数据,就回调一次这个方法
*
* @param productInfo 商品信息
*/
@Override
public void onNext(ProductInfo productInfo) {
System.out.println(productInfo);
}
});
copy
如果是采用线程池方式,并且 HystrixCommand.run() 或者 HystrixObservableCommand.construct() 的执行时间超过了 timeout 时长的话,那么 command 所在的线程会抛出一个 TimeoutException,这时会执行 fallback 降级机制,不会去管 run() 或 construct() 返回的值了。另一种情况,如果 command 执行出错抛出了其它异常,那么也会走 fallback 降级。这两种情况下,Hystrix 都会发送异常事件给断路器统计。
注意,我们是不可能终止掉一个调用严重延迟的依赖服务的线程的,只能说给你抛出来一个 TimeoutException。
如果没有 timeout,也正常执行的话,那么调用线程就会拿到一些调用依赖服务获取到的结果,然后 Hystrix 也会做一些 logging 记录和 metric 度量统计。
步骤七:断路健康检查
Hystrix 会把每一个依赖服务的调用成功、失败、Reject、Timeout 等事件发送给 circuit breaker 断路器。断路器就会对这些事件的次数进行统计,根据异常事件发生的比例来决定是否要进行断路(熔断)。如果打开了断路器,那么在接下来一段时间内,会直接断路,返回降级结果。
如果在之后,断路器尝试执行 command,调用没有出错,返回了正常结果,那么 Hystrix 就会把断路器关闭。
步骤八:调用 fallback 降级机制
在以下几种情况中,Hystrix 会调用 fallback 降级机制。
- 断路器处于打开状态;
- 线程池/队列/semaphore满了;
- command 执行超时;
- run() 或者 construct() 抛出异常。
一般在降级机制中,都建议给出一些默认的返回值,比如静态的一些代码逻辑,或者从内存中的缓存中提取一些数据,在这里尽量不要再进行网络请求了。
在降级中,如果一定要进行网络调用的话,也应该将那个调用放在一个 HystrixCommand 中进行隔离。
- HystrixCommand 中,实现 getFallback() 方法,可以提供降级机制。
- HystrixObservableCommand 中,实现 resumeWithFallback() 方法,返回一个 Observable 对象,可以提供降级结果。
如果没有实现 fallback,或者 fallback 抛出了异常,Hystrix 会返回一个 Observable,但是不会返回任何数据。
不同的 command 执行方式,其 fallback 为空或者异常时的返回结果不同。
- 对于 execute(),直接抛出异常。
- 对于 queue(),返回一个 Future,调用 get() 时抛出异常。
- 对于 observe(),返回一个 Observable 对象,但是调用 subscribe() 方法订阅它时,立即抛出调用者的 onError() 方法。
- 对于 toObservable(),返回一个 Observable 对象,但是调用 subscribe() 方法订阅它时,立即抛出调用者的 onError() 方法。
不同的执行方式
- execute(),获取一个 Future.get(),然后拿到单个结果。
- queue(),返回一个 Future。
- observe(),立即订阅 Observable,然后启动 8 大执行步骤,返回一个拷贝的 Observable,订阅时立即回调给你结果。
- toObservable(),返回一个原始的 Observable,必须手动订阅才会去执行 8 大步骤。