kosheev_maksim_lab_8 is ready
This commit is contained in:
parent
a5a422fc0f
commit
30c34b6371
@ -1,8 +0,0 @@
|
||||
## Какие алгоритмы и методы используются для балансировки нагрузки?
|
||||
Балансировка нагрузки распределяет запросы между серверами, чтобы избежать перегрузки. Простой способ — Round Robin, где запросы отправляются на серверы по очереди. Более умный вариант — Least Connections, который выбирает сервер с наименьшим числом активных подключений. Если серверы отличаются по мощности, применяют Weighted Round Robin, где сильные сервера получают больше запросов. Иногда используется алгоритм на основе хэшей, чтобы запросы одного пользователя всегда направлялись на тот же сервер.
|
||||
## Какие открытые технологии существуют для балансировки нагрузки?
|
||||
Для балансировки нагрузки есть несколько бесплатных и популярных инструментов: NGINX, HAProxy и Traefik. Эти технологии помогают распределять запросы между серверами, чтобы система работала быстро и надежно.
|
||||
## Как осуществляется балансировка нагрузки на базах данных?
|
||||
В базах данных нагрузку делят между серверами с помощью репликации и шардинга. Например, один сервер обрабатывает записи (master), а чтение выполняется на репликах (slaves). Это позволяет распределить нагрузку: чтение чаще встречается в запросах и требует больше ресурсов. Если данных много, их разбивают на куски (шарды) и хранят на разных серверах.
|
||||
## Реверс-прокси как один из элементов балансировки нагрузки.
|
||||
Реверс-прокси — это промежуточный сервер, который принимает запросы от пользователей и перенаправляет их на внутренние сервера. Он может работать как балансировщик нагрузки, распределяя запросы на основе алгоритмов,из 1 пункта. Реверс-прокси улучшает производительность, ускоряет обработку (за счет кэширования) и повышает безопасность, скрывая внутреннюю структуру системы.
|
14
kosheev_maksim_lab_8/READMY.md
Normal file
14
kosheev_maksim_lab_8/READMY.md
Normal file
@ -0,0 +1,14 @@
|
||||
# Устройство распределенных систем
|
||||
Распределенные системы — это архитектура, в которой задачи выполняются не одним большим приложением, а множеством небольших сервисов. Каждое из них отвечает за определенную функцию: авторизацию, обработку данных, отправку сообщений и так далее. Такой подход особенно важен для больших и сложных проектов, таких как социальная сеть ВКонтакте. Здесь разделение на сервисы позволяет масштабировать систему: если, например, сервис обработки изображений упдаёт, то это не заденет остальную програм и его можно запустить на дополнительных серверах, не трогая остальные части системы.
|
||||
|
||||
# Зачем нужны системы оркестрации?
|
||||
Когда распределенных сервисов становится много, управлять ими вручную становится сложно. Системы оркестрации, такие как Kubernetes, автоматизируют этот процесс: они запускают приложения, следят за их состоянием и помогают быстро заменять упавшие части. Это упрощает разработку и сопровождение, позволяя сосредоточиться на коде, а не на инфраструктуре.
|
||||
|
||||
# Очереди обработки сообщений
|
||||
Очереди сообщений нужны для того, чтобы сервисы могли обмениваться информацией. Например, один сервис обрабатывает заказ, а другой — отправляет уведомление покупателю. Очередь (RabbitMQ или Kafka) помогает передать сообщение об этом заказе. Такие очереди делают систему более надежной: если один из сервисов временно недоступен, сообщение остается в очереди, и его обработают позже.
|
||||
|
||||
# Преимущества и недостатки
|
||||
Плюсы распределенных приложений очевидны: они легко масштабируются, проще в поддержке, и каждая часть системы может развиваться независимо. Но есть и минусы: сложнее наладить взаимодействие между сервисами, возрастает количество потенциальных точек отказа, а разработка требует более высокой квалификации.
|
||||
|
||||
# Параллельные вычисления в распределенных системах
|
||||
Параллельные вычисления полезны, когда нужно одновременно обрабатывать большие объемы данных. Например, при выдаче результатов поиска в поисковой системе или обработке миллионов изображений для социальных сетей. Однако не всегда параллельность оправдана. Если задача последовательная, как, например, генерация отчетов, параллельные вычисления только усложнят код.1
|
Loading…
Reference in New Issue
Block a user