高併發下的耗時操作

高併發下，就是請求在一個時間點比較多時，很多寫的請求打過來時，你的伺服器承受很大的壓力，當你的一個請求處理時間長時，這些請求將會把你的伺服器執行緒耗盡，即你的主執行緒池裡的執行緒將不會再有空閒狀態的，再打過來的請求，將會是502了。加 q群：478052716 免費領取（Java架構資料，影片資料，BATJ面試資料）

請求流程圖

http1 http2 http3
thread1 thread2 thread3

解決方案

使用 DeferredResult 來實現非同步的操作，當一個請求打過來時，先把它放到一個佇列時，然後在後臺有一個訂閱者，有相關主題的訊息發過來時，這個訂閱者就去消費它，這一步可以是分散式的，比如一個秒殺場景，當N多的請求打過來時，有一些請求命中後，它們進行寫操作，這時寫操作壓力很大，1個請求可以要處理3秒，對於高併發場景這是不能容許的，因為你這樣佔用的伺服器執行緒資源太長了，很快你的伺服器就沒有可用的執行緒資源了，這時就可以用到DeferredResult這處理。

程式碼實現

建立訂單的介面，只負責簡單的校驗和事件的釋出

/**
 * 非同步建立高併發的訂單.
 *
 * @return
 */
 @GetMapping("/create-order")
 public DeferredResult<Object> createOrder() {
 DeferredResult<Object> deferredResult = new DeferredResult<>((long) 3000, "error order");
 logger.info("釋出建立訂單的事件");
 applicationEventPublisher.publishEvent(deferredResult);
 return deferredResult;
 }

非同步的訂單處理核心邏輯，也是耗時的操作

@Component
@EnableAsync
public class OrderListener {
 static Logger logger = LoggerFactory.getLogger(OrderListener.class);
 /**
 * 事實上它是一個訂單佇列的消費者，在後臺寫訂單，本例使用簡單的事件監聽器實現非同步處理的功能.
 *
 * @return
 */
 @EventListener
 @Async
 public String processOrder(DeferredResult<Object> deferredResult) throws InterruptedException {
 logger.info("處理訂單並返回到對應的Http上下文");
 String order = UUID.randomUUID().toString();
 Thread.sleep(2000);//假設處理資料需要5秒，前端需要阻塞5秒，但http主執行緒已經釋放了，比較適合IO密集型場合
 //當設定之後，create-order將成功響應
 deferredResult.setResult(order);
 return order;
 }
}

測試結果

當請求/create-order後，伺服器在處理2秒後，返回結果，而spring後臺真正做的是，執行緒1在事件釋出後，它成為空閒狀態，其它請求可以複用它，當processOrder後臺處理結果後，spring又會用執行緒池中拿一個新的執行緒處理剩下的邏輯！

Springboot：高併發下耗時操作的實現

相關文章