ТАК, я хочу спросить что-то, чего не могу понять. Например, у меня есть приложение, которое требуется для отслеживания местоположения APPLICATION_1, и оно обновляется в базе данных Firebase RealTime, которая в дальнейшем используется моим сервером. Теперь я хочу показать это непрерывное расположение на двух других приложениях. Делая Rnd, я узнал о реализации сокетов, но учту, что у меня есть 200 пользователей, использующих APPLICATION_1 и постоянно загружающих данные в базу данных Firebase, а затем эти данные передаются 400 конечным пользователям через сервер, что означает сохранение или сохранение 400 сокетов открытыми для этой самой цели , Это выглядит как очень плохой вариант для моего сервера, так как он будет зависать и может в итоге перестать отвечать. Однако, если я использую альтернативный рекурсивный API Callback, который пингует сервер для определения местоположения 200 пользователей APPLICATION_1 в реальном времени, это тоже ужасное решение. Я как бы зашел в тупик в том, какой подход использовать при реализации решения для этой конкретной проблемы. Ограничение состоит в том, что у меня есть только 1 сервер и 3 приложения для передачи данных, которые в дальнейшем могут использоваться многими пользователями.
UPDATE
Ну, после долгих размышлений я пришел к следующим выводам:
Установить соединения Кафки:
Как это делает Youtube или другие сайты потоковой передачи данных, платформа должна кэшировать свои ресурсы и передавать их через поток, как это в настоящее время делает Kafka. Поэтому было бы необходимо написать оболочку для потока Kafka на всех концах платформы, таких как web-оболочки, ios и android-оболочки. Тем не менее, то, что делает Youtube, это то, что изначально он устанавливает соединение один к одному между клиентом и сервером, независимо от того, насколько велико расстояние, но, поскольку Youtube - гораздо БОЛЬШАЯ платформа, если он чувствует, что больше пользователей используют этот поток, он делает копия текущего потока и публикует его на соседнем сервере, куда клиенты, получающие его из этой местности, перемещаются. Мы не можем этого сделать, поскольку у нас ограничены функциональные возможности сервера.
Реализация API обратных вызовов:
Хорошая реализация Callbacks API изначально казалась очень рекурсивной и плохой реализацией, но потом я исследовал ее для платформы Интернета вещей и обнаружил, что IOT реализует другой протокол вызовов API, MQTT , который гораздо легче, долговечнее и не ресурсосберегающее решение. Однако это также требует обещаний (нужно погрузиться в это больше).
Получение FireBase Realtime Database Feed напрямую:
База данных Firebase RealTime обеспечивает синхронизацию в реальном времени и кажется наилучшей альтернативой, однако учтите, что если 200 пользователей APPLICATION_1 обновляют FireBase RDB, то стоимость будет указана только для тех 200 пользователей, которые используют APPLICATION_1, тогда как когда 200 пользователей APPLICATION_2 и 200 пользователей APPLICATION_3 извлекают данные из одна и та же БД, общее количество узлов достигает 600, и это может быть довольно дорого. Масштабируемость Firebase имеет значение здесь.
Реализация сокетов:
Розетки портовые голодные. Несмотря на то, что их соединение один к одному является бесшовным и идеальным для связи, они имеют тенденцию становиться проблемой, когда количество узлов резко увеличивается. Следовательно, если сервер используется для множества процессов обработки данных, это может быть не идеальным решением.