redis目前已經到了3.2版本，3.2版本裡面新增的乙個功能就是對geo(地理位置)的支援。
地理位置大概提供了6個命令，分別為：
具體的功能如下：
1.命令：
geoaddkey longitude latitude member [longitude latitude member ...]
命令描述：將指定的地理空間位置（緯度、經度、名稱）新增到指定的key中。
返回值：
新增到sorted set元素的數目，但不包括已更新score的元素。
2.命令：
geodistkey member1 member2 [unit]
命令描述：
返回兩個給定位置之間的距離。如果兩個位置之間的其中乙個不存在， 那麼命令返回空值。指定單位的引數 unit 必須是以下單位的其中乙個：
3.命令：
geoposkey member [member ...]
命令描述：從key裡返回所有給定位置元素的位置（經度和緯度）。
返回值：geopos 命令返回乙個陣列， 陣列中的每個項都由兩個元素組成： 第乙個元素為給定位置元素的經度， 而第二個元素則為給定位置元素的緯度。當給定的位置元素不存在時， 對應的陣列項為空值。
4.命令：
geohashkey member [member ...]
命令描述：
返回乙個或多個位置元素的 geohash 表示。通常使用表示位置的元素使用不同的技術，使用geohash位置52點整數編碼。由於編碼和解碼過程中所使用的初始最小和最大座標不同，編碼的編碼也不同於標準。此命令返回乙個標準的geohash
返回值：乙個陣列， 陣列的每個項都是乙個 geohash 。 命令返回的 geohash 的位置與使用者給定的位置元素的位置一一對應。
5.命令：
georadiuskey longitude latitude radius m|km|ft|mi [withcoord] [withdist] [withhash] [count count]
命令描述：
以給定的經緯度為中心， 返回鍵包含的位置元素當中， 與中心的距離不超過給定最大距離的所有位置元素。
範圍可以使用以下其中乙個單位：
在給定以下可選項時， 命令會返回額外的資訊：
命令預設返回未排序的位置元素。 通過以下兩個引數， 使用者可以指定被返回位置元素的排序方式：
在預設情況下， georadius 命令會返回所有匹配的位置元素。 雖然使用者可以使用count選項去獲取前 n 個匹配元素， 但是因為命令在內部可能會需要對所有被匹配的元素進行處理， 所以在對乙個非常大的區域進行搜尋時， 即使只使用count選項去獲取少量元素， 命令的執行速度也可能會非常慢。 但是從另一方面來說， 使用count選項去減少需要返回的元素數量， 對於減少頻寬來說仍然是非常有用的。
返回值：
在返回巢狀陣列時， 子陣列的第乙個元素總是位置元素的名字。 至於額外的資訊， 則會作為子陣列的後續元素， 按照以下順序被返回：
以浮點數格式返回的中心與位置元素之間的距離， 單位與使用者指定範圍時的單位一致。
geohash 整數。
由兩個元素組成的座標，分別為經度和緯度。
6.命令：
georadiusbymemberkey member radius m|km|ft|mi [withcoord] [withdist] [withhash] [count count]
命令描述：這個命令和 georadius 命令一樣， 都可以找出位於指定範圍內的元素， 但是georadiusbymember的中心點是由給定的位置元素決定的。
redis原始碼 （九）Redis
前些天主要看了redis底層依賴的一些資料結構和事件管理庫的 比較零散，但大體上了解了作者的設計思路.對不同規模 n 的資料採用不同的資料結構以實現對記憶體利用的 最優 這裡的最優我想作者也沒有做過嚴格的實驗，不同的應用場景在redis上的表現肯定有所不同，如果有必要，可以再配置檔案中對一些閾值做調...
Redis學習之事務九
1.可以一次執行多個命令，本質就是一組命令的集合。乙個事務中的所有命令都會序列化，按順序地序列化執行而不會被其他命令插入，不許加塞。開啟事務執行 multi執行事務完成佇列中命令的執行 exec什麼是樂觀鎖？樂觀鎖 每次去那資料的時候都認為別人不會修改資料，所以不會上鎖，但是在更新的時候會去判斷一下...
Redis 九 redis使用場景
傳統mysql memcached架構遇到的問題 實際mysql是適合進行海量資料儲存的，通過memcached將熱點資料載入到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務資料量的不斷增加，和訪問量的持續增長，我們遇到了很多問題 1.mysql需要不斷進行拆庫拆表，memcach...