前言

并發(fā)問題可以理解為兩個問題

• 并發(fā)連接數(shù)，就是支持同時接受多少客戶端TCP連接
• 并發(fā)請求數(shù)，每秒能處理多少請求

Swoole底層基于epoll，所以第一個問題在Swoole擴展中實際上不存在任何問題。使用Swoole可以輕松應對10萬甚至100萬長連接。開發(fā)者唯一需要做的就是修改

ulimit -n

將系統(tǒng)最大文件描述符改為 10萬或更大。

不同的模型每秒能處理多少請求數(shù)，這個是應用層需要考慮的問題。而且不同的場景下有些模式無法使用。真正的難題就是在這里。實際上

工具永遠是死的，而人是活的。

再復雜艱難的場景也阻擋不了聰明的工程師。合理利用Swoole提供的各項功能可以巧妙解決各種難題。

第一 Worker同步阻塞

這個模式的使用方法：

• swoole_server設置為SWOOLE_PROCESS
• 只使用Worker進程
• 根據(jù)不同的情況設置worker_num的數(shù)值
• 設置dispatch_mode參數(shù)為1或3
• Worker進程內(nèi)使用同步阻塞的代碼編寫方式，這里不使用任何異步IO接口

這個模式的瓶頸就在與onRequest或onReceive里代碼邏輯的處理速度。按照快慢可以分為幾種

1. 外網(wǎng)CURL調(diào)用。這個最慢，快的數(shù)百毫秒，慢的情況可能需要幾十秒
2. 內(nèi)網(wǎng)RPC或Http接口，這個取決與這個接口的速度
3. MySQL復雜查詢，一條SQL如果沒有索引可能需要幾百毫秒，甚至幾秒或更長時間。而如果是主鍵查詢或者索引足夠有效可能只需要幾毫秒
4. Redis/Memcache，內(nèi)存數(shù)據(jù)庫局域網(wǎng)而且是長連接，調(diào)用一次可能只需要幾百微秒也就是0.x毫秒就能返回
5. 讀取磁盤文件，普通機械磁盤未命中PageCache引起磁盤尋道，可能需要幾十毫秒。SSD磁盤速度就快多了幾毫秒即可完成隨機讀取。
6. 內(nèi)存文件系統(tǒng)或共享內(nèi)存，讀取/tmp或/dev/shm下的共享文件本質(zhì)上是讀取共享內(nèi)存，僅需幾微妙到幾十微秒即可完成。如果是直接讀共享內(nèi)存可能更快，納秒級別。

進程數(shù)量

根據(jù)上面的IO耗時，設置適當?shù)倪M程數(shù)量即可。

• IO很慢就設置幾百個Worker進程，如操作MySQL、CURL、大量讀寫磁盤
• IO很快就可設置少量進程，如操作Redis、內(nèi)存文件系統(tǒng)、共享內(nèi)存

投遞模式

如果請求是無狀態(tài)的可以使用dispatch_mode=1或3，輪循投遞或者區(qū)分忙閑投遞。

長連接應用

比如聊天室，網(wǎng)絡游戲。連接之間需要交互的應用。 可以使用 MySQL/Redis/文件 存儲用戶的連接fd，分組信息。要向某個用戶發(fā)數(shù)據(jù)可以根據(jù)UID查出對應的fd，發(fā)送數(shù)據(jù)即可。發(fā)送分組，可以根據(jù)分阻ID查詢出fd列表，循環(huán)發(fā)送數(shù)據(jù)即可。

第二 Worker非阻塞+Task

這種模式是典型的同步+異步，復雜的業(yè)務邏輯使用同步阻塞在Task進程中處理，簡單要求高并發(fā)的邏輯使用異步非阻塞在Worker進程中處理。

使用方法

• 使用SWOOLE_PROCESS模式
• dispatch_mode 設置為2（默認就是2，可不做任何設置）
• worker_num 設置為CPU核數(shù)
• task_worker_num 根據(jù)業(yè)務邏輯的耗時情況進行設置，如果平均耗時較長，需要設置數(shù)百個進程，耗時較短可設置幾十個進程

Worker進程

在這個模式中，Worker進程不能有任何同步阻塞的操作，只處理請求響應或數(shù)據(jù)接收發(fā)送，僅進行PHP數(shù)組或?qū)ο蟛僮骰蚱渌嬎氵壿?。具體參考 模式3 Worker進程全異步。

Task進程

無狀態(tài)地處理任務，并返回結(jié)果。需要注意單個Task的執(zhí)行時間，避免處理時間太長導致Task排隊過多。

第三 Worker全異步

這個模式就是真正的異步非阻塞編程，在代碼中只能使用Swoole提供的異步非阻塞IO操作，不得執(zhí)行任何普通的PHP阻塞IO函數(shù)，如curl、mysql、redis、fsockopen、stream、socket、proc_open等。

與模式二 不同的是全異步服務器不使用Task進程，即使是很復雜的業(yè)務邏輯也在Worker進程中執(zhí)行。純異步編程需要對開發(fā)者要求較高。

使用方法

• dispatch_mode設置為2
• worker_num 設置為CPU核數(shù)

邏輯實現(xiàn)

Worker進程內(nèi)的PHP代碼只能進行下列3種操作：

• 使用swoole_redis、swoole_mysql、swoole_http_client、swoole_client+async操作
• 進行PHP數(shù)組、對象操作或其他內(nèi)存計算邏輯
• 使用swoole_server的send、push、close、response->end等操作

適用場景

• 長連接服務
• 對并發(fā)能力和吞吐量有較高要求
• 團隊開發(fā)者技術(shù)水平較高

弊端和解決方案

• 純異步需要使用嵌套回調(diào)的方式編寫代碼，與傳統(tǒng)的編程模式完全不同，異步是事件驅(qū)動式的，代碼不是順序執(zhí)行的。
• 異步嵌套回調(diào)的方式在程序邏輯復雜后會變得難以維護

可使用 Promise 或 Yield/Generator 簡化異步編程。

第四 Base模式+同步阻塞

Base模式是一個簡化版本，Base模式下Swoole的運行原理與Node.js完全一致，是單線程的。對TCP客戶端的Accept、Send、Recv、Close都是同一個進程內(nèi)操作的。

與Process同步阻塞模式不同的是BASE模式下Worker進程的調(diào)度由操作系統(tǒng)實現(xiàn)。因此可以實現(xiàn)一個Leader-Follower模式的服務器程序。

使用方法

• 使用SWOOLE_BASE模式
• worker_num根據(jù)邏輯代碼的耗時情況設置幾百或幾十
• worker進程內(nèi)使用同步阻塞IO操作

適用場景

• 適合短連接 & 請求響應式 服務，如Web服務、RPC服務
• 這種模式不能實現(xiàn)單連接并發(fā)，客戶端的連接被某個Worker進程Accept之后，只能在此進程內(nèi)處理請求

第五 Process

Process提供了對進程管理的封裝?；赑rocess可實現(xiàn)：

多進程+進程間通信編程

將其他語言編寫的程序包裝為子進程，重定向標準輸入輸出到管道，與該程序進行通信?？蓪崿F(xiàn)任意編程語言為我PHP所用。

第六 sendMessage

到此這篇關(guān)于Swoole擴展的6種模式深入詳解的文章就介紹到這了,更多相關(guān)Swoole擴展的5種模式內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論