Происхождение этой статьи состоит в том, чтобы ответить на почти круглом столе «распределенная система Соединенных Штатов «проблема», чтобы узнать, как систематически распределять систему?», Затем немного по порядку, формирование этой статьи (знаю почти ID: килин).
предисловие
Я думаю, что перед изучением какого-либо знания лучше сначала понять его вход и выход: то есть процесс генерирования этого знания, какую проблему оно решает, как оно решает ее и какие новые проблемы оно создает (есть нет худа без добра.) Играйте), чтобы мы могли лучше уловить его контекст и ключевые моменты, а не потеряться в деталях в начале.
Итак, прежде чем изучать распределенные системы, первый вопрос, который нам нужно решить, заключается в следующем: какую проблему решает распределенная система?
Какую проблему решает распределенная система?
Во-первых, это проблема стоимости, вызванная узким местом производительности одного компьютера. Из-за нарушения закона Мура узкое место производительности дешевого ПК больше не может быть преодолено. Мини-компьютеры и мейнфреймы могут улучшить производительность одного компьютера, но стоимость слишком высок для обычных компаний медведь;
Во-вторых, проблема стоимости, вызванная взрывным увеличением количества пользователей и данных.В эпоху Интернета количество пользователей резко возросло, и количество данных, генерируемых пользователями, также резко возросло, но ценность одного пользователя или отдельный фрагмент данных на самом деле по сравнению с эпохой программного обеспечения (например, пользователи банка), значение только ниже, но не выше, поэтому мы должны найти более экономичное решение;
Третье - это требование высокой доступности бизнеса. Для интернет-продуктов необходимо предоставить услуги 7 * 24 часа в сутки, а сбои, такие как отключение услуг, не могут быть допущены. Для предоставления высокодоступных услуг, единственный способ Увеличение избыточности для завершения, так что даже услуга, которую можно поддерживать автономной системой, станет распределенной системой из-за высокой доступности.
Исходя из трех вышеприведенных причин, можно увидеть, что в эпоху Интернета автономная система не может решить проблемы стоимости и высокой доступности, но эти две проблемы являются очень важными вопросами практически для всех компаний. -система в одиночку Система от одной к распределенной системе является неизбежной технологической тенденцией.
Как распределенные системы решают проблемы?
Итак, как распределенная система решает проблемы стоимости и высокой доступности, с которыми сталкивается система с одним компьютером?
На самом деле идея очень проста: соединить несколько дешевых ПК через сеть для выполнения совместной работы и обеспечить избыточность в системе для решения проблемы высокой доступности.
Какие новые проблемы привносят распределенные системы?
Давайте посмотрим на определение распределенной системы: Распределенная система — это система, состоящая из набора компьютерных узлов, которые взаимодействуют по сети и координируют свою работу для выполнения общей задачи. В определении мы видим, что распределенная система решает проблемы стоимости и доступности, с которыми сталкивается система с одним компьютером, за счет нескольких рабочих узлов, но при этом возникает проблема координации внутренних рабочих узлов распределенной системы.
Мы часто говорим, что овладение знанием требует понимания его причин и последствий. Для распределенных систем предшествуют «то, что проблема решает распределенную систему», и следствие является «как это координирует внутренние рабочие узлы», поэтому мы должны Решите второго вопроса: как используется распределенная система встроенной координации узла рабочей силы?
Какие новые проблемы приносят распределенные вычисления?
Начнем с простого случая, для распределенных вычислений (stateless), что нужно сделать для согласования внутри системы:
1. Как найти услугу?
В распределенной системе будут разные сервисы (роли).Как сервис А находит сервис Б - это проблема, которую нужно решить.Вообще говоря, механизм регистрации и обнаружения сервисов - общая идея, так что вы можете понять принцип реализации механизма регистрации и обнаружения службы. , и вы можете подумать о регистрации службы и обнаружить, что более разумно выбрать систему AP или CP (строго в соответствии с теорией CAP, большинство систем, которые мы в настоящее время используем, являются трудно удовлетворить C или A, так что здесь просто AP или CP в обычном смысле);
2. Как найти примеры?
После нахождения службы следует отправить текущий запрос, чтобы выбрать, какой именно экземпляр службы? В общем, если экземпляры одного и того же сервиса полностью эквивалентны (без сохранения состояния), то достаточно нажать для обработки стратегии балансировки нагрузки (опрос, вес, хэш, согласованность хэша, сценарии применения различных стратегий, таких как справедливая); если экземпляры одного и того же сервисы не эквивалентны (с сохранением состояния), нужно сначала определить текущий запрос данных для доступа через экземпляр, что делать на сервисе маршрутизации (сервисы метаданных и т.д.), а потом уже для посещения.
3, как избежать лавины?
Системная лавина — это отказ расширяющегося правила из-за последовательности положительной обратной связи. Лавина обычно вызывается отказом очень небольшой части всей системы, что, в свою очередь, приводит к отказу других частей системы. Например, экземпляр определенной службы в системе выходит из строя, что приводит к удалению экземпляра при балансировке нагрузки и увеличению нагрузки на другие экземпляры, что в конечном итоге приводит к сбою всех экземпляров службы один за другим, как домино.
Общая стратегия предотвращения лавин относительно проста, если есть две идеи, одна из которых представляет собой механизм быстрого отказа и деградации (предохранитель, переход на более раннюю версию, ограничение тока и т. д.), который позволяет избежать возникновения лавин за счет быстрого сокращения системы. нагрузка, а другой представляет собой эластичный механизм расширения емкости, за счет быстрого увеличения пропускной способности системы, чтобы избежать лавин. Это можно сделать по-разному в соответствии с разными сценариями или можно использовать обе стратегии.
Вообще говоря, быстрый сбой приведет к сбою некоторых запросов.Если внутренняя согласованность распределенной системы очень высока, быстрый сбой вызовет проблему несогласованности системных данных, эластичное расширение будет лучшим выбором, но эластичное расширение Стоимость реализации и время отклика намного больше, чем отказоустойчивые.
4. Как отслеживать тревоги?
Для распределенной системы, если мы не можем четко понять внутреннее состояние, нет возможности полностью гарантировать высокую доступность.Поэтому для мониторинга распределенной системы (такой как информация, такая как задержка интерфейса и доступность) распределенная трассировка Trace, Chaos engineering для моделирование неисправностей и соответствующие механизмы сигнализации должны быть усовершенствованы;
Распределенное хранилище, принесшее новые проблемы?
Далее рассмотрим, как осуществляется внутреннее согласование распределенного хранилища (stateful), при этом описанный выше метод согласования распределенных вычислений применим и к распределенному хранилищу, поэтому повторяться не буду:
1. Теория и компромиссы распределенных систем
Теория ACID, BASE и CAP, чтобы понять эти три темы, порекомендуйте эту статью и соответствующие ссылки далее в статье: Английская версия:woohoo.info Q.com/articles/wipe…Китайская версия:woowoo.info Q.capable/article/cap…
2. Как сделать шардинг данных?
Невозможно хранить все данные с объемом памяти одной машины, поэтому необходимо решить, как хранить данные на разных машинах по определенным правилам.В настоящее время используется много схем: Hash, Consistent Hash и Range Based sharding. стратегия, Вы можете узнать об их преимуществах и недостатках и их соответствующих сценариях применения;
3. Как сделать репликацию данных?
Почему вам необходимо выполнять избыточную обработку данных для удовлетворения требований высокой доступности системы?Существующие решения в основном включают в себя: централизованные решения (репликация master-slave, протоколы согласованности, такие как Raft и Paxos и т. д.) и децентрализованные решения (Quorum и векторные часы)) для понимания их преимуществ и недостатков и соответствующих сценариев их применения, а также уровня согласованности данных (линейная согласованность, последовательная согласованность, конечная согласованность и т. д.), отображаемых вне системы;
4. Как делать распределенные транзакции?
В распределенной системе для реализации транзакций в первую очередь необходимо иметь возможность сортировать параллельные транзакции, чтобы в случае конфликта транзакций можно было подтвердить, какая транзакция обеспечивает успех, а какая транзакция терпит неудачу. Для одномашинной системы это вообще не проблема, этого можно добиться, просто добавив временную метку к серийному номеру, однако для распределенной системы время машин в системе не может быть полностью синхронизировано, и серийный номер отдельной машины не имеет глобального значения, так как указанный выше способ не работает. Однако можно выделить одну машину для всей системы для выработки идентификаторов транзакций в одномашинном режиме.Нет проблем с мультицентрами в одном городе и мультицентрами на коротких расстояниях.Однако, если вы хотите чтобы создать глобальную распределенную систему, вы должны обращаться к одной для каждой транзакции. Стоимость получения узлами идентификаторов транзакций слишком высока (например, RTT от Ханчжоу, Китай, до востока США составляет 200 + мс). Google Spanner решает эту проблему, внедряя API TrueTime через GPS и атомные часы для создания глобально распределенной базы данных.
После получения идентификатора транзакции атомарность распределенной транзакции реализуется через протокол 2PC или 3PC, а остальные части мало чем отличаются от автономной транзакции, поэтому я не буду вдаваться в подробности.
Продвинутые этапы обучения
К этому моменту у меня есть базовая концепция контекста распределенной системы, а затем я начинаю вступать в стадию детального изучения, которая также является очень сложной стадией. Детали очень важны.Оценочные показатели, ведь дьявол кроется в деталях. Здесь мы можем систематически учиться в двух аспектах:
1. Начните с практики
Исследуйте структуру широко используемых распределенных систем, HDFS или GFS (распределенная файловая система), Kafka и Pulsar (распределенная очередь сообщений), Redis Cluster и Codis (распределенный кеш), база данных и таблица MySQL (традиционная реляционная распределенная схема типа базы данных), Набор механизмов MongoDB Replica Set and Sharing и децентрализованная Cassandra (база данных NoSQL), централизованная TiDB и децентрализованная CockroachDB (NewSQL), а также некоторые микросервисные фреймворки и т. д.;
2. Начиная с теории
С теоретической точки зрения, для изучения распределенных связанных статей, вот рекомендуемая книга «Проектирование приложений с интенсивным использованием данных» (китайская версия: проектирование системы приложений с интенсивным использованием данных), сначала прочитайте книгу целиком, а затем прочитайте главы вас больше интересуют соответствующие ссылки, упомянутые в этой главе.
Суммировать
В этой статье, из выпуска распределенной системы, обсудите, как это решить проблему, и, наконец, обсудить, какие новые проблемы ввели и обсуждали решения для этих новых проблем, это распределенная система, вероятно, 知络 脉络. После освоения этого контекста знаний вы можете изучить распределенную систему с двух перспектив практики и теории.