Я видел похожие вопросы от пользователей, желающих достичь чего-то похожего, но не в этой детали, и я надеюсь, что это поможет другим, кто пойдет по этому пути.Вот сценарий: у меня есть приложение для Android, и одна из его функций состоит в том, чтобы отображать (с разрешения) местоположение пользователей (используя представление Google Map) другим пользователям в приложении.
Я создал сокет-сервер с нуля, используя Socket.io.Сервер сокетов связывается с RethinkDB для обновления в реальном времени.Когда клиент отправляет новое местоположение, сервер сокетов обновляет свою позицию на RethinkDB.Сокет получает обновленные данные, подписываясь на изменения в базе данных, а затем отправляется другим пользователям в сокете для анализа / отображения на своих картах.
Базовая функциональность работает просто отлично.Два пользователя могут видеть друг друга в режиме реального времени на карте.Теперь встает проблема, с которой я сталкиваюсь.Когда вы пользуетесь приложением Uber, вы видите только транспортные средства, которые находятся в непосредственной близости от вас.Я хотел бы добиться чего-то подобного.Моя болевая точка заключается в определении того, как лучше всего уведомлять пользователей, которые находятся в пределах определенного радиуса друг от друга.Кому-то во Флориде не нужно видеть кого-то в Калифорнии, и я предполагаю, что это было бы огромной нагрузкой, если бы было много соединений.
Моя первая мысль: при каждом обновлении местоположенияприходит, выбрасывайте тех, кто рядом, используя геопространственный запрос.Это выглядит как большая обработка на сервере, если есть много подключений, и просто не практично, поскольку это излучает для всех пользователей.
Моя вторая (и в настоящее время изучаемая) мысль состоит в том, чтобы использовать комнаты Socket.io, чтобы каким-то образом разделять пользователей в зависимости от их местоположения.В этом случае я изменяю геокодирование их местоположения, чтобы получить адрес, и помещаю их в комнату на сервере для своего государства.Это по крайней мере сужает количество пользователей, которые делят комнату.Это работает, но будет работать только в США, и пользователи, которые живут на границе одного штата, могут упустить возможность увидеть пользователя в следующем штате, который находится поблизости.Кроме того, государство по-прежнему большая территория.Пользователям нужно только видеть других в радиусе 20 миль.Больше, чем это не нужно.Я думаю, что у этого есть обещание, но у него есть некоторые недостатки.
Третья мысль, которую я рассматриваю для дальнейшего исследования, заключается в использовании геозон.Например, разбиение состояния на несколько перекрывающихся геозон.У каждой геозоны будет своя комната на розетке.Я полагаю, что это будет большой задачей для составления карты каждого забора, и мне нужно будет решить, будет ли клиент знать, в какой геозоне он находится, или сервер обрабатывает эту логику.Вдобавок ко всему, если каждый забор не перекрывает соседний край заборов, вы не увидите пользователей на следующем заборе, который находится рядом.
Так что мой вопрос: Прежде чем я получуслишком глубоко в одном маршруте, я хотел посмотреть, есть ли лучший вариант или я слишком усложняю это .Я немного покопался, чтобы узнать, была ли информация о том, как Uber определяет, какие драйверы близки пользователю без удачи (вероятно, геопространственный запрос?).В любом случае, их решение может не сработать в этой ситуации, так как местоположение пользователей также может меняться, в то же время получая обновления от соседних пользователей, но его нужно где-то запустить.