
前言:
最近忙着微服務項目的開發,脫更了半個月多,今天項目的初版已經完成,所以打算繼續我們的微服務學習,由於Hystrix這一塊東西好多,只好多拆分幾篇文章寫,對於一般對性能要求不是很高的項目中,可以使用其基礎上開發的Feign進行容錯保護。Hystrix學到現在我認為它的好處在於可以更靈活的調整熔斷時間和自定義的線程隔離策略,設置請求緩存與請求合並,還可以降低被調用服務的負載,配合儀表盤和Turbine進行服務狀態監控等,更加深入的還請閱讀書籍,理解淺薄,還望看官莫笑。 由於篇幅有限,請求合並的使用放在下一篇博客中
本文主要淺析Hystrix的請求緩存的使用
前情提要:
之前我們學習了自定義HystrixCommand,包括繼承和注解兩種方式實現了同步請求和異步請求,也正是這里我們開始使用了整個的項目管理我們的代碼,防止了項目過於分散丟筆記的情況。
如果是和我一樣在搭建並測試的,請來Github clone我的項目,地址是:https://github.com/HellxZ/SpringCloudLearn 歡迎大家對這個項目提建議。
正文:
在高並發的場景中,消費者A調用提供者B,如果請求是相同的,那么重復請求勢必會加重服務提供者B的負載,一般我們做高並發場景會理所應當的想到用緩存,那么針對這種情況Hystrix有什么方式來應對么?
Hystrix有兩種方式來應對高並發場景,分別是請求緩存與請求合並
回顧一下我們前幾篇文章中搭建的服務提供者項目,它會在有請求過來的時候打印此方法被調用。為了這次的測試,我們先在服務提供者項目中提供一個返回隨機數的接口,作為測試請求緩存的調用的接口,方便驗證我們的看法。
在EurekaServiceProvider項目中的GetRequestController中添加如下方法
/**
* 為了請求測試Hystrix請求緩存提供的返回隨機數的接口
*/
@GetMapping("/hystrix/cache")
public Integer getRandomInteger(){
Random random = new Random();
int randomInt = random.nextInt(99999);
return randomInt;
}
注意:以下有些注釋寫的很清楚的地方,就不重復寫了
接下來我們先介紹請求緩存
請求緩存
請求緩存是在同一請求多次訪問中保證只調用一次這個服務提供者的接口,在這同一次請求第一次的結果會被緩存,保證同一請求中同樣的多次訪問返回結果相同。
PS:在寫這篇文章之前,本人將Hystrix與Redis進行了類比,后來證明我是理解錯了。在認識到問題的情況下,我又重新為這篇文章重寫了正確的代碼
正解:請求緩存不是只寫入一次結果就不再變化的,而是每次請求到達Controller的時候,我們都需要為HystrixRequestContext進行初始化,之前的緩存也就是不存在了,我們是在同一個請求中保證結果相同,同一次請求中的第一次訪問后對結果進行緩存,緩存的生命周期只有一次請求!
這里分別介紹使用繼承和使用注解兩種方式,這里使用前文用到的RibbonConsumHystix項目
1. 1繼承方式
1.1.1 開啟請求緩存 與 清除請求緩存
在com.cnblogs.hellxz.hystrix包下,因為和UserCommand類中的返回值不同,為了不破壞已有代碼,我們在hystrix新建一個CacheCommand類,如下:
package com.cnblogs.hellxz.hystrix;
import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandKey;
import com.netflix.hystrix.HystrixRequestCache;
import com.netflix.hystrix.strategy.concurrency.HystrixConcurrencyStrategyDefault;
import org.springframework.web.client.RestTemplate;
/**
* <p><b>描 述</b>: 請求緩存HystrixCommand</p>
*
* <p><b>創建日期</b> 2018/5/18 10:26 </p>
*
* @author HELLXZ 張
* @version 1.0
* @since jdk 1.8
*/
public class CacheCommand extends HystrixCommand<Integer> {
private RestTemplate restTemplate;
private static Long id;
public CacheCommand(Setter setter, RestTemplate restTemplate, Long id){
super(setter);
this.restTemplate = restTemplate;
this.id = id;
}
/**
* 這里我們調用產生隨機數的接口
*/
@Override
protected Integer run() throws Exception {
return restTemplate.getForObject("http://eureka-service/hystrix/cache",Integer.class);
}
/**
* 開啟請求緩存,只需重載getCacheKey方法
* 因為我們這里使用的是id,不同的請求來請求的時候會有不同cacheKey所以,同一請求第一次訪問會調用,之后都會走緩存
* 好處: 1.減少請求數、降低並發
* 2.同一用戶上下文數據一致
* 3.這個方法會在run()和contruct()方法之前執行,減少線程開支
*/
@Override
public String getCacheKey() {
return String.valueOf(id); //這不是唯一的方法,可自定義,保證同一請求返回同一值即可
}
/**
* 清理緩存
* 開啟請求緩存之后,我們在讀的過程中沒有問題,但是我們如果是寫,那么我們繼續讀之前的緩存了
* 我們需要把之前的cache清掉
* 說明 : 1.其中getInstance方法中的第一個參數的key名稱要與實際相同
* 2.clear方法中的cacheKey要與getCacheKey方法生成的key方法相同
* 3.注意我們用了commandKey是test,大家要注意之后new這個Command的時候要指定相同的commandKey,否則會清除不成功
*/
public static void flushRequestCache(Long id){
HystrixRequestCache.getInstance(
HystrixCommandKey.Factory.asKey("test"), HystrixConcurrencyStrategyDefault.getInstance())
.clear(String.valueOf(id));
}
public static Long getId() {
return id;
}
}
說明一下,使用繼承的方式,只需要重寫getCacheKey(),有了開啟緩存自然有清除緩存的方法,用以確保我們在同一請求中進行寫操作后,讓后續的讀操作獲取最新的結果,而不是過時的結果。
需要注意的地方:
1.flushRequestCache(Long id),其中.clear()中的cacheKey的生成方法相同,只有把正確需要清除的key清掉才會連同value一同清掉,從而達到清除緩存的作用。
2.清除緩存時機:我們應該在同一個Controller中進行寫操作之后,如果這個操作之后還有訪問同一資源的請求,那么必須加清除緩存,從而保證數據同步,如果后面沒有讀操作,無須清除緩存,因為在下一次請求到來的時候HystrixRequestContext會重置,緩存自然也沒有了
為了更好的演示,這里擴充一下RibbonService,添加如下代碼:
/**
* 繼承方式開啟請求緩存,注意commandKey必須與清除的commandKey一致
*/
public void openCacheByExtends(){
CacheCommand command1 = new CacheCommand(com.netflix.hystrix.HystrixCommand.Setter.withGroupKey(
HystrixCommandGroupKey.Factory.asKey("group")).andCommandKey(HystrixCommandKey.Factory.asKey("test")),
restTemplate,1L);
CacheCommand command2 = new CacheCommand(com.netflix.hystrix.HystrixCommand.Setter.withGroupKey(
HystrixCommandGroupKey.Factory.asKey("group")).andCommandKey(HystrixCommandKey.Factory.asKey("test")),
restTemplate,1L);
Integer result1 = command1.execute();
Integer result2 = command2.execute();
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
}
/**
* 繼承方式清除請除緩存
*/
public void clearCacheByExtends(){
CacheCommand.flushRequestCache(1L);
LOGGER.info("請求緩存已清空!");
}
在RibbonController添加如下代碼,設計實驗:
/**
* 繼承方式開啟請求緩存,並多次調用CacheCommand的方法
* 在兩次請求之間加入清除緩存的方法
*/
@GetMapping("/cacheOn")
public void openCacheTest(){
//初始化Hystrix請求上下文
HystrixRequestContext.initializeContext();
//開啟請求緩存並測試兩次
service.openCacheByExtends();
//清除緩存
service.clearCacheByExtends();
//再次開啟請求緩存並測試兩次
service.openCacheByExtends();
}
注意:之前說過,每次Controller被訪問的時候,Hystrix請求的上下文都需要被初始化,這里可以用這種方式作測試,但是生產環境是用filter的方式初始化的,這種方式放到請求緩存的結尾講
分別啟動注冊中心、服務提供者、RibbonConsumHystrix(當前項目)
使用postman get 請求訪問:http://localhost:8088/hystrix/cacheOn
我們會看到有以下輸出:
2018-05-18 12:41:42.274 INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService : first request result is:63829 ,and secend request result is: 63829
2018-05-18 12:41:42.274 INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService : 請求緩存已清空!
2018-05-18 12:41:42.281 INFO 1288 --- [nio-8088-exec-1] c.cnblogs.hellxz.servcie.RibbonService : first request result is:65775 ,and secend request result is: 65775
達到目的,接下來我們講講注解的方式!
1.2 注解方式
繼承方式自然沒有注解開發快而且省力,想必大家期待已久了,在此之前我們需要了解三個注解:
| 注解 | 描述 | 屬性 |
|---|---|---|
| @CacheResult | 該注解用來標記請求命令返回的結果應該被緩存,它必須與@HystrixCommand注解結合使用 | cacheKeyMethod |
| @CacheRemove | 該注解用來讓請求命令的緩存失效,失效的緩存根據commandKey進行查找。 | commandKey,cacheKeyMethod |
| @CacheKey | 該注解用來在請求命令的參數上標記,使其作為cacheKey,如果沒有使用此注解則會使用所有參數列表中的參數作為cacheKey | value |
本人實測總結三種注解方式均可用,實現大同小異,與大家分享之
1.2.1 方式1 :使用getCacheKey方法獲取cacheKey
擴充RibbonService
/**
* 使用注解請求緩存 方式1
* @CacheResult 標記這是一個緩存方法,結果會被緩存
*/
@CacheResult(cacheKeyMethod = "getCacheKey")
@HystrixCommand(commandKey = "commandKey1")
public Integer openCacheByAnnotation1(Long id){
//此次結果會被緩存
return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
}
/**
* 使用注解清除緩存 方式1
* @CacheRemove 必須指定commandKey才能進行清除指定緩存
*/
@CacheRemove(commandKey = "commandKey1", cacheKeyMethod = "getCacheKey")
@HystrixCommand
public void flushCacheByAnnotation1(Long id){
LOGGER.info("請求緩存已清空!");
//這個@CacheRemove注解直接用在更新方法上效果更好
}
/**
* 第一種方法沒有使用@CacheKey注解,而是使用這個方法進行生成cacheKey的替換辦法
* 這里有兩點要特別注意:
* 1、這個方法的入參的類型必須與緩存方法的入參類型相同,如果不同被調用會報這個方法找不到的異常
* 2、這個方法的返回值一定是String類型
*/
public String getCacheKey(Long id){
return String.valueOf(id);
}
擴充RibbonController
/**
* 注解方式請求緩存,第一種
*/
@GetMapping("/cacheAnnotation1")
public void openCacheByAnnotation1(){
//初始化Hystrix請求上下文
HystrixRequestContext.initializeContext();
//訪問並開啟緩存
Integer result1 = service.openCacheByAnnotation1(1L);
Integer result2 = service.openCacheByAnnotation1(1L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
//清除緩存
service.flushCacheByAnnotation1(1L);
//再一次訪問並開啟緩存
Integer result3 = service.openCacheByAnnotation1(1L);
Integer result4 = service.openCacheByAnnotation1(1L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
}
測試
使用postman get 請求訪問 http://localhost:8088/hystrix/cacheAnnotation1
查看輸出
2018-05-18 15:39:11.971 INFO 4180 --- [nio-8088-exec-5] o.s.web.bind.annotation.RestController : first request result is:59020 ,and secend request result is: 59020
2018-05-18 15:39:11.972 INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService : 請求緩存已清空!
2018-05-18 15:39:11.979 INFO 4180 --- [nio-8088-exec-5] o.s.web.bind.annotation.RestController : first request result is:51988 ,and secend request result is: 51988
測試通過!
1.2.2 方式2 :使用@CacheKey指定cacheKey
擴充RibbonService
/**
* 使用注解請求緩存 方式2
* @CacheResult 標記這是一個緩存方法,結果會被緩存
* @CacheKey 使用這個注解會把最近的參數作為cacheKey
*
* 注意:有些教程中說使用這個可以指定參數,比如:@CacheKey("id") , 但是我這么用會報錯,網上只找到一個也出這個錯誤的貼子沒解決
* 而且我發現有一個問題是有些文章中有提到 “不使用@CacheResult,只使用@CacheKey也能實現緩存” ,經本人實測無用
*/
@CacheResult
@HystrixCommand(commandKey = "commandKey2")
public Integer openCacheByAnnotation2(@CacheKey Long id){
//此次結果會被緩存
return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
}
/**
* 使用注解清除緩存 方式2
* @CacheRemove 必須指定commandKey才能進行清除指定緩存
*/
@CacheRemove(commandKey = "commandKey2")
@HystrixCommand
public void flushCacheByAnnotation2(@CacheKey Long id){
LOGGER.info("請求緩存已清空!");
//這個@CacheRemove注解直接用在更新方法上效果更好
}
擴充RibbonController
/**
* 注解方式請求緩存,第二種
*/
@GetMapping("/cacheAnnotation2")
public void openCacheByAnnotation2(){
//初始化Hystrix請求上下文
HystrixRequestContext.initializeContext();
//訪問並開啟緩存
Integer result1 = service.openCacheByAnnotation2(2L);
Integer result2 = service.openCacheByAnnotation2(2L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
//清除緩存
service.flushCacheByAnnotation2(2L);
//再一次訪問並開啟緩存
Integer result3 = service.openCacheByAnnotation2(2L);
Integer result4 = service.openCacheByAnnotation2(2L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
}
測試
使用postman get 請求訪問 http://localhost:8088/hystrix/cacheAnnotation2
查看輸出
2018-05-18 15:40:49.803 INFO 4180 --- [nio-8088-exec-6] o.s.web.bind.annotation.RestController : first request result is:47604 ,and secend request result is: 47604
2018-05-18 15:40:49.804 INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService : 請求緩存已清空!
2018-05-18 15:40:49.809 INFO 4180 --- [nio-8088-exec-6] o.s.web.bind.annotation.RestController : first request result is:34083 ,and secend request result is: 34083
測試通過!
1.2.3 方式3 :使用默認所有參數作為cacheKey
擴充RibbonService
/**
* 使用注解請求緩存 方式3
* @CacheResult 標記這是一個緩存方法,結果會被緩存
* @CacheKey 使用這個注解會把最近的參數作為cacheKey
*
* 注意:有些教程中說使用這個可以指定參數,比如:@CacheKey("id") , 但是我這么用會報錯,網上只找到一個也出這個錯誤的貼子沒解決
* 而且我發現有一個問題是有些文章中有提到 “不使用@CacheResult,只使用@CacheKey也能實現緩存” ,經本人實測無用
*/
@CacheResult
@HystrixCommand(commandKey = "commandKey3")
public Integer openCacheByAnnotation3(Long id){
//此次結果會被緩存
return restTemplate.getForObject("http://eureka-service/hystrix/cache", Integer.class);
}
/**
* 使用注解清除緩存 方式3
* @CacheRemove 必須指定commandKey才能進行清除指定緩存
*/
@CacheRemove(commandKey = "commandKey3")
@HystrixCommand
public void flushCacheByAnnotation3(Long id){
LOGGER.info("請求緩存已清空!");
//這個@CacheRemove注解直接用在更新方法上效果更好
}
擴充RibbonController
/**
* 注解方式請求緩存,第三種
*/
@GetMapping("/cacheAnnotation3")
public void openCacheByAnnotation3(){
//初始化Hystrix請求上下文
HystrixRequestContext.initializeContext();
//訪問並開啟緩存
Integer result1 = service.openCacheByAnnotation3(3L);
Integer result2 = service.openCacheByAnnotation3(3L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result1, result2);
//清除緩存
service.flushCacheByAnnotation3(3L);
//再一次訪問並開啟緩存
Integer result3 = service.openCacheByAnnotation3(3L);
Integer result4 = service.openCacheByAnnotation3(3L);
LOGGER.info("first request result is:{} ,and secend request result is: {}", result3, result4);
}
測試
使用postman get 請求訪問 http://localhost:8088/hystrix/cacheAnnotation3
查看輸出
2018-05-18 15:41:19.655 INFO 4180 --- [nio-8088-exec-8] o.s.web.bind.annotation.RestController : first request result is:24534 ,and secend request result is: 24534
2018-05-18 15:41:19.656 INFO 4180 --- [ibbonService-10] c.cnblogs.hellxz.servcie.RibbonService : 請求緩存已清空!
2018-05-18 15:41:19.662 INFO 4180 --- [nio-8088-exec-8] o.s.web.bind.annotation.RestController : first request result is:85409 ,and secend request result is: 85409
測試通過!
1.4 出現的問題
1.4.1 HystrixRequestContext 未初始化
2018-05-17 16:57:22.759 ERROR 5984 --- [nio-8088-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.netflix.hystrix.exception.HystrixRuntimeException: UserCommand failed while executing.] with root cause
java.lang.IllegalStateException: Request caching is not available. Maybe you need to initialize the HystrixRequestContext?
at com.netflix.hystrix.HystrixRequestCache.get(HystrixRequestCache.java:104) ~[hystrix-core-1.5.12.jar:1.5.12]
……省略多余輸出……
初始化HystrixRequestContext方法:
兩種方法
1、在每個用到請求緩存的Controller方法的第一行加上如下代碼:
//初始化Hystrix請求上下文
HystrixRequestContext context = HystrixRequestContext.initializeContext();
//省略中間代碼上下文環境用完需要關閉
context.close();
2、使用Filter方式:
在啟動類加入@ServletComponentScan注解
在con.cnblogs.hellxz.filter包下創建HystrixRequestContextServletFilter.java,實現Filter接口,在doFilter方法中添加方法1中的那一行代碼,並在一次請求結束后關掉這個上下文
package com.cnblogs.hellxz.filter;
import com.netflix.hystrix.strategy.concurrency.HystrixRequestContext;
import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import java.io.IOException;
/**
* <b>類名</b>: HystrixRequestContextServletFilter
* <p><b>描 述</b>: 實現Filter用於初始化Hystrix請求上下文環境</p>
*
* <p><b>創建日期</b>2018/5/18 16:13</p>
* @author HELLXZ 張
* @version 1.0
* @since jdk 1.8
*/
@WebFilter(filterName = "hystrixRequestContextServletFilter",urlPatterns = "/*",asyncSupported = true)
public class HystrixRequestContextServletFilter implements Filter {
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
//初始化Hystrix請求上下文
HystrixRequestContext context = HystrixRequestContext.initializeContext();
try {
//請求正常通過
chain.doFilter(request, response);
} finally {
//關閉Hystrix請求上下文
context.shutdown();
}
}
@Override
public void init(FilterConfig filterConfig) throws ServletException {
}
@Override
public void destroy() {
}
}
此時注釋掉RibbonController中每個Controller方法中的HystrixRequestContext.initializeContext();(不注掉也沒事)
重啟RibbonConsumHystrix項目,訪問其中用到請求緩存的接口http://localhost:8088/hystrix/cacheAnnotation1
查看輸出
2018-05-18 16:17:36.002 INFO 7268 --- [nio-8088-exec-4] o.s.web.bind.annotation.RestController : first request result is:35329 ,and secend request result is: 35329
2018-05-18 16:17:36.005 INFO 7268 --- [RibbonService-8] c.cnblogs.hellxz.servcie.RibbonService : 請求緩存已清空!
2018-05-18 16:17:36.013 INFO 7268 --- [nio-8088-exec-4] o.s.web.bind.annotation.RestController : first request result is:88678 ,and secend request result is: 88678
一切正常!
結語
通過這篇文章我們學習了Hystrix的請求緩存的使用,在寫本文過程中糾正了很多只看書學到的錯誤知識,並不是說書中寫錯了,可能是spring cloud的不同版本所造成的問題,所以,學習還是推薦大家動手實踐。受限於篇幅的限制,本來是想把請求合並一並寫出來的,想了下暫時請求合並的代碼我還沒有測試通過,所以,綜上所述,請求合並部分,我會在下篇文章中寫。可能不會快,但一定會有。
