那为什么要用请求合并呢?
因为对依赖服务的线程池资源有限,将出现排队等待与响应延迟的情况。
1、下面例子中 时间窗设置为100ms,所以在这个时间内的请求会合并在一起请求.

2、下面我们调用一下。

3、结果如下,说明123、456、789在一个时间窗100ms内,所以请求合并了,888、999在一个时间窗内。

那到底什么时候使用请求合并呢?
1、请求命令本身的延迟。如果依赖服务的请求命令本身是一个高延迟的命令,那么可以使用请求合并器,因为延迟时间窗的时间消耗就显得莫不足道了。
2、延迟时间窗内的并发量。
对于多个线程的请求合并,应该如何做呢?

@HystrixCollapser scope属性
所有线程的请求中的多次服务请求进行合并。Scope.GLOBAL;
//默认,对一次请求的多次服务调用合并Scope.REQUEST
下面我们对所有线程的请求合并模拟


1、这里单个请求的service 返回的 Future 包装的对象,如果使用原对象,则是同步请求,不会合并。
2、暂时还不支持 feign 整合
网友评论