Инструменты и алгоритм проектирования высоконагруженных систем, представленный в докладе Олега Бунина.
Разделение приложения на сервисы, которые взаимодействуют друг с другом по некоторому протоколу. Сервисы должны быть независимы друг от друга.
Всего лишь отсрочит наступление ибели системы.
Основа основ. Сервис должен быть спроектирован так, чтобы его можно было запускать на нескольких машинах. При проектировании сервиса необходимо соблюсти 2 самых главных критерия:
- не хранить состояние
- не должно быть общих узлов (полностью такого достичь нельзя, но надо стремиться минимизировать общие узлы)
Необходимо определить, какие задания могут быть вычислены позже (после отправки ответа клиенту). Те, которые могут быть выполнены позже удобно организовать в очередь, управляемую брокером очередей (rabbitmq, celery).
(Пока не понял, в чём отличие от предыдущего пункта)
Переложить часть задач с сервера на клиента. Например балансировка нагрузки.
Система должна работать без кэширования. Кэширование всего лишь облегчает жизнь. Не следует кэшировать готовые ответы сервера. Лучше кэшировать данные, которые используются для построения ответа.
Разнесение различных сервисов на различные сервера для снижения нагрузки на отдельно взятый сервер.
Распределение базы данных между несколькими серверами. Как правило логика распределения данных между узлами содержится в самом приложении, но есть и готовые решения (pg_shard).
Для реализвации шардинга в приложении необходимо знать количестно серверов, между которыми будет происходить распределение данных. При этом имеет смысл не завязываться на реальное количество серверов на данный момент, а сделать много (с очень большим запасом) виртуальных шардов, которые будут отображаться на реальные сервера. Это значительно облегчает горизонтальное масштабирование.
Осторожно: узкая точка! Логика распределения данных выносится в центральный диспетчер. Отдельные узлы обращаются к центральному диспетчеру для получения информации, на какой сервер посылать запрос. Позволяет более гибко использовать железо.
База данных копируется в нескольких экземплярах для обеспечения надёжности хранения данных и распределения нагрузки между серверами. Очень часто запросы разделяются по типу: запросы на чтение идут на один сервер, а запросы на запись -- на другой. При использовании шардига реплицируются отдельно взятые шарды.
Функциональное распределение в рамках базы данных. Одна база рапределяется на несколько: для кажого сервиса своя.
Дублирование информации, ориентированное на повышение производительности наиболее частых запросов (как правило запросов на чтение).
Map-Reduce etc.
- Определение бизнес логики.
- Выяснение ожидаемых чисел (количество пользователей, размер их данных и т.п.). Этот пункт определяет потенциальные проблемные места приложения.
- Определение допустимой степени деградации системы.
- Определение схемы движения данных.
- Проектирование системы.
- Необязательный пункт. После проектирования полезно попытаться сломать систему в целях тестирования (Chaos Monkey).