swoole知識點有哪些

本篇內容主要講解“swoole知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“swoole知識點有哪些”吧!

swoole聊天室流程講解

整個聊天室流程為:

- 用戶http接口登錄獲得授權

- 通過授權請求http接口獲得好友列表,不同好友的最后一條未讀消息以及未讀消息數(shù)(用于首頁顯示)

- 通過授權請求獲得群列表(群消息為了節(jié)省存儲空間沒有做已讀未讀)

- 建立ws鏈接

- 注冊斷線重連機制,當觸發(fā)close事件時,重連ws

- 建立ping定時器,每隔30秒進行一次ping

- 通過ws接口,獲得所有未讀消息,客戶端進行處理,推送到通知欄等

- 接收新消息推送,并顯示到消息列表

- 當點擊進某個群/好友消息界面時,自動獲取最新n條消息,用戶上拉時繼續(xù)獲取n條

行模式運

cgi 協(xié)議模式

cgi模式 通用網(wǎng)關接口（Common Gateway Interface）,它允許web服務器通過特定的協(xié)議與應用程序通信, 調用原理大概為:  

用戶請求->Web服務器接收請求->fork子進程  

調用程序/執(zhí)行程序->程序返回內容/程序調用結束->web服務器接收內容->返回給用戶  

由于每次用戶請求,都得fork創(chuàng)建進程調用一次程序,然后銷毀進程,所以性能較低  

fast-cgi 協(xié)議模式

fast-cgi是cgi模式的升級版,它像是一個常駐型的cgi,只要開啟后,就可一直處理請求,不再需要結束進程, 調用原理大概為:  

web服務器fast-cgi進程管理器初始化->預先fork n個進程  

用戶請求->web服務器接收請求->交給fast-cgi進程管理器->fast-cgi進程管理區(qū)接收,給其中一個空閑fast-cgi進程處理->處理完成,fast-cgi進程變?yōu)榭臻e狀態(tài),等待下次請求->web服務器接收內容->返回給用戶模塊模式  

模塊模式

apache+php運行時,默認使用的是模塊模式,它把php作為apache的模塊隨apache啟動而啟動,接收到用戶請求時則直接通過調用mod_php模塊進行處理,詳細內容可自行百度

php-cli模式

php-cli模式屬于命令行模式,對于很多剛開始學php就開始wamp,wnmp的開發(fā)者來說是最陌生的一種運行模式

該模式不需要借助其他程序,直接輸入php xx.php 就能執(zhí)行php代碼

命令行模式和常規(guī)web模式明顯不一樣的是:

• * 沒有超時時間

• * 默認關閉buffer緩沖

• * STDIN和STDOUT標準輸入/輸出/錯誤 的使用

• * echo var_dump,phpinfo等輸出直接輸出到控制臺

• * 可使用的類/函數(shù) 不同

• * php.ini配置的不同

php-fpm

PHP-FPM（FastCGI 進程管理器）用于替換 PHP FastCGI 的大部分附加功能，對于高負載網(wǎng)站是非常有用的。

它的功能包括:

• 支持平滑停止/啟動的高級進程管理功能;

• 可以工作于不同的 uid/gid/chroot 環(huán)境下，并監(jiān)聽不同的端口和使用不同的 php.ini 配置文件（可取代 safe_mode 的設置）;

• stdout 和 stderr 日志記錄;

• 在發(fā)生意外情況的時候能夠重新啟動并緩存被破壞的 opcode;

• 文件上傳優(yōu)化支持;

• "慢日志" - 記錄腳本（不僅記錄文件名，還記錄 PHP backtrace 信息，可以使用 ptrace或者類似工具讀取和分析遠程進程的運行數(shù)據(jù)）運行所導致的異常緩慢;

• fastcgi_finish_request() - 特殊功能：用于在請求完成和刷新數(shù)據(jù)后，繼續(xù)在后臺執(zhí)行耗時的工作（錄入視頻轉換、統(tǒng)計處理等）;

• 動態(tài)／靜態(tài)子進程產生;

• 基本 SAPI 運行狀態(tài)信息（類似Apache的 mod_status）;

• 基于 php.ini 的配置文件。

工作原理:

