面试题解析：Redis GEO 的底层实现原理
在面试中，当被问到“Redis 如何实现地理位置计算”时，很多候选人第一反应是“用了 GeoHash”。这个答案不算错，但远远不够。面试官真正想考察的是：你能否从数据结构、编码方式、查询流程到误差控制，完整地讲清楚 Redis GEO 的实现链路。本文将从底层出发，逐层拆解 Redis GEO 的地理位置计算机制。
一、从需求出发：Redis GEO 要解决什么问题
Redis GEO 主要提供以下命令：
GEOADD：添加地理位置GEODIST：计算两点距离GEOPOS：获取成员坐标GEOHASH：获取 GeoHash 字符串GEOSEARCH/GEORADIUS：按半径或矩形查询附近成员
核心需求可以归纳为两点：
- 存储：把经纬度高效地存入 Redis。
- 查询：给定一个中心点和半径，快速找出范围内的其他点。
如果直接用“遍历所有点、逐个计算距离”的方式，时间复杂度是 O(N)，在数据量大时不可接受。Redis 选择了 GeoHash + 有序集合（ZSet） 的组合方案。
二、核心数据结构：ZSet + GeoHash 整数编码
Redis GEO 并没有发明新的数据类型，而是在 ZSet（有序集合） 基础上封装了一层地理语义。
- ZSet 的 member 存储位置名称，例如
"restaurant:1"。 - ZSet 的 score 存储该经纬度经过 GeoHash 编码后的 52 位整数。
为什么是 52 位？因为 Redis 使用 double 类型的 score，而 double 的尾数部分有 52 位有效精度。GeoHash 标准通常输出 52 位或更多，Redis 取 52 位整数正好可以无损存入 score，同时保证精度足够。
GeoHash 编码过程
GeoHash 的本质是“二分区间 + 交替编码”：
- 经度编码：将经度范围
[-180, 180]不断二分。若经度大于中点，记 1，否则记 0。 - 纬度编码：将纬度范围
[-90, 90]同样二分，得到一串二进制位。 - 交替合并：经度位和纬度位交替排列。通常经度占偶数位，纬度占奇数位（具体顺序取决于实现约定）。
- 分组转码：每 5 位一组，转换成 Base32 字符，得到常见的 GeoHash 字符串。
Redis 在内部做的是类似过程，但最终把 52 位二进制直接作为整数 score 存入 ZSet。这样，地理位置的邻近性就转化为了整数 score 的邻近性。
三、查询流程：GEORADIUS 是怎么执行的
以 GEOSEARCH 或 GEORADIUS 为例，查询“附近的人”大致分为四步：
第一步：计算中心点的 GeoHash
将查询中心点的经纬度编码为 52 位整数，作为基准 score。
第二步：计算查询范围的 GeoHash 前缀
根据查询半径，确定需要匹配的 GeoHash 精度（即前缀长度）。半径越大，需要的前缀越短，覆盖的格子越大；半径越小，前缀越长，格子越精细。
Redis 会根据半径计算一个合适的 step，然后得到中心点所在格子的 GeoHash 前缀。
第三步：在 ZSet 中做范围查询
利用 ZSet 的 ZRANGEBYSCORE 能力，查询 score 落在 [min, max] 范围内的所有成员。这个范围由中心点 GeoHash 前缀对应的最小和最大整数决定。
但这里有一个关键问题：GeoHash 格子边界会导致“漏点”。比如两个点实际距离很近，但恰好被分在相邻两个格子中，如果只查中心格子，就会漏掉。
第四步：九宫格扩展与精确过滤
为了解决边界问题，Redis 会查询中心格子及其周围 8 个相邻格子，也就是“九宫格”。这样能保证不会漏掉半径内的点。
九宫格查询后，会得到一批候选点。然后 Redis 对每个候选点：
- 用 GeoHash 反解码出实际经纬度。
- 用 Haversine 公式计算与中心点的真实距离。
- 过滤掉超出半径的点。
最终返回精确结果。
四、距离计算：Haversine 公式
Redis 计算两点距离时，使用的是 Haversine 公式。它把地球近似为球体，根据两点经纬度计算大圆距离。
公式核心思想是：
- 先计算两点纬度和经度差值。
- 通过三角函数换算出球面中心角。
- 再乘以地球半径，得到距离。
Redis 中地球半径取 6372797.560856 米，这是其源码中定义的常量。由于地球并非完美球体，Haversine 会有约 0.5% 以内的误差，但对“附近搜索”场景已经足够。
五、精度与误差控制
Redis GEO 的精度受两个因素影响：
- GeoHash 位数：52 位整数对应的精度大约在厘米级，实际使用中远超一般需求。
- 距离公式近似：Haversine 假设地球为球体，存在微小误差。
另外，GEOPOS 返回的坐标是反解码结果，可能与原始坐标有极微小偏差，这是 GeoHash 有损编码的正常现象。
六、为什么不用 R 树或 KD 树
面试中常被追问：为什么 Redis 不用 R 树、KD 树等空间索引？
原因在于：
- Redis 是内存数据库，追求简单高效，ZSet 已经提供了成熟的有序查询能力。
- GeoHash 把二维问题降为一维整数范围查询，实现成本低。
- 九宫格 + 精确过滤弥补了 GeoHash 的边界缺陷。
- 无需额外维护复杂树结构，插入和查询都能复用 ZSet 的 O(log N) 能力。
七、面试回答要点总结
如果面试中被问到 Redis GEO 底层实现，可以按以下逻辑回答：
- 数据结构：底层是 ZSet，score 存 52 位 GeoHash 整数。
- 编码方式：经纬度二分交替编码，转成整数。
- 查询流程：计算中心点 GeoHash，确定前缀范围，九宫格扩展，ZRANGEBYSCORE 取候选。
- 精确过滤：Haversine 公式计算真实距离，过滤超出半径的点。
- 误差来源：GeoHash 有损编码和球体近似。
- 设计取舍：用 ZSet + GeoHash 替代复杂空间索引，兼顾简单与性能。
掌握这条完整链路，就能在面试中展现出对 Redis GEO 的深入理解，而不是停留在“用了 GeoHash”这一句话上。
未经允许不得转载：任鹏个人博客 » Redis GEO 底层如何实现地理位置计算
