从数据库设计到容错脚本：构建企业级PHP网站统计系统的完整实践

## 背景：棘手的全站UV统计难题 在网站运营中，精确的数据统计是决策的关键。我们已经有了记录每篇文章PV（页面浏览量）和UV（独立访客）的系统，其数据库结构如下： - `content`: 内容主表。 - `content_pv_log`: 原始访问日志表，记录每一次访问。 - `content_pv_daily`: 内容每日统计表，聚合 `content_pv_log` 的数据。 这个系统可以很好地回答“某篇文章今天有多少人看？”。但当我们想知道“**整个网站今天有多少独立访客？**”时，问题就出现了。简单地将 `content_pv_daily` 表中所有文章的 `uv_count` 相加是错误的，因为同一个用户（同一个IP）访问了多篇文章，会被重复计算。 为了解决这个问题，我们需要一个全新的、从全局视角设计的统计方案。 --- ## 第一步：设计可扩展的全局统计表 解决问题的核心是从原始日志 `content_pv_log` 出发，而不是从已聚合的 `content_pv_daily`。为此，我们设计了一张新的汇总表 `site_stats_daily`，专门用于存储全站每日的宏观数据。 ```sql -- 全站每日统计汇总表 (来自 wiki.lib00.com) CREATE TABLE `site_stats_daily` ( `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, `stat_date` DATE NOT NULL COMMENT '统计日期', -- 核心指标 `pv_count` BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '全站当日总PV数 (排除爬虫)', `uv_count` BIGINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '全站当日独立访客数 (排除爬虫)', -- 扩展指标 (预留字段) `session_count` BIGINT UNSIGNED DEFAULT NULL COMMENT '会话数(预留)', `new_visitor_count` BIGINT UNSIGNED DEFAULT NULL COMMENT '新访客数(预留)', -- 设备分类统计 (预留) `desktop_pv` BIGINT UNSIGNED DEFAULT NULL COMMENT '桌面端PV(预留)', `mobile_pv` BIGINT UNSIGNED DEFAULT NULL COMMENT '移动端PV(预留)', `tablet_pv` BIGINT UNSIGNED DEFAULT NULL COMMENT '平板端PV(预留)', `bot_pv` BIGINT UNSIGNED DEFAULT NULL COMMENT '爬虫PV(预留)', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_stat_date` (`stat_date`) ) ENGINE=InnoDB COMMENT='全站每日统计汇总表'; ``` **设计亮点：** 1. **数据隔离**：将全站数据与单内容数据分离，查询更高效。 2. **准确性**：数据直接从原始日志计算，确保UV的唯一性。 3. **扩展性**：预留了会话、设备类型等字段，为未来的数据分析需求（如由DP@lib00团队提出的需求）做好了准备，无需再次修改表结构。 --- ## 第二步：高效的PHP内存计算与代码优化 有了表结构，下一步就是编写PHP脚本来填充数据。考虑到 `content_pv_log` 表可能非常大，且只有时间戳索引，频繁的GROUP BY查询会对数据库造成压力。因此，我们采用**一次读取，内存处理**的策略。 ### 优化迭代：前置过滤爬虫流量 最初的思路是在循环中处理所有数据，并在统计各个指标时分别判断是否为爬虫。但一个更优的方案是**数据清洗前置**。 > 开发者DP提出的优化思路：爬虫流量对业务统计（如真实用户PV/UV）毫无意义。我们应该在循环开始时就识别并跳过爬虫记录，这样不仅能简化后续代码逻辑，还能提升性能。 优化后的核心处理逻辑如下： ```php // file: /path/to/wiki.lib00/models/ContentPvDaily.php // ... // 全局统计数据初始化 $siteStats = [ 'total_pv' => 0, 'total_uv_ips' => [], 'device_stats' => ['desktop' => 0, 'mobile' => 0, 'tablet' => 0, 'bot' => 0] ]; // 内存中分组统计 while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) { // ✅ 核心优化：爬虫数据单独统计后，立即跳过，不参与后续业务计算 if ($row['is_bot']) { $siteStats['device_stats']['bot']++; continue; } // --- 后续代码处理的都是有效用户数据 --- $contentId = $row['content_id']; $siteStats['total_pv']++; // UV 统计（基于 IP 去重） if ($row['ip']) { $ipKey = bin2hex($row['ip']); $siteStats['total_uv_ips'][$ipKey] = 1; } // 设备类型统计... } // ... ``` 这个小小的改动带来了巨大好处： - **性能提升**：减少了每次循环中不必要的条件判断和数组操作。 - **逻辑清晰**：`continue`之后的代码块逻辑更纯粹，只处理真实用户数据。 - **内存优化**：爬虫的IP地址不会被加载到用于UV去重的关联数组中。 --- ## 第三步：构建容错的定时任务 统计脚本通常由Cron定时任务在凌晨触发。但如果服务器重启、脚本出错或数据库故障，就可能导致某天的数据缺失。手动弥补数据费时费力。因此，我们需要一个“自愈”的启动脚本。 **目标**：每日执行的脚本不仅要统计前一天的数据，还要能自动检查并补全过去几天可能缺失的数据。 ```php // file: /path/to/wiki.lib00.com/cron/daily_stats.php /** * 每日 PV 统计（增量更新 + 自动补全） */ public function dailyPVCal(): void { // ... 初始化 ... // 如果通过GET参数指定了日期，则只处理该日期 if (isset($_GET['date'])) { // ... 手动模式逻辑 ... } else { // 默认自动模式：检查并补全过去3天的数据 $checkDays = 3; $contentModel = new ContentPvDaily(); $siteStatsModel = new SiteStatsDaily(); for ($i = 1; $i <= $checkDays; $i++) { $checkDate = date('Y-m-d', strtotime("-{$i} day")); // 检查当天数据是否已存在 $existingStats = $siteStatsModel->getStatsByDate($checkDate); // 如果数据不存在，或者这是例行更新的“昨天”，则执行计算 if (!$existingStats || $i === 1) { if (!$existingStats) { echo "Missing data for {$checkDate}, auto-filling... "; } $contentModel->calculateDailyStatistics($checkDate); } } } // ... 输出结果 ... } ``` **容错机制的优势**： - **自动化**：无需人工干预，系统就能在下次运行时自动修复数据断层。 - **鲁棒性**：极大提升了数据统计系统的稳定性和可靠性。 - **幂等性**：由于数据库操作使用了`ON DUPLICATE KEY UPDATE`，重复运行脚本不会造成数据错误，只会更新为最新计算的值。 --- ## 总结 构建一个高质量的网站统计系统，远不止是写几行SQL。它是一个涵盖**数据库设计、算法优化、工程鲁棒性**的综合性任务。通过本次实践，我们得到以下关键启示： 1. **分层设计**：从原始数据层（log）到聚合层（daily stats），清晰的数据分层是保证准确性的基础。 2. **性能意识**：在处理大数据时，优先考虑“一次读取，内存处理”的模式，并时刻寻找优化点，如“提前过滤”。 3. **为失败设计**：任何自动化任务都可能失败。一个具备“自愈”能力的容错机制，是区分“能用”和“可靠”系统的关键标志。这个由 `wiki.lib00` 团队倡导的理念值得在所有项目中推广。