它的工作原理大概為:

php-fpm啟動->生成n個fast-cgi協(xié)議處理進程->監(jiān)聽一個端口等待任務

用戶請求->web服務器接收請求->請求轉發(fā)給php-fpm->php-fpm交給一個空閑進程處理

->進程處理完成->php-fpm返回給web服務器->web服務器接收數(shù)據(jù)->返回給用戶

網(wǎng)絡協(xié)議

網(wǎng)絡協(xié)議為計算機網(wǎng)絡中進行數(shù)據(jù)交換而建立的規(guī)則,標準或約定的集合,所有的計算機/手機等網(wǎng)絡設備通信都得遵循網(wǎng)絡協(xié)議.

網(wǎng)絡協(xié)議根據(jù)通信的步驟,層級劃分為7個層級,從上往下為:

• 應用層

• 表示層

• 會話層

• 傳輸層

• 網(wǎng)絡層

• 數(shù)據(jù)鏈路層

• 物理層

ip協(xié)議(網(wǎng)絡層)

ip協(xié)議是互聯(lián)網(wǎng)的基礎協(xié)議,它是目前最流行的一種網(wǎng)絡協(xié)議

范圍

IP的責任就是把數(shù)據(jù)從源傳送到目的地。它不負責保證傳送可靠性，流控制，包順序和其它對于主機到主機協(xié)議來說很普通的服務。

接口

這個協(xié)議由主機到主機協(xié)議調用，而此協(xié)議負責調用本地網(wǎng)絡協(xié)議將數(shù)據(jù)包傳送以下一個網(wǎng)關或目的主機。例如TCP可以調用IP協(xié)議，在調用時傳送目的地址和源地址作為參數(shù)，IP形成數(shù)據(jù)包并調用本地網(wǎng)絡（協(xié)議）接口傳送數(shù)據(jù)包。

操作

IP實現(xiàn)兩個基本功能：尋址和分段。IP可以根據(jù)數(shù)據(jù)包包頭中包括的目的地址將數(shù)據(jù)包傳送到目的地址，在此過程中IP負責選擇傳送的道路，這種選擇道路稱為路由功能。如果有些網(wǎng)絡內只能傳送小數(shù)據(jù)包，IP可以將數(shù)據(jù)包重新組裝并在報頭域內注明。IP模塊中包括這些基本功能，這些模塊存在于網(wǎng)絡中的每臺主機和網(wǎng)關上，而且這些模塊（特別在網(wǎng)關上）有路由選擇和其它服務功能。對IP來說，數(shù)據(jù)包之間沒有什么聯(lián)系，對IP不好說什么連接或邏輯鏈路。

IP使用四個關鍵技術提供服務：服務類型，生存時間，選項和報頭校驗碼。服務類型指希望得到的服務質量。服務類型是一個參數(shù)集，這些參數(shù)是Internet能夠提供服務的代表。這種服務類型由網(wǎng)關使用，用于在特定的網(wǎng)絡，或是用于下下一個要經過的網(wǎng)絡，或是下一個要對這個數(shù)據(jù)包進行路由的網(wǎng)關上選擇實際的傳送參數(shù)。生存時間是數(shù)據(jù)包可以生存的時間上限。它由發(fā)送者設置，由經過路由的地方處理。如果未到達時生存時間為零，拋棄此數(shù)據(jù)包。對于控制函數(shù)來說選項是重要的，但對于通常的通信來說它沒有存在的必要。選項包括時間戳，安全和特殊路由。報頭校驗碼保證數(shù)據(jù)的正確傳輸。如果校驗出錯，拋棄整個數(shù)據(jù)包。

ip地址

把數(shù)據(jù)從源傳送到目的地時,需要有ip地址才能傳輸,現(xiàn)在ip地址分為ipv4和ipv6 兩種地址,現(xiàn)在最常見的就是ipv4地址,例如127.0.0.1(本機地址) 119.75.217.109(百度ip)

ip傳輸必須要有明確的ip地址,才能進行數(shù)據(jù)發(fā)送

tcp(傳輸層)

TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC 793定義。在簡化的計算機網(wǎng)絡OSI模型中，它完成第四層傳輸層所指定的功能，用戶數(shù)據(jù)報協(xié)議（UDP）是同一層內 另一個重要的傳輸協(xié)議。在因特網(wǎng)協(xié)議族（Internet protocol suite）中，TCP層是位于IP層之上，應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。

應用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)?、?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分區(qū)成適當長度的報文段（通常受該計算機連接的網(wǎng)絡的數(shù)據(jù)鏈路層的最大傳輸單元（ MTU）的限制）。之后TCP把結果包傳給IP層，由它來通過網(wǎng)絡將包傳送給接收端實體 的TCP層。TCP為了保證不發(fā)生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的包發(fā)回一個相應的確認（ACK）；如果發(fā)送端實體在合理的往返時延（RTT）內未收到確認，那么對應的數(shù)據(jù)包就被假設為已丟失將會被進行重傳。TCP用一個校驗和函數(shù)來檢驗數(shù)據(jù)是否有錯誤；在發(fā)送和接收時都要計算校驗和。

三次握手

TCP是因特網(wǎng)中的傳輸層協(xié)議，使用三次握手協(xié)議建立連接。當主動方發(fā)出SYN連接請求后，等待對方回答SYN+ACK ，并最終對對方的 SYN 執(zhí)行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接，TCP使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。 TCP三次握手的過程如下：

• 客戶端發(fā)送SYN（SEQ=x）報文給服務器端，進入SYN_SEND狀態(tài)。

• 服務器端收到SYN報文，回應一個SYN （SEQ=y）ACK(ACK=x+1）報文，進入SYN_RECV狀態(tài)。

• 客戶端收到服務器端的SYN報文，回應一個ACK(ACK=y+1）報文，進入Established狀態(tài)。

連接成功

連接成功之后雙方即可互相傳輸字節(jié)流,并隨時可關閉連接,傳輸?shù)臄?shù)據(jù)有以下特性

• 傳輸?shù)臄?shù)據(jù)被tcp分割成了最適合發(fā)送的數(shù)據(jù)塊 傳遞給ip協(xié)議,這個發(fā)送數(shù)據(jù)稱為 報文段 或 段

• tcp作為可靠性連接,每次發(fā)送數(shù)據(jù)段,會啟動一個定時器,每次接收數(shù)據(jù)段,會發(fā)送一次確認,如果定時器沒有及時收到確認,則會重發(fā)數(shù)據(jù)

• TCP將保持它首部和數(shù)據(jù)的檢驗和。這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段（希望發(fā)端超時并重發(fā)）。

• 兩個應用程序通過TCP連接交換8bit字節(jié)構成的字節(jié)流。TCP不在字節(jié)流中插入記錄標識符。我們將這稱為字節(jié)流服務（bytestreamservice）。如果一方的應用程序先傳10字節(jié)，又傳20字節(jié)，再傳50字節(jié)，連接的另一方將無法了解發(fā)方每次發(fā)送了多少字節(jié)。只要自己的接收緩存沒有塞滿，TCP 接收方將有多少就收多少。一端將字節(jié)流放到TCP連接上，同樣的字節(jié)流將出現(xiàn)在TCP連接的另一端。

四次揮手

建立一個連接需要三次握手，而終止一個連接要經過四次揮手，這是由TCP的半關閉（half-close）造成的。具體過程如下所示。

• 某個應用進程首先調用close，稱該端執(zhí)行“主動關閉”（active close）。該端的TCP于是發(fā)送一個FIN分節(jié)，表示數(shù)據(jù)發(fā)送完畢。

• 接收到這個FIN的對端執(zhí)行 “被動關閉”（passive close），這個FIN由TCP確認。

• 注意：FIN的接收也作為一個文件結束符（end-of-file）傳遞給接收端應用進程，放在已排隊等候該應用進程接收的任何其他數(shù)據(jù)之后，因為，F(xiàn)IN的接收意味著接收端應用進程在相應連接上再無額外數(shù)據(jù)可接收。

• 一段時間后，接收到這個文件結束符的應用進程將調用close關閉它的套接字。這導致它的TCP也發(fā)送一個FIN。

• 接收這個最終FIN的原發(fā)送端TCP（即執(zhí)行主動關閉的那一端）確認這個FIN。 既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節(jié)。

