Немного размышлений о высоком уровне параллелизма и высокой доступности

задняя часть рептилия API дизайн

Полка этой статьи относится к книге Чжан Кая «Основная технология архитектуры веб-сайтов с миллиардным трафиком», которая разделена на четыре части: руководящие принципы, высокая доступность, высокая степень параллелизма и практические примеры. В этой статье рассказывается о первых трех частях, большая часть содержания является моим собственным размышлением, книга предназначена только для справки.

Руководящие принципы

Кое-что из перечисленного в книге может быть не принципами, а техниками. Принципы, которые я понимаю, следующие:

Принцип высокого параллелизма:

  1. Дизайн без сохранения состояния: поскольку состояние может включать операции блокировки, блокировки могут привести к параллельной сериализации.
  2. Сохраняйте разумную степень детализации: независимо от того, разделена она или обслуживается, на самом деле это контроль детализации службы. Гранулярность управления улучшает параллелизм, чтобы рассредоточить запросы или улучшить работоспособность с точки зрения управления.
  3. Такие методы, как кэширование, очереди и параллелизм, можно использовать для справки при проектировании с высокой степенью параллелизма, но их необходимо использовать в соответствии со сценарием.

Принцип высокой доступности:

  1. Любой выпуск системы должен иметь возможность отката.
  2. Любые внешние зависимости системы должны точно измерять, можно ли понизить ее версию, можно ли понизить ее версию без потерь, и обеспечить переключение на более раннюю версию.
  3. Интерфейс, предоставляемый системой, должен быть настроен с ограничением тока, а значение ограничения тока должно быть максимально точным и надежным.

Принципы бизнес-дизайна:

  1. Безопасность: защита от сканирования, перелистывания, отправки дубликатов форм и т. д.
  2. По крайней мере, потребление, следует подумать, следует ли принимать идемпотентный дизайн
  3. Динамический бизнес-процесс, динамические бизнес-правила
  4. Система ответственности владельца системы, система резервирования персонала, дежурная система
  5. системная документация
  6. Отслеживание фоновых операций

Вышеперечисленные принципы — лишь малая часть большого мира, и читатели должны по крупицам накапливать их в работе и учебе.

Высокая доступность

Давайте сначала поговорим об основных требованиях высокой доступности:Высокая доступность позволяет противостоять неопределенности и обеспечивать работоспособность системы7.Круглосуточная медицинская служба*. Что касается высокой доступности, проблема, с которой мы фактически сталкиваемся, состоит в том, чтобы противостоять неопределенности, которая исходит со всех сторон. Например, сильное землетрясение вызовет перебои в работе всего компьютерного зала, как с этим бороться? Например, если инженер, отвечающий за ядро ​​системы, уходит в отставку, как с этим быть? Другой пример — отказал нижестоящий интерфейс, как с этим бороться? Системный диск поврежден и данные могут быть потеряны, что делать? Я думаю, что все более или менее знают о том, как бороться с вышеперечисленными проблемами в своей работе, и процесс борьбы с этой неопределенностью - это аварийное восстановление.Разные "катастрофы" соответствуют разным уровням аварийного восстановления.

Чтобы бороться с этими разными уровнями неопределенности, существуют разные уровни затрат, поэтому должны быть стандарты доступности. Это стандартN个9. С увеличением N соответственно увеличивается и стоимость Как максимально сэкономить стоимость на основе достижения требуемой бизнесом доступности? Это тоже тема, над которой стоит подумать. В противном случае 100% минус этоN个9Говоря о так называемом среднем времени наработки на отказ (MTBF), многие люди заботятся только об этих девятках и игнорируют время обработки сбоя, что неправильно: чем быстрее вы можете справляться со сбоями, тем выше возможная доступность системы.

Выше упоминались некоторые концепции юзабилити, давайте поговорим о навыках. В книге Кайтао нет классификации техник юзабилити, здесь я пытаюсь использовать «вещи» для их классификации. Под «событием» здесь понимается отказ, который подразделяется на: до события (до возникновения отказа), событие (отказ происходит до тех пор, пока система или человек не осознают отказ), во время события (время от отказа до обработки сбоя) и после события (после устранения сбоя) ).

Согласно приведенной выше классификации, на разных этапах должны быть разные навыки:

  1. Предварительно: копирование, изоляция, квота, предварительный план, обнаружение
  2. Инцидент: мониторинг, тревога
  3. В процессе: переход на более раннюю версию, откат, план на случай непредвиденных обстоятельств, серия failXXX
  4. После мероприятия: обзор, размышление, техническое усовершенствование

