Комментарии 40
В тему: тут есть видео с мастер-класса от Алексея www.youtube.com/watch?v=pn7IT_cG8ck
НЛО прилетело и опубликовало эту надпись здесь
Хм, кажется была статья по мотивам этого доклада www.slideshare.net/BadooDev/badoo-19888002
Спасибо, интересно было почитать.
Отличный формат, так держать!
Спасибо Алексею за непрекращающийся образовательный проект, спасибо Антону и Антону за отличную беседу (оч. клевые вопросы, даже неожиданно).
Спасибо Алексею за непрекращающийся образовательный проект, спасибо Антону и Антону за отличную беседу (оч. клевые вопросы, даже неожиданно).
Хм, то есть получается они используют Linux, PHP, MySQL, nginx и memcached? Блин, это же гениально! Почему больше никто не додумался использовать этот набор инструментов?
Куда более занятно — за счет чего они до сих пор на нем остаются и не высказывают (по-видимому) желания переходить на рельсы, эрланг, скалу, node.js, тысячи их?
Предварительно предполагаю, что для такой уверенности нужно было пропатчить сами инструменты хорошо под себя. Уже PHP-FPM как бы намекает. Алсо, Pinba.
Предварительно предполагаю, что для такой уверенности нужно было пропатчить сами инструменты хорошо под себя. Уже PHP-FPM как бы намекает. Алсо, Pinba.
Угу, куча рассказов про серверы приложений, да какая в конечном счете разница какие они, описание приема нагрузки начинается с того, как балансируются запросы, разделяются данные, как происходит восстановление данных, как организован кэш и как все это мониторится. А тут детский садик какой-то, ни про одну из перечисленных областей ничего интересного не сказано. Ну думаю они попробвать vargrant, ну ладно, большое достижение.
Про vagrant сказали ведущие, к сожалению, иногда тяжело отличить, что говорил я, а что они (попрошу выделить их текст болдом). Касательно оставшейся части комментария — няня, я у них поел. Ну то есть почти всё, что Вы перечислили — было затронуто — в рамках часового интервью поговорить подробнее не получилось. Может быть, Вы дочитали только до балансировки серверов приложений?
Мы, кстати, были одними из первых, кто запустил nginx в продакшен — в мамбе в 2004-м году. Что касается стека технологий — пионеры, не надо ничего выдумывать без надобности, все уже придумали за вас. Просто нужно уметь пользоваться простыми и популярными инструментами.
В этом нет ничего удивительного — многие крупные высоконагруженные проекты используют именно этот набор инструментов. Вообще, шардинг решает большую часть проблем с нагрузками этого типа, а уж чем его делать и что использовать в качестве бэкенда для хранения — неважно, почему-бы и не MySQL.
Сложности начинаются, если у вас есть data intensive задачи, требующие выборки по многим шардам, и данные при этом плохо или совсем не агрегируемые. Здесь придется писать тонны логики, реализующей распределенные запросы. Второй неприятный случай, если вы хотите повысить время ответа, при том что у вас в рамках шарды уже минимально допустимое количество данных (которых на самом деле может быть очень много), необходимых для ответа, и дальше эти данные уже не режутся. Например один очень-очень активный пользователь, генерящий половину всех запросов/данных.
Сложности начинаются, если у вас есть data intensive задачи, требующие выборки по многим шардам, и данные при этом плохо или совсем не агрегируемые. Здесь придется писать тонны логики, реализующей распределенные запросы. Второй неприятный случай, если вы хотите повысить время ответа, при том что у вас в рамках шарды уже минимально допустимое количество данных (которых на самом деле может быть очень много), необходимых для ответа, и дальше эти данные уже не режутся. Например один очень-очень активный пользователь, генерящий половину всех запросов/данных.
Поделитесь, пожалуйста, как происходит склеивание данных из разных шард и как при этом работают сортировки?
Как это выглядит для конечного программиста, который пишет запрос на выборку данных?
Как это выглядит для конечного программиста, который пишет запрос на выборку данных?
Данные по одному пользователю всегда на одной из шард. Так что не совсем понимаю о каком склеивании вы говорите.
Например, поиск пользователей или комментарии под фото. В результате отображаются данные разных пользователей (наверняка с разных шард).
Черт, я перепутал наши топики на хабре. Прошу прощения. Подумал что вы спрашиваете про демон событий.
Возвращаясь к вашему вопросу. Глобально на этот вопрос не смогу, но по поводу поиска скажу что он — самописный демон. Очень шустрый, довольно сложный и данные для поиска находятся на одной машине. Слияние не нужно.
По поводу остального думаю кто-то из моих коллег еще ответит.
Возвращаясь к вашему вопросу. Глобально на этот вопрос не смогу, но по поводу поиска скажу что он — самописный демон. Очень шустрый, довольно сложный и данные для поиска находятся на одной машине. Слияние не нужно.
По поводу остального думаю кто-то из моих коллег еще ответит.
За поиск отвечает отдельный демон, в которого помещаются все пользователи, и они там уже отсортированы. При этом, демон ещё и в состоянии отдать нужные данные для отображения информации о пользователе, так, что в базу данных на разные шарды лезть вообще не приходится.
Наверное, крутой демон, раз обрабатывает данные о миллионах пользователей внутри себя, ну или как-то распределён по серверам.
Для многих задач приходится писать специальные демоны или большая часть решается прямым обращением к данным?
Для многих задач приходится писать специальные демоны или большая часть решается прямым обращением к данным?
Демонов у нас штук 15 наберется, думаю. Они написаны на Си (на С++ есть несколько), используют асинхронную обработку (libevent). Перед тем как делать какую-то задачу, мы думаем можно ли ее сделать какими-то существующими продуктами. Если нет — пишем свой демон.
Получается у вас php используется больше для «генерации HTML», а большая часть логики реализована в бинарных демонах?
Демон действительно крутой, об этом даже никто не спорит :). Насколько я знаю, сам демон по серверам не шардится, но при этом есть «мастер» и у него несколько «слейвов». То есть, мы используем соединение к одному из экземпляров демона и не устанавливаем лишних соединений: все данные есть во всех экземплярах демона.
В стандартных библиотеках php есть функции для соединения с базой через persistent-коннект, который не рвётся при завершении php-скрипта. У вас к демонам тоже получаются persistent-коннекты из php? Пишите свои бинарные-модули для php для работы со своими же демонами?
Получается мастер-демон собирает данные и раздаёт их на слейвы, а получение данных php`шками уже идёт только со слейвов? Заморачиваетесь на отставании по времени слейвов от мастера? Если слейв отстал от мастера уже на 10 минут перераспределяете его нагрузку на другие сервера?
Делаете привязку клиента к серверу? Т.е. когда один пользователь всегда обращается к одному и тому же серверу за данными?
Получается мастер-демон собирает данные и раздаёт их на слейвы, а получение данных php`шками уже идёт только со слейвов? Заморачиваетесь на отставании по времени слейвов от мастера? Если слейв отстал от мастера уже на 10 минут перераспределяете его нагрузку на другие сервера?
Делаете привязку клиента к серверу? Т.е. когда один пользователь всегда обращается к одному и тому же серверу за данными?
Про поиск ответили выше, а комментарии под фото собственно к этому фото и относятся(как многие к одному), а значит принадлежат владельцу фото, хоть и автор коммента не владелец.
Получается пользователь, его фоты, и комментарии к ним на одном шарде.
Гораздо интереснее ситуация когда пользователь А подписался на коменты к фотке/альбому пользователя Б и пользователь В добавил коммент. Или что то же самое А отметил Б на фотке В :)
Получается пользователь, его фоты, и комментарии к ним на одном шарде.
Гораздо интереснее ситуация когда пользователь А подписался на коменты к фотке/альбому пользователя Б и пользователь В добавил коммент. Или что то же самое А отметил Б на фотке В :)
Спасибо за ответ!
Интересно просто есть ли некая магическая обёртка как в примере что вы описали или в таких ситуациях нужно склеивать/пересылать данные вручную.
Интересно просто есть ли некая магическая обёртка как в примере что вы описали или в таких ситуациях нужно склеивать/пересылать данные вручную.
У нас в среднем в вебе отправляется 1 SQL-запрос в базу данных :), и это очень хорошо. Поэтому ни о каких магических обертках не может и идти речи, потому что нам очень важна производительность и низкая нагрузка на наши сервера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура высоконагруженных приложений. Масштабирование распределенных систем. Часть первая