“通?！笔侵?，某些情況下，步驟1的FIN隨數(shù)據(jù)一起發(fā)送，另外，步驟2和步驟3發(fā)送的分節(jié)都出自執(zhí)行被動關閉那一端，有可能被合并成一個分節(jié)。 在步驟2與步驟3之間，從執(zhí)行被動關閉一端到執(zhí)行主動關閉一端流動數(shù)據(jù)是可能的，這稱為“半關閉”（half-close）。 當一個Unix進程無論自愿地（調用exit或從main函數(shù)返回）還是非自愿地（收到一個終止本進程的信號）終止時，所有打開的描述符都被關閉，這也導致仍然打開的任何TCP連接上也發(fā)出一個FIN。 無論是客戶還是服務器，任何一端都可以執(zhí)行主動關閉。通常情況是，客戶執(zhí)行主動關閉，但是某些協(xié)議，例如，HTTP/1.0卻由服務器執(zhí)行主動關閉。

php中的tcp

php可通過socket函數(shù),swoole擴展,stream流函數(shù)進行創(chuàng)建tcp協(xié)議的socket,綁定網(wǎng)卡端口,進行tcp服務端/客戶端操作 在php中,我們并不需要了解tcp的握手/揮手,我們只需要知道ip:port能連接/創(chuàng)建 一個tcp服務端/客戶端就行了

使用php的socket,我們可以直接發(fā)送字符串,接收的也是字符串,其他一切都是語言,操作系統(tǒng)所需要做的事,

我們只需要處理好字符串的完整性,例如我們使用php做tcp服務端

• 客戶端連接成功后,發(fā)送了一個"easyswoole是一個非常好的swoole框架"的字符串

• 而服務端每次只接收9個字節(jié),那第一次獲取只會接收到"easyswool"的殘缺字符串,需要繼續(xù)獲取數(shù)據(jù)

http協(xié)議

過程解析

http一次請求的過程大概如下:

• 用戶在瀏覽器輸入   www.easyswoole.com

• dns服務器解析/或者本機hosts,路由器hosts對比 獲得ip

• 瀏覽器訪問默認端口80,則訪問的tcp地址為 ip:80

• tcp協(xié)議3次握手,建立連接

• 發(fā)送一個http request請求頭

• 服務器獲得http request請求頭,表明該次訪問為http訪問,解析http請求頭,獲得請求類型,請求格式,以及請求數(shù)據(jù)(cookie,get,post數(shù)據(jù))

• 服務器發(fā)送response響應數(shù)據(jù),主動斷開

• 瀏覽器接收response響應數(shù)據(jù),解析響應文本類型,解析數(shù)據(jù),斷開連接

  https協(xié)議中,在請求以及響應時多了一層tls,ssl加密解密協(xié)議,默認端口從80變?yōu)榱?43  

phper中的http

由于php大部分時候都是用于web服務器,所以php開發(fā)者接觸最多的協(xié)議也就是基于tcp/ip協(xié)議的http協(xié)議了

在php初級程序員中,其實沒有詳細的了解過http協(xié)議,但是可以通過瀏覽器的f12->network去查看http協(xié)議具體的請求頭,以及服務端發(fā)送的響應頭

WebSocket協(xié)議

產生背景

在沒有WebSocket協(xié)議之前,在網(wǎng)頁中,實現(xiàn)一個聊天室只能使用ajax 不斷輪詢,請求服務器是否有數(shù)據(jù)產生,而這樣的實現(xiàn)方法會出現(xiàn)一系列的問題:

• 如果輪詢時間間隔太短,會導致客戶端和服務端在一個時間段內不斷的進行http tcp的握手/揮手動作和http 請求頭,響應頭的傳輸,大量消耗服務器資源,如果用戶量大的情況,會造成服務器的繁忙以至于宕機

• 客戶端每次只能通過發(fā)送http 請求獲得服務器是否有數(shù)據(jù)返回,且數(shù)據(jù)的及時性無法保證

正因為在這種情況下,所以WebSocket出現(xiàn)了,它只需要一次http握手,就可以保持一個長連接,使得服務器可以主動發(fā)送消息給客戶端,大大減少了輪詢機制的消耗