заранее

копировать технологию

Природа является заслуженным мастером технологии копирования.Будь то ледниковый период или сокрушительный удар, вызванный падением метеорита на землю, виды продолжают непрерывно воспроизводиться.В этом роль репликации генов. Реплика — мощное оружие против неопределенности.Внедрение технологии реплик в компьютерные системы также повысит их доступность. Кластер службы без сохранения состояния — это приложение реплик.Поскольку состояния нет, его можно масштабировать по горизонтали, а между этими серверами без состояния требуется слой агентов для унифицированного планирования и управления, поэтому существует обратный прокси-сервер. Когда агент обнаруживает проблему с машиной с помощью механизма обнаружения сердцебиения, она отключается, а другие машины-«копии» продолжают предоставлять услуги; поле хранения также часто использует технологию копирования, такую ​​как трехсайтовая трехсайтовая система OB. технология пяти копий центра и т. д., переключатель mysql master-standby, очередь зеркал rabbitMQ, технология дискового RAID, копии разделов в различных nosql и т. д., существует бесчисленное множество, почти все системы, гарантирующие высокую доступность, имеют избыточные копии.

технология изоляции

В книге упоминается множество видов изоляции: изоляция потоков, изоляция процессов, изоляция кластеров, изоляция машинного зала, изоляция чтения-записи, динамическая и статическая изоляция, изоляция обходчиков, изоляция горячих точек и изоляция аппаратных ресурсов. На мой взгляд, эти выделения действительно своего рода, а именноИзоляция ресурсов, независимо от того, являются ли потоки, процессы, аппаратное обеспечение, компьютерные залы или кластеры ресурсами; динамические ресурсы и статические ресурсы — это просто классификация ресурсов; изоляция горячих точек — это изоляция ресурсов горячих точек и ресурсов, не являющихся горячими точками; изоляция чтения-записи — это только как используются ресурсы, те же самые два ресурса, один для записи и один для чтения. Поэтому суть изоляции фактически состоит в самостоятельной защите ресурсов. Поскольку каждый ресурс защищен независимо, проблема с одним из ресурсов не повлияет на другие ресурсы, что повышает доступность службы в целом. Люди использовали методы изоляции в течение долгого времени.В сельском хозяйстве, сельском хозяйстве, инвестировании в акции и даже в тюрьмах, где содержатся заключенные, можно найти тень методов изоляции.

Технология квот

Технология квот защищает систему, ограничивая количество ресурсов, тем самым повышая общую доступность. Текущее регулирование — это своего рода технология квот, которая позволяет избежать простоев службы, вызванных недостаточным предложением, за счет корректировки уровня входящего потока для перехода в режим онлайн. Ограничение тока делится на ограничение тока кластера и автономное ограничение тока.Ограничение тока кластера требует взаимодействия с распределенной инфраструктурой, а ограничение тока одной машины — нет. В большинстве бизнес-сценариев достаточно использовать одну машину для ограничения тока.В особых сценариях (таких как seckill и т. д.) ограничение тока должно ограничивать весь кластер. Кроме того, здесь следует учитывать несколько моментов:

  1. Как установить разумное значение ограничения тока? Для установки текущего предельного значения требуется полноценный стресс-тест, правильная оценка взаимосвязи между мощностью ЦП, диском, памятью, вводом-выводом и другими показателями и трафиком (не обязательно линейная зависимость) в сочетании с бизнес-оценками и эксплуатацией и обслуживанием. опыт. , чтобы быть уверенным.
  2. Как быть с ограниченным трафиком? Есть несколько способов справиться с этим: один — отказаться от него напрямую и напомнить пользователю аккуратной копией, другой — использовать тишину, обычно известную как понижение версии без потерь, для обновления страницы с кешированным содержимым, третий — сохранить лавинно и асинхронно возвращают кровь, что обычно используется в транзакционных сценариях.
  3. Приведет ли это к непредумышленному убийству? Ограничение тока одной машины приведет к непредумышленному убийству, особенно когда нагрузка не сбалансирована, может произойти непредумышленное убийство; если значение предельного тока для одной машины установлено слишком маленьким, также может произойти непредумышленное убийство.

технология обнаружения

