本文目录导读：
PHP高并发未读数计数方案深度解析：从Redis到消息队列的实战选型指南
📖 目录导读
- 未读数系统的核心痛点 – 为什么简单的
UPDATE语句撑不过1000并发？ - 主流计数方案横向对比 – Redis INCR / 哈希聚合 / 队列异步落库的优劣边界
- 高并发场景最佳实践 – 多级缓存 + 最终一致性架构拆解（含PHP代码示例）
- 数据一致性陷阱与补偿机制 – 丢失/重复计数的救火方案
- 常见问题快问快答 – 覆盖99%开发者的5个核心疑问
未读数系统的核心痛点
未读数（如私信、通知、动态红点）是社交/电商类产品的"地基功能"，当用户量达到百万级时，每次刷新都直查MySQL的写法会瞬间打爆数据库连接池，典型的失败案例：
- 用户A连点10次刷新 → 产生10次
SELECT COUNT(*)全表扫描 - 跨表统计（私信表+评论表+点赞表） → 单次请求耗时 > 800ms
本质矛盾：读多写少（读:写 ≈ 20:1）且要求毫秒级响应，而传统关系型数据库的索引B+树在超高并发读下会触发IO瓶颈。
主流计数方案横向对比（重点）
| 方案 | 核心机制 | 读写性能 | 一致性 | 适用量级 |
|---|---|---|---|---|
| 方案A：MySQL计数列 | 每产生互动就对unread_count字段加1 |
写快读慢（需回表） | 强一致 | <10万用户 |
| 方案B：Redis INCR | 所有写操作直接INCR内存计数器 |
读写均微秒级 | 最终一致（需持久化） | 100万+ |
| 方案C：Redis Hash + 定时刷盘 | 每个用户一个Hash，field区分计数类型 | 读写均衡 | 异步窗口期可能丢失 | 千万级 |
| 方案D：专业MQ流式计算 | Kafka/RabbitMQ削峰 + 消费者批量聚合 | 最高吞吐 | 链路中最复杂 | 亿级 |
关键结论：中小团队首推方案B/C结合——Redis负责热数据计数，MySQL仅做冷备份，纯Redis方案需警惕内存碎片：用
HINCRBY按用户维度聚合即可将Key数量压缩90%。
高并发最佳实践：多级缓存架构（附PHP代码）
架构三层结构：
① Redis Hash存储实时计数（有效期7天）
② MySQL落地全量计数（用于跨设备同步）
③ 协程/进程内缓存标记本次会话已读偏移量
// 1. 写入未读数（点赞/评论等触发时）
$redis->hIncrBy("unread:user_{$uid}", 'comment', 1);
// 2. 批量读取未读数（用户进入首页时）
$counts = $redis->hMGet("unread:user_{$uid}", ['comment', 'like', 'system']);
if (empty($counts['comment'])) {
// 缓存失效降级方案：从MySQL恢复
$counts = DB::table('unread_counts')->where('uid', $uid)->first();
$redis->hMSet("unread:user_{$uid}", (array)$counts, 3600);
}
// 3. 已读清零（使用Pipeline避免多次RTT）
$redis->pipeline(function ($pipe) use ($uid) {
$pipe->del("unread:user_{$uid}");
$pipe->set("read_offset:user_{$uid}", time());
});
关键优化点：
- 用
hMGet一次取多种计数 → 减少网络IO - 设置
EXPIRE兜底，防止永不失效的垃圾Key - 用
Pipeline批量操作，性能提升3倍以上
数据一致性陷阱与补偿机制
问题1：Redis宕机丢数据
解决：采用AOF everysec持久化 + 启动时全量回源MySQL。
问题2：异步队列积压导致计数延迟
解决：在Redis中记录last_sync_time，若超过30秒未同步，强制同步队列任务。
问题3：并发清零与新增互斥
经典场景：用户刚已读清零，又收到新消息，若两个操作同时执行，会导致新消息未读数被0覆盖。
正确解法：使用Lua脚本原子操作：
if redis.call('EXISTS', KEYS[1]) == 1 then
redis.call('DEL', KEYS[1])
redis.call('SET', KEYS[2], ARGV[1]) -- 记录已读时间戳
end
常见问题快问快答
Q1：为什么不用SETBIT位图存未读数？
答：位图适合布尔状态（已读/未读），但无法统计“未读3条私信”这种累加值，且跨天清理困难。
Q2：MongoDB能替代Redis吗？
答：可以，但Mongo每次读写都要经过BSON序列化，且内存映射机制在高并发下CPU抖动明显，性能仅为Redis的60%。
Q3：未读数为0时是否要删除Key？
答：不能删！保留空Hash（开销约50字节），否则会出现缓存穿透，可设置当某用户连续30天未活跃时统一清理。
Q4：跨端已读同步如何实现？
答：记录read_offset时间戳，拉取计数时过滤create_time > read_offset的数据量，注意时区统一用UTC存储。
Q5：大数据量下如何做冷热分离？
答：将活跃度分3个等级：超过30天未登录的账号只存MySQL，活跃用户存Redis，通过Crontab每10分钟迁移一次。
未读数方案的本质是用空间换时间：将高频读操作压在内存层，低频写操作异步落盘，对于日均PV过亿的产品，建议引入Kafka + FLink进行实时聚合，但90%的中型项目直接采用Redis Hash方案即可满足性能要求，关键要记住：永远不要相信单一存储，最终一致性才是高并发系统的常态，请务必在业务层做好降级预案（例如将红点按钮改为灰色静态提示）。
实战建议：上线前用
JMeter模拟10万用户同时刷新，观察Redis的miss rate与PHP-FPM的进程耗时曲线，当内存命中率低于95%时，必须增加本地二级缓存（如Swoole Table）。