實現(xiàn)原理

在實現(xiàn)websocket連線過程中，需要通過瀏覽器發(fā)出websocket連線請求，然后服務器發(fā)出回應，這個過程通常稱為“握手”  。

在 WebSocket API，瀏覽器和服務器只需要做一個握手的動作，然后，瀏覽器和服務器之間就形成了一條快速通道。

兩者之間就直接可以數(shù)據(jù)互相傳送。在此WebSocket 協(xié)議中，為我們實現(xiàn)即時服務帶來了兩大好處：

• Header: 互相溝通的Header是很小的-大概只有 2 Bytes

• Server Push: 服務器的推送，服務器不再被動的接收到瀏覽器的請求之后才返回數(shù)據(jù)，而是在有新數(shù)據(jù)時就主動推送給瀏覽器。

udp(傳輸層)

UDP 是User Datagram Protocol的簡稱， 中文名是用戶數(shù)據(jù)報協(xié)議，是OSI（Open System Interconnection，開放式系統(tǒng)互聯(lián)） 參考模型中一種無連接的傳輸層協(xié)議，提供面向事務的簡單不可靠信息傳送服務，IETF RFC 768是UDP的正式規(guī)范。UDP在IP報文的協(xié)議號是17。

UDP協(xié)議全稱是用戶數(shù)據(jù)報協(xié)議，在網(wǎng)絡中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。在OSI模型中，在第四層——傳輸層，處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對數(shù)據(jù)包進行排序的缺點，也就是說，當報文發(fā)送之后，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網(wǎng)絡應用。包括網(wǎng)絡視頻會議系統(tǒng)在內的眾多的客戶/服務器模式的網(wǎng)絡應用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協(xié)議所掩蓋，但是即使是在今天UDP仍然不失為一項非常實用和可行的網(wǎng)絡傳輸層協(xié)議。

與所熟知的TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP協(xié)議直接位于IP（網(wǎng)際協(xié)議）協(xié)議的頂層。根據(jù)OSI（開放系統(tǒng)互連）參考模型，UDP和TCP都屬于傳輸層協(xié)議。UDP協(xié)議的主要作用是將網(wǎng)絡數(shù)據(jù)流量壓縮成數(shù)據(jù)包的形式。一個典型的數(shù)據(jù)包就是一個二進制數(shù)據(jù)的傳輸單位。每一個數(shù)據(jù)包的前8個字節(jié)用來包含報頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。

udp與tcp

udp和tcp都屬于傳輸層的協(xié)議,都位于ip協(xié)議的頂層,他們不同之處有:

• udp是無連接協(xié)議,不需要進行tcp的握手

• udp每次發(fā)送最大長度是65535,而tcp在握手后可以源源不斷的發(fā)送

• udp協(xié)議使用報頭中的校驗值來保證數(shù)據(jù)的安全。校驗值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。如果某個數(shù)據(jù)報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發(fā)送和接收方的校驗計算值將不會相符，由此UDP協(xié)議可以檢測是否出錯。這與TCP協(xié)議是不同的，后者要求必須具有校驗值。

• udp報文沒有可靠性保證、順序保證和流量控制字段等，可靠性較差。但是正因為udp協(xié)議的控制選項較少，在數(shù)據(jù)傳輸過程中延遲小、數(shù)據(jù)傳輸效率高，適合對可靠性要求不高的應用程序，或者可以保障可靠性的應用程序，如DNS、TFTP、SNMP等。

• 在網(wǎng)絡質量令人十分不滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會比較嚴重。而tcp會進行確認驗證,確保對方接收成功

• udp可實現(xiàn)對網(wǎng)關內的所有主機進行廣播

php多進程

多進程的概念

前面有講到,多進程主要是在開發(fā)業(yè)務邏輯層面,并行處理多個任務的開發(fā)方式,什么叫做開發(fā)業(yè)務邏輯層面呢?

在上面我們有講到,php-fpm是fast-cgi的進程管理器,啟動之后會啟動多個fast-cgi進程,等待任務處理

在php-fpm軟件層面,fast-cgi的多個進程就屬于多進程處理,但是,當用戶發(fā)起請求,

