Skip to content

Commit 0bc53f6

Browse files
committed
docs: update hystrix-request-cache.md
- Update request cache - Update offer.md - Update title of Advanced-Java
1 parent e57d35f commit 0bc53f6

File tree

3 files changed

+145
-21
lines changed

3 files changed

+145
-21
lines changed

docs/high-availability/hystrix-request-cache.md

+142-17
Original file line numberDiff line numberDiff line change
@@ -3,23 +3,23 @@ Hystrix command 执行时 8 大步骤第三步,就是检查 Request cache 是
33

44
首先,有一个概念,叫做 Request Context 请求上下文,一般来说,在一个 web 应用中,如果我们用到了 Hystrix,我们会在一个 filter 里面,对每一个请求都施加一个请求上下文。就是说,每一次请求,就是一次请求上下文。然后在这次请求上下文中,我们会去执行 N 多代码,调用 N 多依赖服务,有的依赖服务可能还会调用好几次。
55

6-
在一次请求上下文中,如果有多个 command,参数都是一样的,调用的接口也是一样的,其实结果可以认为也是一样的。那么这个时候,我们可以让第一个 command 执行返回的结果缓存在内存中,然后这个请求上下文后续的其它对这个依赖的调用全部从内存中取出缓存结果就可以了。
6+
在一次请求上下文中,如果有多个 command,参数都是一样的,调用的接口也是一样的,而结果可以认为也是一样的。那么这个时候,我们可以让第一个 command 执行返回的结果缓存在内存中,然后这个请求上下文后续的其它对这个依赖的调用全部从内存中取出缓存结果就可以了。
77

88
这样的话,好处在于不用在一次请求上下文中反复多次执行一样的 command,**避免重复执行网络请求,提升整个请求的性能**
99

10-
举个栗子。比如说我们在一次请求上下文中,请求获取 productId 为 1 的数据,第一次缓存中没有,那么会从商品服务中获取数据,返回最新数据结果,同时将数据缓存在内存中。后续同一次请求上下文中,如果还有获取 productId 为 1 的请求,直接从缓存中取就好了。
10+
举个栗子。比如说我们在一次请求上下文中,请求获取 productId 为 1 的数据,第一次缓存中没有,那么会从商品服务中获取数据,返回最新数据结果,同时将数据缓存在内存中。后续同一次请求上下文中,如果还有获取 productId 为 1 的数据的请求,直接从缓存中取就好了。
1111

1212
![hystrix-request-cache](/img/hystrix-request-cache.png)
1313

1414
HystrixCommand 和 HystrixObservableCommand 都可以指定一个缓存 key,然后 Hystrix 会自动进行缓存,接着在同一个 request context 内,再次访问的话,就会直接取用缓存。
1515

16-
下面,我们结合一个具体的**业务场景**,来看一下如何使用 request cache 请求缓存技术。
16+
下面,我们结合一个具体的**业务场景**,来看一下如何使用 request cache 请求缓存技术。当然,以下代码只作为一个基本的 Demo 而已。
1717

18-
现在,假设我们要做一个批量查询商品数据的接口,在这个里面,我们是 HystrixObservableCommand 一次性批量查询多个商品 id 的数据。但是这里有个问题,如果说 Nginx 在本地缓存失效了,重新获取一批缓存,传递过来的 productIds 都没有进行去重,比如`productIds=1,1,1,2,2`,那么可能说,商品 id 出现了重复,如果按照我们之前的业务逻辑,可能就会重复对 productId=1 的商品查询三次,productId=2 的商品查询两次。
18+
现在,假设我们要做一个**批量查询商品数据**的接口,在这个里面,我们是用 HystrixCommand 一次性批量查询多个商品 id 的数据。但是这里有个问题,如果说 Nginx 在本地缓存失效了,重新获取一批缓存,传递过来的 productIds 都没有进行去重,比如 `productIds=1,1,1,2,2`,那么可能说,商品 id 出现了重复,如果按照我们之前的业务逻辑,可能就会重复对 productId=1 的商品查询三次,productId=2 的商品查询两次。
1919

