Документ охватывает лекцию по разработке высоконагруженных систем, представленной Олегом Буниным, включая принципы масштабируемости, архитектурные решения и примеры применения. Основные темы включают архитектурные паттерны, ошибки в разработке и методы оптимизации, такие как кэширование и шардинг. Лекция также обсуждает выбор архитектурного решения между сервисно-ориентированной и монолитной архитектурой.

1. Разработка и
проектирование
высоконагруженных
систем
Олег Бунин
oleg.bunin@ontico.ru

2. Структура лекции
Первый блок:
•
•
•
•
•
•
Знакомство;
Цель обучения;
Принципы масштабируемости;
Архитектурные решения;
Виды масштабирования;
Трёхзвенная структура.
Второй блок:
• Архитектурные паттерны;
• Алгоритм проектирования высоконагруженных систем.
Третий блок:
• Примеры: профили на сайте знакомств, новостной сайт, френдлента;
Если успеем:
• Ошибки в разработке высоконагруженных систем;
• Хаки;
• Эксплуатация.
2

3. Знакомство
Давайте познакомимся!
3

4. Олег Бунин
• Председатель Программного комитета конференции
разработчиков высоконагруженных систем HighLoad++ вот уже
семь лет;
4

5. Олег Бунин
• Председатель Программного комитета конференции
разработчиков высоконагруженных систем HighLoad++ вот уже
семь лет;
• Руководитель компании по разработке и консалтингу в области
высоконагруженных проектов;
5

6. Олег Бунин
• Председатель Программного комитета конференции
разработчиков высоконагруженных систем HighLoad++ вот уже
семь лет;
• Руководитель компании по разработке и консалтингу в области
высоконагруженных проектов;
• Руководитель отдела веб-разработки компании Рамблер (ещё
тогда, когда Рамблер был номером один);
6

7. 7

8. Кто вы?
• У кого пользователей больше 10 тысяч в сутки?
8

9. Кто вы?
• У кого пользователей больше 10 тысяч в сутки?
100 тысяч в сутки?
9

10. Кто вы?
• У кого пользователей больше 10 тысяч в сутки?
100 тысяч в сутки?
500 тысяч в сутки?
10

11. Кто вы?
• У кого пользователей больше 10 тысяч в сутки?
100 тысяч в сутки?
500 тысяч в сутки?
миллион в сутки?
11

12. Кто вы?
• У кого пользователей больше 10 тысяч в сутки?
100 тысяч в сутки?
500 тысяч в сутки?
миллион в сутки?
10 миллионов в сутки?
12

13. Кто вы?
• У кого есть в управлении сайты, расположенные на
выделенном сервере?
13

14. Кто вы?
• У кого есть в управлении сайты, расположенные на
выделенном сервере?
более, чем на двух выделенных серверах?
14

15. Кто вы?
• У кого есть в управлении сайты, расположенные на
выделенном сервере?
более, чем на двух выделенных серверах?
более, чем на пяти выделенных серверах?
15

16. Кто вы?
• У кого есть в управлении сайты, расположенные на
выделенном сервере?
более, чем на двух выделенных серверах?
более, чем на пяти выделенных серверах?
более, чем на двадцати выделенных серверах?
16

17. Цель нашей встречи
17

18. Цель нашей встречи
• Состоит в том, чтобы вы глубоко начали понимать смысл
происходящего в вашим программным кодом;
• Знание нескольких принципов заменяет знание множества
фактов;
18

19. Репликация полезна?
19

20. В чѐм суть репликации?
Запись
Мастер
Слейв
Репликация
Слейв
Слейв
Чтение
20

21. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
21

22. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
• Решает ли репликация любую проблему и всегда ли она полезна?
22

23. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
• Решает ли репликация любую проблему и всегда ли она полезна?
23

24. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;
24

25. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;
• Отсутствие консистентности данных;
25

26. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
• Решает ли репликация любую проблему и всегда ли она полезна?
• Записей больше, чем чтения;
• Отсутствие консистентности данных;
• Слишком много слейвов;
26

27. Репликация
• В чём суть репликации?
• Что происходит на серверах физически?
• Решает ли репликация любую проблему и всегда ли она полезна?
•
•
•
•
Записей больше, чем чтения;
Отсутствие консистентности данных;
Слишком много слейвов;
Слишком много данных;
27

