在lbs的應用中，乙個基本的需求是查詢附近的使用者，現在有兩種做法：
1. 使用mysql的空間資料庫，具體做法參考： 。
2. 使用geohash編碼，這個是本文需要討論的。
geohash編碼，可以把球面上的經緯度轉換成乙個值，簡單點來說就是把二維座標轉換成一維座標。查詢附近的時候，非常方便，用sql中，like 『w23yr3%』可查詢附近的所有地點。
geohash的詳細介紹，可參考
在以前的產品中，乙個需求是查詢使用者附近的商鋪，發現用mysql like 『w23yr3%』這種方式檢索geohash效能上的瓶頸很大，檢索130萬行的資料，平均花費了8秒，這是響應速度是無法忍受的。
後來經過不斷優化，確定了如下使用coreseek+redis+mysql解決方案，一下子就把響應速度減少到平均1 秒，這個方案的如下：
1. 用每個商鋪的座標值計算geohash，把geohash作為key，商鋪的作為value，放到redis的set集中。
$this->cache->redis->select(1);//不能使用0，因為這裡有大量的資料，需要獨立
$this->cache->redis->set('place:geohash:'.$geohash,$place_id);
2. 根據使用者的座標，在redis中查詢附近的商鋪id
<?php/*** 獲取附近的地標公共處理方法
* @param $lat
* @param $lng
* @param $n geohash值的長度，一般來說，當n=6,是獲取當前附近1千公尺範圍內的使用者
*/function getlocalplace($lat, $lng, $n)}}
if ($searchkeys)
}return $placeids;
}
3. 如果需要查詢關鍵字或商鋪的型別，則用把2中$placeids 作為filter調戲 ，在coreseek中繼續查詢。
如果您覺得這系列的文章對你有所幫助，歡迎打賞。
支付寶賬號：[email protected] 收款人：曾健生
[文章作者]曾健生
[作者郵箱][email protected]
[作者qq]190678908
[部落格]
app後端設計 資料增量更新
因為分頁機制的存在，這個演算法實現起來是挺多需要注意的地方，下面我舉乙個簡化的例子詳細說明 一些假設 count 每頁的顯示條數 預設為3 page 當前頁碼 預設為1 since 時間戳，若指定此引數，則返回時間戳大於等於since的結果 應該是上次獲取的最新資料的update time max ...
app後端設計 資料增量更新
因為分頁機制的存在，這個演算法實現起來是挺多需要注意的地方，下面我舉乙個簡化的例子詳細說明 一些假設 count 每頁的顯示條數 預設為3 page 當前頁碼 預設為1 since 時間戳，若指定此引數，則返回時間戳大於等於since的結果 應該是上次獲取的最新資料的update time max ...
app後端設計 5 表情的處理
1.表情在mysql的儲存。表情的utf8編碼，有時是有4個位元組的，所以在一般的utf編碼是沒法儲存的，我在網上看到的乙個常用的解決方案，是把mysql公升級到5.5,然後把字元編碼改為utf8mb4 general ci。但在實踐中，我發現了還有乙個方法，適用於mysql 5.1,就是把含有表情...