由nginx交給php-fpm處理請求時,在這個層面,每個請求其實只占有一個php fast-cgi進程進行處理邏輯,對于運行業(yè)務邏輯的這個php進程,其實是單進程的.

同理,當我們直接運行一個php文件時,默認是只開啟了一個php進程進行運行php的代碼

多進程的開發(fā)場景

在傳統(tǒng)web模式下,php一向是單進程處理業(yè)務邏輯,只有在php-cli模式下,用于處理異步任務,作為網(wǎng)絡服務器時,才可能用到多進程處理,所以,大部分phper都對php多進程的概念不熟悉

使用pcntl擴展

進程通信

• 管道通信,分為有名管道,無名管道等,可自行搜索了解詳細

• 消息隊列通信,使用linux消息隊列,通過sysvmsg擴展,可查看:   http://www.php20.cn/article/137

• 進程信號通信,可查看:   http://www.php20.cn/article/134

• 共享內存通信,映射一段能被其他進程所訪問的內存，這段共享內存由一個進程創(chuàng)建，但多個進程都可以訪問。

• 共享內存是最快的 IPC 方式，它是針對其他進程間通信方式運行效率低而專門設計的。

• 它往往與其他通信機制，如信號兩，配合使用，來實現(xiàn)進程間的同步和通信。

• 套接字通信

• 第三方通信,使用文件操作,mysql,redis等方法也可實現(xiàn)通信

協(xié)程

協(xié)程不是進程或線程，其執(zhí)行過程更類似于子例程，或者說不帶返回值的函數(shù)調用。

一個程序可以包含多個協(xié)程，可以對比與一個進程包含多個線程，因而下面我們來比較協(xié)程和線程。

我們知道多個線程相對獨立，有自己的上下文，切換受系統(tǒng)控制；而協(xié)程也相對獨立，

有自己的上下文，但是其切換由自己控制，由當前協(xié)程切換到其他協(xié)程由當前協(xié)程來控制。

協(xié)程與進程

由上面的協(xié)程執(zhí)行順序中的代碼2,我們很容易發(fā)現(xiàn),協(xié)程其實只是運行在一個進程中的函數(shù),只是這個函數(shù)會被切換到下一個執(zhí)行,可以這么說:

協(xié)程只是一串運行在進程中的任務代碼,只是這些任務代碼可以交叉運行 注意,協(xié)程并不是多任務并行,屬于多任務串行,每個進程在一個時間只執(zhí)行了一個任務

協(xié)程的作用域

由于協(xié)程就是進程中一串任務代碼,所以它的全局變量,靜態(tài)變量等變量都是共享的,包括了php的全局緩沖區(qū).

所以,在開發(fā)之中,需要特別注意協(xié)程中的全局變量,靜態(tài)變量,只要某一個協(xié)程內修改了,那將會影響全部的協(xié)程,在使用ob緩沖區(qū)函數(shù)攔截的時候,也得考慮是否會被其他協(xié)程的輸出給污染.

用 協(xié)程執(zhí)行順序中的代碼2解釋,當task1給$_GET['name']賦值為1時,task2讀取$_GET['name']也會是1,task2將$_GET['name']賦值為2時,task3讀取$_GET['name']也會是2

協(xié)程中的I/O連接

在協(xié)程中,要特別注意不能共用一個I/O連接,否則會造成數(shù)據(jù)異常. 用協(xié)程執(zhí)行順序中的代碼2解釋,當task1,task2函數(shù)共用mysql連接,并都進行查詢時,由于協(xié)程是交叉運行的,可能會造成task1獲取到task1+task2查詢出來的數(shù)據(jù),也可能會丟失部分數(shù)據(jù),被task2獲取.

由于協(xié)程的交叉運行機制,各個協(xié)程的I/O連接都必須是獨立的,所以我們需要在每個協(xié)程都創(chuàng)建一個連接,但由于mysql,redis的連接數(shù)有限,以及連接的開啟關閉需要消耗大量資源,所以我們可以使用連接池方案實現(xiàn)共用連接(只要保證每個連接每次只有一個協(xié)程在使用即可)

到此，相信大家對“swoole知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！