每4秒,每个在线司机往服务器扔一次GPS坐标。高峰期500万司机同时在线,每分钟就是500万次更新——还没算那些盯着地图看小车移动的乘客。定位管道是整个平台的脉搏,慢了,司机乘客不同步;崩了,App直接变砖。
用.NET搭这种系统,第一课是学会"什么时候别碰数据库"。定位数据高频、短命、还带地理坐标,关系型数据库会被写操作压垮。这时候该请出Redis。
![]()
先算笔硬账:500万峰值司机,每4秒一次心跳,Redis层每秒125万笔写入;乘客端看地图,延迟得压到1秒内;叫车时系统要在毫秒级圈出半径内的可用司机。 naive的做法是把每次更新塞进SQL表,两分钟后就是1.5亿行,写队列排到地平线——这种坑别留到半夜11点调。
我们的解法分三步走。
第一步:定位更新模型
消息要薄。一个LocationUpdate记录就四样东西:司机ID、纬度、经度、时间戳。司机每4秒发一次,我们不存历史——那是 analytics 的事,只存当前位置。
第二步:Channel缓冲层
请求进来先不碰Redis,先写进Channel。这是.NET原生解耦生产者和消费者的招,不用上消息队列。司机端点往Channel一写,立刻返回202 Accepted,HTTP层零等待、零背压。消费者异步慢慢消费。
Channel设成有界队列,容量1万条,满了就DropOldest——消费者跟不上时,丢掉最老的数据。位置信息稍微旧点,比队列积压强。
第三步:Redis GEO + SignalR推送
消费者拿到更新,GEOADD进Redis,司机最新坐标入库。同时SignalR往订阅该司机的乘客端推实时位置,地图上的点动起来。匹配叫车时,GEORADIUS一圈,毫秒级返回半径内的可用司机。
这套组合拳下来,125万TPS扛住,延迟压进1秒,不用数据库硬扛写风暴。下一篇聊行程状态机,再下一篇串完整架构。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.