事件驅(qū)動和請求響應模式有什么區(qū)別？這兩樣東西的層次不同，不適合比較。操作系統(tǒng)對設(shè)備進行抽象后，將設(shè)備分為塊設(shè)備和流設(shè)備，通過中斷處理相應的IO事件。為了降低上下文切換的成本，一般操作系統(tǒng)都會嘗試將IO

事件驅(qū)動和請求響應模式有什么區(qū)別？

這兩樣東西的層次不同，不適合比較。操作系統(tǒng)對設(shè)備進行抽象后，將設(shè)備分為塊設(shè)備和流設(shè)備，通過中斷處理相應的IO事件。為了降低上下文切換的成本，一般操作系統(tǒng)都會嘗試將IO事件綁定到CPU上進行處理。典型的事件處理框架，如poll、epoll等，大多在內(nèi)核中進行優(yōu)化，實現(xiàn)無阻塞，充分利用DMA，減少內(nèi)存拷貝，提高效率。為用戶提供同步或異步調(diào)用接口。進一步優(yōu)化Epoll，為異步調(diào)用提供水平觸發(fā)器或邊緣觸發(fā)器支持，減少用戶調(diào)用次數(shù)。這種編程模式主要基于事件啟動模型。

許多流協(xié)議，如TCP、HTTP等，它們的編解碼器實際上是基于非阻塞異步事件驅(qū)動的。與HTTP協(xié)議一樣，它本質(zhì)上是一個請求-響應協(xié)議。解析請求時，上層應用程序需要對其進行處理。此時，框架需要考慮是向用戶提供同步回調(diào)接口還是異步回調(diào)接口。這與用戶的線程管理策略有很大關(guān)系。如果提供了同步回調(diào)，則用戶可以通過單個線程處理請求，并通過調(diào)用阻塞IO接口來操作數(shù)據(jù)。但這種處理方法效率低，擴展性差。半同步和半異步通信框架就是指這種類型。建立鏈接，異步解析底層協(xié)議，然后將其轉(zhuǎn)換為與用戶的同步回調(diào)接口。大多數(shù)HTTP服務器都這樣做。

另一種方式稱為主動完全異步模式。用戶必須使用非阻塞系統(tǒng)調(diào)用，任何阻塞調(diào)用都將是災難。用戶必須處理數(shù)據(jù)是否足以進行下一個協(xié)議解析或請求處理。當數(shù)據(jù)不足時，書簽處于當前處理狀態(tài)，并切換到下一個帶有數(shù)據(jù)事件的請求進行處理。這個處理線程可以處理多個甚至所有的請求，基本上沒有線程切換或掛起。少數(shù)需要非常高性能、采用主動全異步模式的HTTP服務器對應用端開發(fā)異步應用也有很高的要求。