Рекомендации по разделу тем pubsub на основе геохешей для умелого сервиса веб-сокетов

Question

Мой вопрос касается следующего варианта использования:

Актеры варианта использования

• Пользователь A: Пользователь, который устанавливает область широковещания и просматривает поток в режиме реального временисообщения.
• Пользователь B: первый пользователь, который отправляет широковещательное сообщение из области широковещания, установленной пользователем A.
• Пользователь C: второй пользователь, который отправляет широковещательное сообщение из набора широковещательной областипо пользователю A.

Описание использования

• Пользователь A выбираетшироковещательный регион, в пределах которого (радиусов) он / она хочет получать прямые широковещательные сообщения.
• Пользователь A открывает канал прямой трансляции и запрашивает начальный набор элементов канала прямой трансляции.
• Пользователь B передает сообщение из региона широковещательной рассылки пользователя A, в то время как прямая трансляция пользователя A все еще открыта.Ярлык с 1 новым элементом прямой трансляции появляется в верхней части прямой трансляции пользователя А, когда он открыт.
• Когда пользователь C публикует еще одно сообщение прямой трансляции из выбранного региона вещания от пользователя A, счетчик меток увеличивается.

Пользователь A получает уведомление, похожее на этот пример Facebook:

Решение, которое я решил применить (и которое, я думаю, использует Pubnub), - создать тему для каждого геохеша.
В моем случае это будет означать, что для каждого пользователя, передавшего сообщение, его необходимо опубликовать в теме геохеша, а клиенты (пользователи приложения / веб-сайта) будут использовать геохэш-топичем через веб-розетку, если она попала в диапазон заданной области (радиуса).Кажется, Ably предоставляет такой масштабируемый сервис с использованием веб-сокетов.

Полагаю, это было бы упрощенно примерно так:

Так что это означает, что геохэш должен быть извлечен из текущегоместо, откуда отправляется широковещательное сообщение.Этот геохэш должен иметь гранулярный масштаб, который достаточно мал, чтобы принимающий пользователь мог установить область широковещательной передачи, которая является более или менее точной.(Т.е. геохэш должен иметь достаточную точность, если мы хотим позволить пользователям определять область широковещания, в которой будут поступать живые сообщения, а это означает, что следует ожидать довольно большое количество тем, если мы решили масштабировать).

Вариант 2 заключается в создании тем для геохеша, который имеет менее специфическую гранулярность (охватывающую большую область), и позволяет клиентам обрабатывать точность на основе значений latlng, которые отправляются вместе с сообщением.
Затем клиент будет решать, следует ли удалять сообщения.Однако это означает, что отправляется больше сообщений (больше накладных расходов) и более высокая стоимость.

У меня нет опыта работы с такой архитектурой, и я сомневаюсь в жизнеспособности / масштабируемости этого подхода.
Не могли бы вы придумать альтернативное решение этого вопроса для достижения желаемого результата или предоставить более глубокое понимание?о том, как решить эту проблему в целом?(Я также подумал об использовании регулярного потока req-res, но это означает рассылку спама на сервер, что также не кажется очень хорошим решением).

Я на самом деле проверил.
Учитывая область 161,4 км ² (например, область Брюссель), геохэш делится на длину строки следующим образом:

1   ≤ 5,000km   ×   5,000km
2   ≤ 1,250km   ×   625km
3   ≤ 156km     ×   156km
4   ≤ 39.1km    ×   19.5km
5   ≤ 4.89km    ×   4.89km
6   ≤ 1.22km    ×   0.61km
7   ≤ 153m      ×   153m
8   ≤ 38.2m     ×   19.1m
9   ≤ 4.77m     ×   4.77m
10  ≤ 1.19m     ×   0.596m
11  ≤ 149mm     ×   149mm
12  ≤ 37.2mm    ×   18.6mm

Учитывая, что мыпозволит пользователям иметь возможную неточность до 153 м (для региона, на который пользователи могут захотеть подписаться на получение локальных широковещательных сообщений), это потребует определенного количества тем, которые уже слишком велики, чтобы охватить только весь регион.Брюссель.
Так что я все еще немного застрял на этом уровне в настоящее время.

Answer 1

Если оставить в стороне вопрос об Ably, Pubnub и решении «Сделай сам», суть вопроса такова:

