【系统设计】本地生活之附近商家 LBS 服务实现

LBS

在本章中我们会设计一个基于位置的附近商家服务系统，用于发现用户附近的一些地方，比如餐厅、酒店、话剧院、博物馆等。

明确需求

张三：用户可以制定搜索半径吗？如果搜索范围内没有足够的商家，系统是否支持扩大半径？

面试官：这是一个非常好的问题，让我们假设仅需要考虑一个确定范围内的商家，如果之后的时间允许我们再考虑如果没有足够商家时扩大搜索范围的问题。

张三：系统能支持的最大半径是多少？我们可以设定为 20 km？

面试官：这是一个合理的假设。

张三：用户可以通过 UI 自行更改搜索半径吗？

面试官：当然，我们有大概有如下一些选择，如 0.5km、1km、2km、5km、10km、20km。

张三：商家信息的 CRUD 是如何操作的？且是否需要实时展示？

面试官：商家信息是店主添加、删除和修改的，这些信息会在第二天生效？

张三：用户可能在使用期间移动位置，我们是否需要更新搜索结果？

面试官：让我们假设用户的移动速度非常慢，以至于无需持续更新结果。

功能要求

基于上诉的交流，我们注意到三个关键功能：

• 需要基于用户位置（经纬度）和搜索半径返回商家信息。
• 店主可以 CRUD，但信息无需实时更新到前台。
• 用户可以查看商家的详细信息。

非功能要求

从商业角度，我们可以推理出一系列非功能性要求，可以和面试官讨论：

• 低延迟：用户需要快速的获得搜索结果。
• 数据隐私：地理位置信息是一个敏感数据，当我们设计一个基于地理位置服务的系统时，应该将用户的隐私保护考虑进去。
• 高可用和可拓展性：我们需要确保我们的系统可以支持人口密集地区高峰时间段的流量。

粗略评估

让我们做一些简单的评估，以便明确我们的设计方案面临的签字风险和挑战。此处假设我们拥有 100 万的日活用户和 200 万的商家。

方案设计

本小节中我们需要提出以下部分的设计并获得面试官认可：

• API 接口设计
• 高层次设计
• 算法（查询商家）设计
• 数据模型

API 设计

这里作者通过 RESTful 协议设计出几个简单的 API 接口。

GET /v1/search/nearby

以及商家管理 API：

数据模型

这里我们需要再次明确一下读写比例和 schema 设计。同时数据库的可伸缩性也在深层次的讨论中。

• 商家表

business	desc
bussiness_id	PK
address
state
latitude
longitude

• GEO 索引表

一张 GEO 索引表可以支持高效的空间计算操作，但需要对 geohash 有一定了解。