简介
移动互联网时代LBS应用越来越多,交友软件中附件的小姐姐、外卖软件中附件的美食店铺、高德地图附近的核酸检查点等等,那这种附件各种形形色色的XXX地址位置选择时如何实现的?
地球上的地理位置是使用二维码的经纬度表示,经度范围(-180,180],维度范围(-90,90],只要我们确定一个点的经纬度就可以名取得他在地球上得位置。
例如嘀嘀打车,最直观得操作就是实时记录各个车的位置,然后我们要找车时,在数据库中查找距离我们(坐标x0,y0)附件r公里范围内部的车辆
使用如下SQL即可:
select taxi from position where x0-r < x < x0 + r and y0-r < y <y0+r
但是这样会有什么问题呢?
1.查询性能问题,如果并发高,数据量大这种查询是要搞垮数据库的。
2.这个查询的是一个矩形访问,而不是以我为中心的r公里为半径的圆形访问。
3.精确度的问题,我们知道地球不是平面坐标系,而是一个圆球,这种矩形计算在长距离计算时会有很大误差。
GEOADD 添加经纬度坐标
127.0.0.1:6379>GEOADD city 116.403963 39.915119 "天安门" 116.403414 39.924091 "故宫" 116.024067 40.362639 "长城"
(integer) 3
127.0.0.1:6379>ZRANGE city 0 -1
1) "\xe5\xa4\xa9\xae\x89\xe9\x97\xa8"
2) "\xe6\x95\x85\xe5\xae\xab"
3) "\xe9\x95\xbf\xe5\x9f\x8e"
出现中文乱码 进入redis前加上-- raw参数即可正常显示
redis-cli --raw
127.0.0.1:6379>ZRANGE city 0 -1
天安门
故宫
长城
GEOPOS 返回经纬度
127.0.0.1:6379>GEOPOS city 天安门 故宫 长城
116.40396326780319214
39.91511970338637383
116.40341609716415405
39.92409008156928252
116.02406591176986694
40.36263993239462167
GEOHASH 返回坐标的GEOHASH表示
127.0.0.1:6379>GEOHASH city 天安门 故宫 长城
wx4g0f6f2v0
wx4g0gfqsj0
wx4t85yikt0
GEODIST 两个位置之间的距离
127.0.0.1:6379>GEODIST city 天安门 长城 km
59.3390
127.0.0.1:6379>GEODIST city 天安门 长城 m
59338.9814
GEORADIUS 以半径为中心,查找附近的XXX
GEORADIUS city 116.418017 39.914402 10km withdist withcoord withhash count 10 desc
WITHDIST:在返回位置元素的同时,将位置元素与中心之间的距离也一并返回,距离的单位和用户给定的范围单位保持一致。
WITHCOORD:将位置元素的经度和维度也一并返回。
WITHHASH:以52位有符号整数的形式,返回位置元素经过原始geohash编码的有序集合分值,这个选项主要用于底层应用或者调试,实际中作用并不大.
127.0.0.1:6379>GEORADIUS city 116.418017 39.914402 10 km withdist withcoord withhash count 10 desc
故宫
1.6470
4069885568908290
116.40341609716415405
39.92409008156928252
天安门
1.2016
4069885555089531
116.40396326780319214
39.91511970338637383