1. 為什么要在PHP里搞Actor先理清模型本身和PHP的契合點(diǎn)標(biāo)題里的“php方案”其實(shí)已經(jīng)圈定了本文的邊界——不是泛泛而談Actor模型的理論而是聊在PHP環(huán)境下把Actor模型真正落地。聽到“PHP做Actor”第一反應(yīng)普遍是PHP不是腳本語言嗎一個請求一個生命周期連常駐內(nèi)存都得靠擴(kuò)展怎么做并發(fā)模型這個質(zhì)疑本身沒有錯但它指向的“PHP單線程、無狀態(tài)、生命周期短”這些特性恰恰是Actor模型最喜歡的土壤。先說我個人對Actor模型的理解。Actor模型本質(zhì)上就是對并發(fā)的一種組織方式核心就三件事Actor是獨(dú)立的執(zhí)行單元內(nèi)部持有自己的狀態(tài)Actor之間不共享內(nèi)存只通過消息通信每個Actor有一個郵箱mailbox收到消息后按順序處理。聽起來很像真實(shí)世界里餐廳后廚的運(yùn)作方式每個廚師是一個Actor自己管自己灶臺上的東西菜做好了通過傳菜窗口消息遞給下一個環(huán)節(jié)不需要互相搶同一口鍋。這就是Actor和傳統(tǒng)多線程模型之間最大的差別——傳統(tǒng)并發(fā)是“一群人搶一個廁所”靠鎖來保證同一時刻只有一個人進(jìn)去Actor是“每個人都有自己的廁所”根本不用搶。順帶說一句很多討論都把Actor和“高性能”劃等號這其實(shí)是誤區(qū)。Actor模型解決的核心問題是并發(fā)復(fù)雜性性能只是順帶的好處。它最大的價值在于你不需要再去思考共享鎖、競態(tài)條件、內(nèi)存屏障這些折磨人的東西每個Actor內(nèi)部是串行處理的全局并發(fā)靠的是成千上萬個Actor并行本質(zhì)上是“邏輯串行、物理并行”的折中方案。回到PHP。PHP長期以來被人吐槽“并發(fā)能力弱”但認(rèn)真想想這一半是模型問題一半是運(yùn)行方式問題。PHP-FPM模式下每個請求獨(dú)占一個進(jìn)程進(jìn)程間本來就沒有共享內(nèi)存依靠外部存儲數(shù)據(jù)庫、Redis做狀態(tài)同步這天然就是“無共享架構(gòu)”。只不過過去我們靠外部服務(wù)來通信而Actor模型要求的是通過消息通信——兩者在理念上幾乎一致。所以我說PHP和Actor模型的契合度甚至比Java這種自帶線程模型的語言更高只不過PHP開發(fā)者很少往這個方向想。要做這件事前提是PHP代碼必須常駐內(nèi)存運(yùn)行而不能走FPM的請求-響應(yīng)循環(huán)。這一點(diǎn)想通了后面所有技術(shù)選型都是水到渠成的事。2. 技術(shù)選型三條路怎么挑常駐內(nèi)存是必要條件但選哪條路直接決定你后面要付出多少維護(hù)成本。我從實(shí)際項(xiàng)目出發(fā)把常見方案拆成三條路線對比如下。對比維度路線一常駐進(jìn)程框架路線二協(xié)程擴(kuò)展改造路線三純PHP自研代表方案某常駐框架、某協(xié)程框架某協(xié)程框架的Channel/協(xié)程特性自定義進(jìn)程 進(jìn)程間通信開發(fā)速度快內(nèi)置TCP服務(wù)、定時器中需要理解協(xié)程調(diào)度慢要自己造輪子Actor支持無內(nèi)置需自封裝部分內(nèi)置如Channel完全自建上手門檻低中高可控性中中高最高適用規(guī)模中小型業(yè)務(wù)中大型高并發(fā)學(xué)習(xí)研究和特殊需求2.1 路線一基于某常駐框架快速起步這是最省力的方案。某常駐框架的核心思路是用PHP寫一個常駐內(nèi)存的TCP/UDP服務(wù)進(jìn)程業(yè)務(wù)代碼以回調(diào)方式掛在事件循環(huán)上。這個框架最大的優(yōu)點(diǎn)是沒有擴(kuò)展依賴純PHP實(shí)現(xiàn)部署時不需要額外編譯PHP版本滿足要求就能跑。我當(dāng)時搭建第一個Actor原型時用的就是它因?yàn)樗鉀Q了最煩人的“進(jìn)程管理事件輪詢”問題讓我能把精力集中在Actor的業(yè)務(wù)邏輯上。但有個問題必須提前說這類框架本質(zhì)上還是多進(jìn)程模型一個Worker進(jìn)程同一時刻處理一個連接。如果Actor之間消息量很大頻繁的進(jìn)程間通信代價不低因?yàn)橄⒁?jīng)過框架的轉(zhuǎn)發(fā)層。另外它對“回調(diào)地獄”的容忍度很低Actor邏輯稍微復(fù)雜一點(diǎn)代碼就開始難以維護(hù)。所以它適合原型驗(yàn)證和中小規(guī)模業(yè)務(wù)不適合作為大型Actor集群的底座。某協(xié)程框架則是另一條路利用協(xié)程在單進(jìn)程內(nèi)實(shí)現(xiàn)高并發(fā)Actor之間通信更像是內(nèi)存操作延遲極低。代價是你得接受協(xié)程的思維轉(zhuǎn)換別再寫阻塞式代碼了所有涉及網(wǎng)絡(luò)IO的地方都得改成異步或協(xié)程風(fēng)格。這一點(diǎn)勸退了不少人——業(yè)務(wù)里有現(xiàn)成的同步代碼改造工作量非常大。2.2 路線二某協(xié)程框架的Channel/隊列能力如果只挑某協(xié)程框架的一部分能力而不是全量引入倒是可以走一條折中路線。某協(xié)程框架提供的Channel協(xié)程通道很適合作Actor郵箱的底層實(shí)現(xiàn)。Channel本質(zhì)上是帶緩沖的消息隊列協(xié)程A往Channel里推消息協(xié)程B從中取消息天然帶有阻塞/非阻塞兩種模式完美匹配Actor的信箱語義。而且Channel在單進(jìn)程內(nèi)部沒有序列化和網(wǎng)絡(luò)開銷性能遠(yuǎn)高于跨進(jìn)程通信。我第二版Actor引擎就是基于某協(xié)程框架重寫的每個Actor實(shí)例綁定一個Channel作為郵箱再掛一個協(xié)程循環(huán)消費(fèi)。實(shí)測下來局域網(wǎng)內(nèi)單機(jī)每秒可處理的消息數(shù)比第一版基于某常駐框架的進(jìn)程間通信高了一個量級。不過這條路也有它的隱性成本某協(xié)程框架的調(diào)試工具鏈不算成熟協(xié)程泄漏問題排查起來很酸爽。一旦有一個協(xié)程阻塞或退出對應(yīng)Actor就“失聯(lián)”了而且這種故障現(xiàn)象在日志里幾乎看不出異常只能通過外部監(jiān)控發(fā)現(xiàn)消息不再被消費(fèi)。2.3 路線三純PHP 自研消息層第三路線是我個人最“偏科”的選項(xiàng)。如果你想徹底弄明白Actor模型的每一塊拼圖那就用純PHP自己實(shí)現(xiàn)一版不依賴任何框架的Actor能力。你需要自己解決的問題包括進(jìn)程間通信Unix Socket、消息隊列、消息序列化JSON、PHP序列化、二進(jìn)制協(xié)議、消息路由ActorId到進(jìn)程的映射表、故障恢復(fù)進(jìn)程崩潰后消息怎么補(bǔ)償。這條路開發(fā)量大但收獲也最大。做完一遍之后你會對并發(fā)模型中的每個細(xì)節(jié)都有極深的體感。我在第三版里用Unix Socket 自定義二進(jìn)制協(xié)議實(shí)現(xiàn)了消息總線為了把序列化開銷降到最低甚至把消息頭單獨(dú)編碼。雖然最終沒有全部用到生產(chǎn)環(huán)境但這次自研過程讓我搞清楚了什么情況下Actor會丟消息、什么情況下會亂序、什么情況下會死鎖這些經(jīng)驗(yàn)在后面排查線上問題時幫了大忙。2.4 我的選型建議綜合來看如果是生產(chǎn)環(huán)境要落地我建議直接選路線二某協(xié)程框架 自封裝Actor層。理由很簡單協(xié)程天然契合Actor的“每個Actor單線程順序處理”的語義Channel又是現(xiàn)成的郵箱實(shí)現(xiàn)整體上既高效又可控。如果是學(xué)習(xí)/寫Demo演示選路線三用純PHP實(shí)現(xiàn)一輪體會會更深刻。如果公司現(xiàn)有PHP環(huán)境已經(jīng)大量使用某常駐框架那就別折騰了直接在它上面封裝Actor層即可畢竟新增框架的部署成本和團(tuán)隊學(xué)習(xí)成本也是隱性技術(shù)債。當(dāng)年我做這個項(xiàng)目時選了路線三“自研”一部分原因是對路線一和路線二都試過之后覺得不夠“通透”自己被Actor這個概念驅(qū)動著想連最底層的消息調(diào)度都自己掌控。現(xiàn)在回過頭看路線三固然收獲極大但確實(shí)走了不少彎路。如果讓我重新來一次在時間有限的條件下我會先用某協(xié)程框架把業(yè)務(wù)跑通再逐步自研替代組件而不是一上來就挑戰(zhàn)最難的路徑。3. 架構(gòu)設(shè)計Actor的郵箱、消息與狀態(tài)機(jī)無論選哪條路線Actor模型的核心結(jié)構(gòu)是不變的。我先給出一個貼合PHP實(shí)際的Actor通用結(jié)構(gòu)設(shè)計這部分內(nèi)容不依賴具體的框架直接看設(shè)計思路即可。3.1 核心結(jié)構(gòu)一個Actor長什么樣我把Actor抽象成四層身份ActorId、行為handle方法、狀態(tài)私有屬性、郵箱消息隊列。一個最小化的Actor基類大概長這樣?php abstract class Actor { protected string $actorId; protected array $inbox []; protected array $state []; protected bool $processing false; public function __construct(string $actorId) { $this-actorId $actorId; $this-init(); } abstract protected function init(): void; abstract protected function handle(Message $message): void; public function receive(Message $message): void { // 追加到郵箱隊列 $this-inbox[] $message; } public function runOnce(): bool { if ($this-processing || empty($this-inbox)) { return false; } $this-processing true; try { $message array_shift($this-inbox); $this-handle($message); } finally { $this-processing false; } return true; } public function getActorId(): string { return $this-actorId; } }這個基類最重要的設(shè)計點(diǎn)是processing標(biāo)志位它保證了每個Actor在任一時刻只處理一條消息這是Actor模型“內(nèi)部串行”約束的根本保證。如果丟了它actor就可能并發(fā)處理多條消息狀態(tài)就亂了。這才是Actor模型對并發(fā)問題的核心解法。3.2 郵箱的有序性為什么它必須是一個隊列郵箱的本質(zhì)是先進(jìn)先出的隊列。常見的一個誤解是既然消息發(fā)送是并發(fā)的那Actor收到的消息不也應(yīng)該是亂序的不Actor模型恰恰通過郵箱保序——同一個Actor收到的消息按發(fā)送順序入隊、按隊列順序消費(fèi)。這一點(diǎn)在很多業(yè)務(wù)場景里是剛需。比如一個訂單Actor它的狀態(tài)變遷是“創(chuàng)建→支付→發(fā)貨→完成”如果“支付”消息被“發(fā)貨”搶先處理了整個狀態(tài)機(jī)就崩了。所以郵箱不能用無序集合必須是FIFO隊列。如果你用了某協(xié)程框架的Channel它本身就保證FIFO順序直接復(fù)用即可。如果用自研方案用PHP的SplQueue比array更符合語義——注意不要用array_shift它會把整個數(shù)組重新索引在消息量大的時候有性能問題。不過我上面給出的示例為了直觀用了array_shift生產(chǎn)環(huán)境建議換成SplQueue。關(guān)于郵箱容量我踩過一個坑一開始郵箱長度沒設(shè)上限結(jié)果一個Actor處理能力跟不上消息生產(chǎn)速度內(nèi)存直接被打爆。后來給郵箱加了最大長度閾值比如一萬條超出之后采用兩種策略要么丟棄并計入死信要么讓發(fā)送方阻塞等待。生產(chǎn)環(huán)境用后者犧牲一點(diǎn)吞吐?lián)Q穩(wěn)定。3.3 消息路由消息怎么找到Actor消息路由的關(guān)鍵是ActorId到Actor實(shí)例的映射。單進(jìn)程內(nèi)一張哈希表就夠了多進(jìn)程場景下需要一個路由中心來維護(hù)“ActorId落在哪個進(jìn)程上”的映射關(guān)系。我的方案是每個進(jìn)程啟動時向路由中心注冊自己負(fù)責(zé)的ActorId段路由中心存一套ActorId 進(jìn)程ID的映射消息發(fā)送方先把消息發(fā)給路由中心由它決定轉(zhuǎn)發(fā)到哪個進(jìn)程。這樣消息跨進(jìn)程傳遞時系統(tǒng)設(shè)計反而更清晰因?yàn)樵跓o共享架構(gòu)里消息本身就是唯一的通行貨幣。實(shí)際實(shí)現(xiàn)時我簡化了這一步因?yàn)闃I(yè)務(wù)里Actor數(shù)量是可控的我直接讓路由中心維護(hù)了一張全量映射表并支持動態(tài)注冊和心跳?；?。如果Actor在某個進(jìn)程上退出路由中心會把該Actor標(biāo)記為“遷移中”舊消息不丟、新消息排隊等新版Actor起來后再投遞。這塊后續(xù)在“問題排查”里再細(xì)說。消息信封我統(tǒng)一設(shè)計成四段actorId 消息類型type 載荷payload 消息ID msgId。msgId的用途是冪等——萬一消息被投遞了兩次接收方可以靠msgId識別并去重。這類細(xì)節(jié)在單體應(yīng)用里無所謂到了分布式場景就是救命稻草。3.4 狀態(tài)存儲與故障隔離Actor的狀態(tài)可以放在內(nèi)存里但一定要有一個持久化兜底。我做的方案是狀態(tài)快照定期寫入本地文件消息處理過程中產(chǎn)生的高頻更新只寫內(nèi)存每隔N條消息或固定時間間隔落盤一次。如果進(jìn)程崩潰重啟時加載最近一次快照再結(jié)合死信隊列里未處理完的消息做增量恢復(fù)。這套方案類似數(shù)據(jù)庫的WAL思想簡單但有效。對于狀態(tài)量極大的Actor比如百萬級別的用戶會話我會將快照拆成多份分片每個分片獨(dú)立存儲避免單文件讀寫成為瓶頸。故障隔離是Actor模型一個隱藏很深的好處——如果某個Actor內(nèi)部拋了異常只要在handle外層捕獲并記錄其他actor完全感知不到。我在基類里做了異常兜底捕獲異常后把異常消息轉(zhuǎn)成一條特殊狀態(tài)消息回傳給監(jiān)控Actor而不是讓整個進(jìn)程崩潰。這個設(shè)計看似只是加了一個try/catch實(shí)際上它把故障邊界框在了單個Actor內(nèi)進(jìn)程不會因?yàn)閭€別邏輯bug而全家桶。4. 從0到1實(shí)現(xiàn)一個輕量Actor引擎這一章直接上實(shí)操。我以某協(xié)程框架為例從消息總線到執(zhí)行循環(huán)拆開講代碼可以直接復(fù)用。4.1 消息總線的協(xié)程實(shí)現(xiàn)先看消息總線到底在Actor模型里扮演什么角色。如果把Actor們看作獨(dú)立運(yùn)行的島嶼消息總線就是連接島嶼之間的航線。島嶼之間不直接修橋避免耦合所有包裹統(tǒng)一走航線的貨船通道。在PHP里這個航線的具體形態(tài)取決于Actor分布在同一進(jìn)程還是跨進(jìn)程同進(jìn)程場景用某協(xié)程框架的Channel效率極高跨進(jìn)程場景用集團(tuán)隊內(nèi)部基于Unix Socket定制的輕量消息協(xié)議。先看同進(jìn)程核心實(shí)現(xiàn)?php use Swoole\Coroutine\Channel; class ActorMailbox { private Channel $channel; private string $actorId; public function __construct(string $actorId, int $capacity 1024) { $this-actorId $actorId; $this-channel new Channel($capacity); } public function push(Message $message): void { // 隊列滿時等待避免內(nèi)存無限增長 $this-channel-push($message); } public function pop(): Message { return $this-channel-pop(); } }這里有兩個細(xì)節(jié)要提醒Channel的容量參數(shù)要結(jié)合Actor處理時長來定。如果Actor平均處理一條消息需要50ms理時長有限但消息涌入特別猛容量設(shè)太小會導(dǎo)致大量發(fā)送方協(xié)程阻塞整體吞吐直接被拖垮。我一般按“處理時長(ms) × 預(yù)期每秒消息數(shù) / 1000 × 2”來估算初始容量再留出兩倍余量。第二在協(xié)程環(huán)境下輕量線程的調(diào)度才是真正要注意的。如果你的Actor處理函數(shù)里有同步阻塞操作比如sleep()、file_get_contents()、同步MySQL查詢在非阻塞環(huán)境下會把整個協(xié)程調(diào)度器卡住——這不是某協(xié)程框架的bug而是協(xié)程的特性協(xié)程自己主動讓出CPU而不是被操作系統(tǒng)強(qiáng)制切換。所以Actor的handle方法里能用協(xié)程化客戶端就用協(xié)程化客戶端千萬別碰同步阻塞調(diào)用。4.2 Actor引擎的主循環(huán)調(diào)度器怎么工作有了信箱還得有一個人不斷把信箱里的消息取出來交給Actor處理。這個“人”我稱之為調(diào)度器它維護(hù)一組“可運(yùn)行Actor”的隊列。調(diào)度器主循環(huán)邏輯?php class ActorScheduler { private array $actorMap []; // actorId Actor對象 private array $readyActorIds []; private bool $running false; public function register(Actor $actor): void { $this-actorMap[$actor-getActorId()] $actor; } public function send(Message $message): void { $actorId $message-getActorId(); if (!isset($this-actorMap[$actorId])) { throw new RuntimeException(Actor not found: . $actorId); } $this-actorMap[$actorId]-receive($message); // 標(biāo)記該Actor為就緒狀態(tài)由調(diào)度器在下一輪執(zhí)行 if (!in_array($actorId, $this-readyActorIds)) { $this-readyActorIds[] $actorId; } } public function run(): void { while ($this-running) { if (empty($this-readyActorIds)) { // 沒有就緒Actor讓出CPU防止空轉(zhuǎn) usleep(1000); // 1ms continue; } $actorId array_shift($this-readyActorIds); $actor $this-actorMap[$actorId]; $hasMore $actor-runOnce(); if ($hasMore) { $this-readyActorIds[] $actorId; } } } }注意調(diào)度器里的runOnce()返回值牽涉到一個設(shè)計決策什么時候把Actor重新放回就緒隊列我采用的是“處理完一條且郵箱里還有消息就繼續(xù)放回隊列”。有的實(shí)現(xiàn)會把整個郵箱一次性清空再讓出CPU那種方式在消息量大的時候會造成“一個Actor獨(dú)占總線”的問題。我的做法是每條消息處理后就檢查郵箱輪轉(zhuǎn)給其他Actor公平性更好。4.3 注冊中心Actor怎么被發(fā)現(xiàn)單進(jìn)程場景調(diào)度器自己管理actorMap就夠了但多進(jìn)程場景需要一個全局注冊中心。我的設(shè)計是在路由中心維護(hù)一張分布式的Actor表?php class ActorRegistry { private array $actors []; private array $actorLocks []; public function bind(string $actorId, string $nodeId): bool { $this-actorLocks[$actorId] $nodeId; return true; } public function lookup(string $actorId): ?string { return $this-actorLocks[$actorId] ?? null; } public function unbind(string $actorId, string $nodeId): bool { if (($this-actorLocks[$actorId] ?? ) $nodeId) { unset($this-actorLocks[$actorId]); return true; } return false; } }這個注冊中心支持兩個關(guān)鍵操作綁定(bind)和解綁(unbind)節(jié)點(diǎn)上線時綁定節(jié)點(diǎn)下線或Actor退出時解綁。特別注意unbind時比對了nodeId避免舊節(jié)點(diǎn)的過期心跳把新節(jié)點(diǎn)的綁定覆蓋掉。我實(shí)際遇到過一個場景節(jié)點(diǎn)A宕機(jī)后重啟重新綁定時把節(jié)點(diǎn)B的綁定覆蓋了導(dǎo)致節(jié)點(diǎn)B上的Actor消息全部路由錯誤。加了這個比對之后才徹底解決了問題。多進(jìn)程消息路由的完整時序大致是發(fā)送方先調(diào)lookup拿到目標(biāo)nodeId再把消息投遞到對應(yīng)的網(wǎng)絡(luò)鏈路如果查不到actorId將消息轉(zhuǎn)投死信隊列。注冊中心本身也可以做成多副本保證自身的高可用但這個就屬于另一層話題了。4.4 消息序列化性能與兼容的權(quán)衡多進(jìn)程通信必然涉及序列化。選哪種序列化方案直接影響消息的吞吐上限。我實(shí)際對比過三種常見方案json_encode/decode可讀性好跨語言兼容強(qiáng)但性能一般而且對PHP對象支持需要額外映射serialize/unserializePHP原生能處理復(fù)雜對象但產(chǎn)生的內(nèi)容偏大且是PHP私有格式跨語言沒法用igbinary序列化后的體積比serialize小約40%速度快30%以上缺點(diǎn)是需要裝擴(kuò)展。下面是一組當(dāng)時壓測的數(shù)據(jù)局域網(wǎng)內(nèi)同一臺機(jī)器單消息1KB發(fā)送10萬條方案序列化反序列化總耗時包體大小json4.2s約1.3KBserialize3.6s約2.1KBigbinary2.3s約1.5KB能看到igbinary在性能和體積上都是最優(yōu)的但需要額外安裝擴(kuò)展。如果部署環(huán)境不方便裝擴(kuò)展json也是可以接受的選擇——只要消息結(jié)構(gòu)里不塞太深層級的PHP對象。我在生產(chǎn)環(huán)境最終選了igbinary因?yàn)樗〉舻膸捄虲PU時間對整體吞吐的影響非常明顯。另外一個我強(qiáng)烈建議的實(shí)踐消息結(jié)構(gòu)盡量用標(biāo)量數(shù)組而不是PHP對象。對象雖然代碼寫起來順手但序列化往往會把類名、屬性名都帶進(jìn)去既膨脹包體又讓前后端版本兼容變得復(fù)雜。用數(shù)組做傳輸層協(xié)議字段自己維護(hù)版本號后面升級接口時只有明確的兼容成本沒有隱性的反序列化坑。5. 壓測、調(diào)參與踩坑實(shí)錄5.1 一次壓測復(fù)盤瓶頸到底在哪基于某協(xié)程框架 自研Actor層我壓過一次單機(jī)性能。環(huán)境是8核16G的Linux服務(wù)器PHP 8.240個Worker進(jìn)程每個Worker內(nèi)部獨(dú)立運(yùn)行調(diào)度器。測試場景是模擬用戶登錄后發(fā)送100萬條消息每個消息觸發(fā)一個Actor更新一條狀態(tài)再回復(fù)一條確認(rèn)消息。結(jié)果是總耗時約4.8秒平均每秒處理約20.8萬條消息P95延遲18msP99延遲34ms。這個數(shù)據(jù)的體感是“夠用但不算極致”。當(dāng)時CPU占用率約75%內(nèi)存占用峰值1.2G。瓶頸基本在Actor狀態(tài)快照的落盤——每次處理狀態(tài)變更都要寫一次文件磁盤IO開銷占了大約30%的CPU。后續(xù)優(yōu)化做了兩件事第一把快照從“每次消息都寫”改成“每處理100條消息寫一次”“定期刷盤”第二改用異步落盤方式狀態(tài)更新先寫內(nèi)存緩存由獨(dú)立協(xié)程批量刷盤。優(yōu)化后同樣壓測平均每秒處理提升到了31.6萬條P99降到22ms。這說明在Actor模型里IO策略對性能的影響比消息調(diào)度邏輯大得多。5.2 消息積壓和背壓控制消息積壓是所有消息系統(tǒng)繞不開的話題。我遇到過一個典型場景某個批量任務(wù)Actor每秒收到2萬條消息但它的處理能力只有每秒8千條郵箱持續(xù)膨脹內(nèi)存直線上漲。解決背壓不能只靠“擴(kuò)容郵箱”而是要建立反饋機(jī)制。我參考了消息隊列的經(jīng)典做法發(fā)送方投遞消息時可以選擇阻塞等待接收方確認(rèn)同步模式也可以異步發(fā)送不關(guān)心結(jié)果。同步模式下如果接收方處理不過來投遞操作就會阻塞生產(chǎn)速度自然被限制這就是背壓。而異步模式下消息會囤積在郵箱里越堆越多。生產(chǎn)環(huán)境必須兩手抓核心鏈路用同步模式允許一定程度的阻塞非核心鏈路用異步模式但配合郵箱容量的硬上限死信溢出策略。我見過只圖快、全鏈路異步的兄弟半夜被OOM告警叫醒——內(nèi)存里的消息堆積就是一個定時炸彈。異步模式可以但要限流、限隊列、有限流輔路。5.3 循環(huán)依賴兩個Actor互相發(fā)消息為何就死鎖了有業(yè)務(wù)場景是這樣的Actor A處理完消息給Actor B發(fā)一條消息Actor B處理完后又給Actor A回一條消息。理論上這沒什么問題因?yàn)橄⑹钱惒降陌l(fā)送方發(fā)出消息后不應(yīng)該持續(xù)占用CPU。但如果在調(diào)度器里send方法被實(shí)現(xiàn)成了同步等待目標(biāo)Actor處理完才返回就會形成經(jīng)典死鎖A等B回復(fù)B等A的后續(xù)消息雙方都卡住。這類問題的排查思路是先確認(rèn)send方法是不是異步的。我在自研引擎里差點(diǎn)犯錯——因?yàn)槟硡f(xié)程框架的Channel在緩沖區(qū)寫滿后會阻塞如果A給B發(fā)送消息時B的郵箱正好滿了A的協(xié)程就會卡住。為了避免這個問題我引入了“超時轉(zhuǎn)投死信”的機(jī)制發(fā)送消息時設(shè)置超時時間超時后不再阻塞而是把消息標(biāo)記為“待重試”重新進(jìn)入隊列。另外建議在死信隊列里加上消息鏈路ID方便排查到底卡在哪個環(huán)節(jié)。5.4 進(jìn)程崩潰后消息去哪兒了某協(xié)程框架跑在Worker進(jìn)程里如果某個Worker因?yàn)槎五e誤或未捕獲異常退出該進(jìn)程內(nèi)所有Actor連同它們郵箱里的消息都會灰飛煙滅。這個事故模式我第一次遇到時完全懵了——日志顯示進(jìn)程退出前明明還在正常處理消息但重啟后哪些消息被處理過、哪些沒處理過全都沒了。解決方案分三塊全局唯一消息ID 處理狀態(tài)記錄。每條消息分配一個全局唯一ID消息被Actor讀取后先記錄狀態(tài)為“處理中”處理完成后更新為“已完成”。重啟時只重放“處理中”和“未處理”的消息避免重復(fù)處理。消息日志落盤。所有跨進(jìn)程消息在發(fā)送時異步寫一份到本地消息日志文件。進(jìn)程崩潰后新進(jìn)程可以掃描日志文件恢復(fù)未完成消息同時靠消息ID冪等去重。這個日志文件的讀寫性能要專門優(yōu)化我用的是追加寫配合定期輪轉(zhuǎn)單機(jī)寫入了上千萬條消息也沒出過性能問題。Actor狀態(tài)快照 增量操作日志?？煺肇?fù)責(zé)狀態(tài)整體恢復(fù)操作日志負(fù)責(zé)增量回放。前者恢復(fù)快后者恢復(fù)準(zhǔn)兩者配合用。這套機(jī)制看著很重但對長時間運(yùn)行的Actor集群來說屬于必需品。寧可多寫點(diǎn)基礎(chǔ)代碼也不能在凌晨三點(diǎn)被“消息神秘消失”的告警支配。5.5 一個小技巧用Actor模型編排分布式任務(wù)最后分享一個我實(shí)際用過、覺得很順手的擴(kuò)展場景——用Actor模型做分布式任務(wù)編排。傳統(tǒng)任務(wù)編排用狀態(tài)機(jī)或者隊列串行執(zhí)行步驟一多代碼就很啰嗦。我的做法是每個任務(wù)流程建模成一個“流程Actor”流程中的每一步是它處理的一個消息類型某一步執(zhí)行完后流程Actor主動向下一步發(fā)起內(nèi)部投遞給自己或向子任務(wù)Actor發(fā)消息。如果某個子任務(wù)失敗流程Actor收到失敗消息后決定重試還是終止?fàn)顟B(tài)轉(zhuǎn)移完全在Actor內(nèi)部完成。這個編排方式最爽的地方在于每一步之間幾乎沒有共享狀態(tài)天然支持并行子任務(wù)。比如我已經(jīng)把一條訂單流程拆成了“創(chuàng)建訂單、鎖定庫存、鎖定優(yōu)惠券、支付扣款、發(fā)貨通知”五個子Actor它們各自獨(dú)立執(zhí)行全部完成后向流程Actor回執(zhí)。之前的單體流程要處理各種條件判斷互相穿插的情況現(xiàn)在各干各的再通過消息把結(jié)果匯集代碼一下子就清爽了。整體來看Actor模型在PHP里的落地核心不是高深的理論而是把“消息驅(qū)動”和“狀態(tài)隔離”真正落到代碼里。我個人體會最深的是在PHP這類“無共享、短生命周期”的生態(tài)里Actor模型不僅可行而且在某些場景下比如長連接服務(wù)、任務(wù)編排、狀態(tài)管理類業(yè)務(wù)反而比多線程模型更自然。當(dāng)然它也不是萬能藥——如果你的業(yè)務(wù)就是簡單CURD完全沒有并發(fā)狀態(tài)管理的痛點(diǎn)那就別折騰Actor了常規(guī)架構(gòu)更穩(wěn)。但如果你正在被“鎖競爭、狀態(tài)同步、并發(fā)環(huán)境下的一致性問題”折磨不妨試試把模型轉(zhuǎn)換成Actor的思維也許會發(fā)現(xiàn)PHP的并發(fā)世界比想象中大得多。