20-
我们对批量查询商品数据的接口,可以用 request cache 做一个优化,就是说一次请求,就是一次request context,对相同的商品查询只执行一次,其余的都走 request cache。
20+
我们对批量查询商品数据的接口,可以用 request cache 做一个优化,就是说一次请求,就是一次 request context,对相同的商品查询只执行一次,其余重复的都走 request cache。
2121

22-
### 实现 Hystrix 请求上下文过滤器,并注册到 Application。
22+
### 实现 Hystrix 请求上下文过滤器并注册
2323
定义 HystrixRequestContextFilter 类,实现 Filter 接口。
2424

2525
```java
@@ -52,24 +52,149 @@ public class HystrixRequestContextFilter implements Filter {
5252
}
5353
```
5454

55-
然后将该对象注册到 Application 中。
55+
然后将该 filter 对象注册到 SpringBoot Application 中。
5656

5757
```java
5858
@SpringBootApplication
5959
public class EshopApplication {
6060

61-
public static void main(String[] args) {
62-
SpringApplication.run(EshopApplication.class, args);
63-
}
61+
public static void main(String[] args) {
62+
SpringApplication.run(EshopApplication.class, args);
63+
}
6464

65-
@Bean
66-
public FilterRegistrationBean filterRegistrationBean() {
67-
FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean(new HystrixRequestContextFilter());
68-
filterRegistrationBean.addUrlPatterns("/*");
69-
return filterRegistrationBean;
70-
}
65+
@Bean
66+
public FilterRegistrationBean filterRegistrationBean() {
67+
FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean(new HystrixRequestContextFilter());
68+
filterRegistrationBean.addUrlPatterns("/*");
69+
return filterRegistrationBean;
70+
}
7171
}
7272
```
7373

