PHP 怎么PHP 业务连续性

本文目录导读：

1. 应用层高可用
2. 容错与错误处理
3. 数据层连续性
4. 优雅降级（Graceful Degradation）
5. 部署与恢复
6. 总结：PHP 业务连续性清单

在 PHP 中实现业务连续性（Business Continuity），通常指的是确保核心业务在遇到故障、流量高峰或数据损坏时，能够持续提供服务并快速恢复，完善的业务连续性涉及架构设计、代码逻辑、运维部署等多个层面，你需要从高可用架构、错误处理、数据一致性、优雅降级与快速恢复四个方面考虑。

以下是针对 PHP 业务连续性的实践策略：

应用层高可用

PHP 是动态语言，通常不擅长保持长连接状态（传统模式下），实现高可用需要从无状态化入手。

• 无状态设计：

  • 将用户 Session 从本地文件系统迁移到共享存储，如 Redis 或 Memcached 集群，这样，当某一台 PHP 服务器宕机时，用户的请求可以平滑切换到另一台服务器，Session 数据不丢失。
  • 避免在 PHP 进程中存储业务数据（如数据库连接池、单例变量的缓存），如果必须，使用进程外缓存（如 APCu + Redis）。

• 负载均衡与健康检查：

  • 前端使用 Nginx/HAProxy 进行负载均衡。
  • 在 Nginx 配置中设置 max_fails 和 fail_timeout，如果某台 PHP-FPM 处理速度变慢或返回 502/504，自动将其从上游集群中移除。
  • PHP 健康检查端点：提供一个简单的健康检查路由（如 /health），仅返回 HTTP 200，不依赖数据库或外部服务，用于负载均衡器判断机器是否存活。

  upstream php_backend {
      server 10.0.0.1:9000 max_fails=3 fail_timeout=30s;
      server 10.0.0.2:9000 max_fails=3 fail_timeout=30s;
      server 10.0.0.3:9000 backup; # 备用节点
  }

容错与错误处理

这是 PHP 代码层面容易忽视的地方，仅靠 try-catch 不够，需要全局兜底。

• 全局异常处理器：

  • 使用 set_exception_handler 和 set_error_handler 捕获所有未处理的异常。
  • 确保不会因为一次代码错误导致白屏,应该记录详细错误日志，并返回一个友好的错误页面（如 JSON {"code":500} 或静态 HTML 提示）。

  set_exception_handler(function ($e) {
      // 1. 记录完整错误到日志（包含堆栈）
      error_log("Uncaught Exception: " . $e->getMessage() . " in " . $e->getFile());
      // 2. 检查业务连续性标志，决定是返回错误页还是尝试优雅降级
      http_response_code(500);
      header('Content-Type: application/json');
      echo json_encode(['error' => 'System busy, please retry later.']);
      // 3. 如果是 CLI 模式，可能需要自定义退出策略
      exit(1);
  });

• 接口重试与幂等性：

  • 关键业务（如支付、下单）接口需要实现幂等性（使用请求 ID 或 Token 防重放）。
  • 调用外部 API 时，使用 Guzzle 的重试中间件，遇到网络超时或 5xx 错误时，自动重试 2-3 次（使用指数退避策略）。

  use GuzzleHttp\Client;
  use GuzzleHttp\RetryMiddleware;
  $client = new Client([
      'handler' => RetryMiddleware::factory([
          'max_retry_attempts' => 3,
          'retry_on_timeout' => true,
          'delay' => function ($num) { return 100 * pow(2, $num); }, // 100ms, 200ms, 400ms
          'decider' => RetryMiddleware::httpError()
      ])
  ]);

数据层连续性

业务连续性通常败在数据库或缓存上,PHP 部分需要处理连接断连和故障转移。

• 数据库连接池与故障检测：

  • 如果使用 PDO，不要在 try-catch 后立即丢弃连接，当捕捉到 ConnectionException 时，应该等待几秒后重试，或者立即切换到读库或降级服务。
  • 主从架构：写操作失败时，不要立即停止服务，如果主库挂掉，可以先将请求进入消息队列（如 RabbitMQ/Kafka），或者在业务允许的情况下暂时只读（从库）。

  // 伪代码：写失败时的降级策略
  function createOrder($data) {
      try {
          $db->insert($data);
      } catch (PDOException $e) {
          // 记录错误
          // 写入本地文件或消息队列，等主库恢复后异步补偿
          $queue->push(['action' => 'recreate_order', 'data' => $data]);
          // 告知用户订单处理中，而非直接返回错误
          return ['code' => 202, 'msg' => 'Order pending confirmation.'];
      }
  }

• 缓存穿透与雪崩保护：

  • 穿透：当 Redis 缓存没有数据时（如商品详情），使用互斥锁，只让第一个 PHP 进程去查数据库重建缓存，其他进程等待或返回默认值。
  • 雪崩：缓存过期时间增加随机偏移量，避免同时过期。$expire = 3600 + rand(0, 300);。

优雅降级（Graceful Degradation）

这是高级的业务连续性策略,当依赖的服务不可用时，PHP 应用不应直接崩溃，而应自动降低非核心功能。

• 断路器模式：

  • 直接使用 PHP 库（如 Ytake\CircuitBreaker），或自己维护一个文件/内存计数器。
  • 如果对支付服务的调用连续失败 5 次，则“熔断”该服务 30 秒，在这 30 秒内，PHP 不再尝试调用真实支付，而是返回“不支持该支付方式”或跳转到备用支付渠道。

• 依赖隔离：

  • 将核心功能（登录、浏览商品）和非核心功能（推荐算法、用户行为分析）彻底分离。
  • 非核心功能使用异步处理（如通过 pcntl_fork 或消息队列），即使失败也不影响主流程。

部署与恢复

PHP 代码部署和恢复速度很重要。

• 无宕机部署：

  • 使用 PHP-FPM 时，配合 SO_REUSEPORT 或 Nginx 平滑重载，每次发布代码，先更新备用节点，reload php-fpm，再切换流量。

• 回滚策略：

  • 发布时保留上一版的代码目录（版本号区分），并保留数据库迁移的回滚脚本。
  • 一旦发现严重 Bug，直接通过运维脚本将 Nginx 指向旧版本目录。

• 健康检查与自愈：

  • PHP 脚本如果产生僵尸进程或内存泄漏（常见于旧代码），用 supervisord 管理常驻脚本（如队列消费者），并设置 autorestart=true。

PHP 业务连续性清单

PHP 虽然不像 Go 或者 Java 那样天然支持高并发和高可用，但通过上述架构设计 + 代码防御 + 运维工具的组合，完全可以实现 99.9% 以上的业务连续性，核心思路是：提前预判失败，将失败的影响局限在最小范围内，并提供清晰的降级路径给用户。