распределенная теория

Распределенная система: Система, в которой аппаратное или программное обеспечение распределено по разным сетевым компьютерам и взаимодействует или координируется друг с другом посредством сообщений.

1. Проблемы, которые необходимо решить (недостатки единой архитектуры)

1. Ограниченная вычислительная мощность для массовых пользователей
2. Чем выше сложность программы, тем ниже эффективность разработки
3. Серьезная ошибка в производственной среде приведет к остановке всех служб.
4. Объем кода увеличивается, а эффективность компиляции снижается.
5. Сосредоточьтесь только на одном стеке технологий

2. Объяснение терминов

1. Распределенный - несколько людей делают [разные] вещи вместе

2. Кластер — несколько человек, делающих одно и то же вместе.

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

3. Эволюция архитектуры

1. архитектура единого приложения
2. Сервер приложений и сервер данных разделены
3. кластер серверов приложений
4. Разделение чтения и записи базы данных
5. Добавьте поисковую систему, чтобы облегчить чтение библиотеки
6. Добавьте кеш, чтобы уменьшить нагрузку на библиотеку чтения
7. Горизонтальное/вертикальное разделение базы данных
8. Вертикальное разделение сервера приложений
9. Разделение горизонта сервера приложений

4. Классификация консистенции

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

5. Теорема CAP

1. Непротиворечивость Непротиворечивость — все данные реплики непротиворечивы, а данные, считанные с любого узла, являются самыми последними.
2. Доступность - служба, предоставляемая внешнему миру, остается нормальной без тайм-аутов ответа или ошибок ответа.
3. Допуск к разделению Допуск к разделению — в случае сетевых разделов услуги могут по-прежнему предоставляться извне.

Только два из трех требований могут быть выполнены одновременно

Доказательство: пользователь отправляет запрос на N1, чтобы изменить значение с V0 на V1. В это время сеть между N1 и N2 прервана. Однако другой пользователь отправляет запрос на N2, чтобы получить значение. В это время существует это три метода.

(1) Верните V0 в [режим AP, пожертвовав согласованностью]

(2) Подождите, пока сеть восстановится, а затем вернитесь к V1 [режим CP, жертвуя доступностью]

(3) Объединить N1 и N2 [режим CA, отказаться от распределенной технологии]

6. Базовая теория

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

1. В основном доступно — допускает частичную потерю доступности при сбое распределенной системы.
   • Время: обычно в течение 0,5 секунд для ответа на результаты, увеличьте до 1-2 секунд в случае сбоя
   • Функция: когда трафик резко возрастает, направлять некоторых пользователей на страницу перехода на более раннюю версию.
2. Мягкое состояние — позволяет данным существовать в промежуточном состоянии (некоторые данные не были синхронизированы), но не влияет на общую доступность системы.
3. В конечном счете согласованные — после периода синхронизации данные в конечном итоге будут согласованными.

7. Протокол согласованности (обработка транзакций базы данных)

1. Двухэтапная фиксация 2PC

обработать

1. Этап подготовки — координатор отправляет сообщение «Подготовка» каждому участнику, выполняя локальную транзакцию, но не фиксируя ее.
2. Фаза фиксации — координатор получает сообщение о сбое или тайм-ауте участника и отправляет участнику сообщение об откате, в противном случае он отправляет сообщение о фиксации

недостаток

1. Синхронная блокировка - когда первый этап не достигает второго этапа, все транзакции участников блокируются.
2. Единая проблема — если координатор выйдет из строя до запуска второй фазы, транзакция участника будет заблокирована.
3. Несогласованные данные — координатор аварийно завершает работу перед отправкой сообщения о фиксации, что приводит к несогласованности данных.
4. Слишком консервативно — сбой любого узла приведет к сбою всей транзакции.

2. Трехэтапная фиксация 3PC

обработать

