Swoole擴(kuò)展的6種模式深入詳解

前言

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

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

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

ulimit -n

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

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

工具永遠(yuǎn)是死的，而人是活的。

再?gòu)?fù)雜艱難的場(chǎng)景也阻擋不了聰明的工程師。合理利用Swoole提供的各項(xiàng)功能可以巧妙解決各種難題。

第一 Worker同步阻塞

這個(gè)模式的使用方法：

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

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

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

進(jìn)程數(shù)量

根據(jù)上面的IO耗時(shí)，設(shè)置適當(dāng)?shù)倪M(jìn)程數(shù)量即可。

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

投遞模式

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

長(zhǎng)連接應(yīng)用

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

第二 Worker非阻塞+Task

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

使用方法

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

Worker進(jìn)程

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

Task進(jìn)程

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

第三 Worker全異步

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

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

使用方法

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

邏輯實(shí)現(xiàn)

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

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

適用場(chǎng)景

• 長(zhǎng)連接服務(wù)
• 對(duì)并發(fā)能力和吞吐量有較高要求
• 團(tuán)隊(duì)開發(fā)者技術(shù)水平較高

弊端和解決方案

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

可使用 Promise 或 Yield/Generator 簡(jiǎn)化異步編程。

第四 Base模式+同步阻塞

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

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

使用方法

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

適用場(chǎng)景

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

第五 Process

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

多進(jìn)程+進(jìn)程間通信編程

將其他語言編寫的程序包裝為子進(jìn)程，重定向標(biāo)準(zhǔn)輸入輸出到管道，與該程序進(jìn)行通信?？蓪?shí)現(xiàn)任意編程語言為我PHP所用。

第六 sendMessage

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