Пошаговый алгоритм разработки высоконагруженной системы Олег Бунин

ПОДГОТОВКА Вспомним инструменты, которые мы будем использовать 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АЛГОРИТМ, ШАГ ПЯТЫЙ Проектируем схему хранения данных 23

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новости / #5 Шардирование? Шард с последним днём будет умирать 44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И ДАЛЕЕ ПО АНАЛОГИИ Алгоритм универсален! 67

Вопросы? facebook.com/oleg.bunin