Краткое изложение интервью по Java, включая ключевые знания Java и общие платформы с открытым исходным кодом, приветствуется к прочтению. В статье возможны ошибки, т.к. личные знания ограничены, прошу указать! Статья постоянно обновляется...
ID заглавие адрес 1 Design Patterns Interview Questions (резюме наиболее полных вопросов для интервью) nuggets.capable/post/684490… 2 Вопросы для собеседования по базовым знаниям Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 3 Вопросы для собеседования по коллекции Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 4 Вопросы для интервью JavaIO, BIO, NIO, AIO, Netty (резюме наиболее полных вопросов для интервью) nuggets.capable/post/684490… 5 Вопросы для собеседования по параллельному программированию на Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 6 Вопросы для собеседования об исключении Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 7 Вопросы для интервью с виртуальной машиной Java (JVM) (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 8 Весенние вопросы для интервью (резюме наиболее полных вопросов для интервью) nuggets.capable/post/684490… 9 Вопросы интервью Spring MVC (сводка наиболее полных вопросов интервью) nuggets.capable/post/684490… 10 Вопросы интервью Spring Boot (сводка наиболее полных вопросов интервью) nuggets.capable/post/684490… 11 Вопросы интервью Spring Cloud (краткое изложение наиболее полных вопросов интервью) nuggets.capable/post/684490… 12 Вопросы интервью Redis (сводка наиболее полных вопросов интервью) nuggets.capable/post/684490… 13 Вопросы для интервью MyBatis (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 14 Вопросы для собеседования по MySQL (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 15 TCP, UDP, Socket, HTTP вопросы интервью (резюме наиболее полных вопросов интервью) nuggets.capable/post/684490… 16 Вопросы для интервью с Nginx (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 17 ElasticSearch Вопросы на собеседовании 18 кафка вопросы интервью 19 Вопросы для интервью RabbitMQ (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 20 Вопросы для интервью Dubbo (краткое изложение наиболее полных вопросов для интервью) nuggets.capable/post/684490… 21 Вопросы интервью ZooKeeper (резюме наиболее полных вопросов интервью) nuggets.capable/post/684490… 22 Вопросы для интервью Netty (краткое изложение наиболее полных вопросов для интервью) 23 Вопросы для интервью с Tomcat (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 24 Вопросы для собеседования по Linux (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 25 Вопросы для интервью, связанные с Интернетом (краткое изложение наиболее полных вопросов для интервью) 26 Вопросы для интервью по безопасности в Интернете (краткое изложение наиболее полных вопросов для интервью)
Что такое ZooKeeper?
-
ZooKeeper — это служба распределенной координации с открытым исходным кодом. Это должно обеспечить последовательный сервис для распределенных приложений, распределенные приложения могут быть основаны на таких данных, Zookeeper реализует публикацию/подписку, балансировку нагрузки, службы имен, распределенную координацию/уведомление, управление кластером, главные выборы и функции распределенной очереди распределенной блокировки.
-
Цель ZooKeeper — инкапсулировать сложные и подверженные ошибкам ключевые службы и предоставить пользователям простой в использовании интерфейс и систему с высокой производительностью и стабильными функциями.
-
Zookeeper гарантирует следующие характеристики распределенной согласованности:
(1) Последовательная согласованность
(2) атомарность
(3) единый вид
(4) Надежность
(5) В режиме реального времени (возможная согласованность)
-
Запрос клиента на чтение может быть обработан любой машиной в кластере.Если у запроса на чтение есть прослушиватель, зарегистрированный на узле, прослушиватель также обрабатывается подключенным компьютером zookeeper. Для запросов на запись эти запросы будут отправлены на другие компьютеры zookeeper одновременно, и запрос не будет возвращать успех, пока не будет достигнуто соглашение. Следовательно, по мере увеличения количества машин кластера в zookeeper пропускная способность запросов на чтение будет увеличиваться, а пропускная способность запросов на запись будет уменьшаться.
-
Порядок — очень важная функция в zookeeper.Все обновления упорядочены глобально, и каждое обновление имеет уникальную отметку времени, которая называется zxid (идентификатор транзакции Zookeeper). Запрос на чтение будет упорядочен только относительно обновления, то есть возвращаемый результат запроса на чтение будет иметь последний zxid зоопарка.
Что предлагает ZooKeeper?
-
Файловая система
-
Механизм уведомления
Файловая система ZooKeeper
-
Zookeeper предоставляет многоуровневое пространство имен узлов (узлы называются znodes). В отличие от файловой системы, эти узлы могут устанавливать связанные данные, а в файловой системе только файловый узел может хранить данные, а узел каталога не может.
-
Чтобы обеспечить высокую пропускную способность и низкую задержку, Zookeeper поддерживает эту древовидную структуру каталогов в памяти, что делает Zookeeper неспособным хранить большой объем данных, а верхний предел хранения данных для каждого узла составляет 1 МБ.
Как Zookeeper обеспечивает синхронизацию состояния главного и подчиненного узлов?
- Ядром Zookeeper является механизм атомарного вещания, обеспечивающий синхронизацию между различными серверами. Протокол, реализующий этот механизм, называется протоколом Zab. Протокол Zab имеет два режима: режим восстановления и режим широковещания.
режим восстановления
- Заб переходит в режим восстановления при запуске службы или после сбоя лидера.Режим восстановления заканчивается, когда лидер избран и большинство серверов завершили синхронизацию с состоянием лидера. Синхронизация состояний гарантирует, что лидер и сервер имеют одинаковое состояние системы.
режим трансляции
- Как только лидер синхронизирует состояние с большинством последователей, он может начать широковещательную рассылку сообщений, то есть войти в широковещательное состояние. В это время, когда сервер присоединяется к службе ZooKeeper, он запускается в режиме восстановления, обнаруживает лидера и синхронизирует состояние с лидером. После завершения синхронизации он также участвует в рассылке сообщений. Служба ZooKeeper остается в состоянии трансляции до тех пор, пока лидер не выйдет из строя или лидер не потеряет поддержку большинства последователей.
Четыре типа узлов данных Znode
-
(1) PERSISTENT-постоянный узел Если узел не удален вручную, он всегда существует в Zookeeper.
-
(2) EPHEMERAL-временный узел Жизненный цикл временной ноды привязан к сеансу клиента.Если сеанс клиента недействителен (отключение клиента от zookeeper не обязательно означает, что сеанс недействителен), то все временные узлы, созданные клиентом, будут удалить.
-
(3) PERSISTENT_SEQUENTIAL — постоянный узел последовательности Основные функции такие же, как и у постоянных узлов, но добавляется атрибут порядка, а к имени узла добавляется автоинкрементное целое число, поддерживаемое родительским узлом.
-
(4) EPHEMERAL_SEQUENTIAL-узел временной последовательности Основные функции такие же, как и у временных узлов, но добавлен атрибут последовательности.К имени узла будет добавлено целое число с автоинкрементом, поддерживаемое родительским узлом.
Механизм наблюдения Zookeeper - уведомление об изменении данных
-
Zookeeper позволяет клиенту зарегистрировать прослушиватель Watcher с Znode на сервере.Когда некоторые указанные события на сервере запускают этот Watcher, сервер отправит уведомление о событии указанному клиенту для реализации функции распределенного уведомления, а затем клиент Следите за Наблюдателем. Уведомляйте о состояниях и типах событий, чтобы вносить изменения в бизнес.
-
Рабочий механизм:
(1) Клиент регистрирует наблюдателя
(2) Наблюдатель за серверной обработкой
(3) Наблюдатель обратного вызова клиента
Сводка функций Наблюдателя
-
Одноразовый Будь то сервер или клиент, после запуска Watcher ZooKeeper удалит его из соответствующего хранилища. Такой дизайн эффективен для снижения нагрузки на сервер или для очень частого обновления узлов, сервер будет продолжать отправлять уведомления о событиях клиенту, независимо от того, является ли сеть очень большой.
-
Последовательное выполнение клиента Процесс обратного вызова клиентского Watcher представляет собой процесс последовательной синхронизации.
-
Легкий 3.1 Уведомление Watcher очень простое, оно только сообщает клиенту, что произошло событие, и не объясняет конкретное содержание события. 3.2 Когда клиент регистрирует Watcher на сервере, он не передает реальную объектную сущность Watcher клиента серверу, а только использует атрибут логического типа, чтобы пометить его в клиентском запросе.
-
событие наблюдателя асинхронно отправляет события уведомления наблюдателя с сервера клиенту асинхронны, есть проблема, разные клиенты и серверы обмениваются данными через сокеты, из-за задержки в сети или других факторов клиент прослушивает в момент сбоя Когда дело доходит до событие, потому что сам Zookeeper предоставляет гарантию упорядочения, то есть после того, как клиент прослушает событие, он поймет, что отслеживаемый им znode изменился. Поэтому мы не можем ожидать, что сможем отслеживать каждое изменение узла с помощью Zookeeper. Zookeeper может гарантировать только конечную согласованность, а не сильную согласованность.
-
Регистрация наблюдателя getData, exists, getChildren
-
Наблюдатель триггеров создает, удаляет, устанавливает данные
-
Когда клиент подключается к новому серверу, часы будут запускаться при любом событии сеанса. Когда соединение с сервером потеряно, часы не могут быть получены. И когда клиент повторно подключается, все ранее зарегистрированные часы будут зарегистрированы повторно, если это необходимо. Обычно это совершенно прозрачно. Существует только один особый случай, когда наблюдение может быть потеряно: существующее наблюдение за несозданным znode, если оно было создано во время отключения клиента и впоследствии удалено до подключения клиента, в этом случае событие наблюдения может быть потеряно.
Клиент регистрирует реализацию Watcher
-
(1) Вызвать три API getData()/getChildren()/exist() и передать объект Watcher
-
(2) Отметьте запрос запроса и инкапсулируйте Watcher в WatchRegistration.
-
(3) Инкапсулировать его в объект Packet и отправить серверу для отправки запроса
-
(4) После получения ответа от сервера зарегистрируйте Watcher в ZKWatcherManager для управления
-
(5) Запрос возвращается для завершения регистрации.
Реализация наблюдателя на стороне сервера
-
Сервер для наблюдения получает и магазины Получение запроса клиента, обработка запроса Surection, следует ли зарегистрировать наблюдателя, если требуемый узел канала узела и ServerCNXn (ServerCNXn представляет собой связывание клиента и сервер, чтобы достичь наблюдателя интерфейсов процессов, на этот раз можно рассматривать как объекты наблюдения) Хранится в Watchermanager Watchtable Go и Watch2Paths.
-
Триггер наблюдателя В качестве примера возьмем сервер, получающий запрос транзакции setData() для запуска события NodeDataChanged:
2.1 Инкапсуляция WatchedEvent Инкапсулировать статус уведомления (SyncConnected), тип события (NodeDataChanged) и путь узла в объект WatchedEvent.
2.2 Наблюдатель запросов Найти Watcher на основе пути к узлу из WatchTable
2.3 Не найдено означает, что ни один клиент не зарегистрировал Watcher на узле данных
2.4 Найдите, извлеките и удалите соответствующий Watcher из WatchTable и Watch2Paths (из этого видно, что Watcher одноразовый на стороне сервера, и при однократном срабатывании он будет невалидным)
-
Вызовите метод процесса, чтобы вызвать Watcher Процесс здесь в основном заключается в отправке уведомлений о событиях Watcher через TCP-соединение, соответствующее ServerCnxn.
Наблюдатель обратного вызова клиента
-
Клиентский поток SendThread получает уведомление о событии и передает его потоку EventThread для обратного вызова Наблюдателя.
-
Механизм Watcher клиента также является одноразовым, после срабатывания Watcher становится недействительным.
Механизм контроля разрешений ACL
-
УГО (Пользователь/Группа/Другие)
-
В настоящее время используется в файловых системах Linux/Unix, а также является наиболее широко используемым методом контроля разрешений. Это режим контроля разрешений файловой системы общего назначения.
-
ACL (список управления доступом) список управления доступом
-
Он включает в себя три аспекта:
-
Режим разрешения (схема) (1) IP: управление доступом на основе детализации IP-адресов (2) Дайджест: наиболее часто используемая конфигурация разрешений, аналогичная имени пользователя: пароль, используется для конфигурации разрешений, что позволяет легко различать разные приложения для управления разрешениями. (3) Мир: самый открытый метод управления разрешениями — это специальный режим дайджеста, в котором используется только один идентификатор разрешения «мир: любой». (4) Супер: Суперпользователь
-
Авторизованный объектАвторизованный объект относится к пользователю или указанному объекту, которому предоставлены полномочия, такие как IP-адрес или машинный свет.
-
Разрешение разрешений(1) CREATE: разрешение на создание узла данных, позволяющее авторизованным объектам создавать дочерние узлы в Znode. (2) DELETE: разрешение на удаление дочернего узла, позволяющее авторизованному объекту удалять дочерние узлы узла данных. (3) ЧТЕНИЕ: разрешение на чтение узла данных, позволяющее авторизованным объектам получать доступ к узлу данных и читать его содержимое данных или список дочерних узлов и т. д. (4) WRITE: полномочия обновления узла данных, позволяющие авторизованным объектам обновлять узел данных. (5) ADMIN: полномочия управления узлом данных, позволяющие авторизованным объектам выполнять операции настройки, связанные с ACL, на узле данных.
Chroot Properties.
-
После версии 3.2.0 добавлена функция Chroot, которая позволяет каждому клиенту устанавливать пространство имен для себя. Если клиент устанавливает Chroot, то клиент будет ограничен своим собственным пространством имен для сервера.
-
Установив Chroot, клиент может быть применен к поддереву сервера Zookeeper, что очень полезно для достижения взаимной изоляции между различными приложениями в сценариях, когда несколько приложений совместно используют Zookeeper в группе.
управление сессиями
-
Стратегия обмена ковшами: управлять аналогичными сеансами в том же блоке, чтобы зоофидер мог изолировать различные блоки для сеансов и равномерно обрабатывать один и тот же блок.
-
Принципы выделения: «Тайм-аут следующего пункта» для каждого сеанса (Expirtime)
-
Формула расчета:
ExpirationTime_ = currentTime + sessionTimeout
ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *
ExpirationInterval , ExpirationInterval — это интервал проверки тайм-аута сеанса Zookeeper, по умолчанию tickTime
роль сервера
-
Leader
(1) Единственный планировщик и обработчик запросов транзакций для обеспечения упорядоченности обработки транзакций кластера
(2) Планировщики различных сервисов в кластере
-
Follower
(1) необработанный клиентский сервер запросов на транзакцию перенаправляет запрос на транзакцию ведущему
(2) участвовать в голосовании предложений по заказу с транзакциями
(3) Участвовать в голосовании на выборах лидера
-
Observer
(1) Роль сервера, представленная после версии 3.0, улучшает возможности кластера по обработке транзакций, не влияя на возможности обработки транзакций кластера.
(2) Обработать нетранзакционный запрос клиента и перенаправить транзакционный запрос на ведущий сервер.
(3) Не участвовать в голосовании ни в какой форме.
Рабочий статус сервера под Zookeeper
-
У сервера есть четыре состояния: СМОТРЮ, СЛЕДУЮЩИЙ, ВЕДУЩИЙ, НАБЛЮДАЮЩИЙ.
(1) ИЩУ: Найдите статус лидера. Когда сервер находится в этом состоянии, он будет думать, что в текущем кластере нет лидера, поэтому ему необходимо войти в состояние выбора лидера.
(2) FOLLOWING: Статус ведомого. Указывает, что текущая роль сервера — Follower.
(3) LEADING: Статус лидера. Указывает, что текущая роль сервера — Лидер.
(4) НАБЛЮДЕНИЕ: состояние наблюдателя. Указывает, что текущая роль сервера — Наблюдатель.
синхронизация данных
-
После того, как весь кластер завершит выбор Лидера, Ученик (коллектив Коллоуера и Наблюдателя) возвращается на сервер Лидера. Когда сервер Learner захочет, чтобы сервер Leader завершил регистрацию, введите ссылку для синхронизации данных.
-
Процесс синхронизации данных: (все в виде передачи сообщений)
- Учащийся Зарегистрируйтесь в Ученике
- синхронизация данных
- подтверждение синхронизации
-
Синхронизация данных Zookeeker обычно делятся на четыре категории:
(1) Прямая дифференциальная синхронизация (DIFF-синхронизация)
(2) Сначала откат, а затем дифференцированная синхронизация (синхронизация TRUNC+DIFF)
(3) Только синхронизация отката (синхронизация TRUNC)
(4) Полная синхронизация (синхронизация SNAP)
-
Перед синхронизацией данных сервер Лидер завершит инициализацию синхронизации данных:
- peerLastZxid: извлечь lastZxid (последний ZXID, обработанный обучающим сервером) из сообщения ACKEPOCH, отправленного обучающим сервером во время регистрации.
- minCommittedLog: минимальный ZXID в очереди кэша предложений ведущего сервера commitLog.
- maxCommittedLog: максимальный ZXID в очереди кэша предложений ведущего сервера commitLog.
-
Прямая дифференциальная синхронизация (DIFF Sync) Сценарий: peerLastZxid находится между minCommittedLog и maxCommittedLog
-
Сначала откат, а затем дифференциальная синхронизация (синхронизация TRUNC+DIFF) Сценарий: когда новый ведущий сервер обнаруживает, что обучающий сервер содержит запись транзакции, которой у него нет, ему необходимо позволить обучающему серверу откатить транзакцию — вернуться к той, которая существует на ведущем сервере и также ближайший к peerLastZxid ZXID
-
Только синхронизация отката (синхронизация TRUNC) Сценарий: peerLastZxid больше, чем maxCommittedLog
-
Полная синхронизация (синхронизация SNAP) Сценарий 1: peerLastZxid меньше, чем minCommittedLog Сценарий 2: На сервере Leader нет очереди кэша предложений, а peerLastZxid не равен lastProcessZxid.
Как zookeeper должен обеспечить согласованность порядка транзакций?
- zookeeper использует глобальный инкрементный идентификатор транзакции для идентификации, все предложения (предложения) добавляются с zxid, когда они предлагаются, zxid на самом деле является 64-битным числом, а верхние 32 бита — это эпоха (период; эпоха; мир; новая эра). используется для идентификации цикла лидера.Если генерируется новый лидер, эпоха будет автоматически увеличиваться, а младшие 32 бита используются для увеличения счетчика. Когда создается новое предложение, оно сначала отправляет запрос на выполнение транзакции другим серверам в соответствии с двухэтапным процессом базы данных.Если более половины машин могут выполнить и выполнить успешно, тогда выполнение начнется.
Зачем в распределенном кластере главный узел?
- В распределенной среде некоторая бизнес-логика должна выполняться только определенной машиной в кластере, а другие машины могут совместно использовать результат, что может значительно сократить повторные вычисления и повысить производительность, поэтому требуется выбор лидера.
Как справиться с простоем узла zk?
-
Сам Zookeeper тоже является кластером, и рекомендуется настраивать не менее 3-х серверов. Сам Zookeeper также гарантирует, что, когда узел выйдет из строя, другие узлы продолжат предоставлять услуги.
-
Если подписчик выходит из строя, остается 2 сервера для предоставления доступа, потому что данные на Zookeeper имеют несколько копий, и данные не будут потеряны;
-
Если лидер идет вниз, зоокедра избирает новый лидер.
-
Механизм кластера ZK заключается в том, что пока более половины узлов работают нормально, кластер может нормально предоставлять услуги. Кластер выходит из строя только тогда, когда висит слишком много узлов ZK и работает только половина или меньше узлов.
так
- Кластер из 3 узлов может вывести из строя 1 узел (лидер может получить 2 голоса > 1,5)
- Кластер из 2 узлов не могут повесить любой 1 узел (лидер может получить 1 голос
Разница между балансировкой нагрузки zookeeper и балансировкой нагрузки nginx
- Балансировка нагрузки ZK может регулироваться, но NGINX может регулировать вес, другие потребности управляются необходимостью написания собственных плагинов; однако пропускная способность Nginx намного больше, чем Zk, следует сказать, что бизнес выбирают, какой способ использовать.
Каковы режимы развертывания Zookeeper?
- Zookeeper имеет три режима развертывания:
- Автономное развертывание: запуск на одном кластере;
- Развертывание кластера: работает несколько кластеров;
- Развертывание псевдокластера: кластер запускает несколько экземпляров Zookeeper.
Кластер хотя бы на несколько машин, правила кластеризации - это то, что? В кластере есть три сервера, один узел снижается, на этот раз зоокедра также может использовать его?
- Правило кластера — 2N+1 единиц, N>0, то есть 3 единицы. Его можно продолжать использовать, и единственный сервер может продолжать использоваться до тех пор, пока не будет отключено более половины серверов.
Поддерживает ли кластер динамическое добавление машин?
-
По сути, это горизонтальное расширение, и Zookeeper в этом плане не очень хорош. Два пути:
-
Перезапустить все: остановите все службы Zookeeper и запустите их после изменения конфигурации. Не влияет на предыдущие сеансы клиента.
-
Перезапускайте один за другим: в соответствии с принципом доступности более половины машин перезапуск машины не влияет на внешние службы, предоставляемые всем кластером. Это более распространенный способ.
-
Версия 3.5 поддерживает динамическое расширение.
Является ли уведомление Zookeeper о мониторинге часов постоянным для узлов? Почему не постоянный?
-
нет. Официальное заявление: событие наблюдения является одноразовым триггером.Когда данные, для которых установлено наблюдение, изменяются, сервер отправляет изменение клиентам, установившим наблюдение, чтобы уведомить их.
-
Почему это не постоянное?Например, если сервер часто меняется, а клиент мониторинга во многих случаях, каждое изменение должно быть уведомлено для всех клиентов, что оказывает большую нагрузку на сеть и сервер.
-
Как правило, клиент выполняет getData("/node A", true). Если узел A изменен или удален, клиент получит свое событие наблюдения, но затем узел A снова изменился, и клиент не установил его. событие watch больше не отправляется клиенту.
-
В практических приложениях во многих случаях нашему клиенту не нужно знать каждое изменение сервера, мне нужны только самые последние данные.
Что такое Java-клиенты Zookeeper?
- Клиент Java: zkclient, который поставляется с куратором с открытым исходным кодом zk и Apache.
Что такое пухленький, и как вы думаете, что это по сравнению с зоопарком?
- Chubby от Google, он полностью реализует алгоритм paxos и не имеет открытого исходного кода. zookeeper — это реализация Chubby с открытым исходным кодом, использующая протокол zab, вариант алгоритма paxos.
Произнесите несколько общих команд смотрителя зоопарка.
- Общие команды: ls get set create delete и т. д.
Связь и разница между алгоритмами ZAB и Paxos?
-
Тот же пункт:
(1) существует как роль, аналогичная процессу Лидер, который отвечает за координацию нескольких процессов, выполняющихся Последователем
(2) Процесс «Лидер» будет ждать, пока более половины подписчиков оставят правильный отзыв, прежде чем подавать предложение.
(3) В протоколе ZAB каждое Предложение содержит значение эпохи для представления текущего цикла Лидера, а имя в Paxos — «Бюллетень».
-
разница:
ZAB используется для создания высокодоступной распределенной системы мастеров и резервных копий данных (Zookeeper), а Paxos используется для создания распределенной согласованной системы конечных автоматов.
Типичные сценарии применения Zookeeper
-
ZOOKEEKER - это типичное представление о публикации / подписке, распределенных данных, разработчиков, разработчики могут использовать его для публикации и подписки распределенных данных.
-
Благодаря перекрестному использованию узлов богатых данных в Zookeeper и механизме уведомления о событиях Watcher очень удобно создавать ряд основных функций, которые будут задействованы в распределенных приложениях в середине года, например:
(1) Публикация/подписка на данные
(2) Балансировка нагрузки
(3) Служба имен
(4) Распределенная координация/уведомление
(5) Управление кластером
(6) Генеральные выборы
(7) распределенный замок
(8) Распределенная очередь
1 Данные публикуются/подписываются
вводить
- Система публикации/подписки на данные, так называемый центр конфигурации, как следует из названия, заключается в том, что издатели публикуют данные для подписки подписчиков.
Цель
- Получать данные динамически (информация о конфигурации)
- Реализовать централизованное управление данными (информация о конфигурации) и динамическое обновление данных
Шаблоны проектирования
- Push-режим
- Режим вытягивания
Свойства данных (информация о конфигурации)
(1) количество данных обычно мало (2) содержимое данных, динамически во время обновления времени выполнения произойдет (3) Каждый кластер Shared Machine, сконфигурированный с тем же
- Например: информация о списке машин, конфигурация переключателя времени выполнения, информация о конфигурации базы данных и т. д.
Реализация на базе Zookeeper
- Хранение данных: храните данные (информацию о конфигурации) в узле данных на Zookeeper.
- Сбор данных: приложение считывает данные из узла данных Zookeeper на узле инициализации запуска и регистрирует наблюдатель за изменением данных на узле.
- Изменение данных: при изменении данных обновите данные узла, соответствующие Zookeeper, Zookeeper отправит уведомление об изменении данных каждому клиенту, и клиент сможет повторно прочитать измененные данные после получения уведомления.
2 балансировка нагрузки
- служба именования zk
- Служба именования относится к получению адреса ресурса или службы по указанному имени и использованию zk для создания глобального пути, этот путь можно использовать в качестве имени для указания на кластер в кластере, адрес предоставленной службы, или удаленный объект и т. д. Подождите.
Распределенное уведомление и координация
-
Для системного планирования: оператор отправляет уведомление о фактическом изменении состояния узла через консоль, а затем zk рассылает эти изменения всем клиентам, зарегистрированным в наблюдателе этого узла.
-
Для подведения итогов выполнения: каждый рабочий процесс создает временный узел в некотором каталоге. И переносите данные о ходе работы, чтобы агрегированный процесс мог отслеживать изменения подузлов каталога, чтобы получать глобальную ситуацию о ходе работы в реальном времени.
служба именования zk (файловая система)
- Служба именования относится к получению адреса ресурса или услуги по указанному имени, и использование ZK для создания глобального пути, то есть уникальный путь, этот путь можно использовать в качестве имени, чтобы указать на кластер в кластере и Укажите адрес службы. Или удаленный объект и так далее.
управление конфигурацией zk (механизм уведомления файловой системы)
- Программа распространяется на разных машинах, и информация о конфигурации программы размещается под znode zk.При изменении конфигурации, то есть при изменении znode, вы можете изменить содержимое узла каталога в zk, чтобы использовать watcher уведомляет каждого клиента об изменении конфигурации.
Управление кластером Zookeeper (файловая система, механизм уведомлений)
-
Так называемое управление кластером не заботится о двух моментах: есть ли машины, выходящие и присоединяющиеся, и выбор мастера.
-
Во-первых, все машины соглашаются создать узел временного каталога в родительском каталоге, а затем прослушивать узел родительского каталога.
-
сообщение об изменении дочернего узла. Как только машина умирает, машина отключается от zookeeper, созданный ею временный узел каталога удаляется, а все остальные машины уведомляются: родственный каталог удаляется, поэтому все знают: он находится на борту.
-
Присоединение новых машин похоже. Все машины уведомляются: добавляется новый каталог Sibling, а высокий доступ снова. Для второго значения мы внесите небольшое изменение. Все машины создают временные последовательные узлы номера, и каждый раз Машина с наименьшим числом выбрана как хозяин просто отлично.
Zookeeper распределенный замок (файловая система, механизм уведомлений)
-
Благодаря согласованной файловой системе zookeeper проблемы с блокировкой упрощаются. Службы блокировки можно разделить на две категории: одна предназначена для сохранения эксклюзивности, а другая — для контроля времени.
-
Для первой категории мы рассматриваем znode на zookeeper как блокировку, которая реализуется путем создания znode. Все клиенты создают узел /distribute_lock, и успешно созданный клиент в конечном итоге становится владельцем блокировки. После израсходования удалите созданный вами узел распределения_блокировки и снимите блокировку.
-
Для второго типа /distribute_lock уже существует заранее, и все клиенты создают под ним временные последовательно пронумерованные узлы каталога, так же, как и при выборе master, получается блокировка с наименьшим номером, и ее удобно удалять по мере использования. .
Управление очередью Zookeeper (файловая система, механизм уведомлений)
-
Два типа очередей:
(1) Синхронная очередь, когда все члены очереди собраны, очередь доступна, в противном случае она ожидает прибытия всех участников. (2) Очередь ставится в очередь и удаляется из нее в порядке FIFO.
-
Первая категория заключается в создании временного узла каталога в согласованном каталоге и отслеживании того, соответствует ли количество узлов требуемому количеству.
-
Второй тип согласуется с основным принципом сцены управляющей последовательности в службе распределенной блокировки. Создайте узел PERSISTENT_SEQUENTIAL в определенном каталоге. Когда создание будет успешным, Watcher уведомит ожидающую очередь, и очередь удалит узел с наименьшим порядковым номером для использования. В этом сценарии znode Zookeeper используется для хранения сообщений.Данные, хранящиеся в znode, представляют собой содержимое сообщения в очереди сообщений, а SEQUENTIAL порядковый номер — это номер сообщения, который может быть получен последовательно. Поскольку созданный узел является постоянным, не нужно беспокоиться о потере сообщений очереди.
Каковы функции Zookeeper?
-
Управление кластером: отслеживайте статус выживания узла, выполняющиеся запросы и т. д.;
-
Выбор главного узла: после того, как главный узел повесит трубку, с резервного узла можно начать новый раунд выборов главного узла.Выбор главного узла относится к процессу выбора, и Zookeeper может использоваться для помощи в этом процессе;
-
Распределенные блокировки: Zookeeper предоставляет два типа блокировок: эксклюзивные блокировки и общие блокировки. Исключительная блокировка означает, что только один поток может одновременно использовать ресурс.Общая блокировка разделяется блокировками чтения, а чтение и запись являются взаимоисключающими, то есть несколько потоков могут читать один и тот же ресурс одновременно. должна использоваться блокировка записи, ее может использовать только один поток. Zookeeper может управлять распределенными блокировками.
-
Служба именования: в распределенной системе, используя службу именования, клиентские приложения могут получить информацию, поставщики и т. Д. Ресурс или услуг в соответствии с указанным именем.
Zookeeper говорит о механизме уведомления?
- Клиентская сторона установит событие наблюдателя для znode.Когда znode изменится, эти клиенты получат уведомление zk, а затем клиент сможет внести бизнес-изменения в соответствии с изменениями znode.
Отношения между Zookeeper и Dubbo?
-
Роль смотрителя зоопарка: Zookeeper используется для регистрации сервисов и выполнения балансировки нагрузки.Какая служба предоставляется на какой машине должно быть известно звонящему.Проще говоря,это соответствие между ip адресом и именем службы. Конечно, это соответствие может быть реализовано и в бизнес-коде вызывающей стороны путем жесткого кодирования, но если машина, предоставляющая услугу, выйдет из строя, вызывающая сторона не может этого знать, и если код не будет изменен, она продолжит запрашивать неисправную машина для оказания услуг. Zookeeper может обнаружить зависшую машину через механизм сердцебиения и удалить из списка соответствующую связь между ip и службой зависшей машины. Что касается поддержки high concurrency, то это просто горизонтальное расширение, а вычислительная мощность увеличивается за счет добавления машин без изменения кода. При добавлении новых машин для регистрации услуг в zookeeper, чем больше поставщиков услуг, тем больше клиентов они могут обслуживать.
-
даббо: Это инструмент для управления средним уровнем.Существует множество доступов к службам и поставщиков услуг, которые необходимо запланировать между бизнес-уровнем и хранилищем данных.Dubbo предоставляет основу для решения этой проблемы.
Обратите внимание, что даббо здесь — это всего лишь рама, а то, что вы поставите на полку, полностью зависит от вас, как и скелет автомобиля, вам нужно соответствовать вашему колесному двигателю. Чтобы завершить планирование в этой структуре, должен быть распределенный реестр для хранения метаданных всех сервисов.Вы можете использовать zk или другие, но все используют zk. -
Отношения ZooKeeper и Dubbo: Реферат Dubbo, который можно взять в реестр, предоставляющий услуги реестра, ZooKeeper, Memcached, Redis и т.д.
Внедрение ZooKeeper в качестве носителя данных также знакомит с функциями ZooKeeper. Во-первых, это балансировка нагрузки.Грузоподъемность одного центра регистрации ограничена.Когда трафик достигает определенного уровня, его необходимо распределять.Балансировка нагрузки существует для целей распределения.Группа ZooKeeper может легко добиться балансировки нагрузки с помощью соответствующее веб-приложение. ;Синхронизация ресурсов, балансировка нагрузки сами по себе недостаточны, данные и ресурсы между узлами должны быть синхронизированы, и кластер ZooKeeper, естественно, имеет такую функцию; служба именования, древовидная структура используется для ведения глобального списка адресов службы , сервис-провайдеры. При запуске введите свой собственный URL-адрес в каталог /dubbo/${serviceName}/providers указанного узла в ZooKeeper, и эта операция завершит выпуск службы. Другие функции включают выбор мачты, распределенные блокировки и т. д.