>Сам пример
все хорошо, но я бы сперва перед описанием примера описал бы, как будет организована асинхронная обработка в целом,
для более понятного восприятия, а потом перешел бы уже к деталям. Когда я был студентом, нас учили писать научные работы (статья мало чем отличается от научной работы) по следующему плану, пригодится в будущем ;):
— введение в проблему,
— если есть то обзор существующих решений
— описание решения проблемы в целом
— частные описания и конкретные предложения, действия и т.д
— возможные выводы и заключение
Данный комментарий прошу не считать как критику, а как пожелание в дальнейшей работе
Если приглядеться, то большинство авторов статей с рейтингом придерживается такого плана.
Очень было бы хорошо выложить проект на гитхабе, а здесь дать ссылку
чтоб иметь полное представление о модуле.
А так… если что-то не учел, то ничего не получится и статья ушла в карзину.
>Я использовал для компиляции и настройки VS2010.
Не единым окном живет человечество, многие разработчики седят под линуксом или иной осью, по этому хорошо бы как минимум дать ссылку на компилирование под другие ОС
> Да, в наш век отказ от пищи — намного более лёгкий пост, чем отказ от технологий
легко… был в Турции, почти 100% отказ от технологий (роуминг дорогой, наличка, интернет нафиг не нужен...). и если бы была возможность 30 дней или 45-ть вместо 15-ти, я бы не задумываясь их продлил.
Очереди мы используем, но уже внутри процеса. Ну, во первых у нас нагрузка не такая, как у вас и масштабироваться не нужно. Одни поток принимает данные и распихивает его по очередям. Другие потоки читают свои очереди и делают соответствующие пуши на службы гугла и эпла. Один поток слушает (принимает) эпл нотификации, а еще один отвечает за статистику и данные (пишет в БД). Практически тоже, что и у вас… только масштабы меньше :)
В общем все очень интересно…
да, сам демон написан на сях…
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.
общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…
написал один типовой демон и потом теражируй его, вписывая новый функционал
В нашем проекте ключевым сервисом является сервер обмена сообщениями. Рассылкой уведомлений о новом сообщении занимается отдельный демон. Демон хранит состояние клиента и некоторые данные. У нас есть следующие типы клиентов: Мобильный IOs, Android & WEB. Пуш уведомления на мобильные клиенты рассылаются через API Apple Push Notification Service & Google Cloud Messaging. Уведомление WEB клиентов происходит через флеш. Флеш открывает постоянное соединение с демоном на 80 порту, и при появлении нового события получает порцию JSON, который парсится и передаётся в кэллбэк JS, а тот в свою очередь изменяет HTML.
> Разве MyISAM не быстрее на чтение?
если его постоянно не лочить :)
>Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
что верно, то верно
>Сами разработчики рекомендуют, как минимум, 3 сервера для создания кластера.
с Кассандрой не путаешь? которая разрабатывалось как чисто кластерное решение с дублированием информации.
и воввсе не обязательно отказоустойчивость… Монга интересна сама по себе и как кластеное, и как серверное решение.
Если вдруг такое случится и станет не хватать скорости или функциональности MongoDB — ничто не помешает использовать MySQL в качестве кэширующей прослойки / индекса для данных — один раз настроить и забыть.
Все более менее хорошо (есть пара дискуссионных мест, но нет времени на холливар), но последняя фраза бред какой-то… хотите использовать кеширующий индекс — используйте тогда сфинкс.
тут есть много разных предложений на дороботку по производительности. У Монги один недостаток — это общий лок на коллекцию.
согл, мой плагин блокирующий, по этому смысла его использовать нет :)
но есть и хорошие новости: плагин Романа Аратюняна github.com/arut/nginx-mysql-hsock-module,
он же автор плагина видеовещания, в том числе и коммерческой версии.
спасибо за статью,
но Хабросообществу более интересен алгоритм подбора маршрута, о котором ни слова,
алгоритм поиска и источники сбора данных а не реклама ресурса…
все хорошо, но я бы сперва перед описанием примера описал бы, как будет организована асинхронная обработка в целом,
для более понятного восприятия, а потом перешел бы уже к деталям. Когда я был студентом, нас учили писать научные работы (статья мало чем отличается от научной работы) по следующему плану, пригодится в будущем ;):
— введение в проблему,
— если есть то обзор существующих решений
— описание решения проблемы в целом
— частные описания и конкретные предложения, действия и т.д
— возможные выводы и заключение
Данный комментарий прошу не считать как критику, а как пожелание в дальнейшей работе
Если приглядеться, то большинство авторов статей с рейтингом придерживается такого плана.
В целом статья полезная, спасибо.
чтоб иметь полное представление о модуле.
А так… если что-то не учел, то ничего не получится и статья ушла в карзину.
>Я использовал для компиляции и настройки VS2010.
Не единым окном живет человечество, многие разработчики седят под линуксом или иной осью, по этому хорошо бы как минимум дать ссылку на компилирование под другие ОС
легко… был в Турции, почти 100% отказ от технологий (роуминг дорогой, наличка, интернет нафиг не нужен...). и если бы была возможность 30 дней или 45-ть вместо 15-ти, я бы не задумываясь их продлил.
В общем все очень интересно…
нагрузка 3 млн сообщ в день
исторически так сложилось, что у нас вся разработка преимущественно на си, есть питон и перл.
общение между бэкендом и демонами преимущественно осуществляется по мемкешовому протоколу. В этом свои плюсы — отладка, не нужно писать собственных клиентов…
написал один типовой демон и потом теражируй его, вписывая новый функционал
если его постоянно не лочить :)
>Да и вообще все это лирика и холивар без хорошей конкретизации задачи.
что верно, то верно
с Кассандрой не путаешь? которая разрабатывалось как чисто кластерное решение с дублированием информации.
и воввсе не обязательно отказоустойчивость… Монга интересна сама по себе и как кластеное, и как серверное решение.
blog.ulf-wendel.de/2013/mysql-5-7-sql-functions-for-json-udf/
жаль что не нативные, но и в этом тоже есть свой плюс.
хорошая новость… но мы ушли с версии где-то 2.3
>Могу ошибиться, но разве MyISAM не блокируется на таблицу (читай как коллекцию)?
а кто-то из тех, кому нужна производительность, пользуется MyISAM?
Все более менее хорошо (есть пара дискуссионных мест, но нет времени на холливар), но последняя фраза бред какой-то… хотите использовать кеширующий индекс — используйте тогда сфинкс.
тут есть много разных предложений на дороботку по производительности. У Монги один недостаток — это общий лок на коллекцию.
но есть и хорошие новости: плагин Романа Аратюняна github.com/arut/nginx-mysql-hsock-module,
он же автор плагина видеовещания, в том числе и коммерческой версии.
как недостаток — ищет медленно, но в принципе приемлемо, на нагрузку тестировалось или ожидаем Хаброэффекта?..
но Хабросообществу более интересен алгоритм подбора маршрута, о котором ни слова,
алгоритм поиска и источники сбора данных а не реклама ресурса…