Redis 在 3.2 版本以后增加了地理位置 GEO 模塊，意味著我們可以使用 Redis 來實現摩拜單車「附近的 Mobike」、美團和餓了么「附近的餐館」這樣的功能了。

用數據庫來算附近的人

地圖元素的位置數據使用二維的經緯度表示，經度范圍 (-180, 180]，緯度范圍 (-90, 90]，緯度正負以赤道為界，北正南負，經度正負以本初子午線 (英國格林尼治天文臺) 為界，東正西負。比如掘金辦公室在望京 SOHO，它的經緯度坐標是 (116.48105,39.996794)，都是正數，因為中國位于東北半球。

當兩個元素的距離不是很遠時，可以直接使用勾股定理就能算得元素之間的距離。我們平時使用的「附近的人」的功能，元素距離都不是很大，勾股定理算距離足矣。不過需要注意的是，經緯度坐標的密度不一樣 (經度總共 360 度，緯度總共 180 度)，勾股定律計算平方差時之后再求和時，需要按一定的系數比加權求和。

現在，如果要計算「附近的人」，也就是給定一個元素的坐標，然后計算這個坐標附近的其它元素，按照距離進行排序，該如何下手？

如果現在元素的經緯度坐標使用關系數據庫 (元素 id, 經度 x, 緯度 y) 存儲，你該如何計算？

首先，你不可能通過遍歷來計算所有的元素和目標元素的距離然后再進行排序，這個計算量太大了，性能指標肯定無法滿足。一般的方法都是通過矩形區域來限定元素的數量，然后對區域內的元素進行全量距離計算再排序。這樣可以明顯減少計算量。如何劃分矩形區域呢？可以指定一個半徑 r，使用一條 SQL 就可以圈出來。當用戶對篩出來的結果不滿意，那就擴大半徑繼續篩選。

select id from positions where x0-r  x  x0+r and y0-r  y  y0+r

為了滿足高性能的矩形區域算法，數據表需要在經緯度坐標加上雙向復合索引 (x, y)，這樣可以最大優化查詢性能。

但是數據庫查詢性能畢竟有限，如果「附近的人」查詢請求非常多，在高并發場合，這可能并不是一個很好的方案。

GeoHash 算法

業界比較通用的地理位置距離排序算法是 GeoHash 算法，Redis 也使用 GeoHash 算法。GeoHash 算法將二維的經緯度數據映射到一維的整數，這樣所有的元素都將在掛載到一條線上，距離靠近的二維坐標映射到一維后的點之間距離也會很接近。當我們想要計算「附近的人時」，首先將目標位置映射到這條線上，然后在這個一維的線上獲取附近的點就行了。

那這個映射算法具體是怎樣的呢？它將整個地球看成一個二維平面，然后劃分成了一系列正方形的方格，就好比圍棋棋盤。所有的地圖元素坐標都將放置于唯一的方格中。方格越小，坐標越精確。然后對這些方格進行整數編碼，越是靠近的方格編碼越是接近。那如何編碼呢？一個最簡單的方案就是切蛋糕法。設想一個正方形的蛋糕擺在你面前，二刀下去均分分成四塊小正方形，這四個小正方形可以分別標記為 00,01,10,11 四個二進制整數。然后對每一個小正方形繼續用二刀法切割一下，這時每個小小正方形就可以使用 4bit 的二進制整數予以表示。然后繼續切下去，正方形就會越來越小，二進制整數也會越來越長，精確度就會越來越高。

上面的例子中使用的是二刀法，真實算法中還會有很多其它刀法，最終編碼出來的整數數字也都不一樣。

編碼之后，每個地圖元素的坐標都將變成一個整數，通過這個整數可以還原出元素的坐標，整數越長，還原出來的坐標值的損失程度就越小。對于「附近的人」這個功能而言，損失的一點精確度可以忽略不計。

GeoHash 算法會繼續對這個整數做一次 base32 編碼 (0-9,a-z 去掉 a,i,l,o 四個字母) 變成一個字符串。在 Redis 里面，經緯度使用 52 位的整數進行編碼，放進了 zset 里面，zset 的 value 是元素的 key，score 是 GeoHash 的 52 位整數值。zset 的 score 雖然是浮點數，但是對于 52 位的整數值，它可以無損存儲。

在使用 Redis 進行 Geo 查詢時，我們要時刻想到它的內部結構實際上只是一個zset(skiplist)。通過 zset 的 score 排序就可以得到坐標附近的其它元素 (實際情況要復雜一些，不過這樣理解足夠了)，通過將 score 還原成坐標值就可以得到元素的原始坐標。

Redis 的 Geo 指令基本使用

Redis 提供的 Geo 指令只有 6 個，讀者們瞬間就可以掌握。使用時，讀者務必再次想起，它只是一個普通的 zset 結構。

增加

geoadd 指令攜帶集合名稱以及多個經緯度名稱三元組，注意這里可以加入多個三元組

127.0.0.1:6379> geoadd company 116.48105 39.996794 juejin
(integer) 1
127.0.0.1:6379> geoadd company 116.514203 39.905409 ireader
(integer) 1
127.0.0.1:6379> geoadd company 116.489033 40.007669 meituan
(integer) 1
127.0.0.1:6379> geoadd company 116.562108 39.787602 jd 116.334255 40.027400 xiaomi
(integer) 2