1. CanCommit - координатор отправляет каждому участникусодержит транзакциизапрос, чтобы узнать, можно ли запустить
2. PreCommit — координатор просит участника выполнить транзакцию
3. DoCommit - Координатор просит участника зафиксировать транзакцию - Если участник не может получить сообщение координатора на данном этапе, транзакция будет зафиксирована по умолчанию по тайм-ауту

Уменьшен диапазон блокировки транзакций 2PC, но полностью проблема несогласованности данных не решена.

8. Алгоритм согласованности (выбрать конечный результат или Лидер)

1. Алгоритм Паксос

Роль

1. Клиент Клиент - делает запросы к распределенным системам
2. Proposer Proposer - убедить акцептантов согласиться
3. Принимающее решение лицо, принимающее решение - одобрить предложение
4. Ученик Ученик - Узнай Окончательное решение

Технические характеристики

1. Акцептор должен принять первое полученное предложение.
2. Каждый раз полученная ценность предложения должна быть такой же, как и в первый раз.
3. Предложение выбрано и должно быть принято более чем половиной акцепторов.

**Процесс 1**

1. Предлагающий отправляет запрос на подготовку с номером N, но без значения более чем половине акцепторов.
2. Возвращает Null, если Акцептор не принял предложение
3. В это время предлагающий может сам определить значение значения и инициировать запрос на принятие с номером N и значением значения для принимающего.
4. Акцептор принимает предложения с номером N и значением как Значение

Процесс 2

1. Предлагающий инициирует запрос на подготовку с номером N+1, но без значения для более чем половины акцепторов.
2. Если Акцептор принял предложение с номером N, вернуть значение Value предложения N.
3. В это время предлагающий инициирует запрос на принятие со значением N+1 для акцептора.
4. Акцептор принимает предложение с номером N+1, и значение равно Value.

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

Решение: указать, что только основной предлагающий может подавать предложения

2. Рафт-алгоритм

Роль

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

обработать

1. Начинаются выборы, все узлы являются Последователями
2. Если вы получаете RequestVote (проголосовали за меня), AppendEntries (выбран лидер), сохраните статус подписчика
3. Если в течение определенного периода времени (случайно 150 ~ 300 мс) запрос не будет получен, идентификатор будет преобразован в Кандидата, чтобы начать баллотироваться в Лидер, и если будет получено более половины голосов, он станет Лидером.
4. Если лидер не избран в конце, то Срок + 1, чтобы начать следующий тур выборов

9. Идемпотентность

Запуск действия несколько раз имеет тот же эффект, что и запуск действия только один раз.

1. Потребность в идемпотентности

• Пользователь повторно отправляет форму

• Злонамеренное двойное голосование пользователя

• Запрос на повторную попытку тайм-аута интерфейса

• Сообщения используются повторно

  Необходимо избегать неизвестных проблем в системе, вызванных повторными попытками

2. Решения

• уникальное поле базы данных

  • Применимые операции
    • Добавить к
    • удалять
  • ограничение
    • Таблица данных должна содержать уникальные поля
  • Операционные процедуры
    1. Вышестоящий сервис генерирует идентификатор (поле уникально), и при вызове нижестоящего сервиса идентификатор передается в
    2. Когда нижестоящая служба добавляет данные, будет сообщено об ошибке, если данные уже существуют.

• Оптимистическая блокировка базы данных

  • Применимые операции
    • возобновить
  • ограничение
    • Нужно добавить дополнительное поле в datatable
  • Операционные процедуры

    1. Восходящая служба передаст значение текущей версии записи, которая будет изменена, нижестоящей службе.

    2. Перед изменением записи нижестоящая служба сначала проверяет соответствие версии, а затем обновляет, если совпадение успешно, и добавляет значение версии + 1.

• Токен токен

  • Применимые операции
    • Добавить к
    • возобновить
    • удалять
  • ограничение
    • Необходимо использовать Redis для проверки
  • Применимая сцена
    • Пользователь отправляет заказ
  • Операционные процедуры
    1. Когда запись базы данных успешно добавлена, значение токена пользователя используется в качестве ключа Redis, а запись со временем существования вставляется в Redis (10 секунд).
    2. При добавлении данных в базу ищите Redis, если запись существует, значит она добавляется повторно

