Практическое создание крупного масштабируемого проекта web 2.0 с нуля Дмитрий Бородин

Об авторе

В настоящее время – развлекательное приложение «Лице-Мер»:
5-е место в рунете

Часть 1.

Приступая к разработке…

Традиционный подход к разработке: ТЗ, функционал, ООП.
Неправильные вопросы: выбор

Слово «Highload» обманчиво
Проект, имеющий масштабирование, способен выдержать любую нагрузку, даже если

Проблема первого шага [1]

Все новое – принимается в штыки.
Богатый опыт программирования

Проблема первого шага [2]

99% стартапов web 2.0 никогда не запустятся чисто

Честное горизонтальное масштабирование

Проект разбит на множество независимых компонент, способных выполняться на

Честное горизонтальное масштабирование

Масштабирование – это не репликация.
SQL кластеры и прочие

Часть 2.

Доказательства приведенной теории.
Технические причины, почему ваш стартап гарантированно никогда не

Невозможная задача №1

Мы делаем очередной клон самой популярной соц.сети.
100.000.000 пользовательских

Страница «Мои друзья»

Попробуем реализовать эту страницу.
Список user_id друзей (100 шт.)
Веб-страница должна

Как получить данные?

Обращаться к 100 SQL серверам – нереально.
Каждая веб-страница может

Расширяем проблему

Замените слово «друзья» на другую сущность крупного проекта:
запись в

Невозможная задача №2

На всех социальных сайтах есть подписка на разные события

Вывод

Забудьте про суть проекта, его функционал, назначение и т.д.
Сегодня вы задумали

Часть 3.

О главном:
Правильное оперирование данными
Многопоточность и атомарность в SQL/Memcache
Отложенная обработка
Memcache –

Какую БД выбрать?

Выбор небольшой – MySQL и PostgreSQL.
Разницы – нет, т.к.

Какой язык выбрать?

Ответ: не важно.
Проблема и задачи масштабирования лежат в иной

Тщательность изучения

Без тщательно изучения выбранных инструментов ничего не работает.
Пример:
Знание memcache на

О главном [1/3]

Основная задача, о которой нужно думать для создания горизонтально

О главном [2/3]

Очень важно думать о многопоточности и атомарности операций.
Это

О главном [3/3]

Последняя из важнейших оптимизаций – все что можно (и

Пример оперирования данными

К тезису «О главном [1]».
Допустим, для решения одной задачи,

Memcache – это не кеш!

Полноценная и надежная база данных с уникальными

Тонкости Memcache

Memcache – с виду прост. На деле - в 100

Memcache::CAS()

Вся мощь в атомарности операций вашего кода на PHP.
CAS – это

Memcache и сессии

Сессии на PHP блокируют потоки.
Сессии в memcache - типичный

Memcache и большие массивы

По аналогии с сессиями – в одном ключе

Memcache Highload

MemcacheDB, как и SQL, упирается в лимиты: iostat, CPU, MEM.
Готовьтесь

SQL: атомарность и многопоточность

Важность обдумывания многопоточности.
Основное заблуждение: транзакции решают проблемы.
Далее –

Характерная задача

Изначально некий скрипт работал в один поток с неким абстрактным

Типичное ошибочное решение

С файлами: прочитать файл, если там нет флага «Занято»,

Решения задачи

SQL – блокировки: SELECT … FOR UPDATE, LOCK TABLES, GET_LOCK.
SQL

Лучшее решение задачи

UPDATE … SET flag=1 WHERE flag=0
SELECT … FOR UPDATE
Memcache::lock()

Статистика по задаче

Из примерно 200 хороших программистов (новичков не приглашали) в

Часть 4

Конкретные технические подробности в Highload и масштабировании.
Практика использования SQL и

SQL Highload [1]

Все запросы – простейшие выборки по Primary key.
Без JOIN

SQL Highload [2]

Auto_increment замените на Sequence, для возможной репликации SQL.
Репликацию SQL

SQL Highload [3]

Проблема отката транзакций: запросы на 2 сервера + memcache.
Транзакции

SQL Highload [4]

Правильное оперирование данными: SQL потребляет мало CPU. Пропускная способность

SQL Highload [5]

Очень редко обсуждаемая опция innodb_flush_log_at_trx_commit.
1 или 2 – часто

SQL кеш [1]

Паттерн сохранения в кеш результатов (чтение и обновление).
Типичные массовые

SQL кеш [2]

Самый сложный и часто встречаемый баг – это кусок

Лавинообразные нагрузки

Пусть, 100.000.000 пользователей разбиты в таблицы по 1000 пользователей (это

Защита от лавины

Благодаря разбиению пользователей на мелкие пачки (споты), выявляем зависшие

Причина лавины

Их всего три. Первые – наиболее вероятны.
Физическая. Сервер уперся в

SQL шардинг [1]

Представим, что мы делаем клон самой популярной социальной сети.
Имеется

SQL шардинг [2]

Типы данных.
Пользовательская информация: друзья, профайлы, сообщения, статьи, записи в

SQL шардинг [3]

Пользовательская информация: хранится по спотам. Споты добавляются по мере

SQL шардинг [4]

Друзья, сообщения, профайлы и т.д. – пусть будет всего

Невозможное возможно

Очевидный вывод из шардинга –JOIN невозможен.
Как решить «Невозможную задачу

Авторайзер [1]

Запустим 150 инстансов MemcacheDB, по числу SQL серверов. В них

Авторайзер [2]

Не храним невосполнимых данных.
Скрипт миграции по серверам и восстановления из

Ketama в memcache – зло

«Ketama» отлично подойдет небольшому проекту и только

Отложенная обработка

90% информации пишем не в SQL и Memcache, а в

Часть 5.

Технические характеристики [1]

Более 1.100.000 «уников» в сутки.
Около 60.000 онлайн пользователей.
База

Технические характеристики [2]

Разработка – 3 месяца. Запуск – 2,5 месяца назад

Технические характеристики [3]

PHP 5.3, MySQL, php-fpm, APC/xcache (зависит от версии и