位置请求的缓存策略答案

【问题标题】：Caching Strategy for location requests位置请求的缓存策略
【发布时间】：2014-06-01 16:42:18
【问题描述】：

我正在构建在特定区域返回数据（比如说事件）的 REST API。 REST URL 是一个简单的 GET

/api/v1/events?lat=<lat>&lng=<lng>&radius=<radius>.

使用参数lat、lng 和radius（默认为10 英里），纬度和经度是设备或浏览器API 返回的内容。现在不用说，随着用户的移动，lat 和 lng 会不断变化，而且两个用户可以在相同的附近，但 lat / lng 不同。在服务器上缓存此类请求的最佳方法是什么，这样我就不必每次都深入研究业务逻辑。由于 lat/lng 更改，该 URL 不会是唯一的。

谢谢

【问题讨论】：

您的意思是在您的应用程序代码中进行缓存，还是使用允许缓存带有查询字符串参数的请求的缓存服务器？
所以让我澄清一下，如果两个人请求在 yelp 上获取特定 lat、lng 和 radius 的餐厅信息。让它们之间的绝对距离小于 0.1 英里或某个阈值。你如何对系统进行编码以便从缓存中返回结果而不是进入后端数据库等......
好的，你的意思是缓存你的地理定位算法和数据库的结果，这样当你在附近找到另一个位置时，它使用缓存，而不是 http 请求。让我考虑一下。
完全正确......我认为这是一个足够普遍的问题......似乎在任何地方都没有找到任何讨论或考虑过。
看看 r-trees。不是地球上最快的结构，但可以解决您的问题

标签： rest caching geolocation location http-caching

【解决方案1】：

我假设您有某种“网格”，当用户请求特定坐标时，您会返回该位置周围的网格图块。所以你有一个无限的 URL 空间（坐标），它映射到有限数量的图块。一种解决方案是将每个请求重定向到该图块的“规范”缓存友好 URL，例如

GET /api/v1/events?lat=123&lng=456
=>
302 Found
Location: /api/v1/events?tile=abc

或者，如果您想在 URL 中保留纬度/经度信息，您可以使用磁贴中心的位置。

【讨论】：

【解决方案2】：

我认为最好的方法是您将结果存储在以中心坐标为键的缓存中，然后在圆内查询新请求的点。

我不知道有任何缓存引擎可以让您执行空间查询，所以我认为您必须使用一个可以轻松查询和索引空间数据的数据库。您可以使用该数据库来缓存您的结果，或者至少将该结果的密钥存储在其他地方的缓存引擎中，然后您可以使用空间坐标查询它们，询问与您的新请求具有阈值距离的所有点。

PostGis 用于 PostgreSQL，它应该非常简单，因为它完全支持纬度/经度距离计算。一旦你用适当的索引设置它，它应该很简单：

SELECT * FROM your_cache_table 
WHERE ST_Distance_Sphere(the_geom, ST_MakePoint(new_lon, new_lat)) <= 160.934

MySQL 对 OpenGis 扩展有一些支持，但是它不支持纬度/经度距离计算。也许你需要自己做一些计算，也许简单的笛卡尔距离对你有用。检查文档here，this answer 也应该有所帮助。

我也相信即使 MySQL 5.6 仍然只支持 MyISAM 表中的空间索引，但这应该不是问题，因为您只是将它们用于缓存。

管理缓存可能比平时复杂一些。如果您需要过期，您应该只在数据库中存储密钥并在缓存服务器上设置过期参数。当您点击不再有有效密钥的数据库点时，您可以从数据库中清除它。当主要数据发生变化时，您可能需要一种使缓存失效的方法，从数据库和缓存服务器中删除。

【讨论】：

【解决方案3】：

我一直在对一个爱好应用程序进行数据建模，该应用程序也需要处理地理位置数据，并且不得不尝试解决类似的问题。解决方案当然取决于您拥有的约束以及对您的应用程序的目的至关重要的实际用例。我将假设您具有设计灵活性来更改应用程序的所有方面。即技术栈。

注意：

... 这样我就不必每次都深入研究业务逻辑。网址不是自从 lat/lng 改变后，将变得独一无二。

以上是一个模棱两可的陈述，因为不深入研究业务逻辑可能意味着很多事情。我假设这意味着您不想进行任何数据库查询来检索可能与缓存中已有数据相似的新数据。还假设您只想在服务器上缓存，可以想到以下方法：

在数据库和应用程序之间缓存数据。

数据库 ---> 缓存 --> 应用程序 ---> 用户

在这种方法中，您的应用程序会处理所有其余的 api 调用，然后决定是可以使用缓存中的结果还是需要其他数据库访问。

在应用程序和用户之间缓存数据。

数据库 --> 应用程序 ---> 缓存 ---> 用户

考虑到 url 总是在变化，这种方法有点棘手。因此，您可能需要一个“智能缓存机制”来处理传入的 url，然后确定缓存的数据是否相关。智能缓存可以通过多种方式完成，具体取决于您的应用程序是如何实现的。像 mongodb 这样的东西可以用作 json 缓存，然后可以对每个传入的请求进行预处理，以查看数据是否可以从该缓存返回或重定向到主应用程序。所以结构可能如下所示：

数据库 --> 应用程序 ---> (一些逻辑(例如 NodeJS 应用程序) + Mongodb) ---> 用户

结论：

如果不了解解决方案的架构、关键用例和完整的设计约束，就无法真正提出针对此问题的完整解决方案。您可能必须重新考虑您尝试提供的某些功能，并做出艰难的妥协以使事情正常进行。希望这里不同人提供的建议会有所帮助。

【讨论】：