Где происходит фильтрация сообщений?

Существует три возможных решения:

1. Служба Pub / Sub.

2. Сервер (обработчик соединения WebSocket).

3. Клиентсторона (устройство клиента).

Поскольку это, очевидно, мобильный подход, фильтрация сообщений на стороне клиента является чрезвычайно грубой, поскольку увеличивает потребление данных клиентом, в то время как большая часть данных можетне имеет значения.

Фильтрация на стороне клиента также увеличит потребление батареи и, вероятно, приведет к снижению коэффициента приемки клиентами.

Это оставляет фильтрацию пабов / субфильтраций (имена каналов / сопоставление с образцом) и сервер-боковая фильтрация.

Фильтрация имен пабов / подканалов

Одна паб / под сервис обслуживает несколько серверов (если не все), что делает его очень дорогим ресурсом (относительный(1029 *

Использование имен каналов для фильтрации сообщений было бы идеальным вариантом - , если фильтрация дешевая (с использованием точных совпадений с отображением хэша имени канала).

Однако сопоставление с образцом (при подписке на каналы с неточными именами, такими как "users.*") очень велико по сравнению с точным сопоставлением с образцом.

Это означает, что фильтрация названий каналов Pub / Sub Channelневозможно использовать для фильтрации всех сообщений без перегрузки системы pub / sub.

Фильтрация на стороне сервера

Поскольку сервер принимает соединения WebSocket и мосты между WebSocket и службой pub / subон идеально подходит для фильтрации сообщений.

Однако мы не хотим, чтобы сервер обрабатывал все сообщения для всех клиентов для каждого соединения, так как это является чрезмерным дублированием усилий.

Гибридное решение

Классическое решение разделит землю на управляемые участки (1 кв. Км на участокдля полного охвата потребуется 510,1 миллиона уникальных имен каналов ... но я бы посоветовал пренебречь 70% пространства океана).

Занятые участки могут быть разделены (для Нью-Йорка может потребоваться участок на 250 кв. м.чем 1 кв. км).

Это позволяет издателям публиковать точные названия каналов, а подписчикам - точные названия каналов.

Издателям может потребоваться публикация более чем на один канал, и подписчикам может потребоватьсяподписаться на более чем один канал, в зависимости от их точного местоположения и границ сетки.

Эта схема фильтрации будет фильтровать много, но не все.

Узлу сервера нужно будет посмотреть всообщение, проверьте его точное географическое местоположение и отфильтруйте сообщения, прежде чем решить, следует ли их отправлять по соединению WebSocket клиенту.

Почему гибридное решение?

Это позволяет системе масштабироваться сотносительная простота.

Поскольку серверные узлы (по замыслу) дешевле, чемслужба pub / sub, они могут использоваться для точной фильтрации местоположения (тяжелая работа).

В то же время, сила системы pub / sub может использоваться для минимизации нагрузки на сервер иОтфильтровать очевидные несоответствия.

Пубнуб против Абли?

Не знаю.Я не использовал ни один из них.Я работал с Redis и внедрил свое собственное решение для пабов / суб.или сложные ситуации.ИМХО, похоже, что я попал бы в категорию DIY, если бы я его реализовал.

Answer 2

1.PubNub

В настоящее время PubNub является единственной услугой, которая предлагает готовое решение для геохаш-пабов через веб-розетки, но их цена очень высока (500 подключенных устройств стоят около 49 $, 20 000 устройств стоят 799$) ОБНОВЛЕНИЕ: PubNub обновил цену, теперь с неограниченным количеством устройств .Скоро будут обновлены веб-сайты.

Pubnub работает над своей моделью ценообразования, потому что некоторые из их клиентов платили много за неожиданные всплески трафика.

Однако это не будет жизнеспособным решением для универсального приложения обмена сообщениями, которое должно быть открыто для всех и для которого трафик поэтому очень непредсказуем.

Очень жаль, поскольку этот сервис был бы для нас идеальным решением в противном случае.

2.Ably

Ably предлагает систему pubsub для потоковой передачи данных клиентам через веб-сокеты для пользовательских каналов.Каналы создаются динамически, когда клиент присоединяется, чтобы либо опубликовать, либо подписаться на этот канал.

Основная проблема здесь заключается в том, что:

• Если нам нужна высокая точность геохеша, нам нужно большое количество каналов и, следовательно, мы должны платить больше;
• Если мы пойдем с низкой точностью геохеша, будет много лишних сообщений: допустим, что мы берем канал, который представлен геохешем из 4 символов, охватывающий географическую область 39,1 x 19,5 км.

Любая запись, отправляемая на этот канал, будет мультиплексирована всем в этом регионе, кто в данный момент слушает.

Однако предположим, что наше приложение допускает максимальный радиус 10 км, и половина подключенных пользователей имеет настройку на радиус 1 км.

Это означает, что все сообщения за пределами этого радиуса в 2 км будут излишне мультиплексированы для этих пользователей и будут просто отброшены без дальнейшего использования.

Мы также должны учитывать масштабируемость этого подхода.Для каждого геохеша, который нужен как производителю, так и потребителю, будет создан другой канал.

Определенно дороже иметь приложение, для которого требуются темы, основанные на геошах по всему миру, чем приложение, которое требует только тем, основанных на темах.

То есть, по всему миру количество тем резко возрастает, а следовательно, и цена.

Другое соображение заключается в том, что нашему приложению требуется дополнительное количество каналов:

• По геохэшу и группе: наше приложение позволяет создавать группы на основе геолокации (что будет эквивалентноТвиттер как #hashtags).
• По месту
• По подписчикам (расширенная функция)

Этот подход имеет несколько оптимистичных соображений, несмотря на:

• Потоковая передача требуется только при активной ленте новостей: когда у пользователя открыто окно браузера на нашем веб-сайте +, когда пользователь подключен к мобильному устройству и активно открыт соответствующий канал
• Можно выполнить дальнейшую оптимизацию,например, потоковую передачу можно начинать только через 10–20 секунд после обновления канала
• Потоковая передача по местным / последующим пользователям может иметь высокий трафик в зависимости от текущей активности, но многие каналы мест также будут простаивать

Очень важным замечанием в этом отношении является то, как Ably выставляет счета своим потребителям, что может быть использовано для нашего полного преимущества:

Канал открывается, когда происходит любое из следующего:

• Сообщение публикуется на канале через REST
• Клиент, подключенный к каналу в реальном времени.Канал остается активным в течение всего времени, когда клиент подключен к этому каналу, поэтому, если вы подключаетесь к Ably, подключаетесь к каналу и публикуете сообщение, но никогда не отключаете канал, канал будет оставаться активным до тех пор, пока это соединение остаетсяopen.

Открытый канал автоматически закроется, когда всеприменяются следующие условия:

Больше нет клиентов реального времени, подключенных к каналу. С момента публикации последнего сообщения прошло не менее двух минут.Мы поддерживаем каналы в течение двух минут, чтобы обеспечить непрерывность канала как часть восстановления состояния соединения.

Например, если у вас есть 10 000 пользователей, и в ваше самое загруженное время месяцаэто один пик, когда 500 клиентов устанавливают соединение в реальном времени с Ably, и каждый из них подключается к одному уникальному каналу и одному глобальному общему каналу, максимальное количество каналов будет суммой 500 уникальных каналов на клиента и одного глобального общего канала, то есть 501пиковые каналы.Если в течение месяца каждый из этих 10 000 пользователей подключается к своему уникальному каналу и подключается к нему, но не обязательно в одно и то же время, это не влияет на количество пиковых каналов, поскольку пиковые каналы - это одновременное количество каналов, открытых в любой момент времени.в течение этого месяца.

Оптимистичный вывод

Самый важный вывод заключается в том, что мы должны учитывать, что эта функция может быть не столь важной, как полагают, что дляПервая версия приложения.

Несмотря на то, что Twitter, Facebook и т. Д. Предлагают эту функцию получения обновлений в реальном времени (и пользователи ожидают этого), первоначальная бета-версия нашего приложения в ограниченном масштабе может работать без, то есть пользователь должен обновлять вЧтобы получать новые обновления.

Во время первого запуска приложения можно собирать статистику, чтобы получить более подробные сведения о поведении пользователей.Это позволит нам строить более надежные инфраструктурные и финансовые размышления на основе фактических данных.