28. Кеширование полезно?
28

29. Кеширование
• Поход в кеш занимает 20 миллисекунд;
• Поход к базе данных занимает 100 миллисекунд;
29

30. Кеширование
• Поход в кеш занимает 20 миллисекунд;
• Поход к базе данных занимает 100 миллисекунд;
• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;
30

31. Кеширование
• Поход в кеш занимает 20 миллисекунд;
• Поход к базе данных занимает 100 миллисекунд;
• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;
• Если количество промахов составляет:
•
•
•
•
10% -> кеш ускоряет выполнение приложения в 3.3 раза;
40% -> кеш ускоряет выполнение приложения в 1.7 раз;
80% -> кеш не приносит пользы;
90% -> кеш замедляет выполнение приложения.
31

32. Кеширование
• Поход в кеш занимает 20 миллисекунд;
• Поход к базе данных занимает 100 миллисекунд;
• Попадание в кеш = 20 миллисекунд, промах = 120 миллисекунд;
• Если количество промахов составляет:
•
•
•
•
10% -> кеш ускоряет выполнение приложения в 3.3 раза;
40% -> кеш ускоряет выполнение приложения в 1.7 раз;
80% -> кеш не приносит пользы;
90% -> кеш замедляет выполнение приложения.
• Вы знаете своё соотношение hit/miss?
32

33. Индексы полезны?
33

34. Индексы полезны?
• Индекс – это возможность по значению столбца или группы
столбцов быстро найти весь кортеж, всю строку в базе данных;
34

35. Индексы полезны?
• Индекс – это возможность по значению столбца или группы
столбцов быстро найти весь кортеж, всю строку в базе данных;
• Каждый индекс:
• замедляет выполнение операции вставки строки;
• увеличивает количество требуемой оперативной памяти;
• усложняет работу планировщика запросов.
35

36. Индексы полезны?
• Нужно учитывать селективность индекса;
• Индексы с низкой селективностью, не просто бесполезны, они
вредны;
36

37. Принципы построения
высоконагруженных
систем
37

38. Основная логика масштабируемости
• Рано или поздно в процессе оптимизации мы упираемся в
производительность аппаратного обеспечения;
• Значит надо сделать так, чтобы задачу можно было выполнять
одновременно на нескольких машинах;
• Это легко сделать в парадигме запрос-ответ, в которой работает
веб;
Как нужно учитывать будущее масштабирование?
38

39. Принципы построения
высоконагруженных систем
• Максимальная независимость компонент
• Отсутствие единой точки отказа:
• По функциональности;
• По данным;
39

40. Выбор архитектурного
решения
40

41. Выбор архитектурного решения
Сервисно-ориентированная
архитектура
41

42. Сервис-ориентированная архитектура
Каждый сервис решает строго определенную задачу.
Основной минус этого подхода заключается в наличии
оверхеда на интеркоммуникацию сервисов между собой и на
обработку API взаимодействия между слоями.

43. Выбор архитектурного решения
Монолитное приложение
43

44. Монолитное приложение
Приложение представляет из себя монолитный программный код.
Плюсы:
• Отсутствие какого-либо оверхеда на интеркоммуникацию сервисов;
Минусы:
• Высокая сложность разработки;
• В случае проблемы встает все;
• Невозможность вести распределенную разработку.

45. Выбор архитектурного решения
Ремесленный подход
45

46. Ремесленный подход
Приложение
Приложение
Приложение
Масштабируемая
архитектура
Масштабируемая
архитектура
Масштабируемая
архитектура
Система
хранения
Видео
хранилище
Кеш
СУБД
MySQL
Бизнес-логика проекта и
инструменты для
масштабирования
разрабатываются
одновременно, учитывая
особенности бизнеслогики именно этого
проекта.

47. Ремесленный подход
• Быстрая разработка любых новых решений;
• Высокие требования к квалификации разработчиков – низкая
масштабируемость разработки;
• Максимально эффективное использование технологий и
аппаратного обеспечения;

48. Выбор архитектурного решения
Промышленный подход
48

49. Промышленный подход
Страница
Страница
Приложение
Мобильная
версия
API для обмена данными
Слой веб-сервисов
Хранилище
Хранилище
Хранилище
Хранилище
Разработка инструментов
для масштабирования
происходит отдельно от
разработки бизнес-логики
прикладных проектов.

