postgresql的listen/notify配合php实现实时消息通知，核心在于利用长连接监听特定频道并在收到通知时触发业务逻辑。由于php通常是无状态的请求驱动模型，直接维持长连接较为困难，因此最佳实践是结合系统级进程管理工具（如supervisor）运行一个常驻的php监听脚本，或者使用支持异步io的扩展（如swoole、reactphp）。当应用需要发送通知时，通过标准的sql notify 命令将消息推送到数据库；监听进程在后台阻塞等待，一旦捕获到通知，便立即执行后续操作（如写入redis缓存、推送websocket或更新状态），从而实现低延迟的消息分发。
如何编写并启动常驻的PHP监听进程？
要实现真正的实时监听，必须打破PHP“请求-响应”的生命周期限制，让PHP进程在后台持续运行并调用 pg_get_notify()。这通常通过编写一个独立的CLI脚本，并使用Supervisor等进程管理器来保证其在崩溃后自动重启。监听脚本的核心逻辑是建立持久连接，进入循环等待状态，处理接收到的通知负载，并定期清理空闲连接以防超时断开。
<?php // listen_worker.php
require_once 'vendor/autoload.php';
$dsn = 'host=127.0.0.1 dbname=mydb user=postgres password=secret';
$conn = pg_connect($dsn);
if (!$conn) {
die("Connection failed\n");
}
// 监听名为 'notifications' 的频道
pg_query($conn, "LISTEN notifications;");
echo "Listening for notifications...\n";
while (true) {
// 获取通知，如果没有通知则阻塞等待
$result = pg_get_notify($conn, PGSQL_ASSOC);
if ($result) {
$pid = $result['pid'];
$channel = $result['channel'];
$payload = $result['payload'];
echo date('Y-m-d H:i:s') . " - Received on {$channel}: {$payload}\n";
// 在这里处理业务逻辑，例如：
// 1. 解析JSON payload
// 2. 写入Redis Pub/Sub
// 3. 触发内部事件队列
processNotification($payload);
}
// 可选：添加 usleep(100000); 防止CPU占用过高，但会引入微小延迟
// 对于高实时性要求，建议移除sleep或使用非阻塞轮询
}
function processNotification($payload) {
// 示例：简单的日志记录或数据库更新
error_log("Processing: " . $payload);
}
?>
上述代码展示了一个基础的监听器。在实际生产环境中，你需要将其放入 supervisord.conf 中进行管理，配置 autostart=true 和 autorestart=true。同时，需要注意数据库连接的空闲超时问题，如果长时间没有网络活动，PostgreSQL可能会断开连接。因此，在循环中偶尔发送一个简单的 SELECT 1 心跳查询是必要的维护手段，但这会稍微增加延迟，需根据实时性需求权衡。
如何在业务代码中触发通知并优化性能？
发送通知端（Producer）的代码非常轻量，只需执行一条 NOTIFY SQL语句即可。为了优化性能，应避免在高频事务中直接调用复杂的PHP函数库，而是直接使用PDO或PgSQL扩展执行原生SQL。此外，考虑到网络开销和数据库压力，通常建议在事务提交成功后再发送通知，或者将通知作为事务的一部分（PostgreSQL保证同一事务内的NOTIFY在事务提交后才对监听者可见）。
<?php // producer.php
$dsn = 'host=127.0.0.1 dbname=mydb user=postgres password=secret';
$conn = new PDO($dsn, 'postgres', 'secret');
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try {
$conn->beginTransaction();
// 1. 执行业务逻辑，例如插入订单
$stmt = $conn->prepare("INSERT INTO orders (user_id, amount) VALUES (:uid, :amt)");
$stmt->execute([':uid' => 101, ':amt' => 99.5]);
// 2. 发送通知，payload可以是JSON字符串
$orderId = $conn->lastInsertId();
$payload = json_encode(['order_id' => $orderId, 'status' => 'created']);
$conn->exec("NOTIFY notifications, '" . addslashes($payload) . "'");
$conn->commit();
echo "Order created and notification sent.\n";
} catch (Exception $e) {
$conn->rollBack();
echo "Error: " . $e->getMessage() . "\n";
}
?>
这种模式的优势在于解耦。业务代码不需要知道谁在监听，也不需要维护WebSocket连接池。然而，需要注意的是，NOTIFY 的负载大小有限制（通常为65KB），且仅适用于同集群内的低延迟场景。如果需要跨地域或极高并发，建议将PostgreSQL NOTIFY作为触发器，进一步转发至Redis Pub/Sub或RabbitMQ等专门的消息中间件。另外，务必对 $payload 进行转义或使用参数化查询的安全替代方案，虽然 NOTIFY 不支持预编译参数，但手动转义单引号是防止SQL注入的关键步骤。
如何处理监听进程崩溃或连接断开的情况？
在长期运行的PHP监听进程中，网络波动、数据库重启或PHP内存泄漏都可能导致连接中断或进程挂死。单纯的 while(true) 循环无法自动恢复这些状态。因此，必须在代码层面实现重连机制和健康检查。当 pg_get_notify() 或任何数据库操作返回 false 或抛出异常时，程序应捕获错误，关闭当前连接，等待短暂时间后重新建立连接并重新执行 LISTEN 命令。
<?php // 改进的重连逻辑片段
$retryDelay = 5; // 秒
$maxRetries = 3;
while (true) {
try {
if (!$conn || pg_connection_status($conn) == PGSQL_CONNECTION_BAD) {
echo "Reconnecting...\n";
$conn = pg_connect($dsn);
pg_query($conn, "LISTEN notifications;");
}
$result = pg_get_notify($conn, PGSQL_ASSOC);
if ($result) {
processNotification($result['payload']);
} else {
// 如果没有通知，可以休眠一小段时间以减少CPU空转
// 注意：这会引入最大500ms的延迟
usleep(100000);
}
} catch (Exception $e) {
echo "Error: " . $e->getMessage() . ". Retrying in {$retryDelay}s...\n";
sleep($retryDelay);
$conn = null; // 强制断开坏连接
}
}
?>
除了代码层面的重连，基础设施层面的监控同样重要。建议使用Prometheus + Grafana监控监听进程的存活状态和消息处理延迟。如果进程意外退出，Supervisor会自动拉起新进程，但新进程不会“补听”在它离线期间发出的通知。这意味着对于关键业务，可能需要结合数据库日志表（Write-Ahead Log）或外部消息队列来确保消息不丢失，PostgreSQL NOTIFY本身更适合用于最终一致性要求的实时状态同步，而非严格的事务性消息传递。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
