打车类应用最核心的能力，是把散布在城市中的司机和乘客通过位置联系起来，并快速完成匹配。司机端持续上报自己的经纬度和行驶方向，乘客端提交上车点，系统要在秒级时间内从成千上万辆车里挑出最适合接单的那一辆。这个过程涉及位置采集、轨迹存储、空间检索和派单策略多个模块，任何一环延迟或误差都会被用户直接感知为车不来、接错人、绕远路。
司机与乘客位置轨迹的采集与压缩
移动端获取位置主要依赖GPS、基站和Wi-Fi混合定位。打车App一般在司机端开启前台服务，通过Android的FusedLocationProvider或iOS的CLLocationManager按1到3秒间隔取点。原始经纬度是浮点数，若全量上报既费流量也压服务器，所以端上先做初级过滤：速度低于阈值且坐标漂移小于五米的点直接丢弃。
轨迹压缩常用道格拉斯-普克算法，在后端把一段时间内司机行驶路径化简为关键拐点。例如司机沿直线开两公里，中间上百个点可压成首尾两个。这样存储和回放都轻量。下面是一段Python演示如何按距离阈值抽稀：
def compress(points, max_dist=0.0005):
# points: list of (lat, lng)
if len(points) < 3:
return points
result = [points[0]]
for p in points[1:-1]:
last = result[-1]
# 简单按经纬度差绝对值判断，真实场景应算球面距离
if abs(p[0] - last[0]) > max_dist or abs(p[1] - last[1]) > max_dist:
result.append(p)
result.append(points[-1])
return result
raw = [(39.9, 116.4), (39.9001, 116.4002), (39.91, 116.41), (39.9102, 116.4103)]
print(compress(raw))
除了抽稀，轨迹还要带时间戳和订单号，方便后续用<table>做行程回放或纠纷取证。值得注意的是，乘客端在叫车时只需单次定位，不必持续耗电，但要引导用户打开高精度模式，否则定位偏到隔壁街区会让派单完全失效。
基于geohash的空间索引与附近车辆检索
把地球表面划分成网格，并用base32编码成字符串，就是geohash的思路。打车App把司机坐标转成七位geohash，例如wx4g0ec，相同前缀代表距离近。检索附近车只需拿乘客geohash的前几位去Redis或MongoDB做前缀匹配，比全表算球面距离快几个数量级。
但geohash有边界问题：两个司机一东一西隔街相望，hash前缀却不同。工程上通常取乘客hash及其周围八个邻居格子一起查，再在内存里按真实距离排序。示例展示如何生成邻居：
import geohash
def neighbors(lat, lng, precision=7):
h = geohash.encode(lat, lng, precision)
# 返回自身与八邻域
return [h] + geohash.expand(h)
print(neighbors(39.9042, 116.4074))
在大规模场景下，单纯geohash仍可能热点区域过载，可结合一致性哈希把不同网格分散到多台节点。同时司机下线、断网要及时从索引剔除，否则乘客会反复派给一辆早已收车的车。位置轨迹和空间索引是派单的底座，底座稳了上层策略才好施展。
实时派单算法的设计与权衡
最朴素的派单是距离最近优先：算出乘客到每辆候选车直线距离，取最小。但城市里直线近不等于好接，中间高架、单行道会让实际车程翻倍。进阶做法是用路网接口预估驾驶时长，以ETA代替距离排序，并给连续拒单的司机降权。
派单系统还要处理一对多广播和一对一专属两种模式。高峰时段用广播，三秒内无司机接则扩大范围；专属模式用于预约单，提前十分钟锁定车辆。下面伪代码说明核心循环：
public Driver dispatch(Order order, List<Driver> candidates) {
Driver best = null;
double minEta = Double.MAX_VALUE;
for (Driver d : candidates) {
if (d.isBusy() || d.getRating() < 4.5) continue;
double eta = RouteService.estimateEta(d.getLoc(), order.getStart());
double score = eta + d.getLoadFactor() * 2.0;
if (score < minEta) {
minEta = score;
best = d;
}
}
return best;
}
派单不是纯技术，也含运营规则：新司机保护期多派单、机场排队按到达顺序放车。系统应把这些规则做成可配置权重，避免每次调策略发版。轨迹数据还能反哺算法，用历史行程训练接驾成功率模型，让派单越跑越准。
轨迹数据安全与隐私控制
司机和乘客的轨迹属于敏感个人信息，打车App须做脱敏。服务端存储时，乘客上车点可泛化到geohash五位，不落精确门牌。司机完整轨迹仅保留必要周期，过期用定时任务清理。
接口层面要鉴权，司机只能拉取自己当班轨迹，乘客只能看本次行程。下列SQL示意查询限制：
SELECT path, start_time FROM trip WHERE driver_id = 'D123' AND order_id = 'O2024' AND owner_token = 'client_signed_token';
合规之外，轨迹还可用于运费纠偏：乘客质疑绕路时，调出轨迹对照导航路线，一眼看清是谁的问题。把位置轨迹、派单、安全三条线织在一起，打车App才真正好用。