Он используется только для определения текущей доступности системы и не может эффективно улучшить доступность системы.Если это не сделано должным образом, это даже снизит доступность системы. Стресс-тестирование и тренировки, а также наиболее распространенные методы обнаружения. Стресс-тестирование делится на полноканальное стресс-тестирование и одноканальное стресс-тестирование. Полноканальное стресс-тестирование используется для таких событий, как Double Eleven, требующих общего взаимодействия вышестоящих и нижестоящих систем. или выполняет простое автономное измерение давления для извлечения показателей производительности. Общий процесс полноканального стресс-тестирования: установка и оценка цели стресс-тестирования, трансформация стресс-тестирования, написание и развертывание сценария стресс-тестирования, подготовка данных стресс-тестирования, проверка канала с низким трафиком, уведомление владельцев вышестоящей и нижестоящей системы, стресс-тестирование. разминка, стресс-тестирование, отчет об оценке результатов стресс-тестирования, оптимизация производительности. Вышеупомянутый процесс многократно повторяется до тех пор, пока не будет достигнута цель стресс-теста; учения обычно делятся на масштабы: например, учения по аварийному восстановлению на уровне города, учения по аварийному восстановлению на уровне компьютерного зала и учения по аварийному восстановлению в масштабе кластера (кластер БД, кэш-память). кластер, кластер приложений и т. д.), внесение ошибок на уровне одной машины, отработка планов и т. д. Роль учений не нужно особо подчеркивать, но учения обычно проводятся рано утром и требуют сотрудничества владельцев системы для устранения ошибок.

план

Планы, как правило, делятся на предварительные (до события) и экстренные (на случай). Предварительные планы реализуются заранее, например, временное переключение системы из пикового режима в энергосберегающий режим; аварийные планы выполняются только в критические моменты, в основном для гемостаза, например переключение аварийного восстановления одним нажатием. Плановая технология обычно используется в сочетании с переключателем, а принудительный план обычно представляет собой нажимной переключатель. Кроме того, план также можно комбинировать с текущим ограничением, откатом, переходом на более раннюю версию и т. д. и использовать в качестве регулярного проекта упражнений.

инцидент

Инцидент относится к периоду с момента возникновения сбоя до момента, когда система или человек воспринимают сбой и готовы с ним справиться.Основное требование состоит в том, как быстро и точно идентифицировать сбой.

Мониторинг и оповещение

Как правило, когда происходит ошибка, большинство начальников задают три вопроса: Почему они узнали? Почему это было решено? Насколько велико влияние? Даже если влияние ошибки велико, если вы можете быстро остановить кровотечение, вы можете сохранить лицо при обзоре.Наоборот, если вы не устраните ее вовремя, даже небольшая ошибка может заставить вас проиграть. твоя работа. Чем раньше будет выявлена ​​неисправность, тем скорее проблема может быть решена, а глаза наблюдают и тревожатся. Мониторинговая тревога знакома всем, поэтому я не буду здесь вдаваться в подробности.

в центре

Текущая работа относится к тому, что мы можем или должны сделать, чтобы обеспечить доступность системы в случае сбоя. Делится на даунгрейд, откат, экстренный план (см. выше, тут не много), фейлХХХ серии.

понижение рейтинга

