我已经从希望完成相似的事情的用户那里看到了类似的问题，但并没有涉及到这个细节，我希望它可以帮助其他走这条路的人。这里是场景：我有一个android应用程序，它的功能之一是（具有权限）向应用程序上的其他用户显示用户位置（使用Google Map视图）。
我已经使用Socket.io从头开始构建了一个套接字服务器。套接字服务器与RethinkDB通信以进行实时更新。当客户端发出新位置时，套接字服务器将更新其在RethinkDB上的位置。套接字通过订阅数据库上的更改来获取更新的数据，然后将其发送给套接字上的其他用户以进行解析/显示在他们的地图上。
基本功能运行正常。两个用户可以在地图上实时看到彼此。现在是我面临的问题。使用Uber应用程序时，您只会看到您附近一定范围内的车辆。我想实现类似的目标。我的痛点在于确定如何最好地仅通知彼此在给定半径内的用户。佛罗里达的某个人不需要在加利福尼亚的某个人看到，我想如果联系很多，这将是一个巨大的负担。
我的第一个想法：随着每个位置更新的到来，请使用地理空间查询向附近的位置发出信号。如果存在许多连接，这在服务器上似乎要进行大量处理，并且不可行，因为它将发送给所有用户。
我的第二个想法（也是目前正在追求的）是使用Socket.io房间以某种方式根据用户的位置来分隔用户。在这种情况下，我对地址进行地理编码以获取地址，然后将其放置在服务器上用于其状态的房间中。这至少缩小了共享房间的用户数量。确实可以，但是只能在美国使用，居住在一个州边界上的用户可能会错过在附近的另一个州看到用户的机会。而且，状态仍然很大。用户只需要查看20英里范围内的其他人即可。除此之外没有其他必要。我认为这很有希望，但是有一些缺陷。
我正在考虑进一步研究的第三个想法是使用某种地理围栏。例如，将一个状态分成多个重叠的地理围栏。每个地理围栏在套接字上都有自己的空间。我相信这将是映射每个围栏的一项艰巨的任务，我将不得不决定客户端是否知道其所在的地理围栏，或者服务器是否能够处理该逻辑。最重要的是，除非每个围栏都与其相邻的围栏边缘重叠，否则您不会在附近的下一个围栏中看到用户。
所以我的问题：在我深入了解一条路线之前，我想看看是否有更好的选择，或者我是否正将其复杂化。我做了一些挖掘工作，以查看是否存在有关Uber如何确定哪些驱动程序最接近用户而没有运气的信息（可能是地理空间查询？）。无论如何，他们的解决方案在这种情况下可能无法正常工作，因为用户位置可能也在发生变化，同时仍在接收附近用户的更新，但是它的起点很高。
答案 0 :(得分：1)