Netty運(yùn)用Reactor模式到極致
點(diǎn)擊上方「藍(lán)字」關(guān)注我們
常見的reactor模式有以下三種
單線程reactor
多線程reactor
主從reactor
0x01、單線程reactor
ractor 單線程模式是指所有的I/O操作都在一個(gè)NIO線程完成，該線程的職責(zé)：
1.作為NIO服務(wù)端，接收客戶端TCP連接
2.作為NIO客戶端，向客戶端發(fā)送TCP連接
3.READ/WRITE?客戶端的請(qǐng)求
?不過單線程的reactor 模式無法發(fā)揮多核的優(yōu)勢(shì)，因此對(duì)于高并發(fā)量的系統(tǒng)仍然存在瓶頸，主要原因如下：
1、reactor 線程既要處理來自客戶端的連接，又要處理READ/WRITE/編碼/解碼。即便cpu 100%?也難以滿足實(shí)際場景的需求
多線程Reactor?解決了這些問題
?
0x02、多線程reactor模型
reactor?多線程的實(shí)現(xiàn)最大的區(qū)別是擁有一個(gè)專門用來處理實(shí)際I/O?操作是線程池
優(yōu)點(diǎn)：
1、擁有一個(gè)Acceptor?專門用來監(jiān)聽請(qǐng)求的I/O?類型
2、使用專門線程池可以提高acceptor的并發(fā)量，并且可以將同一個(gè)SocketChannel?放于同一個(gè)I/O?線程處理，同一個(gè)I/O線程可以處理多個(gè)SocketChannel的READ/WRITE事件
在大部分場景，該線程模型都能處理，但存在這樣一種場景：單個(gè)Acceptor 線程?可能會(huì)因?yàn)樾枰O(jiān)聽大量的 SocketChannel 連接 或 I/O事件處理或在建立建立時(shí)需要進(jìn)行安全的握手認(rèn)證、黑白名單過濾，而導(dǎo)致出現(xiàn)性能瓶頸。所以這種場景下，單獨(dú)一個(gè)Accceptor 會(huì)導(dǎo)致性能不足，便出現(xiàn)了第三種線程模型，主從Reactor 模型
?
0x03、主從reactor 多線程模型
相比多線程reactor模型，主從reactor多線程模型擁有了一個(gè)獨(dú)立處理 SocketChannel 連接的線程池，當(dāng)客戶端從Acceptor建立連接之后，便將該連接綁定到subreactor 線程池中的某個(gè)線程中，然后由該線程綁定客戶端感興趣的I/O事件（READ/WRITE），監(jiān)聽客戶端連接請(qǐng)求，最后處理。
mainReactor :?監(jiān)聽 ServerSocketChannel 、建立與 SocketChannel? 的連接、將完成建立連接之后的Socket?交給subReactor
subReactor :?監(jiān)聽SocketChannel的 I/O事件，完成編解碼、相應(yīng)的業(yè)務(wù)處理（默認(rèn)為CPU個(gè)數(shù)）
Netty運(yùn)用Reactor模式到極致，Netty支持以上三種Reactor線程模型。通過在啟動(dòng)輔助類中創(chuàng)建不同的EventLoopGroup實(shí)例并通過適當(dāng)?shù)膮?shù)配置，就可以支持。正是因?yàn)镹etty 對(duì)Reactor線程模型的支持提供了靈活的定制能力，所以可以滿足不同業(yè)務(wù)場景的性能訴求。
看了這本書，也不是很厚，如果想了解Netty的不妨看看。
掃碼二維碼
獲取更多精彩
Java樂園
