直接改数据库字段会丢数据，因并发时多个请求读取相同play_count值后写回导致计数丢失；应使用Redis的INCR原子操作实时计数并异步落库，配合前端token校验、IP+视频ID去重及代理跳转或CDN日志解析来保障准确性。
直接改数据库字段会丢数据
很多开发者第一反应是每次播放就执行 $pdo->exec("UPDATE videos SET play_count = play_count + 1 WHERE id = ?")。这在低并发下看似可行，但实际线上环境容易因并发请求导致计数丢失——两个请求几乎同时读到 play_count = 100，各自加 1 后都写回 101，最终只+1而非+2。
用 Redis 原子操作兜底更可靠
推荐用 Redis 的 INCR 做实时计数，再异步落库。它天然原子性，且比数据库快两个数量级：
redis-cli > INCR video:play:123 (integer) 4567
关键点：
-
video:play:{id}是标准 key 命名，避免 key 冲突 - 不要在 PHP 中用
GET + INCR + SET模拟，必须用原生命令 - 每小时或每万次增量后，用后台任务把 Redis 计数同步到 MySQL
play_count字段，防止 Redis 重启丢数据
前端埋点需防刷，不能只靠 JS
单纯在 的 onplay 事件里发 AJAX 请求，极易被脚本批量触发。必须叠加服务端校验：
立即学习“PHP免费学习笔记（深入）”；
- 每次播放请求带临时 token（如 JWT，5 分钟过期），由后端生成并注入页面
- 校验 Referer 是否为本站、User-Agent 是否合理（排除空 UA 或明显爬虫特征）
- 对同一 IP + 视频 ID 组合，10 分钟内只记 1 次（用 Redis
SETNX+ 过期时间实现）
CDN 缓存会拦截真实播放请求
如果视频文件走 CDN，用户直接请求 https://cdn.example.com/video.mp4，你的 PHP 后端根本收不到这次播放。解决路径只有两条：
- 强制所有播放走代理接口（如
/api/play?id=123），该接口返回 302 跳转到 CDN 地址，同时完成计数 - 用 CDN 提供的访问日志（如阿里云 OSS 日志、Cloudflare Logs），定时解析
GET /video.mp4行为，过滤掉爬虫 UA 和非 200 响应，再聚合统计——但这有 5~30 分钟延迟，仅适合日报/周报
真正难的是平衡实时性、准确性和性能。Redis 计数 + 异步落库 + 前端 token 校验 + 代理跳转，这套组合才能扛住日均百万级播放的统计需求。漏掉任意一环，数据就会偏高或偏低。