北京
每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.
