100个用户的聊天系统：轮询 vs WebSocket 综合对比

📊 对比表

对比维度	普通轮询（Polling）	WebSocket
实时性	⏳ 一般（延迟=轮询间隔） 例如 5 秒轮询，平均延迟 2.5 秒	⚡️ 高（消息可毫秒级送达）
数据库压力	🚨 高（每次轮询都可能查数据库，尤其是无新消息也查）	✅ 极低（仅有新消息时触发推送）
服务器 QPS	🚨 高（大量重复无效请求） 例如 100 人 5 秒轮询 = 20 QPS	✅ 低（只维持长连接，无空请求）
网络带宽消耗	❌ 浪费（频繁 HTTP 请求 + 无效负载）	✅ 高效（仅必要数据推送）
连接资源（内存）	✅ 少（短连接）	⚠️ 较高（每个用户维持一个长连接）
实现复杂度	✅ 简单（HTTP 接口即可）	⚠️ 中等（需要连接管理、心跳、消息推送）
浏览器兼容性	✅ 100%（所有环境支持）	✅ 广泛支持（IE10+、移动端均支持）
可扩展性	❌ 差（用户增多后服务器压力急剧增加）	✅ 强（结合 Redis Pub/Sub 可水平扩展）
消息可靠性	❌ 差（轮询间隔期间可能漏感知）	✅ 高（实时送达，可确认）
移动端支持	❌ 不省电（后台频繁唤醒）	✅ 更省电（后台维持连接或推送）

---

🎯 场景建议

场景	推荐方案
✅ 用户量小（<50人），部署简单优先	普通轮询即可
✅ 中型用户量（约 100 人），需聊天实时性	推荐使用 WebSocket
✅ 用户量大或计划扩展	WebSocket + Redis Pub/Sub 架构
✅ 快速上线 MVP 原型	可先用轮询，后期平滑切换为 WebSocket