#Деградация функциональности http://joxi.ru/DxXOU4wyTJCzLlQsA7o Есть фичи у проекта - есть критичные вещи, есть такие что можно пожертвовать чем-то При проектировании архитектуры нужно учесть возможные фоллбеки Все доп, фичи можно отключить или не использовать в ситуации крайней нагрузки
#Масштабирование Нагрузка растет нужно мастабироваться
Что делать?
1) Вертикальное - Купить железо (программисты дороже железа) - не нужно преребрегать
2) Функциональное разделение
Разделение приложения на несколько частей - будь то СУБД, разделение кода по серверам и т.д.
Пример - форум на сайте СМИ ложит сам сайт
3) Горизонтальное масштабирование
http://joxi.ru/vx3OU_3JTJDsR2DeRk8
Stateless - не сохраняем состояния бекенда. Если для для следующего шага нужен предыдуший - это плохо, нужна синхронизация - роутить пользователя на "нужный сервер"
Shared nothing - отсутствие единой точки отказа, отсутствие такого сервиса, недоступность которого положит все остальное
http://joxi.ru/oB_OU4wyTJCzLjQQET8
Чем больше общих частей - тем горизонтальное масштабирование принесет меньше пользы
Балансировка фронтендов / бекендов
4) Масштабирование во времени
Отложенные вычисления
Пример:
Apache стадии обработки запроса
http://joxi.ru/piPOU_3JTJDzRycV68A
Очереди
* Отложенная обработка
* Межсервисная коммуникация
Очередь может быть какой угодно - хоть mySQL
Пример очереди:
http://joxi.ru/ZSXOU_3JTJBgDktbK7g
http://joxi.ru/CibOU_3JTJD6R3qGyik
Пример взаимодействия независимых сервисов:
Свяжем сервис комментарив и сервис почты
http://joxi.ru/ySbOU4wyTJC1LoDkgbU
Сервисно-ориентированная архитектура
http://joxi.ru/PyHOU4wyTJClLsG8QrU
При новых комментаниях в ФБ - почту отсылает не сервис комментариев - а др. сервис - которому ставят задачу сервис комментариев
+ Слабая связность позволяет не падать сразу всему
Монолитное приложение
+ Маленький оверхед
- Сложность разработки
#Базы Данных САР теорема http://joxi.ru/qynOU4wyTJC6Li6rzLs
Примеры
http://joxi.ru/CCrOU4wyTJCwLkFBcBM
http://joxi.ru/UCrOU_3JTJDlR4T-4CY
http://joxi.ru/ZirOU4wyTJDALhg_-IY
Репликация
Есть ограничение - нет консистентности
Обходим это:
Читаем с мастера
Не читаем - например толстый клиент может сам отобразить сообшение
Прблемы - при обновлении страницы может не быть поста
#Вертикальный шардинг Использование разных СУБД или разных типов СУБД
#Горизонтальный шардинг http://joxi.ru/pyzOU4wyTJChLjrtLTs
#Виртуальный шардинг Делим пользователей сразу на столько шардов, сколько необходимо (100, 1000)
http://joxi.ru/Hy7OU4wyTJC_OLvphUU
Далее нужно будет просто мигрировать виртуальными вервероми на реальные сервера
Для миграции - нужно пометить записи для миграции "только чтение" и мигрировать
http://joxi.ru/VS_OU4wyTJAbNdWjWek
Поиск пользвателя по фамилии (если шардирование по ID)
Нужен сервис поиска - он будет искать на всех серверах
#Центральный диспетчер http://joxi.ru/3TDOU_3JTJDxR_R8_DQ
#Партиционирование Разбиение таблиц на меньшие - средствами БД или на уровне приложении
#Денормализация Задача http://joxi.ru/hDPOU4wyTJCYLhfMiAo
Введение избыточности http://joxi.ru/OzTOU_3JTJB0DiZLXMw
В таблицу связей добавить все нужные для выборки флаги
Минусы: целостность данных
#Специализорованные сервера Пример - фронтед, для стримминга видео, Comet-сервер
#Comet-сервер Типы: WebSocket AJAX Long polling
Разделение Comet-серверов по типам/обязанностям, чтобы толстый клиент сам выбирал нужный