50. Промышленный подход
• Очень долгая разработка общих инструментов;
• Очень быстрая разработка приложений – происходит сборка
страниц как в конструкторе Lego;
• Возможность использовать для разработки приложений
программистов средней и низкой квалификации – высокая
масштабируемость разработки;
• Повышенные требования к аппаратному обеспечению;

51. Что такое
масштабирование?
51

52. Что такое масштабирование?
Вертикальное масштабирование
52

53. Вертикальное масштабирование
Увеличение
производительности
системы за счет
увеличения мощности
сервера.
В какой-то момент мы
все равно достигнем
предела по
процессору, памяти
или жесткому диску.

54. Что такое масштабирование?
Горизонтальное масштабирование
54

55. Горизонтальное масштабирование
Увеличение
производительности
системы за счет
подключения
дополнительных
cерверов

56. Что такое масштабирование?
Масштабирование во времени
56

57. Масштабирование “во времени”
Различные данные имеют различные требования к
обновлению. Это позволяет нам отложить часть обработки
данных до более удобного случая.

58. Трѐхзвенная структура
58

59. Трехзвенная структура
Фронтенды
Быстрая обработка легких
данных
Бекенды
Вычисление
Хранение
данных
Хранение данных

60. Для чего нужен фронтенд?
60

61. Фронтенд
• Отдача статического контента;
• Буферизация запросов;
• Масштабирование бекендов;
• Обслуживание медленных клиентов.
61

62. Балансировка фронтендов
Пользователи
Пользователи
Round-Robin
DNS-балансировка
DNS-балансировка
Heart Beat Или CARP. Идея в
том, что одна машинка не
работает и наблюдает за
другой. Если первая ломается,
то она включается. У обеих
машин один IP-адрес на
двоих.
IP1
IP1
IP2
IP2

63. Балансировка бекендов
Пользователи
Пользователи
Round-Robin
DNS-балансировка
DNS-балансировка
IP1
IP1
IP2
IP2
Бекенд
Бекенд
Бекенд
Бекенд

64. Дублирование фронтендов
П о то к зап р о со в
О сн о вн о й се р ве р
C A RP
В сп о м о гате л ьн ы й
се р ве р

65. Кофебрейк
Паттерны масштабирования сразу после перерыва в 30 минут
65

66. Паттерны
масштабирования
Вспомним инструменты, которые мы будем
использовать
66

67. Инструмент #1
Сервисно-ориентированная
архитектура
67

68. Инструмент #2
Вертикальное масштабирование
68

69. Инструмент #3
Горизонтальное масштабирование:
• Не храним состояние;
• Отсутствие общих узлов;
69

70. Инструмент #4
Отложенные вычисления
70

71. Инструмент #5
Асинхронная обработка
71

72. Очереди
Структура данных с дисциплиной доступа к элементам FIFO (First In
First Out).
Применения:
1. Отложенная обработка (рассылки, обновления лент новостей);
2. Межсервисная коммуникация;

73. Очереди: модерация
Резервный датацентр
Erang-фронтенд
Erlang-фронтенд
Erlang-фроненд
Фронтенд для
модератора
Удаление
сообщений
SQL
Заявки на удаление
сообщений
БД
БД
БД
Входящий
Rabbit MQ
SQL
Очередь на удаление
отмодерированных
комментариев
Копии всех обновлений
SQL
Исходящий
Rabbit MQ
Этот сервер очередей должен стоять
на стороне кластера фронтендов для
того, чтобы в случае пропадания
связи с резервным ДЦ информация
никуда не потерялась.
Приложение,
обновляющее SQL
и считающая кучу
статистики

74. Интеркоммуникация сервисов
Задача: необходимо уведомлять одни части системы о событиях,
которые происходят в других частях:
• размещение информации в пользовательских лентах (feeds) о
событиях, произошедних в сообществах;
• лайки;
• комментарии;
• рассылка писем;

75. Интеркоммуникация:
решение с очередью
Пользователи
Пользователи
Всегда быть готовым
к дублированию
задач в очереди
Постинг поста
Сервис постов
Синхронная
постановка в
очередь
Очередь
Репликация или Heart beat
Синхронная запись в
базу данных
Репликация
очереди
Постоянная
база данных
Если очередь
сломалась –
переставляем
задачи по
постоянной
базе
сообщений
Разборщик
очереди

