Создание сервера xmpp для восходящего потока google gcm

Допустим, у вас есть приложение, которое имеет десятки миллионов установок и десятки тысяч активных пользователей в данный момент времени. Мне нужно регистрировать данные об активности моих пользователей на моих серверах. В настоящее время я делаю HTTP-запросы с устройства на свои серверы. У меня есть куча машин, на которых работает веб-сервер, сидящий за ELB Amazon. Они анализируют данные, поступающие с устройств, и помещают их в mongodb.

Теперь я хотел бы собирать данные устройства с помощью восходящего CCS, предоставляемого Google GCM (чтобы я мог использовать GCM для более надежной доставки данных). Я написал прототип XMPP-сервера, и я могу заставить все это работать, но я беспокоюсь о масштабировании. Что произойдет, если Google начнет отправлять мне сообщения со скоростью, превышающей скорость их потребления? Раньше я мог использовать несколько серверов за балансировщиком нагрузки, чтобы справиться с высокой скоростью запросов. Есть ли здесь понятие балансировки нагрузки?

Если я открою несколько подключений со своего сервера к серверу Google (Google говорит, что у меня может быть до 1000 подключений для данного идентификатора отправителя), будут ли входящие запросы балансироваться между этими подключениями?

Наконец, есть ли рекомендуемое решение, которое решит большинство вышеперечисленных проблем? Решит ли использование ejabberd некоторые из вышеперечисленных проблем?

Огромное спасибо.


person Vivek Pandey    schedule 20.10.2015    source источник


Ответы (2)


Что произойдет, если Google начнет отправлять мне сообщения со скоростью, превышающей скорость их потребления?

В конце https://developers.google.com/cloud-messaging/ccs вы может читать

И наоборот, чтобы избежать перегрузки сервера приложений, CCS прекращает отправку, если слишком много неподтвержденных сообщений. Таким образом, сервер приложений должен как можно скорее «подтвердить» восходящие сообщения, полученные от клиентского приложения через CCS, чтобы поддерживать постоянный поток входящих сообщений. Вышеупомянутый лимит ожидающих сообщений не применяется к этим ACK. Даже если количество ожидающих сообщений достигает 100, сервер приложений должен продолжать отправлять ACK для сообщений, полученных от CCS, чтобы избежать блокировки доставки новых восходящих сообщений.

В том же документе вы найдете частичный ответ на второй и третий вопросы.

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

Для меня это означает, что Google реализовал простую логику избыточности и, вероятно, нечестную систему балансировки нагрузки (во всяком случае, я на это надеюсь). Если у вас есть такие большие объемы, я предлагаю вам связаться с ними напрямую.

Для последних ejabberd — хороший продукт, есть много развернутых систем с кластерной инфраструктурой и куча документов о том, как это сделать. Я предлагаю вам начать отсюда http://docs.ejabberd.im/admin/guide/clustering / .

В любом случае, для ваших больших объемов я бы оценил RabbitMQ, который является еще одной жемчужиной Erlang.

person Emiliano Bonassi    schedule 30.10.2015

ejabberd можно сгруппировать и разместить за балансировщиком нагрузки для распределения соединений. Кластер из 3 или 4 серверов должен нормально справляться с такой нагрузкой и обеспечивать защиту от сбоев. При необходимости вы можете добавить серверы. Как только вы приблизитесь к 10 серверам, вы можете рассмотреть возможность использования Redis для БД в памяти, а не для mnesia.

person sam schonstal    schedule 25.10.2015