在提到高性能服務(wù)器編程的時候肯定有聽過reactor模式，如果只是簡單的寫一個服務(wù)器和客戶端建立連接的程序來熟悉一下使用socket函數(shù)編程，一般這種情況都是同步方式實現(xiàn)的，服務(wù)器阻塞等待客戶端的連接，期間服務(wù)器不能做其他事情。是不是有更好的實現(xiàn)方式，讓服務(wù)器可以提高效率，這就是反應(yīng)堆模式要做的。

• 同步方式

? ? ? ? ? 之前也說了，同步方式是在阻塞等待，會浪費大量的服務(wù)器資源，效率不高，如果還不是多線程的話就更加的糟糕，當(dāng)你在連接下載小視頻的時候，別人就下不了（連連接請求都會被服務(wù)器忽視），別人就很氣。是很簡單的單線連接。

• 多線程方式

? ? ? ? ?那么為了處理多個客戶端的連接請求，為每個連接過來的客戶端單獨開出一個線程進(jìn)行處理（這里提到的多個線程中的每個線程 都是同步方式實現(xiàn)的），每個線程中的每個操作都是阻塞的直到完成。就拿其優(yōu)點來說，每個線程之間是比較獨立的，可以接受不同的請求執(zhí)行不同的操作，并且由于是同步的方式，對于開發(fā)者來說開發(fā)也比較簡單（可以盡情地使用順序操作和阻塞操作）。

缺點也比較明顯：

1.在多線程下使用同步方式是需要加鎖的！總要有點難度，要想使用共享資源就需要對這方面用點心；

2.這么多線程再切換的時候開銷是不能忽略不計的；

3.移植性不高，因為有的機(jī)子不支持多線程。

下圖就是多線程實現(xiàn)的一個web服務(wù)器的圖例

當(dāng)服務(wù)器開有多個線程，每個線程都相當(dāng)于一個同步方式實現(xiàn)的web服務(wù)器（就上面說的那種），這樣看似可以同時接收多個瀏覽器的請求，但是實則可供連接的數(shù)目是固定的，你開了多少個線程就能給多少個瀏覽器連接，如果需要增加同時連接的瀏覽器的數(shù)量，只能再多加幾個線程。同步的一些缺點也依然沒有解決。

• 反應(yīng)器模式(reactor)

反應(yīng)器模式聽起來名字高大上，簡單的來講就是select、poll、epoll的使用搭建出一個異步方式的web服務(wù)器，這里的異步通俗的講就是，當(dāng)服務(wù)器在等待瀏覽器連接請求的時候是自由的，不是阻塞的（同步是阻塞等待的），服務(wù)器可以干別的事情，當(dāng)有瀏覽器的連接請求的時候，服務(wù)器被通知，執(zhí)行回調(diào)函數(shù)來建立起連接。下面是一個反應(yīng)堆模式實現(xiàn)的web服務(wù)器的圖例，分別是連接請求和文件傳輸請求的web服務(wù)器

?

HTTPHandle是事件處理器，主要負(fù)責(zé)事件來臨之后進(jìn)行的操作，Initiation Dispatcher核心就是用select、poll、epoll實現(xiàn)的，當(dāng)有請求到達(dá)Initiation Dispacher會通知http handler數(shù)據(jù)到來，應(yīng)該去讀去解析了，基本是http handle主纜了大部分的工作

缺點就是可能對于http handle來說處理的事務(wù)略多會影響一部分性能并且過于冗雜（就是說太重了），讀寫操作內(nèi)部本身還是同步的，在讀寫的過程中會浪費大量時間（畢竟讀寫比較慢），和之前的前攝器模式的那篇文章作對比來說，前攝器就是把讀寫操作讓給操作系統(tǒng)來做，減少時間浪費，把自身解放出來做其他事情，這就是前攝器和反應(yīng)堆最大的差距。

參考資料：http://www.kuqin.com/ace-2002-12/Part-One/Chapter-8.htm
?

?

?

?

?

?

?

?

?

?

總結(jié)

以上是生活随笔為你收集整理的反应堆模式(reactor)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。