Pull to refresh

Comments 40

А видео выкладывается с разрешения автора? Все-таки мастер-класс то платный.
Не знаю, нашел на простарах ютуба.
нет, без разрешения, но мне уже давно пофигу.
Он на мастер-классе сам говорил, что кто-то снимал видео и выложил на ютюб. Правда там плохо видно и слышно.
UFO landed and left these words here
Не было статьи, между прочим
Спасибо, интересно было почитать.
Отличный формат, так держать!

Спасибо Алексею за непрекращающийся образовательный проект, спасибо Антону и Антону за отличную беседу (оч. клевые вопросы, даже неожиданно).
Хм, то есть получается они используют Linux, PHP, MySQL, nginx и memcached? Блин, это же гениально! Почему больше никто не додумался использовать этот набор инструментов?
Куда более занятно — за счет чего они до сих пор на нем остаются и не высказывают (по-видимому) желания переходить на рельсы, эрланг, скалу, node.js, тысячи их?

Предварительно предполагаю, что для такой уверенности нужно было пропатчить сами инструменты хорошо под себя. Уже PHP-FPM как бы намекает. Алсо, Pinba.
Угу, куча рассказов про серверы приложений, да какая в конечном счете разница какие они, описание приема нагрузки начинается с того, как балансируются запросы, разделяются данные, как происходит восстановление данных, как организован кэш и как все это мониторится. А тут детский садик какой-то, ни про одну из перечисленных областей ничего интересного не сказано. Ну думаю они попробвать vargrant, ну ладно, большое достижение.
Про vagrant сказали ведущие, к сожалению, иногда тяжело отличить, что говорил я, а что они (попрошу выделить их текст болдом). Касательно оставшейся части комментария — няня, я у них поел. Ну то есть почти всё, что Вы перечислили — было затронуто — в рамках часового интервью поговорить подробнее не получилось. Может быть, Вы дочитали только до балансировки серверов приложений?
Мы, кстати, были одними из первых, кто запустил nginx в продакшен — в мамбе в 2004-м году. Что касается стека технологий — пионеры, не надо ничего выдумывать без надобности, все уже придумали за вас. Просто нужно уметь пользоваться простыми и популярными инструментами.
В этом нет ничего удивительного — многие крупные высоконагруженные проекты используют именно этот набор инструментов. Вообще, шардинг решает большую часть проблем с нагрузками этого типа, а уж чем его делать и что использовать в качестве бэкенда для хранения — неважно, почему-бы и не MySQL.

Сложности начинаются, если у вас есть data intensive задачи, требующие выборки по многим шардам, и данные при этом плохо или совсем не агрегируемые. Здесь придется писать тонны логики, реализующей распределенные запросы. Второй неприятный случай, если вы хотите повысить время ответа, при том что у вас в рамках шарды уже минимально допустимое количество данных (которых на самом деле может быть очень много), необходимых для ответа, и дальше эти данные уже не режутся. Например один очень-очень активный пользователь, генерящий половину всех запросов/данных.
Поделитесь, пожалуйста, как происходит склеивание данных из разных шард и как при этом работают сортировки?
Как это выглядит для конечного программиста, который пишет запрос на выборку данных?
Данные по одному пользователю всегда на одной из шард. Так что не совсем понимаю о каком склеивании вы говорите.
Например, поиск пользователей или комментарии под фото. В результате отображаются данные разных пользователей (наверняка с разных шард).
Черт, я перепутал наши топики на хабре. Прошу прощения. Подумал что вы спрашиваете про демон событий.

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

По поводу остального думаю кто-то из моих коллег еще ответит.
А вы демоны на php пишите как и основной код или на плюсах?
Бывают проблемы из-за сетевых накладок (например падение канала)? Что предпочитаете TCP или UDP в качестве транспортного протокола?
Демоны в основном на Си (несколько на C++). Используем TCP. Насколько я знаю только Pinba работает на UDP.