76. Интеркоммуникация: решение с
очередью
Это могут быть те же
сервера, что и
обрабатывают запросы от
фронтендами
Входящие Httpсервера сервиса Б
Сервис A
Внутренняя
очередь
сервиса А
Раздающий демон
сервиса А
Внутренняя
очередь
сервиса Б
Сервис Б
Сервис Б
Входящие Httpсервера сервиса Б
Сервис A
Обработка задач
сервиса А
Входящие Httpсервера сервиса Б
Забираем задачи
Push сообщений из
сервиса А во все
остальные сервисы
Сервис Б
Прием задач для
сервиса Б
Обработка задач
сервиса Б

77. Инструмент #6
Использование толстого клиента
77

78. Антишквал
Фронтенд
Первый запрос
Первый бекенд не ответил,
переходим ко второму
Сервис
Сервис
Ряд серверов-бекендов, выполняющих
однотипные задачи.
Запрос приходит на первый бекенд,
начинает выполняться, но не успевает за
время таймаута.
Фронтенд или толстый клиент
перебрасывает запрос на новый бекенд,
тот тоже не успевает.
Таким образом очень быстро вся сеть
бекендов будет положена.

79. Антишквал: умные запросы
Умные запросы от фронтенда:
Фронтенд
Фронтенд
Фронтенд
Третий запрос,
Timeout = 3с
Первый запрос,
Timeout = 1с
Сервис
Второй запрос,
Timeout = 2с
Сервис
Фронтенд
Четвертого запроса
просто нет.
• Первый запрос к первому бекенду идет с
таймаутом 1 секунду. Второй запрос идет с
таймаутом 2 секунды, третий - 3 секунды,
а четвертого уже нет. То есть ограничиваем
количество запросов;
• Бекенд может принимать решение о том,
что он перегружен (раз в секунду
спрашивать LA и кэшировать его). При
начале обработке запроса происходит
проверка и если LA слишком высокий отдаем фронту Gone Away (штатная
ситуация - перейди к другому бекенду).
Сервис
Сервис

80. Инструмент #7
Кеширование
80

81. Кеширование
• Кеширование в браузере;
• Кеширование HTML-блоков;
• Кеширование данных;
• Кеширование HTML-страниц.
81

82. Кеширование на бекенде;
Кеш
•
•
•
•
Единый кеш для всех бекендов;
Проблема инвалидации кеша;
Проблема старта с непрогретым кешем;
Целесообразность применения кеша;
Бекенд
Бекенд
Бекенд

83. Проблема
инвалидации
кеша
Программный
код
Update
(Обновление
элемента
кеша)
Select
(Запрос
элемента
кеша)
• Обновление по запросу
(проблема race condition
для нагруженных страниц);
Да
Есть значение
в кеше?
Возвращаем результат и
пишем в кеш
Пишем задачу в очередь
Кеш Memcached
• Фоновое обновление;
Нет
Класс для
вычисления
элемента кеша
Пишем в кеш
Используем одни модули для
онлайна и оффлайна
Читаем и обнуляем
очередь
Маленький
демон
Очередь
База данных

84. Инструмент #8
Функциональное разделение
84

85. Инструмент #9
Шардинг
85

86. Шардинг
Базовый принцип: те данные, которые в дальнейшем потребуются вместе, так же
должны храниться вместе.
Примеры:
1. Пользователи;
2. Посты в сообществах;
3. Блоги;
Принципы разбиения данных на шарды:
1. Центральный диспетчер, знающий, что где лежит;
2. Хэш-функция, по ключу вычисляющая шард;
3. Хэш-функция, по ключу вычисляющая виртуальный шард + таблица соответствий
виртуальных шардов реальным.

87. Инструмент #10
Виртуальные шарды
87