74-
新年快乐...待补充......
74+
### command 重写 getCacheKey() 方法
75+
在 GetProductInfoCommand 中,重写 getCacheKey() 方法,这样的话,每一次请求的结果,都会放在 Hystrix 请求上下文中。下一个同一个 productId 的数据请求,直接取缓存,无须再调用 run() 方法。
76+
77+
```java
78+
public class GetProductInfoCommand extends HystrixCommand<ProductInfo> {
79+
80+
private Long productId;
81+
82+
private static final HystrixCommandKey KEY = HystrixCommandKey.Factory.asKey("GetProductInfoCommand");
83+
84+
public GetProductInfoCommand(Long productId) {
85+
super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ProductInfoService"))
86+
.andCommandKey(KEY));
87+
this.productId = productId;
88+
}
89+
90+
@Override
91+
protected ProductInfo run() {
92+
String url = "http://localhost:8081/getProductInfo?productId=" + productId;
93+
String response = HttpClientUtils.sendGetRequest(url);
94+
System.out.println("调用接口查询商品数据,productId=" + productId);
95+
return JSONObject.parseObject(response, ProductInfo.class);
96+
}
97+
98+
/**
99+
* 每次请求的结果,都会放在Hystrix绑定的请求上下文上
100+
*
101+
* @return cacheKey 缓存key
102+
*/
103+
@Override
104+
public String getCacheKey() {
105+
return "product_info_" + productId;
106+
}
107+
108+
/**
109+
* 将某个商品id的缓存清空
110+
*
111+
* @param productId 商品id
112+
*/
113+
public static void flushCache(Long productId) {
114+
HystrixRequestCache.getInstance(KEY,
115+
HystrixConcurrencyStrategyDefault.getInstance()).clear("product_info_" + productId);
116+
}
117+
}
118+
```
119+
120+
这里写了一个 flushCache() 方法,用于我们开发手动删除缓存。
121+
122+
### controller 调用 command 查询商品信息
123+
在一次 web 请求上下文中,传入商品 id 列表,查询多条商品数据信息。对于每个 productId,都创建一个 command。
124+
125+
如果 id 列表没有去重,那么重复的 id,第二次查询的时候就会直接走缓存。
126+
127+
```java
128+
@Controller
129+
public class CacheController {
130+
131+
/**
132+
* 一次性批量查询多条商品数据的请求
133+
*
134+
* @param productIds 以,分隔的商品id列表
135+
* @return 响应状态
136+
*/
137+
@RequestMapping("/getProductInfos")
138+
@ResponseBody
139+
public String getProductInfos(String productIds) {
140+
for (String productId : productIds.split(",")) {
141+
// 对每个productId,都创建一个command
142+
GetProductInfoCommand getProductInfoCommand = new GetProductInfoCommand(Long.valueOf(productId));
143+
ProductInfo productInfo = getProductInfoCommand.execute();
144+
System.out.println("是否是从缓存中取的结果:" + getProductInfoCommand.isResponseFromCache());
145+
}
146+
147+
return "success";
148+
}
149+
}
150+
```
151+
152+
### 发起请求
153+
调用接口,查询多个商品的信息。
154+
155+
```
156+
http://localhost:8080/getProductInfos?productIds=1,1,1,2,2,5
157+
```
158+
159+
在控制台,我们可以看到以下结果。
160+
161+
```
162+
调用接口查询商品数据,productId=1
163+
是否是从缓存中取的结果:false
164+
是否是从缓存中取的结果:true
165+
是否是从缓存中取的结果:true
166+
调用接口查询商品数据,productId=2
167+
是否是从缓存中取的结果:false
168+
是否是从缓存中取的结果:true
169+
调用接口查询商品数据,productId=5
170+
是否是从缓存中取的结果:false
171+
```
172+
173+
第一次查询 productId=1 的数据,会调用接口进行查询,不是从缓存中取结果。而随后再出现查询 productId=1 的请求,就直接取缓存了,这样的话,效率明显高很多。
174+
175+
### 删除缓存
176+
我们写一个 UpdateProductInfoCommand,在更新商品信息之后,手动调用之前写的 flushCache(),手动将缓存删除。
177+
178+
```java
179+
public class UpdateProductInfoCommand extends HystrixCommand<Boolean> {
180+
181+
private Long productId;
182+
183+
public UpdateProductInfoCommand(Long productId) {
184+
super(HystrixCommandGroupKey.Factory.asKey("UpdateProductInfoGroup"));
185+
this.productId = productId;
186+
}
187+
188+
@Override
189+
protected Boolean run() throws Exception {
190+
// 这里执行一次商品信息的更新
191+
// ...
192+
193+
// 然后清空缓存
194+
GetProductInfoCommand.flushCache(productId);
195+
return true;
196+
}
197+
}
198+
```
75199

200+
这样,以后查询该商品的请求,第一次就会走接口调用去查询最新的商品信息。

index.html

+2-2
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
<html lang="en">
33
<head>
44
<meta charset="UTF-8">
5-
<title>Java 进阶面试</title>
5+
<title>Java 进阶扫盲</title>
66
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
77
<meta name="description" content="advanced-java">
88
<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
@@ -22,7 +22,7 @@
2222
coverpage: true,
2323
mergeNavbar: true,
2424
search: [
25-
'/' // => /README.md
25+
'/'
2626
],
2727
plugins: [
2828
function (hook) {

offer.md

+1-2
Original file line numberDiff line numberDiff line change
@@ -122,5 +122,4 @@ HR
122122
123123
```
124124

125-
[![get-up-and-study](/img/get-up-and-study.png)](https://doocs.github.io/advanced-java)
126-
125+
[![get-up-and-study](/img/get-up-and-study.png)](https://doocs.github.io/advanced-java)

0 commit comments

Comments
 (0)