There's no need to use redis for latitude and longitude queries, except for the cache. In fact, we've done a similar in hacker marathon, and its core idea is to remove users near the current user location.
We're using 's geo index, here's a detailed introduction to http://www. Mongodb. org/display/DOCS/G..
But I noticed that you're using MySQL, although mongodb is able to achieve this goal, but if you don't want to migrate the database, there's a way to do it, of course. Most of the things I've shown below are from the MySQL ab introduction to the article of geo search.
First, we need to solve the difference between the difference between the latitude and longitude, which involves some angle conversion formulas.
d is distance ( distance ),
R is a. It's very complex, but our final goal is to get
d out, we look at the evaluation process, the following is a
R = 地球半径
Δlat = lat2 − lat1//纬度之差
Δlong = long2 − long1//经度之差
a = sin2(Δlat/2) + cos(lat1) * cos(lat2) * sin2(Δlong/2)
c = 2*atan2(√a, √(1−a))
d = R*c
To convert it into sql code, look at a little halo, where 3956 is the ground ball.
￼3956 * 2 * ASIN ( SQRT (
￼￼POWER(SIN((orig.lat - dest.lat)*pi()/180/2), 2) + COS(orig.lat * pi()/180) * COS(dest.lat * pi()/180) * POWER(SIN((orig.lon - dest.lon) * pi()/180/2), 2) ) ) as distance
Ok, the evaluation code is out of order to write a test ( the hotel table has three fields
SELECT *, 3956 * 2 * ASIN(SQRT(
POWER(SIN((@orig_lat - abs(dest.lat)) * pi()/180/2), 2) + COS(@orig_lat * pi()/180 ) * COS(abs(dest.lat) * pi()/180) * POWER(SIN((@orig_lon - dest.lon) *
pi()/180/2), 2) )) as distance FROM hotels dest
having distance <@dist ORDER BY distance limit 10;
So you can search all the hotels in the current position
10. You can optimize this code with stored procedures so that it's faster.