❶ 在php隊列php-resque里頭使用了資料庫的單例模式顯示MySQL server has gone away
PHP的輕量消息隊列php-resque使用說明
消息隊列處理後台任務帶來的問題
項目中經常會有後台運行任務的需求，比如發送郵件時，因為要連接郵件伺服器，往往需要5-10秒甚至更長時間，如果能先給用戶一個成功的提示信息，然後在後台慢慢處理發送郵件的操作，顯然會有更好的用戶體驗。
為了實現類似的需求，Web項目中一般的實現方法是使用消息隊列(Message Queue)，比如MemcacheQ，RabbitMQ等等，都是很著名的產品。
消息隊列說白了就是一個最簡單的先進先出隊列，隊列的一個成員就是一段文本。正是因為消息隊列實在太簡單了，當拿著消息隊列時，反而有點無從下手的感覺，因為這僅僅一個發送郵件的任務，就會引申出很多問題：
消息隊列只能存儲字元串類型的數據，如何將一個發送郵件這樣的「任務」，轉換為消息隊列中的一個「消息」?
消息隊列只負責數據的存放與進出，本身不能執行任何程序，那麼我們要如何從消息隊列中一個一個取出數據，再將這些數據轉化回任務並執行。
我們無法預知消息隊列何時會有數據產生，所以我們的任務執行程序還需要具備監控消息隊列的能力，也就是一個常駐後台的守護進程。
一般的Web應用PHP都以cgi方式運行，無法常駐內存。我們知道php還有cli模式，那麼守護進程是否能以php cli來實現，效率如何？
當守護進程運行時，Web應用能否與後台守護進程交互，實現開啟/殺死進程的功能以及獲得進程的運行狀態？
Resque對後台任務的設計與角色劃分
對以上這些問題，目前為止我能找到的最好答案，並不是來自php，而是來自Ruby的項目Resque，正是由於Resque清晰簡單的解決了後台任務帶來的一系列問題，Resque的設計也被Clone到Python、php、NodeJs等語言：比如Python下的pyres以及PHP下的php-resque等等，這里有各種語言版本的Resque實現，而在本篇日誌里，我們當然要以PHP版本為例來說明如何用php-resque運行一個後台任務，可能一些細節方面會與Ruby版有出入，但是本文中以php版為准。
Resque是這樣解決這些問題的：
後台任務的角色劃分
其實從上面的問題已經可以看出，只靠一個消息隊列是無法解決所有問題的，需要新的角色介入。在Resque中，一個後台任務被抽象為由三種角色共同完成：
Job | 任務 ： 一個Job就是一個需要在後台完成的任務，比如本文舉例的發送郵件，就可以抽象為一個Job。在Resque中一個Job就是一個Class。
Queue | 隊列 ： 也就是上文的消息隊列，在Resque中，隊列則是由Redis實現的。Resque還提供了一個簡單的隊列管理器，可以實現將Job插入/取出隊列等功能。
Worker | 執行者 ： 負責從隊列中取出Job並執行，可以以守護進程的方式運行在後台。
那麼基於這個劃分，一個後台任務在Resque下的基本流程是這樣的：
將一個後台任務編寫為一個獨立的Class，這個Class就是一個Job。
在需要使用後台程序的地方，系統將Job Class的名稱以及所需參數放入隊列。
以命令行方式開啟一個Worker，並通過參數指定Worker所需要處理的隊列。
Worker作為守護進程運行，並且定時檢查隊列。
當隊列中有Job時，Worker取出Job並運行，即實例化Job Class並執行Class中的方法。
至此就可以完整的運行完一個後台任務。
在Resque中，還有一個很重要的設計：一個Worker，可以處理一個隊列，也可以處理很多個隊列，並且可以通過增加Worker的進程/線程數來加快隊列的執行速度。
php-resque的安裝
需要提前說明的是，由於涉及到進程的開辟與管理，php-resque使用了php的PCNTL函數，所以只能在Linux下運行，並且需要php編譯PCNTL函數。如果希望用Windows做同樣的工作，那麼可以去找找Resque的其他語言版本，php在Windows下非常不適合做後台任務。
以Ubuntu12.04LTS為例，Ubuntu用apt安裝的php已經默認編譯了PCNTL函數，無需任何配置，以下指令均為root帳號安裝Redis
apt-get install redis-server
安裝Composer
apt-get install curl
cd /usr/local/bin
curl -s http://getcomposer.org/installer | phpchmod a+x composer.phar
alias composer='/usr/local/bin/composer.phar'
使用Composer安裝php-resque
假設web目錄在/opt/htdocs
apt-get install git git-core
cd /opt/htdocs
git clone git://github.com/chrisboulton/php-resque.gitcd php-resque
composer install
php-resque的使用
編寫一個Worker
其實php-resque已經給出了簡單的例子， demo/job.php文件就是一個最簡單的Job：
class PHP_Job
{
public function perform()
{
sleep(120);
fwrite(STDOUT, 'Hello!');
}
}
這個Job就是在120秒後向STDOUT輸出字元Hello!
在Resque的設計中，一個Job必須存在一個perform方法，Worker則會自動運行這個方法。
將Job插入隊列
php-resque也給出了最簡單的插入隊列實現 demo/queue.php：
if(empty($argv[1])) {
die('Specify the name of a job to add. e.g, php queue.php PHP_Job');}
require __DIR__ . '/init.php';
date_default_timezone_set('GMT');
Resque::setBackend('127.0.0.1:6379');
$args = array(
'time' => time(),
'array' => array(
'test' => 'test',
),
);
$jobId = Resque::enqueue('default', $argv[1], $args, true);echo "Queued job ".$jobId."\n\n";
在這個例子中，queue.php需要以cli方式運行，將cli接收到的第一個參數作為Job名稱，插入名為'default'的隊列，同時向屏幕輸出剛才插入隊列的Job Id。在終端輸入：
php demo/queue.php PHP_Job
結果可以看到屏幕上輸出：
Queued job 即Job已經添加成功。注意這里的Job名稱與我們編寫的Job Class名稱保持一致：PHP_Job查看Job運行情況
php-resque同樣提供了查看Job運行狀態的例子，直接運行：
php demo/check_status.php 可以看到輸出為：
Tracking status of . Press [break] to stop.
Status of is: 1我們剛才創建的Job狀態為1。在Resque中，一個Job有以下4種狀態：
Resque_Job_Status::STATUS_WAITING = 1; (等待)Resque_Job_Status::STATUS_RUNNING = 2; (正在執行)Resque_Job_Status::STATUS_FAILED = 3; (失敗)Resque_Job_Status::STATUS_COMPLETE = 4; (結束)因為沒有Worker運行，所以剛才創建的Job還是等待狀態。
運行Worker
這次我們直接編寫demo/resque.php：
<?php
date_default_timezone_set('GMT');
require 'job.php';
require '../bin/resque';
可以看到一個Worker至少需要兩部分：
可以直接包含Job類文件，也可以使用php的自動載入機制，指定好Job Class所在路徑並能實現自動載入包含Resque的默認Worker： bin/resque
在終端中運行：
QUEUE=default php demo/resque.php
前面的QUEUE部分是設置環境變數，我們指定當前的Worker只負責處理default隊列。也可以使用QUEUE=* php demo/resque.php
來處理所有隊列。
運行後輸出為
#!/usr/bin/env php
*** Starting worker
用ps指令檢查一下：
ps aux | grep resque
可以看到有一個php的守護進程已經在運行了
1000 4607 0.0 0.1 74816 11612 pts/3 S+ 14:52 0:00 php demo/resque.php再使用之前的檢查Job指令
php demo/check_status.php 2分鍾後可以看到
Status of is: 4任務已經運行完畢，同時屏幕上應該可以看到輸出的Hello!
至此我們已經成功的完成了一個最簡單的Resque實例的全部演示，更復雜的情況以及遺留的問題會在下一次的日誌中說明。
❷ 學習thinkphp6.0使用rabbitmq示例
以下是如何在ThinkPHP 6.0中使用RabbitMQ進行示例，並通過supervisor實現消費者守護的簡要步驟：
RabbitMQ的關鍵概念包括：Broker（消息隊列服務）、Exchange（消息路由）、Queue（消息隊列）、Binding（綁定關系）和Routingkey（路由鍵）。消息流程包括生產者通過Exchange將消息路由到Queue，Queue再將消息分發給消費端。
❸ PHP實現消息隊列MQ
MQ的應用場景主要解決非同步消息、應用解耦、流量消峰等問題，同時也常用於日誌處理。然而，MQ的引入導致系統可用性降低，因為系統需要考慮消息隊列的可靠性，避免系統因消息隊列故障而宕機。此外，MQ的引入增加了系統復雜性，需要處理一致性問題、防止消息重復消費和確保消息可靠傳輸。
對於消息重復消費的問題，解決方法如下：
消息模型分為P2P模式（點對點模式）和Pub/Sub（發布訂閱模式）。P2P模式下，一個消息只能被一個消費者處理，包含消息隊列、發送者和接受者三個角色。Work模式又分為輪循隊列（一對多）和能者多勞（一對多）兩種，每個消息只有一個消費者。發送者和接受者之間沒有時間依賴性，接受者確認消息的接受和處理。
Pub/Sub模式下，包含主題、發布者和訂閱者三個角色，一個生產者可以向多個消費者發送消息，消息經過交換機到達隊列。Exchange（轉發器）負責接受生產者的消息並將其推送到隊列，實現一個消息被多個消費者消費。此外，還有Direct（路由模式）、Fanout（訂閱模式）等模式。
在PHP中實現消息隊列，首先需要安裝RabbitMQ擴展，並在項目中添加Composer.json文件以整合RabbitMQ。實現包括簡單模式（一對一）、Work模式（輪循隊列）、Work模式（能者多勞）、每個消息只有一個消費者、發送者和接受者沒有時間依賴、接受者確認消息接受和處理成功。
Pub/Sub模式在RabbitMQ中實現松耦合設計，通過主題、發布者和訂閱者進行消息的發布與訂閱。消息的持久化處理包括消息的可靠性機制、自動刪除隊列和交換機的設置以及消息確認機制。RabbitMQ的消息確認機制可以採用事務機制或Confirm機制，確保消息的可靠傳輸。
以上內容旨在幫助PHP開發者理解和實現消息隊列的功能。更多進階資料，包括分布式架構、高可擴展性、高性能、高並發、伺服器性能調優、TP6、Laravel、YII2、Redis、Swoole、Swoft、Kafka、Mysql優化、Shell腳本、Docker、微服務、Nginx等知識點的高級進階干貨，可關注公眾號「PHP開源社區」或訪問相關鏈接獲取更多資源。
❹ 延時 (遲) 操作的 PHP 簡單實現
在業務中，遇到延遲操作需求，比如下單半小時未支付取消訂單，或下單十五分鍾後未支付發簡訊提醒等場景。本文將介紹幾種實現方式。
實現方式分為幾種，首先，執行處理腳本在下單後定時運行，這種方式簡潔但不優雅，且在處理大量訂單時可能遇到性能瓶頸。
第二種方式是利用消費邏輯，在消費者中處理延遲操作，通過啟動生產消息與消費者等待，這種方式利用現有服務，減少開發時間。
第三種方式引入消息隊列如RabbitMQ。消費者啟動，通過生產者啟動消息，消息先入隊列，過期後進入死信隊列被消費，流轉過程清晰可見。
第四種方式，參考原文「延時（遲）操作的PHP簡單實現」，提供進階PHP學習資源，包括分布式架構、高並發、高性能等知識點，助力PHP開發者提升技能。
希望以上內容能幫助大家解決業務中遇到的延遲操作問題，推動PHP開發者在進階道路上成長。