【踩坑】 Supervisor 管理 Swoole 服务的优雅重启机制分析
1. 背景说明在生产环境中，通过 Supervisor 管理 Swoole 服务是常见做法。然而，在执行 supervisorctl restart 或 stop → start 时，开发者常遇到以下问题： 子进程（Swoole worker）无法被正常杀死 重启后依旧存在残留 worker 强制 kill -9 也无效（可能处于 IO 阻塞） 重启过程缓慢导致服务无法即时恢复 本文从 Swoole 进程模型、信号处理机制、Supervisor 行为、业务阻塞问题 等角度进行技术分析，并提供最佳实践配置与建议。 2. Swoole 进程模型概述Swoole Server（如 HTTP / WebSocket / TCP）的基本进程结构： Master Process│├── Manager Process│└── Worker Processes (N 个) 关键特点： Worker 是独立子进程，由 Swoole 的 Master 和 Manager 管理 Worker 在处理请求时必须“优雅退出”，不能强行中断 Worker 使用事件循环 ...
Cloudflare突发全球性故障 多知名网站出现服务异常
今天真是见鬼了。原本只是想像往常一样，用 ChatGPT 优化一下博客文字，结果发现——ChatGPT 打不开，Twitter 上不去，甚至连我自己一些依赖 Cloudflare 的服务也陆续抽风。打开 Cloudflare Status 一看，果然官方事故通报已经发布：（官方事件链接：你在正文里可以加上 Cloudflare 的公告，而不是裸链接） 这一波事故让我第一次真切地感受到什么叫“全球单点故障”。虽然 Cloudflare 本身并不是单点，但它确实已经深度融入全球互联网基础设施，只要它出现大规模问题，波及的范围就会非常可怕。 我自己的服务器架构其实很简单： DNS 解析：Cloudflare 代理功能：Cloudflare 后台服务接入：Cloudflare 理由：免费 + 隐藏源站 IP 本来只是图个方便，没想到今天这些便利成为了隐患。 Cloudflare 事故到底有什么影响？ 对于普通用户来说，就是“好多网站打不开”。但对站长来说，问题更具体： DNS 解析延迟甚至失败 代理层访问 5xx API 调用阻塞 某些地区极端不稳定 连 ChatGPT、Tw...
MQTT 协议简介（含 TCP 之上的协议结构）
1. MQTT 的定位MQTT（Message Queuing Telemetry Transport）是一个轻量级发布/订阅消息协议，专为 低带宽、低功耗、不稳定网络 设计，广泛用于物联网（IoT）。 2. MQTT 在网络协议栈中的位置MQTT 属于 应用层协议，其依赖关系如下： ┌───────────────────────┐│ MQTT 协议 │ ← 应用层└───────────────────────┘┌───────────────────────┐│ TCP 协议 │ ← 可靠的传输层└───────────────────────┘┌───────────────────────┐│ IP 协议（IPv4/6） │ ← 网络层└───────────────────────┘┌───────────────────────┐│ 数据链路层（WiFi/以太网）│└───────────────────────┘ ⭐ MQTT 只能跑在 TCP 上（默认 1883 端口，TLS ...
【踩坑】服务端单进程阻塞导致大量 408 / 499 的根因分析与解决思路
在最近的一次线上问题排查中，我们遇到一个非常典型、但也非常容易被忽略的情况：接口在高峰时段出现大量 HTTP 408（Request Timeout） 和 HTTP 499（Client Closed Request）。这些错误看上去像是网络不稳或负载过高，但最终定位到的根因却是——服务端单进程阻塞。 本文将结合架构图与示意图，从现象、原因到解决方案进行说明，希望能帮助你快速识别并处理类似问题。 一、问题现象：请求量不算大，但 408 / 499 飙升线上监控显示出两个异常指标： 408 Request Timeout：客户端等待超时 499 Client Closed Request：请求未完成前，客户端（或 Nginx）提前断开 这些错误大多在流量上涨时集中爆发，而非持续出现。换句话说，不是一个“总量型问题”，而是一个“阻塞导致的瞬时雪崩”。 二、根因：服务端单进程（单线程）阻塞进一步排查后发现核心原因是： 服务端使用单进程模型，当某个请求执行过慢时，会阻塞整个处理队列，导致后续请求全被拖延。 服务端整体处理流程示意图 ┌───────...
解决本地开发跨域问题：如何配置 Nginx 允许 `localhost` 调用后端接口
在前后端分离开发中，本地前端一般通过 http://localhost:3000、http://localhost:5173、http://localhost:8080 等地址运行，而后端接口常常部署在： https://api.example.com 由于协议、域名或端口不同，浏览器会触发 CORS（跨域访问限制），导致接口请求报错，例如： Access to fetch at 'https://api.example.com' from origin 'http://localhost:5173' has been blocked by CORS policy 要解决这个问题，我们可以在 Nginx 中为开发环境添加 跨域支持。 ✅ 正确理解：CORS 不允许写多个域名错误写法（无效）： add_header Access-Control-Allow-Origin http://localhost:5173, http://localhost:3000; 浏览器会直接忽略，因为 Access-Control-Allow-Or...
【踩坑】 file_get_contents 与 cURL 的 HTTP 协议版本坑点
🧩 背景在日常开发中，我们常常需要在 PHP 程序中抓取第三方接口数据。最常见的两种方式是： file_get_contents($url) cURL 扩展函数（如 curl_exec()） 在 PHP 7.2 的生产环境中，遇到了如下错误： PHP Warning: file_get_contents(https://test.1111.com/Info?...): failed to open stream: HTTP request failed! HTTP/1.0 400 Bad RequestThe content does not support HTTP/1.0 request. 🚨 问题分析1. file_get_contents 默认使用 HTTP/1.0 协议PHP 7.2 的 file_get_contents() 在处理 HTTP(S) 请求时，底层通过流封装器 (http wrapper) 实现，而该封装器默认使用 HTTP/1.0 协议。 很多现代接口服务器（尤其是基于 Nginx + HTTP/2 的 ...
SonarQube 代码审计工具
🧭 一、SonarQube 简介SonarQube 是一个开源的持续代码质量管理平台，支持包括 PHP 在内的多种语言。它可以帮助你检测： 潜在的 Bug 安全漏洞（Security Vulnerabilities） 代码异味（Code Smells） 测试覆盖率 重复代码 等 ⚙️ 二、环境准备1️⃣ 系统要求 Java 17+（SonarQube Server 运行需要） 数据库：PostgreSQL（推荐）、MySQL（老版本支持） SonarScanner（代码扫描器） SonarQube Server 🧩 三、安装步骤1️⃣ 下载 SonarQube前往官网：https://www.sonarsource.com/products/sonarqube/downloads/ 选择版本： Community Edition 免费版（支持 PHP） Developer / Enterprise Edition 提供更高级的规则与安全检测 解压后进入： cd sonarqube-<version>/bin 根据系统启动： # Lin...
[踩坑] 记一次 Swoole 报错排查：`swReactor_write (ERRNO 1008): socket#58 output buffer overflow`
在最近的项目中，我们线上脚本服务跑了一段时间后，日志里频繁出现如下警告： WARNING swReactor_write (ERRNO 1008): socket#58 output buffer overflow 起初看见这个报错有些懵，后来一番排查才确认根因：子进程给 worker 进程发送消息过大且过快，导致 Swoole 的输出缓冲区溢出。本文记录一下整个问题分析与解决过程。 1. 现象描述 服务运行一段时间后，Swoole 日志中出现大量 swReactor_write (ERRNO 1008): socket#XX output buffer overflow 服务本身没有立刻崩溃，但某些业务消息丢失。 报错定位在 子进程与 worker 进程通信 的场景。 2. 背景知识Swoole 在底层基于 异步事件循环 和 socket 通信。 当服务端往某个 socket 写数据时，Swoole 会先写入 输出缓冲区。 如果客户端（或目标进程）没有及时消费，缓冲区就会堆积。 一旦超过配置的阈值，就会报出 output buffer overflow 警告...
【踩坑】connect() failed: Connection timed out in 偶发超时问题排查与解决
在日常运维和开发中，我们经常会用到 Redis 作为缓存或消息存储。但线上偶尔会出现这样一个报错： [13-Sep-2025 15:59:16 Asia/Shanghai] PHP Warning: Redis::connect(): connect() failed: Connection timed out in /www/DB/RedisLibrary.php on line 31 这是 Redis 连接超时，在某些情况下会导致业务请求失败。本文记录一次排查过程以及优化方案。 一、问题现象 错误提示：Redis::connect() failed: Connection timed out 触发特征：偶尔发生，不是持续报错。 Redis 监控指标： connected_clients:1796blocked_clients:0used_cpu_sys:5712795used_cpu_user:4863491 看起来连接数和 CPU 占用都不高。 二、初步怀疑方向 Redis 崩溃/重启？→ 否，监控显示 Redis 稳定运行，未重启。 客户端...
如何在 Linux 上生成 PGP 公钥（支持老版本 GnuPG）
PGP（Pretty Good Privacy）是一种广泛使用的加密技术，常用于邮件加密、签名以及身份认证等安全场景。 本文介绍如何在 Linux 系统中使用 `gpg` 命令生成并导出 PGP 公钥，兼顾 **老版本 GnuPG** 与 **新版本 GnuPG（2.1+）**。---## 一、环境准备首先确认系统已安装 GnuPG：```bashgpg --version 输出类似： gpg (GnuPG) 2.0.22 如果你看到 gpg: invalid option "--quick-gen-key" 这样的报错，说明你用的是 老版本 GnuPG（如 2.0 / 1.x），该版本不支持 --quick-gen-key。本文将分别介绍两种版本的密钥生成方法。 二、老版本 GnuPG（无 --quick-gen-key）老版本（如 GnuPG 2.0 / 1.x）必须使用交互式命令： 1. 生成密钥对gpg --gen-key 然后按提示依次输入： 密钥类型：选择 1（RSA and RSA） 密钥长度：建议输入 409...
