爲什麼在爲非HTTP服務器讀取套接字時需要Async IO

Question

我正在設計一個C++客戶端應用程序，它偵聽多個端口以獲取短消息流。在閱讀ACE，POCO，boost :: asio和所有Proactor之類的設計模式之後，我即將開始使用boost :: asio。

有一件事我注意到它是使用異步套接字IO的一個常量主題，但還沒有閱讀異步io解決的好問題描述。所有這些設計模式都基於HTTP Web服務器設計的假設嗎？由於網絡服務器是複雜的延遲敏感的併發套接字編程最常見的應用程序，我開始懷疑大部分這些模式/習語是否適合這一個應用程序。

我的應用程序將收聽少數幾個插座，以獲取短而頻繁的消息。一個單獨的線程將需要組合所有消息進行處理。我正在研究設計模式的一件事是將連接管理與數據處理分開。我希望有連接在斷開連接後嘗試重新連接，並讓處理線程繼續，如同沒有任何事情發生。這裏推薦什麼設計模式？

我沒有看到async io在我的情況下如何提高性能。

Answer 1

你在正確的軌道上。特別是在異步和事件驅動的所有宣傳中，詢問「爲什麼」是明智的。除了Web以外，還有其他應用程序。考慮消息隊列和金融交易，如高頻交易。基本上任何時候，等待費用或失去爲客戶提供服務的機會都是異步的候選人。網絡是一個很好的例子，因爲網絡比數據庫要快得多。一如既往，問「這是否有意義」爲您的應用程序。如果你沒有從中受益，異步增加了很多複雜性。

如果消息之間的平均時間與處理每條消息所需的時間相差無幾，尤其是在處理包含持久性的情況下，您的簡短快速消息實際上可能會從異步獲益。但是你不必急於進入異步。檢查你的阻止代碼，看看你是否真的有瓶頸。

我希望這會有所幫助。

Answer 2

使用阻塞調用模式將需要：

1. Listening on a socket vector of size N 
2. When a message arrives, you wake up with a start in time K, find and start processing the message, employing a time T (it does not matter if the processing is offloaded to another thread: in this case T becomes your offloading time) 
3. You finish examining the vector and GOTO 1 

所以，你可能會說，如果M郵件到達，並在K + M * T調度時間的另一個消息到達時，M + 1個消息會發現自己在等待K + M * T時間。這是否可以接受你的K（常數），M（交通功能）和T（資源和系統負荷的功能）的期望值？

異步處理，實際上並不存在。總是會有一個「同步」的IO迴路，只有它會很好地集成在內核（甚至是硬件）中，它會比你自己的速度快10-100倍，因此可能會更好地擴展M的值很大。延遲的形式仍然是K1 + M * T1，但是這次K1和T1要低得多。或者，也許K1稍高一些，T1明顯較低：對於大數值的M，架構「可以更好地擴展」。

如果M的值通常很低，那麼異步性的優勢就會比較小。在荒謬的情況下，當您在應用程序生命週期中只有一條消息時，同步或異步使得幾乎沒有區別。

考慮到另一個因素：如果消息的數量變得非常大，異步性有其優勢;但是如果消息本身是獨立的（由消息A引起的變化不影響消息B的處理），那麼你可以保持同步並且水平地縮放，準備數量爲Z的「消息集中器」，每個消息集中器接收分數M/Z的總流量。

如果處理過程需要對其他服務執行其他調用（緩存，持久性，信息檢索，認證...），增加T因子，那麼轉向多線程甚至異步就會更好。使用多線程技術，您可以將T刮至其價值的一小部分（僅限調度時間）。從某種意義上來說，異步處理是一樣的，但是更多的是剃鬚，並且爲您處理更多的編程樣板文件。