Рекомендации по инфраструктуре для мультиплатформенных push-уведомлений

мы планируем внедрить push-приложения в наши мобильные приложения (для телефонов и планшетов Android, iPhone, iPad и Blackberry).

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

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

Мои вопросы:

  1. Можете ли вы дать мне совет по технологии для использования на стороне сервера? Он должен очень хорошо масштабироваться (я ожидаю много подписок на разных платформах), в идеале работать с распространенными push-шлюзами и быть достаточно быстрым, чтобы обрабатывать все уведомления до поступления следующего пакета данных.

  2. У меня есть опасения по поводу скорости доставки этих уведомлений. Допустим, у нас есть 500 000 подписок и данные совпадают на 50%, это означает, что нам нужно отправить 250 000 уведомлений за 15 минут. Есть ли у вас опыт работы с большими числами и push-уведомлениями?

Большое спасибо, Марк.


push-notification architecture infrastructure
person Cornelius    schedule 27.05.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Хотя PHP отлично подходит для создания динамического веб-контента, я чувствую, что ему не хватает некоторых важных функций для выполнения таких высокопроизводительных фоновых операций, как эта. Я бы выбрал язык, поддерживающий многопоточность (мое личное предпочтение привело бы меня к C # 4.0, но это также зависит от вашей серверной платформы).

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

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

И последний совет: создайте тестовую среду, в которой вы сможете смоделировать свою проблему и провести стресс-тестирование. Во время стресс-тестирования не останавливайтесь на целевом количестве 500 000, а увеличивайте его как минимум в десять раз. Это будет намного эффективнее для заблаговременного обнаружения слабых мест вашего программного обеспечения. Также было бы очень полезно иметь возможность регулировать определенные аппаратные параметры, такие как память, дисковый ввод-вывод, сетевой ввод-вывод и ЦП. Имитируя низкое значение любого из них, вы получаете представление о том, как программное обеспечение будет вести себя в определенных условиях. Этот опыт поможет вам, если вы столкнетесь с какими-либо проблемами производительности в рабочей среде, и поможет вам определить требования к оборудованию.

person Jonathan van de Veen    schedule 05.07.2011
comment
Спасибо за вашу запись. Мы используем Linux-серверы, поэтому C# не вариант (сам бы этого очень хотел ;)). Тогда придется изучить C++ или аналогичный. Спасибо за отзыв! - person Cornelius; 11.07.2011