API性能优化之异步
? ? ?很多時候為了達到SLA承諾(Service-Level Agreement)即為“服務水平承諾,我們需要拼命的優化我們的api的性能,其中最有效的便是異步了
異步和同步:
定義:同步和異步關注的是消息通信機制?(synchronous communication/ asynchronous communication)。
同步:一件事當成一件事做,順序執行;
異步:一件事當作多件事做,可以并行執行,或者干脆全部交給另一個人做,自己只負責告訴那個人一聲。
異步請求和同步請求:
同步請求:提交請求->等待服務器處理->處理完畢返回這個期間客戶端瀏覽器不能干任何事
異步請求: 請求通過事件觸發->服務器處理(這是瀏覽器仍然可以作其他事情)->處理完畢
可以先釋放容器分配給請求的線程與相關資源,減輕系統負擔,釋放了容器所分配線程的請求,其響應將被延后,可以在耗時處理完成(例如長時間的運算)時再對客戶端進行響應。一句話:增加了服務器對客戶端請求的吞吐量(實際生產上我們用的比較少,如果并發請求量很大的情況下,我們會通過nginx把請求負載到集群服務的各個節點上來分攤請求壓力,當然還可以通過消息隊列來做請求的緩沖)。
異步調用:
異步請求的處理。除了異步請求,一般上我們用的比較多的應該是異步調用。通常在開發過程中,會遇到一個方法是和實際業務無關的,沒有緊密性的。比如記錄日志信息等業務。這個時候正常就是啟一個新線程去做一些業務處理,讓主線程異步的執行其他業務。異步調用對于api調用的性能提升是十分顯著的,但是有一個缺陷,沒辦法等待api返回的數據,所以只能針對那些在后臺運行而不十分不要返回值的數據,或者在異步方法中再調用一個方法去主動往客戶端推送數據。
SpringBoot中異步調用的使用
- 需要在啟動類加入@EnableAsync使異步調用@Async注解生效
? ?在需要異步執行的方法上加入此注解即可@Async
測試:
可以看出,調用異步方法時,是立即返回的,基本沒有耗時。
注意事項
- 在默認情況下,未設置TaskExecutor時,默認是使用SimpleAsyncTaskExecutor這個線程池,但此線程不是真正意義上的線程池,因為線程不重用,每次調用都會創建一個新的線程。可通過控制臺日志輸出可以看出,每次輸出線程名都是遞增的。所以最好我們來自定義一個線程池。
自定義線程池
創建一個自定義的ThreadPoolTaskExecutor線程池:
此時,使用的是就只需要在@Async加入線程池名稱即可:
- 調用的異步方法,不能為同一個類的方法(包括同一個類的內部類),簡單來說,因為Spring在啟動掃描時會為其創建一個代理類,而同類調用時,還是調用本身的代理類的,所以和平常調用是一樣的。其他的注解如@Cache等也是一樣的道理,說白了,就是Spring的代理機制造成的。所以在開發中,最好把異步服務單獨抽出一個類來管理。下面會重點講述。
@Async異步失效
異步請求與異步調用的區別
- 兩者的使用場景不同,異步請求用來解決并發請求對服務器造成的壓力,從而提高對請求的吞吐量;而異步調用是用來做一些非主線流程且不需要實時計算和響應的任務,比如同步日志到kafka中做日志分析等。
- 異步請求是會一直等待response相應的,需要返回結果給客戶端的;而異步調用我們往往會馬上返回給客戶端響應,完成這次整個的請求,至于異步調用的任務后臺自己慢慢跑就行,客戶端不會關心。
調用同一個類下注有@Async異步方法:
在spring中像@Async和@Transactional、cache等注解本質使用的是動態代理,其實Spring容器在初始化的時候Spring容器會將含有AOP注解的類對象“替換”為代理對象(簡單這么理解),那么注解失效的原因就很明顯了,就是因為調用方法的是對象本身而不是代理對象,因為沒有經過Spring容器,那么解決方法也會沿著這個思路來解決。
將要異步執行的方法單獨抽取成一個類,原理就是當你把執行異步的方法單獨抽取成一個類的時候,這個類肯定是被Spring管理的,其他Spring組件需要調用的時候肯定會注入進去,這時候實際上注入進去的就是代理類了。其實我們的注入對象都是從Spring容器中給當前Spring組件進行成員變量的賦值,由于某些類使用了AOP注解,那么實際上在Spring容器中實際存在的是它的代理對象。那么我們就可以通過上下文獲取自己的代理對象調用異步方法
@Controller
@RequestMapping("/app")
public class EmailController {
?//獲取ApplicationContext對象方式有多種,這種最簡單,其它的大家自行了解一下
?@Autowired
?private ApplicationContext applicationContext;
??
??@RequestMapping(value = "/email/asyncCall", method = GET)
??@ResponseBody
??public Map<String, Object> asyncCall () {
????Map<String, Object> resMap = new HashMap<String, Object>();
????try{
??//這樣調用同類下的異步方法是不起作用的
??????//this.testAsyncTask();
??//通過上下文獲取自己的代理對象調用異步方法
???EmailController emailController = (EmailController)applicationContext.getBean(EmailController.class);
???emailController.testAsyncTask();
??????resMap.put("code",200);
????}catch (Exception e) {
??resMap.put("code",400);
??????logger.error("error!",e);
????}
????return resMap;
??}
?//注意一定是public,且是非static方法
?@Async
??public void testAsyncTask() throws InterruptedException {
????Thread.sleep(10000);
????System.out.println("異步任務執行完成!");
??}
}
開啟cglib代理,手動獲取Spring代理類,從而調用同類下的異步方法。
首先,在啟動類上加上@EnableAspectJAutoProxy(exposeProxy = true)注解。
代碼實現,如下:
@Service
@Transactional(value = "transactionManager", readOnly = false, propagation = Propagation.REQUIRED, rollbackFor = Throwable.class)
public class EmailService {
??@Autowired
??private ApplicationContext applicationContext;
??@Async
??public void testSyncTask() throws InterruptedException {
????Thread.sleep(10000);
????System.out.println("異步任務執行完成!");
??}
??public void asyncCallTwo() throws InterruptedException {
????//this.testSyncTask();
//??? EmailService emailService = (EmailService)applicationContext.getBean(EmailService.class);
//??? emailService.testSyncTask();
????boolean isAop = AopUtils.isAopProxy(EmailController.class);//是否是代理對象;
????boolean isCglib = AopUtils.isCglibProxy(EmailController.class); //是否是CGLIB方式的代理對象;
????boolean isJdk = AopUtils.isJdkDynamicProxy(EmailController.class); //是否是JDK動態代理方式的代理對象;
????//以下才是重點!!!
?EmailService emailService = (EmailService)applicationContext.getBean(EmailService.class);
????EmailService proxy = (EmailService) AopContext.currentProxy();
????System.out.println(emailService == proxy ? true : false);
????proxy.testSyncTask();
????System.out.println("end!!!");
??}
}
參考資料:https://www.jb51.net/article/159256.htm
https://www.cnblogs.com/baixianlong/p/10661591.html
https://blog.csdn.net/Dongguabai/article/details/80782081
總結
以上是生活随笔為你收集整理的API性能优化之异步的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 「数据库系列杂谈」数据库访问性能优化
- 下一篇: 数据分析入门(第一课)