• уникальный серийный номер

  • Применимые операции
    • Добавить к
    • возобновить
    • удалять
  • ограничение
    • Необходимо использовать Redis для проверки
  • Применимая сцена
    • Вызов межсервисного интерфейса
  • Операционные процедуры
    1. Восходящая служба генерирует уникальный серийный номер, сохраняет его в Redis в качестве ключа Redis и передает серийный номер нижестоящей службе.
    2. Перед добавлением данных нижестоящий сервис проверяет, есть ли запись в Redis, если она есть, значит добавляется впервые, после добавления удаляет запись в Redis.

10. Стратегии проектирования распределенных систем

1. Обнаружение сердцебиения

Обычно несут информацию о статусе и метаданных для удобства управления

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

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

• Активно-резервный режим [обычно используется] — когда хост отключен, резервная машина берет на себя всю работу хоста — после восстановления хоста служба переключается обратно на хост автоматически (горячий резерв) или вручную (холодный резерв). резерв) - MySQL, Redis
• Режим взаимного ожидания (multi-master) — два мастера работают одновременно и контролируют друг друга
• Кластерный режим — несколько узлов работают одновременно, а запросы распределяются через мастер-ноду — необходимо решить проблему высокой доступности мастер-узла.

3. Балансировка нагрузки

решение

• Оборудование — F5
• Программное обеспечение - LVS, HAProxy, Nginx

Стратегия

• случайный
• голосование
• Веса
• наименее подключенный
• IP-хеш

11. Сетевое общение

1. RPC

Удаленный вызов процедур

Роль

1. Клиент-клиент — вызывающая служба
2. Клиентская заглушка Клиентская заглушка — упаковывает запросы клиентов в сетевые сообщения и отправляет их на серверную заглушку по сети.
3. Серверная заглушка — получает сообщения клиентской заглушки, распаковывает их и вызывает локальные методы.
4. Сервер Сервер — поставщик услуг

2. RMI

Удаленный вызов метода Удаленный вызов метода

Встроенная поддержка Java для связи между различными виртуальными машинами Java.

Роль

клиент

1. Заглушка заглушка - клиентский прокси
2. Удаленный эталонный уровень — анализ и запуск удаленных эталонных протоколов.
3. Транспортный транспортный уровень — вызывайте удаленные методы и получайте результаты

Сервер

1. Транспортный транспортный уровень — получает запросы клиентов и перенаправляет запросы на удаленный эталонный уровень.
2. Удаленный ссылочный слой — вызов методов скелета
3. Скелет Скелет - Вызов фактического метода

Реестр — регистрирует удаленный объект с помощью URL-адреса и отвечает клиенту ссылкой на удаленный объект.

12. ИО

1. Глоссарий

zhuanlan.zhihu.com/p/22707398

1. Блокировка — после того, как вызов инициирован, он немедленно приостанавливается до тех пор, пока система не закончит чтение данных и не вернет их на прикладной уровень.

2. неблокирующий - возвращается сразу после совершения звонка

3. Синхронизация - активно спрашивайте ядро ​​системы, читаются ли данные или нет

4. Асинхронный - не запрашивать системное ядро, но активно уведомлять системное ядро, когда чтение завершено.

---

2. Тип

1. BIO синхронный блокирующий ввод-вывод - одно соединение один поток

   • Простой
   • Высокая нагрузка на ресурсы
   

2. Синхронный неблокирующий ввод-вывод NIO — одно соединение и один канал — регистрируем соединение с мультиплексором, мультиплексор опрашивает канал и запускает обработку потока, когда в канале есть данные

   

3. Асинхронный неблокирующий ввод-вывод AIO — операции подключения делегируются только ОС, а ОС отвечает за уведомление службы и обратный вызов завершения службы.

🏆 Технический спецвыпуск 5 | Рассказываем о распределенных вещах...