88. Шард 1
Шард 2
Шард 3
Шард 4
Шард 5
Шард 6
Виртуальные шарды
Шард 7
Шард 8
Сервер 1
Шард 1
Шард 2
Шард 3
Шард 4
Шард 5
Шард 6
Сервер 1
Шард 1
Шард 2
Сервер 1
Шард 7
Шард 8
Сервер 2
Шард 3
Шард 4
Шард 5
Сервер 3
Шард 6
Шард 7
Сервер 2
Шард 8
Сервер 4
Шард 1
Шард 2
Шард 3
Шард 4
Шард 5
Шард 6
Шард 7
Шард 8
Сервер 1
Сервер 5
Сервер 3
Сервер 6
Сервер 2
Сервер 7
Сервер 4
Сервер 8

89. Инструмент #11
Центральный диспетчер
89

90. Инструмент #12
Репликация
90

91. Репликация
Базы данных MongoDB
Push-сервер
Лог обновлений
MongoDB
Обновления слушаются с
одной из реплик
Реплики
MongoDB
AJAX-Соообщение об
обновлении
Репликация
Бекенд
Читаем с реплики
Бекенд
Чтение блога
Бекенд
Репликация
Реплики
MongoDB
Репликация
Публикация поста
Бекенд
Запись поста в блог
Мастер
MongoDB
Реплики
MongoDB

92. Инструмент #13
Партиционирование
92

93. Партиционирование
• Разбиение больших таблиц на логические части по выбранным
критериям;
93

94. Функциональное разделение базы
данных
Разные данные хранятся в разных таблицах
или
Разные данные хранятся в разных СУБД
или
Разные данные хранятся в разных типах СУБД

95. Инструмент #14
Денормализация
95

96. Денормализация данных
Денормализация — намеренное приведение структуры базы
данных в состояние, не соответствующее
критериям нормализации, обычно проводимое с целью
ускорения операций чтения из базы за счет добавления
избыточных данных.

97. Инструмент #15
Введение избыточности
97

98. Инструмент #16
Параллельное выполнение
98

99. Алгоритм
проектирования
высоконагруженной
системы
99

100. Алгоритм, ШАГ ПЕРВЫЙ
Опишем бизнес-логику будущей системы, включая потенциальные пути
развития системы
100

101. Алгоритм, ШАГ ВТОРОЙ
Посчитаем объёмы хранимых данных и скорость их приращения. Выбираем
критический путь – хранение, запись или чтение данных?
101

102. Алгоритм, ШАГ ТРЕТИЙ
Определить допустимую деградацию функций системы
102

103. Алгоритм, ШАГ ЧЕТВЕРТЫЙ
Построим схему движения данных и примем решение, какие из особенностей
проектируемой системы мы будем использовать
103

104. Алгоритм, ШАГ ПЯТЫЙ
Проектируем схему хранения данных
104

105. АЛГОРИТМ, ШАГ ШЕСТОЙ
Ломаем систему и смотрим, что у нас получится
105

106. Не пора ли кофебрейк?
Алгоритм проектирования сразу после перерыва в 30 минут
106

107. Примеры

108. ПРОФИЛИ НА САЙТЕ
ЗНАКОМСТВ
Спроектируем систему хранения пользователей на сайте знакомств
108

109. Сайт знакомств, профили / #1
1. Пользователь заполняет анкету;
2. Получает логин пароль для доступа к своему личному кабинету;
3. Пользователи могут смотреть профили друг друга;
109

110. Сайт знакомств, профили / #2
1. Пользователей 200 миллионов;
2. Каждая анкета занимает 10 килобайт, то есть всего 2 000
гигабайт;
3. Хитов в день 5 миллиардов;
110

111. Сайт знакомств, профили / #3
1. Деградация недопустима;
111

112. Сайт знакомств, профили / #4
1.
2.
3.
4.
Данные часто читаются, но редко меняются;
Все анкеты примерно одного размера;
У анкеты есть уникальный идентификатор;
Нет ярко выраженных лидеров;
112

113. Сайт знакомств, профили / #5
Проектируем схему
хранения данных
113

114. Сайт знакомств, профили / #5
Репликация?
Вообще 140к чтений в секунду
114

115. Сайт знакомств, профили / #5
Шардирование?
По какому ключу? Диспетчер?
115

116. Сайт знакомств, профили / #6
Виртуальные шарды
116

117. Сайт знакомств, профили / #6
Сгорает диск?
117

118. Сайт знакомств, пользователи / #6
Репликация
118

119. Сайт знакомств, профили /
результат
• Разбиваем весь массив пользователей на виртуальные шарды;
• Маппим виртуальные шарды на реальные шарды;
• Внутри каждого шарда реплицируем информацию для
отказоустойчивости
119

