不能直接用于服务节点定位，需将IP/主机名、经纬度、TTL三者绑定建模，Geo仅存坐标和成员名，须配合SET/HSET存元数据、Lua脚本保证原子性，并通过GeoRadiusByMember+预置坐标提升稳定性与精度。
Go-Redis 的 GeoAdd 和 GeoRadius 能直接用于服务节点定位吗？
不能直接用，但可以——前提是把服务节点的 IP/主机名、经纬度、TTL（存活状态）三者绑定建模。Go-Redis 的 Geo 命令本身只存坐标和成员名，不带元数据或过期逻辑。常见错误是直接 GeoAdd 一堆服务名，结果查出来全是“死节点”，因为没配套做健康检查和自动清理。
- 必须搭配
SET或HSET存节点元数据（如service:node1→{"ip":"10.0.1.22","last_heartbeat":1717023456}） - Geo 索引只存
node1这个 member 和它的经纬度，查询时靠GeoRadius返回 member 列表，再批量MGET或HGETALL补全信息 - 不要用
EXPIRE给 Geo key 设过期：Redis 的 Geo 数据结构不支持 TTL，得靠外部定时任务或心跳更新时同步清理
为什么用 GeoRadiusByMember 比 GeoRadius 更适合节点发现？
因为客户端通常知道自己所在节点的坐标（或能从本地配置/环境变量读取），不需要传经纬度参数，避免精度误差和重复计算。而 GeoRadius 要求每次请求都带 longitude 和 latitude，在容器或云环境中容易因 DNS 解析延迟、时区错位导致坐标漂移。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
GeoRadiusByMember的参数是key、member（本节点名）、radius、unit（如"km"），更稳定 - 注意：member 必须已存在于 Geo key 中，否则返回空；上线时务必先
GeoAdd自身节点坐标 - 单位选
"m"而非"km"可提升小范围（如同城机房）查询精度，避免舍入误差
如何避免高并发下 GeoRadius 返回脏数据？
Redis 的 Geo 命令本身是原子的，但“查坐标 → 查元数据 → 过滤掉不可用节点”这整条链路不是原子操作。典型问题：A 节点刚被踢出集群，但 GeoRadius 还返回它，紧接着 HGETALL 才发现 status 是 "down"。
- 解决方案一：用 Lua 脚本封装整个流程，在 Redis 内完成“查 geo + 查 hash + 过滤 + 返回” —— 避免网络往返和中间态
- 解决方案二：写入时用
ZADD替代GeoAdd，把时间戳作为 score，配合ZRANGEBYSCORE做时效过滤（需自行维护坐标到 score 的映射） - 别依赖
WITHCOORD或WITHDIST做排序依据：它们不保证顺序，要排序得在 Go 层用sort.Slice
Go 客户端调用时 GeoLocation 结构体字段容易填错
go-redis 的 GeoLocation 结构体字段名和 Redis 原生命令参数不完全对应，容易混淆。比如 GeoRadius 的 radius 单位是字符串（"km"），但 GeoLocation.Radius 是 float64，单位由 GeoRadiusOption.Unit 控制 —— 这个分离设计常导致半径设成 100 却查出 100 米而非 100 公里。
- 务必显式设置
geoRadiusOptions := &redis.GeoRadiusOptions{Unit: "km", Count: 10, Sort: "ASC"} -
GeoLocation.Name是 Redis 返回的 member 名，不是你传的原始键名；若存的是svc-node-01，就别指望它自动变成svc-node-01.prod - 用
redis.GeoPos查单点坐标时，返回[]*redis.GeoPos，哪怕只查一个 member 也是切片，别漏掉索引[0]
topology.kubernetes.io/region）映射到预置坐标表，或者让每个节点启动时调用内部 IP 定位 API。这个环节出错，后面所有 Geo 查询都偏航。 
