system-design-notes位置更新的2种方案定期轮询 vs 流式更新深度对比【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes本文基于开源系统设计笔记 system-design-notes深度对比位置更新的 2 种核心方案定期轮询与流式更新从实时性、移动端耗电、服务端架构等 6 个维度逐项拆解并结合 Google Maps 与附近好友两个真实场景给出选型建议帮助新手快速掌握实时位置服务的系统设计思路。 为什么位置更新是系统设计的高频难题现代位置服务导航、附近的人、打车共享行程都有一个共同点位置数据在持续变化且用户量大到惊人。Google Maps10 亿日活用户每天 2500 万条实时更新仅位置上报在批量合并后就有20 万 QPS峰值可达100 万 QPS附近好友应用1 亿用户每天使用按 30 秒刷新一次计算也要承受约33.4 万 QPS的位置更新写入。设计位置更新方案时我们要同时平衡三组矛盾实时性 vs 客户端电量、写吞吐 vs 服务端成本、低延迟 vs 最终一致性。这决定了不存在永远最优的方案只有最匹配业务的方案。完整的位置服务设计可参考18. Google Maps/README.md 方案一定期轮询 —— 客户端定时批量上报位置定期上报位置的工作流程定期轮询Periodic Update是最朴素的方案客户端按固定周期如 15 秒向服务端发起一次位置上报。更聪明的做法是客户端先攒批每收到一个 GPS 点就先缓存到本地15 秒后把积攒的 30 多个坐标点打包成一次 HTTP 请求发出而不是每个点都单独请求。客户端批量攒点的位置更新机制示意每 15 秒发一个 Batch上报接口通常很简单例如POST /v1/locations参数是「纬度、经度、时间戳」三元组的 JSON 数组。服务端写入为高写入负载优化的数据库如 Cassandra即可平稳支撑 20 万 QPS 的写入。定期轮询方案的优点与短板✅ 优点优点说明实现简单标准 HTTP 请求响应模型服务端无状态水平扩容毫无压力省电省流量批量合并请求减少移动端无线模块的唤醒次数对电池友好天然容错网络中断时数据留在本地恢复后重传不丢更新⚠️ 短板实时性受周期限制最坏情况下位置数据落后一个周期15 秒对附近好友实时刷新这类场景偏慢流量尖峰所有客户端在同一节奏上报周期末尾容易出现突发峰值冗余上报用户静止不动时仍在周期性地上报几乎相同的坐标浪费带宽。 常见优化给上报加触发阈值——位移超过一定距离或速度变化明显时才上报静止时自动降频。⚡ 方案二流式更新 —— 基于长连接的实时位置推送WebSocket 长连接如何让位置更新流起来流式更新Streaming Update走的是长连接路线客户端与服务端之间建立一条持久的双向通道位置数据像流水一样持续传输同时服务端还能主动推送消息给客户端。以 WebSocket 为例客户端先发一次GET /ws请求服务端响应后连接升级为全双工通道之后双向消息自由流动不再需要反复握手建连。在附近好友场景中流式更新的典型链路是客户端经 WebSocket 把位置更新发到WebSocket 服务器服务器写入位置缓存Redis带 TTL过期即视为离线与位置历史库服务器把位置发布到该用户的Redis Pub/Sub 频道订阅了这个频道的其他服务器即承载其好友连接的那些节点收到后计算距离把更新实时推送给相关好友。流式更新的优点与短板✅ 优点毫秒级实时性位置变化几乎立刻触达关心它的用户双向通信服务端可随时主动推送如你的好友上线了无需客户端轮询省去反复握手一次建连长期复用比高频短连接更高效。⚠️ 短板服务端有状态连接挂在特定服务器上缩容时要先把节点标记为 draining、优雅迁移连接断连与重连移动网络切换、App 进后台都会导致连接断开需要心跳保活 客户端重连逻辑推送扇出放大写压力一条位置更新可能要转发给几十上百个在线好友消息总线Redis 集群的 CPU 负载非常高。⚖️ 定期轮询 vs 流式更新6 个维度全面对比对比维度定期轮询批量上报流式更新长连接实时性秒级延迟取决于周期如 15s毫秒~亚秒级近乎实时实现复杂度低标准 HTTP 即可中需管理长连接与有状态服务服务端状态无状态弹性扩容简单有状态扩缩容需优雅迁移连接移动端电量/流量低批量合并、可智能降频较高需维持长连接与心跳流量形态周期末易现尖峰平滑持续典型场景导航轨迹记录、位置打卡附近好友、实时共享位置、协作一句话总结对实时性不敏感、重省成本 → 选定期轮询要求秒内可见、服务端需主动推送 → 选流式更新。 实战选型不同业务该选哪种位置更新方案导航 / 轨迹记录类批量上报 后台流处理Google Maps 的思路很值得学习——对外用定期批量上报对内用流式处理两头的好处都拿到了写路径客户端 15 秒批量上报省电、削峰服务端写入 Cassandra内部链路位置服务把更新灌入Kafka流式分发给下游——交通更新服务、机器学习个性化、路由瓦片加工、行为分析等各消费各的。如果服务端还需要主动推送给客户端如导航中路线重规划协议选择上移动端推送通知载荷太小不适合WebSocket 优于长轮询服务端计算开销更低SSE 也是备选但 WebSocket 支持双向通信对最后一公里配送这类功能更有优势。实时社交类附近好友长连接 Pub/Sub 广播对附近好友 5 秒内刷新这类强实时场景则必须上长连接 消息广播WebSocket 服务器有状态负责双向通信Redis 位置缓存只存最近位置TTL 过期自动剔除离线用户Redis Pub/Sub轻量消息总线按每个用户一个频道分发位置更新并借助一致性哈希把频道分布到 Redis 集群。规模上要注意假设单台 Redis 每秒处理 10 万条推送1400 万条/秒的扇出就需要140 台 Redis 节点再配合 ZooKeeper/etcd 做服务发现——这也是流式方案成本高、需专门运维的直观体现。完整设计可参考17. Nearby Friends/README.md 延伸阅读相关章节资料位置服务全景批量上报、Kafka 流处理、自适应 ETA 与重路由 → 18. Google Maps/README.md附近好友完整设计长连接扇出、Pub/Sub 集群扩容、GeoHash 频道 → 17. Nearby Friends/README.md通信协议原理WebSocket、长轮询、轮询的区别 → 12. Chat System/Readme.md综合两种方案后的位置更新系统最终设计位置更新看似只是把坐标发给服务器背后却是实时性、电量、吞吐与成本之间的精妙权衡。理解定期轮询与流式更新各自的边界再结合业务特点组合使用正是系统设计面试中最能体现功力的地方 【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考