120. Стажировка!
oleg.bunin@ontico.ru

121. Задания на стажировку
• В двух абзацах и одной схеме описать различия в СУБД MySQL и
PostgreSQL;
• Предположить, какие особенности в оптимизации и архитектуре
накладывают из-за этого различия возникают;
• Результаты прислать на oleg.bunin@ontico.ru
121

122. НОВОСТНОЙ САЙТ
Большая и длинная лента новостей крупного СМИ
122

123. Новости / #1
• Пользователь читает свежие новости;
• Пользователь читает архивные новости;
• Редактор публикует новости;
123

124. Новости / #2
• Каждая новость примерно 10 килобайт;
• Мы вечно храним архив с даты основания СМИ – 2000 год;
• В день публикуется около 10 тысяч различных региональных и
федеральных новостей;
• Итого в год 3 миллиона 500 тысяч новостей, в год 35 гигабайт, за
20 лет – 700 гигабайт;
• Это крупнейшее СМИ, посещаемость – 10 миллионов человек в
сутки;
124

125. Новости / #3
• Деградация недопустима;
125

126. Новости / #4
• Количество чтений на несколько порядков превышает количество
записей;
• 99% запросов касаются последнего дня;
• 99,99% запросов касаются последней недели.
126

127. Новости / #5
Проектируем схему
хранения данных
127

128. Новости / #5
Партиционирование
По какому принципу?
128

129. Новости / #5
Как переносить данные из горячей БД
в архив?
129

130. Новости / #5
Не надо ничего переносить! Вводим
избыточность!
130

131. Новости / #5
Очень много запросов к
горячим новостям!
Что делать?
131

132. Новости / #5
Кеширование!
132

133. Новости / результат
• Кеширование для горячих новостей;
• Партиционирование новостей по дате – последние новости в
быстрой таблице;
• Избыточное хранение новостей – новость пишется сразу и в
горячую таблицу и в архивную, горячая раз в какое-то время
чистится;
133

134. ПРОСМОТР ФРЕНДЛЕНТЫ
Просмотр френдлента в блогах
134

135. Просмотр френдленты / #1
• У пользователя может быть сколько угодно друзей;
• Френдленту храним бесконечно долго;
135

136. Просмотр френдленты / #2
• В среднем у пользователя 100 друзей;
• Каждый пользователь в среднем пишет 3 поста в день;
• Каждый пост занимаем около 1 килобайта;
• Пользователей – 10 миллионов в сутки, но каждый пользователь
делает 100 хитов. Итого – миллиард запросов к френдленте в
сутки;
• В сутки генерируется 30 миллионов постов, 10 миллиардов
записей в год;
136

137. Просмотр френдленты / #3
• Допустимо, что пользователь увидит запись своего друга не
моментально, а с небольшой задержкой;
• Допустимо, что порядок записей не будет строго совпадать с
хронологическим;
137

138. Просмотр френдленты / #4
• 99% запросов приходятся на голову френдленты;
• У нас есть пользователи, которые в друзьях у миллионов
пользователей;
138

139. Просмотр френдленты / #5
Проектируем схему
хранения данных
139

140. Просмотр френдленты / #5
Избыточность?
Каждому пользователю свой список записей в его френдленте? Это
же очень много – один триллион записей за год!
140

141. Просмотр френдленты / #5
Храним для каждого пользователя
ленту идентификаторов постов!
141

142. Просмотр френдленты / #5
Шардирование?
Чего? По какому принципу?
142

143. Просмотр френдленты / #5
Пользователь и его посты
лежат рядом
Сделайте составной идентификатор поста, пусть в него входит
идентификатор пользователя
143

144. Просмотр френдленты / #5
Достали список
идентификаторов постов
Как собрать ленту?
144

145. Просмотр френдленты / #5
Толстый клиент!
145

146. Просмотр френдленты / #5
Если вы круты, то можете попробовать
Параллельные вычисления
146

147. Просмотр френдленты / результаты
• Пользователи шардируются, рядом с пользователями лежат его
посты и его френдлента;
• В френдленте пользователя уже записаны идентификаторы
постов его друзей в порядке, близком к хронологическому;
• В идентификатор поста зашит ID пользователя, по которому мы
быстро определяем шард и забираем с него текст поста;
• За текстом поста у нас будет ходить JS-машина, работающая на
клиенте.
147