Сейчас еще исследуем применимость Go для написания демонов. Беспокоит GC.
Go — интересный выбор :)
За поиск отвечает отдельный демон, в которого помещаются все пользователи, и они там уже отсортированы. При этом, демон ещё и в состоянии отдать нужные данные для отображения информации о пользователе, так, что в базу данных на разные шарды лезть вообще не приходится.
Наверное, крутой демон, раз обрабатывает данные о миллионах пользователей внутри себя, ну или как-то распределён по серверам.
Для многих задач приходится писать специальные демоны или большая часть решается прямым обращением к данным?
Демонов у нас штук 15 наберется, думаю. Они написаны на Си (на С++ есть несколько), используют асинхронную обработку (libevent). Перед тем как делать какую-то задачу, мы думаем можно ли ее сделать какими-то существующими продуктами. Если нет — пишем свой демон.
Получается у вас php используется больше для «генерации HTML», а большая часть логики реализована в бинарных демонах?
Ну нет, конечно :-)

На ПХП написана вся «обертка» над этими демонами. Там куча логики и бизнеса. Взаимодействие между демонами (в плане работы с информацией) тоже на ПХП.

Кроме того на ПХП написано громадное кол-во скриптов, которые делают какие задачки в фоне.

Badoo очень большой проект все-таки.
То есть демоны в большинстве случаев решают какую-то узкую утилитарную задачу, которую нерационально делать на php, например очереди и рассылка нотифов, а php-скрипты уже «командуют» демонами что, куда и как?
Демон действительно крутой, об этом даже никто не спорит :). Насколько я знаю, сам демон по серверам не шардится, но при этом есть «мастер» и у него несколько «слейвов». То есть, мы используем соединение к одному из экземпляров демона и не устанавливаем лишних соединений: все данные есть во всех экземплярах демона.
В стандартных библиотеках php есть функции для соединения с базой через persistent-коннект, который не рвётся при завершении php-скрипта. У вас к демонам тоже получаются persistent-коннекты из php? Пишите свои бинарные-модули для php для работы со своими же демонами?

Получается мастер-демон собирает данные и раздаёт их на слейвы, а получение данных php`шками уже идёт только со слейвов? Заморачиваетесь на отставании по времени слейвов от мастера? Если слейв отстал от мастера уже на 10 минут перераспределяете его нагрузку на другие сервера?

Делаете привязку клиента к серверу? Т.е. когда один пользователь всегда обращается к одному и тому же серверу за данными?
Пока что persistent connect'ы особо не используются. Я не могу вам точно сказать, как мы боремся с отставанием слейвов, но совершенно точно пользователь «привязывается» к своему слейву, чтобы для него данные оставались консистентными.
Спасибо вам за статьи и за ответы, читая их кажется будто переход от простой разработки сайтов к хайлоаду это как неандерталец с каменным топором пришёл бы в современный музей оружия :)
Про поиск ответили выше, а комментарии под фото собственно к этому фото и относятся(как многие к одному), а значит принадлежат владельцу фото, хоть и автор коммента не владелец.
Получается пользователь, его фоты, и комментарии к ним на одном шарде.

Гораздо интереснее ситуация когда пользователь А подписался на коменты к фотке/альбому пользователя Б и пользователь В добавил коммент. Или что то же самое А отметил Б на фотке В :)
Спасибо за ответ!
Интересно просто есть ли некая магическая обёртка как в примере что вы описали или в таких ситуациях нужно склеивать/пересылать данные вручную.
У нас в среднем в вебе отправляется 1 SQL-запрос в базу данных :), и это очень хорошо. Поэтому ни о каких магических обертках не может и идти речи, потому что нам очень важна производительность и низкая нагрузка на наши сервера.
М-м-м… получается если в среднем 1 SQL-запрос к базе данных, то есть страницы где несколько запросов, а где-то SQL-запросов вообще нет? Это всё демоны или очень хорошее использование кэша?
Именно так. Демоны, кэш.
Большое спасибо за ответы! И за всю серию статей, которые ваша команда пишет на хабре.
Очень интересно как меняется подход при хайлоад-разработке, а пока сам не попробуешь не узнаешь, приходится спрашивать у профессионалов.
Only those users with full accounts are able to leave comments. Log in, please.