本文系翻譯，原文地址：https://stitcher.io/blog/fibers-with-a-grain-of-salt

Fibers with a grain of salt

所以我打算寫一篇關于在PHP 8.1 中使用Fibers纖維的深入博客文章。我們將從一個基本示例開始，從頭開始解釋它們。這個想法是發(fā)送異步 HTTP 請求并使用纖程并行處理它們。

但是和他們一起玩，我了解到RFC并不是在開玩笑，當它說“不應直接在應用程序級代碼中使用 Fiber API。Fibers 提供了一個基本的、低級的流控制 API 來創(chuàng)建更高然后在應用程序代碼中使用的級抽象”。

因此，與其走這條路并使事情變得過于復雜，我們將討論什么是纖程概念，為什么它們在應用程序代碼中幾乎不可用，以及您到底如何使用異步 PHP。

首先，一點點理論。

假設您要發(fā)送三個 HTTP 請求并處理它們的組合結(jié)果。這樣做的同步方式是發(fā)送第一個，等待響應，然后發(fā)送第二個，等待，等等。

讓我們用盡可能簡單的圖表來表示這樣的程序流程。你需要從上到下閱讀這張圖表，時間越往下越走。每種顏色代表一個 HTTP 請求。每個請求的彩色部分代表實際運行的 PHP 代碼，您服務器上的 CPU 正在執(zhí)行工作，透明塊代表等待時間：請求需要通過網(wǎng)絡發(fā)送，其他服務器需要處理并發(fā)送回. 只有當響應到達時，我們才能再次工作。

這是一個同步執(zhí)行流程：發(fā)送、等待、處理、重復。

在并行處理的世界中，我們發(fā)送請求但不等待。然后我們發(fā)送下一個請求，然后是另一個。只有然后我們等待所有請求。在等待的同時，我們會定期檢查我們的一個請求是否已經(jīng)完成。如果是這種情況，我們可以立即處理。

您可以看到這種方法如何減少執(zhí)行時間，因為我們更優(yōu)化地使用了等待時間。

Fibers 是 PHP 8.1 中的一種新機制，可讓您更有效地管理這些并行執(zhí)行路徑。使用生成器和 已經(jīng)可以實現(xiàn)yield，但是纖維是一個顯著的改進，因為它們是專門為此用例設計的。

您將為每個請求創(chuàng)建一個纖程，并在請求發(fā)送后暫停纖程。創(chuàng)建所有三個光纖后，您將遍歷它們，并一一恢復它們。通過這樣做，纖程檢查請求是否已經(jīng)完成，如果沒有則再次暫停，否則它可以處理響應并最終完成。

你看，纖程是一種啟動、暫停和恢復程序隔離部分執(zhí)行流程的機制。Fiber 也被稱為“綠色線程”：實際上存在于同一進程中的線程。這些線程不是由操作系統(tǒng)管理的，而是由運行時管理的——在我們的例子中是 PHP 運行時。它們是管理某些形式的并行編程的一種經(jīng)濟高效的方式。

但請注意，它們并沒有添加任何真正的異步內(nèi)容：所有纖程都位于同一個 PHP 進程中，并且一次只能運行一個纖程。這是循環(huán)它們并在等待時檢查它們的主進程，該循環(huán)通常稱為“事件循環(huán)”。

并行性的難點不在于你如何在纖程或生成器上循環(huán)，或者你想使用的任何機制；它是關于能夠開始一個操作，將它交給一個外部服務，并且只在你想要的時候以非阻塞的方式檢查結(jié)果。

看，在前面的例子中，我們假設我們可以只發(fā)送一個請求，然后在我們想要的時候檢查它的響應，但這實際上并不像聽起來那么容易。

沒錯：大多數(shù)處理 I/O 的 PHP 函數(shù)都沒有內(nèi)置這種非阻塞功能。事實上，只有少數(shù)函數(shù)可以做到，而且使用它們非常麻煩。

有一個套接字的例子，它可以被設置為非阻塞，像這樣：

[$read, $write] = stream_socket_pair(     STREAM_PF_UNIX,     STREAM_SOCK_STREAM,     STREAM_IPPROTO_IP );   stream_set_blocking($read, false); stream_set_blocking($write, false);

通過使用stream_socket_pair()，創(chuàng)建了兩個可用于雙向通信的套接字。正如您所看到的，它們可以使用stream_set_blocking().

假設我們想要實現(xiàn)我們的示例，發(fā)送三個請求。我們可以使用套接字來做到這一點，但我們需要在它之上自己實現(xiàn) HTTP 協(xié)議。這正是nox7所做的，該用戶在Reddit上分享了一個小型概念證明，以展示如何使用光纖和套接字發(fā)送 HTTP GET 請求。你真的想在你的應用程序代碼中這樣做嗎？

至少對我來說，答案是“不”。這正是 RFC 警告的內(nèi)容；我不生氣。相反，我們鼓勵使用現(xiàn)有的異步框架之一：Amp或ReactPHP。

例如，使用 ReactPHP，我們可以這樣寫：

$loop = ReactEventLoopFactory::create(); $browser = new ClueReactBuzzBrowser($loop); $promises = [     $browser->get('https://example.com/1'),     $browser->get('https://example.com/2'),     $browser->get('https://example.com/3'), ]; $responses = BlockawaitAll($promises, $loop);

與手動創(chuàng)建套接字連接相比，這是一個更好的示例。這就是 RFC 的意思：應用程序開發(fā)人員不需要擔心纖程，它是 Amp 或 ReactPHP 等框架的實現(xiàn)細節(jié)。

不過，這給我們帶來了一個問題：與我們已經(jīng)可以用發(fā)電機做的事情相比，纖維有什么好處？RFC 是這樣解釋的：

與無堆棧生成器不同，每個 Fiber 都有自己的調(diào)用堆棧，允許它們在深度嵌套的函數(shù)調(diào)用中暫停。聲明中斷點的函數(shù)（即調(diào)用 Fiber::suspend()）不需要更改其返回類型，這與使用 yield 的函數(shù)必須返回 Generator 實例不同。

Fiber 可以在任何函數(shù)調(diào)用中掛起，包括那些從 PHP VM 內(nèi)部調(diào)用的函數(shù)，例如提供給 array_map 的函數(shù)或迭代器對象上的 foreach 調(diào)用的方法。

很明顯，纖程在語法和靈活性方面都有顯著的改進。但與 Go 及其“ goroutines ”相比，它們還不算什么。

要使異步 PHP 在沒有框架開銷的情況下成為主流，仍然缺少許多功能，而 Fiber 是朝著正確方向邁出的良好一步，但我們還沒有做到這一點。

所以就是這樣。如果您不是 Amp、ReactPHP 或較小的異步 PHP 框架的維護者，那么實際上沒有什么可說的。也許