148. Запись френдленты / #5
А как посты попадают в
френдленту?
У нас ведь есть пользователи, которые в друзьях у миллионов?
148

149. Запись френдленты / #5
Используем очереди!
149

150. И далее по аналогии
Алгоритм универсален!
150

151. Блок “Если успеем”
На этот раз уже без перерыва!
151

152. Надежность
высоконагруженной вебсистемы
152

153. Принципы надежности
• Взаимозаменяемость серверов;
• Избыточность данных, дублирование узлов:
• Фронтенд: DNS-балансировка, CARP, heartbeat;
• Бекенд: гомогенные взаимозаменяемые бекенды;
• База данных: дублирование данных, репликации, кластера;

154. Мониторинг
154

155. Мониторинг
Вы должны с абсолютной точностью знать, что происходит в
системе.
• Мониторинг серверов;
• Мониторинг приложений;
• Мониторинг элементов приложений;
• Мониторинг показателей базы данных;

156. Мониторинг: pinba

157. Мониторинг: pinba

158. Деплоймент
Регулярный быстрый автоматический деплоймент с возможностью
сплит-тестирования и возможностью быстрого отката.

159. Лайфхаки
159

160. Различное строение СУБД
160

161. Буферизация в операционной системе
База данных
apache
nginx
Операционная система,
Сетевая подсистема
Электрический сигнал
Память
PHP
Операционная система,
дисковая подсистема
Диск
Сетевая карта
161

162. Синхронная обработка,
синхронные запросы
162

163. Бездумное использование
ORM
163

164. Стажировка!
oleg.bunin@ontico.ru

165. Задания на стажировку
• В двух абзацах и одной схеме описать различия в СУБД MySQL и
PostgreSQL;
• Предположить, какие особенности в оптимизации и архитектуре
накладывают из-за этого различия возникают;
• Результаты прислать на oleg.bunin@ontico.ru
165

166. Вопросы?
oleg.bunin@ontico.ru

167. Дополнительные примеры
167

168. Event-driven чат
Быстрый сервер
Node.JS или
phpDaemon
AJAX Long polling
Поток репликации
Основная база
MySQL
POST-запрос с сообщением
Быстрая база
MongoDB
Клиенты
Пишем постоянную версию
Основной сервер (PHPбекенд)

169. Лента новостей
Пользователь А
публикует запись
Сохраняем запись в
статичном постоянном
хранилище
Запись не
сохранилась
Нет
Этот процесс тоже можно
оптимизировать, группировать.
Сначала можно запросить
подробности по двум записям,
потом по четырем, потом по всем
оставшимся.
Постоянное
хранилище
Удачно?
Хранилище лент,
каждая лента =
список
идентификаторов
записей
Да
Удаляем (или не
коммитим) запись в
статичное хранилище.
Нет
Запрашиваем список
идентификаторов
записей из ленты B
Обрабатываем
идентификаторы и для
каждого из них
запрашиваем данные из
постоянного хранилища
Например,
RabbitMQ
Ставим в очередь З
задачу обновить ленты
подписчиков
пользователя А
Удачны обе
операции?
Пользователь B,
подписанный на
пользователя А, читает
свою ленту
Сервер
очередей
Да
Публикация произошла
успешно
Страница
построена
Пул процессов,
обслуживающих
очередь
Обновляем
соответствующие
списки
идентификаторов

170. Отдача
фотографии напрямую
с хоста
Database / 1
Backend / 1
По scp заливаем фотку (все варианты)
на один из серверов
MySQL
PHP + Limb
Backend / 2
Image Server / 1
nginx
Image Server / 2
nginx
User images
User images
PHP + Limb
Image Server / 3
nginx
После того, как nginx
полностью принял
фотографию, он
отправляет ее в
php-бекенд
User images
Frontend / 1
nginx
Backend / 3
Пишем в базу
данных метаинформацию
о фотографии
PHP + Limb
Демоны
Frontend / 2
nginx
memcached
Design images
Design images
Закачивание
фотографии
DNS-Балансинг
DNS-Балансинг
Пользователи
memcached
Хранение
бинарных
данных