Учебный день конференции highload++ 2013
DESCRIPTION
TRANSCRIPT
2
Структура лекцииПервый блок:
• Знакомство;• Цель обучения;• Принципы масштабируемости;• Архитектурные решения;• Виды масштабирования;• Трёхзвенная структура.
Второй блок:• Архитектурные паттерны;• Алгоритм проектирования высоконагруженных систем.
Третий блок:• Примеры: профили на сайте знакомств, новостной сайт, френдлента;
Если успеем:• Ошибки в разработке высоконагруженных систем;• Хаки;• Эксплуатация.
3
ЗнакомствоДавайте познакомимся!
4
Олег Бунин
• Председатель Программного комитета конференции разработчиков высоконагруженных систем HighLoad++ вот уже семь лет;
5
Олег Бунин
• Председатель Программного комитета конференции разработчиков высоконагруженных систем HighLoad++ вот уже семь лет;
• Руководитель компании по разработке и консалтингу в области высоконагруженных проектов;
6
Олег Бунин
• Председатель Программного комитета конференции разработчиков высоконагруженных систем HighLoad++ вот уже семь лет;
• Руководитель компании по разработке и консалтингу в области высоконагруженных проектов;
• Руководитель отдела веб-разработки компании Рамблер (ещё тогда, когда Рамблер был номером один);
7
8
Кто вы?
• У кого пользователей больше 10 тысяч в сутки?
9
Кто вы?
• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки?
10
Кто вы?
• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки? 500 тысяч в сутки?
11
Кто вы?
• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки? 500 тысяч в сутки? миллион в сутки?
12
Кто вы?
• У кого пользователей больше 10 тысяч в сутки? 100 тысяч в сутки? 500 тысяч в сутки? миллион в сутки? 10 миллионов в сутки?
13
Кто вы?
• У кого есть в управлении сайты, расположенные на выделенном сервере?
14
Кто вы?
• У кого есть в управлении сайты, расположенные на выделенном сервере?более, чем на двух выделенных серверах?
15
Кто вы?
• У кого есть в управлении сайты, расположенные на выделенном сервере?более, чем на двух выделенных серверах?более, чем на пяти выделенных серверах?
16
Кто вы?
• У кого есть в управлении сайты, расположенные на выделенном сервере?более, чем на двух выделенных серверах?более, чем на пяти выделенных серверах?более, чем на двадцати выделенных серверах?
17
Цель нашей встречи
18
Цель нашей встречи
• Состоит в том, чтобы вы глубоко начали понимать смысл происходящего в вашим программным кодом;
• Знание нескольких принципов заменяет знание множества фактов;
19
Репликация полезна?
20
В чём суть репликации?
Мастер Слейв
Слейв
Слейв
Запись
Репликация
Чтение
21
Репликация
• В чём суть репликации?• Что происходит на серверах физически?
22
Репликация
• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?
23
Репликация
• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?
24
Репликация
• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;
25
Репликация
• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;• Отсутствие консистентности данных;
26
Репликация
• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;• Отсутствие консистентности данных;• Слишком много слейвов;
27
Репликация
• В чём суть репликации?• Что происходит на серверах физически?• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;• Отсутствие консистентности данных;• Слишком много слейвов;• Слишком много данных;
28
Кеширование полезно?
29
Кеширование
• Поход в кеш занимает 20 миллисекунд;• Поход к базе данных занимает 100 миллисекунд;
30
Кеширование
• Поход в кеш занимает 20 миллисекунд;• Поход к базе данных занимает 100 миллисекунд;• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;
31
Кеширование
• Поход в кеш занимает 20 миллисекунд;• Поход к базе данных занимает 100 миллисекунд;• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;
• Если количество промахов составляет:• 10% -> кеш ускоряет выполнение приложения в 3.3 раза;• 40% -> кеш ускоряет выполнение приложения в 1.7 раз;• 80% -> кеш не приносит пользы;• 90% -> кеш замедляет выполнение приложения.
32
Кеширование
• Поход в кеш занимает 20 миллисекунд;• Поход к базе данных занимает 100 миллисекунд;• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;
• Если количество промахов составляет:• 10% -> кеш ускоряет выполнение приложения в 3.3 раза;• 40% -> кеш ускоряет выполнение приложения в 1.7 раз;• 80% -> кеш не приносит пользы;• 90% -> кеш замедляет выполнение приложения.
• Вы знаете своё соотношение hit/miss?
33
Индексы полезны?
34
Индексы полезны?
• Индекс – это возможность по значению столбца или группы столбцов быстро найти весь кортеж, всю строку в базе данных;
35
Индексы полезны?
• Индекс – это возможность по значению столбца или группы столбцов быстро найти весь кортеж, всю строку в базе данных;
• Каждый индекс:• замедляет выполнение операции вставки строки;• увеличивает количество требуемой оперативной памяти;• усложняет работу планировщика запросов.
36
Индексы полезны?
• Нужно учитывать селективность индекса;• Индексы с низкой селективностью, не просто бесполезны, они
вредны;
37
Принципы построения высоконагруженных
систем
38
Основная логика масштабируемости• Рано или поздно в процессе оптимизации мы упираемся в
производительность аппаратного обеспечения;• Значит надо сделать так, чтобы задачу можно было выполнять
одновременно на нескольких машинах;• Это легко сделать в парадигме запрос-ответ, в которой работает
веб;
Как нужно учитывать будущее масштабирование?
39
Принципы построения высоконагруженных систем
• Максимальная независимость компонент• Отсутствие единой точки отказа:
• По функциональности;• По данным;
40
Выбор архитектурного решения
41
Выбор архитектурного решения
Сервисно-ориентированная архитектура
Сервис-ориентированная архитектураКаждый сервис решает строго определенную задачу. Основной минус этого подхода заключается в наличии оверхеда на интеркоммуникацию сервисов между собой и на обработку API взаимодействия между слоями.
43
Выбор архитектурного решения
Монолитное приложение
Монолитное приложение
Приложение представляет из себя монолитный программный код.
Плюсы:• Отсутствие какого-либо оверхеда на интеркоммуникацию сервисов;
Минусы:• Высокая сложность разработки;• В случае проблемы встает все;• Невозможность вести распределенную разработку.
45
Выбор архитектурного решения
Ремесленный подход
Ремесленный подходБизнес-логика проекта и инструменты для масштабирования разрабатываются одновременно, учитывая особенности бизнес-логики именно этого проекта.
Приложение Приложение Приложение
Система хранения
Кеш
Видео хранилище СУБД
Масштабируемая архитектура
Масштабируемая архитектура
Масштабируемая архитектура
MySQL
Ремесленный подход• Быстрая разработка любых новых решений;
• Высокие требования к квалификации разработчиков – низкая масштабируемость разработки;
• Максимально эффективное использование технологий и аппаратного обеспечения;
48
Выбор архитектурного решения
Промышленный подход
Промышленный подходРазработка инструментов для масштабирования происходит отдельно от разработки бизнес-логики прикладных проектов.
Страница Страница Приложение Мобильная версия
API для обмена данными
Хранилище Хранилище Хранилище Хранилище
Слой веб-сервисов
Промышленный подход• Очень долгая разработка общих инструментов;
• Очень быстрая разработка приложений – происходит сборка страниц как в конструкторе Lego;
• Возможность использовать для разработки приложений программистов средней и низкой квалификации – высокая масштабируемость разработки;
• Повышенные требования к аппаратному обеспечению;
51
Что такое масштабирование?
52
Что такое масштабирование?
Вертикальное масштабирование
Вертикальное масштабированиеУвеличение производительности системы за счет увеличения мощности сервера.
В какой-то момент мы все равно достигнем предела по процессору, памяти или жесткому диску.
54
Что такое масштабирование?
Горизонтальное масштабирование
Горизонтальное масштабирование
Увеличение производительности системы за счет подключения дополнительных cерверов
56
Что такое масштабирование?
Масштабирование во времени
Масштабирование “во времени”
Различные данные имеют различные требования к обновлению. Это позволяет нам отложить часть обработки данных до более удобного случая.
58
Трёхзвенная структура
Трехзвенная структура
Фронтенды Бекенды Хранение данных
Быстрая обработка легких данных Вычисление Хранение данных
60
Для чего нужен фронтенд?
61
Фронтенд
• Отдача статического контента;• Буферизация запросов;• Масштабирование бекендов;• Обслуживание медленных клиентов.
Балансировка фронтендов
ПользователиПользователи
DNS-балансировкаDNS-балансировка
Round-Robin
IP1 IP1 IP2 IP2
Heart Beat Или CARP. Идея в том, что одна машинка не работает и наблюдает за другой. Если первая ломается, то она включается. У обеих машин один IP-адрес на двоих.
Балансировка бекендов
ПользователиПользователи
DNS-балансировкаDNS-балансировка
Round-Robin
IP1 IP1 IP2 IP2
Бекенд Бекенд Бекенд Бекенд
Дублирование фронтендов
Основной сервер
Вспомогательный сервер
CARP
Поток запросов
65
КофебрейкПаттерны масштабирования сразу после перерыва в 30 минут
66
Паттерны масштабированияВспомним инструменты, которые мы будем использовать
67
Инструмент #1
Сервисно-ориентированная архитектура
68
Инструмент #2
Вертикальное масштабирование
69
Инструмент #3
Горизонтальное масштабирование:• Не храним состояние;• Отсутствие общих узлов;
70
Инструмент #4
Отложенные вычисления
71
Инструмент #5
Асинхронная обработка
Очереди
Структура данных с дисциплиной доступа к элементам FIFO (First In First Out).
Применения:1. Отложенная обработка (рассылки, обновления лент новостей);2. Межсервисная коммуникация;
Очереди: модерация
Исходящий Rabbit MQ
Приложение, обновляющее SQL и считающая кучу
статистики
Erang-фронтенд Erlang-фронтенд Erlang-фроненд
БД БД БД
SQL
Копии всех обновлений
Этот сервер очередей должен стоять на стороне кластера фронтендов для того, чтобы в случае пропадания связи с резервным ДЦ информация никуда не потерялась.
SQL
SQL
Резервный датацентр
Входящий Rabbit MQ
Удаление сообщений
Очередь на удаление отмодерированных комментариев
Фронтенд для модератора
Заявки на удалениесообщений
Интеркоммуникация сервисов
Задача: необходимо уведомлять одни части системы о событиях, которые происходят в других частях:• размещение информации в пользовательских лентах (feeds) о
событиях, произошедних в сообществах;• лайки;• комментарии;• рассылка писем;
Интеркоммуникация: решение с очередью
ПользователиПользователи
Постинг поста
Сервис постов Очередь
Репликация очереди
Разборщик очереди
Постоянная база данных
Синхронная запись в базу данных
Синхронная постановка в
очередь
Репликация или Heart beat
Всегда быть готовым к дублированию задач в очереди
Если очередь сломалась –
переставляем задачи по
постоянной базе
сообщений
Интеркоммуникация: решение с очередью
Сервис A
Сервис A
Внутренняя очередь
сервиса А
Раздающий демон сервиса А
Входящие Http-сервера сервиса Б
Входящие Http-сервера сервиса Б
Входящие Http-сервера сервиса Б
Это могут быть те же сервера, что и обрабатывают запросы от фронтендами
Внутренняя очередь
сервиса Б
Сервис Б
Сервис Б
Сервис Б
Прием задач для сервиса Б
Обработка задач сервиса Б
Push сообщений из сервиса А во все
остальные сервисы
Обработка задач сервиса А
Забираем задачи
77
Инструмент #6
Использование толстого клиента
АнтишквалРяд серверов-бекендов, выполняющих однотипные задачи. Запрос приходит на первый бекенд, начинает выполняться, но не успевает за время таймаута. Фронтенд или толстый клиент перебрасывает запрос на новый бекенд, тот тоже не успевает. Таким образом очень быстро вся сеть бекендов будет положена.
Фронтенд
Сервис Сервис
Первый запрос
Первый бекенд не ответил, переходим ко второму
Антишквал: умные запросыУмные запросы от фронтенда:
• Первый запрос к первому бекенду идет с таймаутом 1 секунду. Второй запрос идет с таймаутом 2 секунды, третий - 3 секунды, а четвертого уже нет. То есть ограничиваем количество запросов;
• Бекенд может принимать решение о том, что он перегружен (раз в секунду спрашивать LA и кэшировать его). При начале обработке запроса происходит проверка и если LA слишком высокий - отдаем фронту Gone Away (штатная ситуация - перейди к другому бекенду).
Фронтенд Фронтенд Фронтенд Фронтенд
Сервис Сервис Сервис Сервис
Первый запрос, Timeout = 1с
Второй запрос,Timeout = 2с
Третий запрос,Timeout = 3с Четвертого запроса
просто нет.
80
Инструмент #7
Кеширование
81
Кеширование
• Кеширование в браузере;• Кеширование HTML-блоков;• Кеширование данных;• Кеширование HTML-страниц.
Кеширование на бекенде;
• Единый кеш для всех бекендов;• Проблема инвалидации кеша;• Проблема старта с непрогретым кешем;• Целесообразность применения кеша;
Бекенд
Бекенд
Бекенд
Кеш
Проблема инвалидации кеша
• Обновление по запросу (проблема race condition для нагруженных страниц);
• Фоновое обновление;
Update(Обновление
элемента кеша)
Select(Запрос
элемента кеша)
Кеш Memcached
Да
Есть значениев кеше?
База данных
Очередь
Класс для вычисления
элемента кеша
Маленький демон
Пишем задачу в очередь
Нет
Возвращаем результат и пишем в кеш
Используем одни модули дляонлайна и оффлайна
Читаем и обнуляемочередь
Пишем в кеш
Программный код
84
Инструмент #8
Функциональное разделение
85
Инструмент #9
Шардинг
ШардингБазовый принцип: те данные, которые в дальнейшем потребуются вместе, так же должны храниться вместе.
Примеры:1. Пользователи;2. Посты в сообществах;3. Блоги;
Принципы разбиения данных на шарды:4. Центральный диспетчер, знающий, что где лежит;5. Хэш-функция, по ключу вычисляющая шард;6. Хэш-функция, по ключу вычисляющая виртуальный шард + таблица соответствий
виртуальных шардов реальным.
87
Инструмент #10
Виртуальные шарды
Виртуальные шардыШард 1 Шард 2 Шард 3 Шард 4 Шард 5 Шард 6 Шард 7 Шард 8
Шард 1 Шард 2 Шард 3 Шард 4 Шард 5 Шард 6 Шард 7 Шард 8
Шард 1 Шард 2 Шард 3 Шард 4 Шард 5 Шард 6 Шард 7 Шард 8
Шард 1 Шард 2 Шард 3 Шард 4 Шард 5 Шард 6 Шард 7 Шард 8
Сервер 1
Сервер 1 Сервер 2
Сервер 1 Сервер 3 Сервер 2 Сервер 4
Сервер 1 Сервер 3 Сервер 2 Сервер 4Сервер 5 Сервер 6 Сервер 7 Сервер 8
89
Инструмент #11
Центральный диспетчер
90
Инструмент #12
Репликация
Репликация
Бекенд
Лог обновлений MongoDB
Обновления слушаются содной из реплик
Мастер MongoDB
Запись поста в блог
Базы данных MongoDB
Реплики MongoDB
Реплики MongoDB
Реплики MongoDB
Репликация
Репликация
Репликация
Push-сервер
Бекенд
Бекенд
Бекенд
Читаем с реплики
Публикация поста
Чтение блога
AJAX-Соообщение об обновлении
92
Инструмент #13
Партиционирование
93
Партиционирование
• Разбиение больших таблиц на логические части по выбранным критериям;
Функциональное разделение базы данныхРазные данные хранятся в разных таблицахили
Разные данные хранятся в разных СУБДили
Разные данные хранятся в разных типах СУБД
95
Инструмент #14
Денормализация
Денормализация данных
Денормализация — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.
97
Инструмент #15
Введение избыточности
98
Инструмент #16
Параллельное выполнение
99
Алгоритм проектирования высоконагруженной системы
100
Алгоритм, ШАГ ПЕРВЫЙОпишем бизнес-логику будущей системы, включая потенциальные пути развития системы
101
Алгоритм, ШАГ ВТОРОЙПосчитаем объёмы хранимых данных и скорость их приращения. Выбираем критический путь – хранение, запись или чтение данных?
102
Алгоритм, ШАГ ТРЕТИЙОпределить допустимую деградацию функций системы
103
Алгоритм, ШАГ ЧЕТВЕРТЫЙПостроим схему движения данных и примем решение, какие из особенностей проектируемой системы мы будем использовать
104
Алгоритм, ШАГ ПЯТЫЙПроектируем схему хранения данных
105
АЛГОРИТМ, ШАГ ШЕСТОЙЛомаем систему и смотрим, что у нас получится
106
Не пора ли кофебрейк?Алгоритм проектирования сразу после перерыва в 30 минут
Примеры
108
ПРОФИЛИ НА САЙТЕ ЗНАКОМСТВСпроектируем систему хранения пользователей на сайте знакомств
109
Сайт знакомств, профили / #1
1. Пользователь заполняет анкету;2. Получает логин пароль для доступа к своему личному кабинету;3. Пользователи могут смотреть профили друг друга;
110
Сайт знакомств, профили / #2
1. Пользователей 200 миллионов;2. Каждая анкета занимает 10 килобайт, то есть всего 2 000
гигабайт;3. Хитов в день 5 миллиардов;
111
Сайт знакомств, профили / #3
1. Деградация недопустима;
112
Сайт знакомств, профили / #4
1. Данные часто читаются, но редко меняются;2. Все анкеты примерно одного размера;3. У анкеты есть уникальный идентификатор;4. Нет ярко выраженных лидеров;
113
Сайт знакомств, профили / #5
Проектируем схему хранения данных
114
Сайт знакомств, профили / #5
Репликация?Вообще 140к чтений в секунду
115
Сайт знакомств, профили / #5
Шардирование?По какому ключу? Диспетчер?
116
Сайт знакомств, профили / #6
Виртуальные шарды
117
Сайт знакомств, профили / #6
Сгорает диск?
118
Сайт знакомств, пользователи / #6
Репликация
119
Сайт знакомств, профили / результат• Разбиваем весь массив пользователей на виртуальные шарды;
• Маппим виртуальные шарды на реальные шарды;
• Внутри каждого шарда реплицируем информацию для отказоустойчивости
Стажировка[email protected]
121
Задания на стажировку
• В двух абзацах и одной схеме описать различия в СУБД MySQL и PostgreSQL;
• Предположить, какие особенности в оптимизации и архитектуре накладывают из-за этого различия возникают;
• Результаты прислать на [email protected]
122
НОВОСТНОЙ САЙТБольшая и длинная лента новостей крупного СМИ
123
Новости / #1
• Пользователь читает свежие новости;• Пользователь читает архивные новости;• Редактор публикует новости;
124
Новости / #2
• Каждая новость примерно 10 килобайт;• Мы вечно храним архив с даты основания СМИ – 2000 год;• В день публикуется около 10 тысяч различных региональных и
федеральных новостей;• Итого в год 3 миллиона 500 тысяч новостей, в год 35 гигабайт, за
20 лет – 700 гигабайт; • Это крупнейшее СМИ, посещаемость – 10 миллионов человек в
сутки;
125
Новости / #3
• Деградация недопустима;
126
Новости / #4
• Количество чтений на несколько порядков превышает количество записей;
• 99% запросов касаются последнего дня;• 99,99% запросов касаются последней недели.
127
Новости / #5
Проектируем схему хранения данных
128
Новости / #5
ПартиционированиеПо какому принципу?
129
Новости / #5
Как переносить данные из горячей БД в архив?
130
Новости / #5
Не надо ничего переносить! Вводим избыточность!
131
Новости / #5
Очень много запросов к горячим новостям!
Что делать?
132
Новости / #5
Кеширование!
133
Новости / результат
• Кеширование для горячих новостей;• Партиционирование новостей по дате – последние новости в
быстрой таблице;• Избыточное хранение новостей – новость пишется сразу и в
горячую таблицу и в архивную, горячая раз в какое-то время чистится;
134
ПРОСМОТР ФРЕНДЛЕНТЫПросмотр френдлента в блогах
135
Просмотр френдленты / #1
• У пользователя может быть сколько угодно друзей;• Френдленту храним бесконечно долго;
136
Просмотр френдленты / #2
• В среднем у пользователя 100 друзей;• Каждый пользователь в среднем пишет 3 поста в день;• Каждый пост занимаем около 1 килобайта;• Пользователей – 10 миллионов в сутки, но каждый пользователь
делает 100 хитов. Итого – миллиард запросов к френдленте в сутки;
• В сутки генерируется 30 миллионов постов, 10 миллиардов записей в год;
137
Просмотр френдленты / #3
• Допустимо, что пользователь увидит запись своего друга не моментально, а с небольшой задержкой;
• Допустимо, что порядок записей не будет строго совпадать с хронологическим;
138
Просмотр френдленты / #4
• 99% запросов приходятся на голову френдленты;• У нас есть пользователи, которые в друзьях у миллионов
пользователей;
139
Просмотр френдленты / #5
Проектируем схему хранения данных
140
Просмотр френдленты / #5
Избыточность?Каждому пользователю свой список записей в его френдленте? Это
же очень много – один триллион записей за год!
141
Просмотр френдленты / #5
Храним для каждого пользователя ленту идентификаторов постов!
142
Просмотр френдленты / #5
Шардирование?Чего? По какому принципу?
143
Просмотр френдленты / #5
Пользователь и его посты лежат рядом
Сделайте составной идентификатор поста, пусть в него входит идентификатор пользователя
144
Просмотр френдленты / #5
Достали список идентификаторов постов
Как собрать ленту?
145
Просмотр френдленты / #5
Толстый клиент!
146
Просмотр френдленты / #5
Если вы круты, то можете попробовать
Параллельные вычисления
147
Просмотр френдленты / результаты• Пользователи шардируются, рядом с пользователями лежат его
посты и его френдлента;
• В френдленте пользователя уже записаны идентификаторы постов его друзей в порядке, близком к хронологическому;
• В идентификатор поста зашит ID пользователя, по которому мы быстро определяем шард и забираем с него текст поста;
• За текстом поста у нас будет ходить JS-машина, работающая на клиенте.
148
Запись френдленты / #5
А как посты попадают в френдленту?
У нас ведь есть пользователи, которые в друзьях у миллионов?
149
Запись френдленты / #5
Используем очереди!
150
И далее по аналогииАлгоритм универсален!
151
Блок “Если успеем”На этот раз уже без перерыва!
152
Надежность высоконагруженной веб-системы
Принципы надежности
• Взаимозаменяемость серверов;• Избыточность данных, дублирование узлов:
• Фронтенд: DNS-балансировка, CARP, heartbeat;• Бекенд: гомогенные взаимозаменяемые бекенды;• База данных: дублирование данных, репликации, кластера;
154
Мониторинг
Мониторинг
Вы должны с абсолютной точностью знать, что происходит в системе.
• Мониторинг серверов;• Мониторинг приложений;• Мониторинг элементов приложений;• Мониторинг показателей базы данных;
Мониторинг: pinba
Мониторинг: pinba
Деплоймент
Регулярный быстрый автоматический деплоймент с возможностью сплит-тестирования и возможностью быстрого отката.
159
Лайфхаки
160
Различное строение СУБД
161
Буферизация в операционной системе
Электрический сигнал Сетевая карта
Операционная система, Сетевая подсистема
nginx
apache PHP
Операционная система, дисковая подсистема
Диск
ПамятьБаза данных
162
Синхронная обработка, синхронные запросы
163
Бездумное использование ORM
Стажировка[email protected]
165
Задания на стажировку
• В двух абзацах и одной схеме описать различия в СУБД MySQL и PostgreSQL;
• Предположить, какие особенности в оптимизации и архитектуре накладывают из-за этого различия возникают;
• Результаты прислать на [email protected]
Вопросы[email protected]
167
Дополнительные примеры
Event-driven чат
Основной сервер (PHP-бекенд)
Основная базаMySQL
Быстрая база MongoDB
Быстрый серверNode.JS или phpDaemon
Клиенты
AJAX Long polling
POST-запрос с сообщением
Пишем постоянную версию
Поток репликации
Лента новостейПользователь А
публикует запись
Сохраняем запись в статичном постоянном
хранилище
Удачны обе операции?
Ставим в очередь З задачу обновить ленты
подписчиков пользователя А
Например, RabbitMQ
Публикация произошла успешно
Удачно?
Удаляем (или не коммитим) запись в
статичное хранилище.
Сервер очередей
Пул процессов, обслуживающих
очередь
Обновляем соответствующие
списки идентификаторов
Постоянное хранилище
Пользователь B, подписанный на
пользователя А, читает свою ленту
Запрашиваем список идентификаторов
записей из ленты B
Обрабатываем идентификаторы и для
каждого из них запрашиваем данные из постоянного хранилища
Этот процесс тоже можно оптимизировать, группировать.
Сначала можно запросить подробности по двум записям,
потом по четырем, потом по всем оставшимся.
Да
Запись не сохранилась
Нет
Нет Да
Хранилище лент, каждая лента =
список идентификаторов
записей
Страница построена
Хранение бинарных данных
Frontend / 1
nginx
Design images
memcached
Frontend / 2
Design images
nginx memcached
Пользователи
DNS-БалансингDNS-Балансинг
Image Server / 1
User images
nginx
Image Server / 3
User images
nginx
Image Server / 2
User images
nginx
Backend / 1
PHP + Limb
Backend / 2
PHP + Limb
Backend / 3
PHP + Limb
Демоны
Database / 1
MySQL
Закачивание фотографии
После того, как nginx полностью принялфотографию, он отправляет ее в
php-бекенд
Пишем в базуданных метаинформацию
о фотографии
По scp заливаем фотку (все варианты)на один из серверов
Отдачафотографии напрямую
с хоста