Коннотация понижения рейтинга богата, и мы думаем только с точки зрения ссылки. Суть понижения - отказаться от машины и защитить красавца.Временным отказом от некоторых функций гарантируется общая доступность системы. Даунгрейд Хотя система в целом по-прежнему доступна, из-за компромисса видно, что все понижения должны быть с потерями. Не может быть настоящего даунгрейда без потерь, который часто называют пользовательским интерфейсом без потерь. Понижение должно происходить между уровнями (восходящим и нисходящим), либо уровень a временно не вызывает уровень b, который называется предохранителем, либо слой a временно вызывает уровень c (рациональность уровня c должна быть

Давайте посмотрим на некоторые ухудшенные примеры в книге: 1. Ухудшение чтения-записи на самом деле является ухудшением между уровнем хранения и прикладным уровнем.Применяется метод переключения резервного канала, и согласованность теряется 2. Функция ухудшается , и некоторые функции закрыты Вышеупомянутое ухудшение между уровнем приложения и уровнем функционального модуля, и принят метод предохранителя, который теряет некоторые функции. ③Понижение краулера на самом деле является понижением между краулером поисковой системы и системой приложений.Метод альтернативного переключения ссылок используется для направления краулера на статическую страницу, а потеря заключается в создании индекса движка и коллекции страниц.

откат

Когда не удается выполнить какое-либо изменение, самым безопасным и эффективным способом является откат. Хотя откаты работают, они непросты, потому что у откатов есть одна важная предпосылка: изменения должны иметь возможность отката. Требуется много усилий, чтобы сделать определенный вид изменений откатываемым. Проще говоря, большинство базовых сервисов уже инкапсулировали эту функцию для нас, например, откат транзакции БД (механизм транзакций БД), откат базы кода (контроль версии файла GIT), откат выпуска (поддержка системы выпуска) и т. д. Когда мы ежедневно меняем операции, мы должны определить, можно ли откатить ваши операции, и сделать все возможное, чтобы обеспечить возможность отката всех изменений. Если его нельзя откатить, можно ли выполнять горячие обновления (например, публикацию приложений в магазине приложений) или использовать дополнительные средства, такие как компенсация возможной согласованности, чтобы обеспечить высокую доступность системы.

Серия failXXX

Когда нисходящий вызов терпит неудачу, у нас обычно есть несколько способов справиться с этим:

  1. failretry, то есть повторная попытка в случае сбоя, должна быть согласована с временем отсрочки, иначе немедленная повторная попытка может оказаться неэффективной.
  2. отказоустойчивость, так называемый отказоустойчивость. Например, если вызов нижестоящего интерфейса a завершается неудачно, балансировщик нагрузки RPC вызовет другие машины поставщика интерфейса a для повторной попытки; например, если база данных x зависнет, адаптивное аварийное восстановление приложения переключит вызов библиотеки x к вызову библиотеки y, эта библиотека y может быть резервной библиотекой (бизнес-поток) или резервной библиотекой (бизнес-тип состояния).
  3. отказоустойчивость, то есть тишина.Вообще, когда нисходящий канал слабо зависим, можно использовать отказоустойчивость, которую можно комбинировать с отказоустойчивостью.Например, если отказоустойчивость терпит неудачу три раза, то выполняется отказоустойчивость.
  4. failfast, немедленно сообщайте об ошибках, failfast в основном позволяет инженерам быстро обнаружить проблему и своевременно выполнить ручное вмешательство.
  5. отказоустойчивость, компенсация задержки (восстановление крови), как правило, можно использовать очередь сообщений или сканирование по времени.

Вышеупомянутые 1, 2 и 4 относятся к стратегии повторных попыток, то есть к повторной попытке, упомянутой в главе «Тайм-аут и повторная попытка» книги. Проблема с повторной попыткой: каков интервал отсрочки? Сколько раз повторять? Как правило, в случае временного джиттера в нисходящем направлении его можно восстановить за короткое время, но когда нисходящий поток полностью недоступен, очень вероятно, что повторные попытки не увенчаются успехом, но это вызовет большую нагрузку на нисходящий поток. случае следует использовать предохранитель. Поэтому необходимо тщательно продумать настройку количества повторных попыток и правильный выбор времени отсрочки. Давайте поговорим о тайм-ауте. Тайм-аут — это всего лишь превентивный механизм, а не стратегия реагирования на сбои. В основном он предназначен для предотвращения накопления запросов — ресурсы используются для ожидания возврата нисходящих запросов. Стоит ли говорить о последствиях накопления, главное, как выбрать правильный период тайм-аута? В книге только описано, как настроить период тайм-аута каждой части ссылки, но не известно, сколько настраивать, что недостаточно полно.

после

Проверяйте, думайте и вносите технические изменения. Нечего сказать.

Высокий параллелизм

Если вы стремитесь только к высокой доступности, это на самом деле несложно.Представьте, что только один человек получает доступ к вашей системе в год, при условии, что этот человек получает доступ успешно, тогда «доступность» вашей системы составляет 100%. Но реальность такова, что с развитием бизнеса объем запросов будет все выше и выше, и тогда будут активироваться различные системные ресурсы, и потенциальные риски будут постепенно выявляться. Поэтому одна из трудностей создания системы заключается в следующем: как обеспечить высокую доступность системы при условии высокого параллелизма. Некоторые методы обеспечения высокой доступности были упомянуты выше.В этом разделе мы обсудим высокую степень параллелизма в сочетании с книгой Кайтао.

На картинке выше — обычная сцена из нашей жизни — очередь за покупками. Кассир — это наша служба, а каждый клиент в очереди — это заявка. Наш основной призыв состоит в том, чтобы позволить как можно большему количеству людей завершить свое потребление в течение разумного времени ожидания. Как это сделать? Один-улучшить скорость обработки кассиров.Чем быстрее они обрабатывают, тем больше клиентов можно обслужить в единицу времени,другой-увеличить количество персонала.Если количества людей не хватает, наймем 100 человек( если стоимость не включена); в-третьих, уменьшить количество посетителей, то есть фильтрация отвлечения, фильтрация некоторых людей заранее или действия по предварительному нагреву (например, предварительный нагрев Double Eleven) до пика. Удовлетворение потребностей некоторых люди в первую очередь. Поэтому, если вы хотите высокий параллелизм, вам нужно начать со следующих аспектов:

  1. Улучшить скорость обработки: кэширование, асинхронность
  2. Увеличение рабочей силы: многопоточность (многопроцессность), расширение емкости
  3. Сокращение количества посетителей: предварительная обработка (не рассматривается в этой статье)

Улучшить скорость обработки

тайник

Причина, по которой кеш может улучшить скорость обработки, заключается в том, что скорость доступа разных устройств различается. Тему кэширования можно разделить на несколько книг без повторения. От ЦП до клиентского кеша, то есть от нижнего уровня до уровня, который достигает ближайшего пользователя, каждый уровень может иметь или может иметь кеш. Мы не будем здесь много говорить, просто поговорим о простом кэшировании на стороне сервера. Теперь посмотрим на кэширование с нескольких разных точек зрения:

①С точки зрения эффекта. Чем выше процент попаданий, тем лучше? 100 000 хранилищ данных, 1 000 хранилищ кэшируются, а процент попаданий стабилен на уровне 100%.Означает ли это, что 99 000 хранилищ являются хранилищами с длинным хвостом? Оценка эффекта кеша не может просто смотреть на частоту попаданий.
②Из стратегии утилизации. Если кеш используется в качестве устройства хранения наподобие базы данных, такого понятия, как переработка, не существует (за исключением перезапуска или простоя, данные остаются в силе); если хранятся только горячие данные, возникнут проблемы с переработкой и заменой. Есть два способа переработать: один — квота пространства, а другой — квота времени. Так же есть несколько способов замены, LRU, FIFO, LFU.
③С точки зрения режима использования кеша: пользователь напрямую управляет кешем и БД, пользователь напрямую управляет кешем, а кеш помогает нам читать и записывать БД;
④С точки зрения классификации кеша. Кэш Java в куче, кеш Java вне кучи, дисковый кеш, распределенный кеш, многоуровневый кеш.
⑤С точки зрения использования кеша. Проблема нулевого проникновения, проблема шокирующего стада, проблема точки доступа к кешу, проблема согласованности кеша, проблема распространения чтения и записи. . . . . .
⑥ Метод обновления. Чтение обновления, запись обновления, асинхронное обновление.

Если кэш-кластер предполагает многокластерное развертывание в разных местах в сочетании с большими объемами данных и бизнес-сценариями с высокой степенью параллелизма, возникнет множество более сложных проблем, которые здесь не перечислены.

асинхронный

Существует несколько коннотаций асинхронности.Одним из них является превращение нескольких синхронных вызовов в асинхронные одновременные вызовы, чтобы общее время отклика изменилось с исходного t1+t2+t3+…..+tn на max(t1,t2,t3 .. ..,tn), что также называется асинхронной оркестровкой; второе — использовать asyc io на уровне операционной системы для повышения производительности обработки ввода-вывода; третье — «сбрасывать» запрос и обрабатывать его асинхронно позже, как правило, с использованием промежуточного программного обеспечения очереди . Среди них асинхронная оркестровка может использовать CompletableFuture, общая структура асинхронного ввода-вывода инкапсулирована, а промежуточное программное обеспечение очереди — одна из наиболее часто используемых технологий, и это также объект, на котором мы сосредоточимся.

Бизнес допускает отложенную обработку, что является основной предпосылкой для использования промежуточного программного обеспечения очередей, то есть для использования больше подходят системы не в реальном времени или системы квазиреального времени. Основными функциями являются: асинхронная обработка (увеличение пропускной способности), пиковое сглаживание и хранение флуда (гарантия стабильности), синхронизация данных (в конечном счете согласованные компоненты) и развязка системы (нисходящему потоку не нужно воспринимать абонентов).

Очередь буфера: как правило, циклическая очередь буфера используется для управления размером буфера.
Очередь задач: обычно используется в системах планирования задач, таких как пулы потоков, прерыватели.
Очередь сообщений: промежуточное ПО сообщений в общем смысле.Разные бизнес-сценарии требуют разных возможностей промежуточного ПО.Некоторым требуется высокая пропускная способность, некоторым требуется поддержка транзакций, некоторым требуется поддержка нескольких клиентов, некоторым требуется поддержка определенных протоколов и т. д. Подождите, пробуем разрабатывать большая и всеобъемлющая очередь сообщений, я лично считаю, что лучше предоставить множество очередей для выбора по запросу, а затем предоставить единый коммуникационный центр для полной интеграции возможностей сообщений.
Очередь запросов: это очередь для обработки запросов, которая немного похожа на обработчик процессов.Он может выполнять некоторую обработку до и после постановки в очередь и обработки из очереди, например, ограничение тока, фильтрацию и т. д.
Очередь шины данных: синхронизация каналов, данных и других данных (гетерогенных или гомогенных).
Приоритетная очередь: общая реализация большой корневой кучи
Очередь реплик: если очередь поддерживает воспроизведение, очередь реплик несколько избыточна.
Зеркальная очередь: обычно используется для переключения системы очередей с высокой доступностью. Иногда он также реплицируется в кластерах и компьютерных залах, чтобы обеспечить большее потребление потребителями и увеличить возможности доставки.

Потребительская сторона очереди имеет выбор между режимом извлечения или режимом проталкивания. Режим вытягивания может контролировать ход выполнения, а режим выталкивания работает в режиме реального времени; вытягивание может поддерживать упорядочение в одной очереди, а выталкивание трудно поддерживать. В дополнение к режиму потребления, очередь имеет ряд других проблем, пожалуйста, обратитесь к другим книгам, здесь нечего объяснять.

Вот еще немного пояснений об асинхронности. Синхронный к асинхронному может повысить пропускную способность, а асинхронный к синхронному может повысить надежность.

Увеличение рабочей силы обработки

Многопоточность

Многопоточность (многопроцессорность) проще всего представить в технологии «увеличения рабочей силы», и мы обычно широко используем ее. Будь то контейнер веб-службы, шлюз, RPC-сервер, потребитель и отправитель очереди сообщений и т. д., все они используют многопоточность. Его преимущества не нужно слишком долго объяснять. Здесь мы говорим только об одной важной вещи, а именно о настройке количества потоков.Если количество потоков слишком велико, это может съедать системные ресурсы.Если оно слишком мало, преимущества многопоточности не могут быть реализованы. проявленный. В общих настройках это будет означать среднее время обработки, пиковый параллелизм, средний параллелизм, скорость блокировки, максимально допустимое время отклика, количество ядер ЦП и т. д., а затем выполнять определенные операции для расчета количества потоков, ядер и макс. и Размер очереди блокировки. Конкретный алгоритм можно погуглить самостоятельно.

Расширение

Для сервисов без сохранения состояния масштабирование, вероятно, является одним из наиболее эффективных методов увеличения параллелизма на данный момент. Когда возникает временная проблема параллелизма, вы можете напрямую создать заказ на работу для расширения и получить немедленные результаты. Но самая большая проблема с расширением мощностей — это стоимость.Думая о физических машинах, которые стоят десятки тысяч, если они предназначены только для поддержки одночасовой рекламной акции, а обычный коэффициент использования почти равен нулю, это действительно пустая трата. Поэтому существует эластичное облако. Когда емкость необходимо расширить, вы можете заимствовать чужие машины (Alibaba Cloud), чтобы использовать их и возвращать. Вы также можете смешивать офлайн и онлайн, чтобы в полной мере использовать ресурсы.

С точки зрения методов расширения оно делится на вертикальное расширение (увеличение масштаба) и горизонтальное расширение (уменьшение масштаба). Вертикальное расширение предназначено для увеличения вычислительной мощности одной машины, но аппаратная мощность по-прежнему ограничена; горизонтальное расширение — для увеличения количества машин, но с увеличением числа машин возможность параллелизма одного приложения не снижается. обязательно показать линейную связь с ним.На этом этапе может возникнуть необходимость разделить приложение как услугу.

С точки зрения данных расширение емкости можно разделить на расширение емкости без сохранения состояния и расширение емкости с отслеживанием состояния. Расширение без сохранения состояния обычно относится к расширению нашего сервера приложений; расширение с сохранением состояния обычно относится к расширению хранилища данных либо путем разделения части данных на несколько разных копий, то есть сегментирования, либо путем копирования n копий целиком, то есть копии. Проблема, с которой сталкивается сегментирование, заключается в надежности сегментирования. Как правило, используются передача, повторное хеширование и копирование фрагментов. Проблема, с которой сталкивается копирование, заключается в согласованности. Как правило, используются алгоритмы согласованности, такие как paxos и raft.