距離

geodist 指令可以用來計算兩個元素之間的距離，攜帶集合名稱、2 個名稱和距離單位。

127.0.0.1:6379> geodist company juejin ireader km
"10.5501"
127.0.0.1:6379> geodist company juejin meituan km
"1.3878"
127.0.0.1:6379> geodist company juejin jd km
"24.2739"
127.0.0.1:6379> geodist company juejin xiaomi km
"12.9606"
127.0.0.1:6379> geodist company juejin juejin km
"0.0000"

我們可以看到掘金離美團最近，因為它們都在望京。距離單位可以是 m、km、ml、ft，分別代表米、千米、英里和尺。

獲取元素位置

geopos 指令可以獲取集合中任意元素的經緯度坐標，可以一次獲取多個。

127.0.0.1:6379> geopos company juejin
1) 1) "116.48104995489120483"
 2) "39.99679348858259686"
127.0.0.1:6379> geopos company ireader
1) 1) "116.5142020583152771"
 2) "39.90540918662494363"
127.0.0.1:6379> geopos company juejin ireader
1) 1) "116.48104995489120483"
 2) "39.99679348858259686"
2) 1) "116.5142020583152771"
 2) "39.90540918662494363"

我們觀察到獲取的經緯度坐標和 geoadd 進去的坐標有輕微的誤差，原因是 geohash 對二維坐標進行的一維映射是有損的，通過映射再還原回來的值會出現較小的差別。對于「附近的人」這種功能來說，這點誤差根本不是事。

獲取元素的 hash 值

geohash 可以獲取元素的經緯度編碼字符串，上面已經提到，它是 base32 編碼。 你可以使用這個編碼值去 http://geohash.org/${hash}中進行直接定位，它是 geohash 的標準編碼值。

127.0.0.1:6379> geohash company ireader
1) "wx4g52e1ce0"
127.0.0.1:6379> geohash company juejin
1) "wx4gd94yjn0"

讓我們打開地址 http://geohash.org/wx4g52e1ce0，觀察地圖指向的位置是否正確。

很好，就是這個位置，非常準確。

附近的公司

georadiusbymember 指令是最為關鍵的指令，它可以用來查詢指定元素附近的其它元
素，它的參數非常復雜。

# 范圍 20 公里以內最多 3 個元素按距離正排，它不會排除自身
127.0.0.1:6379> georadiusbymember company ireader 20 km count 3 asc
1) "ireader"
2) "juejin"
3) "meituan"
# 范圍 20 公里以內最多 3 個元素按距離倒排
127.0.0.1:6379> georadiusbymember company ireader 20 km count 3 desc
1) "jd"
2) "meituan"
3) "juejin"
# 三個可選參數 withcoord withdist withhash 用來攜帶附加參數
# withdist 很有用，它可以用來顯示距離
127.0.0.1:6379> georadiusbymember company ireader 20 km withcoord withdist withhash count 3 asc
1) 1) "ireader"
 2) "0.0000"
 3) (integer) 4069886008361398
 4) 1) "116.5142020583152771"
 2) "39.90540918662494363"
2) 1) "juejin"
 2) "10.5501"
 3) (integer) 4069887154388167
 4) 1) "116.48104995489120483"
 2) "39.99679348858259686"
3) 1) "meituan"
 2) "11.5748"
 3) (integer) 4069887179083478
 4) 1) "116.48903220891952515"
 2) "40.00766997707732031"

除了 georadiusbymember 指令根據元素查詢附近的元素，Redis 還提供了根據坐標值來查詢附近的元素，這個指令更加有用，它可以根據用戶的定位來計算「附近的車」，「附近的餐館」等。它的參數和 georadiusbymember 基本一致，除了將目標元素改成經緯度坐標值。

127.0.0.1:6379> georadius company 116.514202 39.905409 20 km withdist count 3 asc
1) 1) "ireader"
 2) "0.0000"
2) 1) "juejin"
 2) "10.5501"
3) 1) "meituan"
 2) "11.5748"

小結 注意事項

在一個地圖應用中，車的數據、餐館的數據、人的數據可能會有百萬千萬條，如果使用Redis 的 Geo 數據結構，它們將全部放在一個 zset 集合中。在 Redis 的集群環境中，集合可能會從一個節點遷移到另一個節點，如果單個 key 的數據過大，會對集群的遷移工作造成較大的影響，在集群環境中單個 key 對應的數據量不宜超過 1M，否則會導致集群遷移出現卡頓現象，影響線上服務的正常運行。

所以，這里建議 Geo 的數據使用單獨的 Redis 實例部署，不使用集群環境。

如果數據量過億甚至更大，就需要對 Geo 數據進行拆分，按國家拆分、按省拆分，按市拆分，在人口特大城市甚至可以按區拆分。這樣就可以顯著降低單個 zset 集合的大小。

到此這篇關于Redis 的 GeoHash詳解的文章就介紹到這了,更多相關Redis 的 GeoHash內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！