Вопрос: Один сервисный сервер, одна база данных, операция: запрос текущего баланса пользователя, вычитание 3% текущего баланса в качестве комиссии за обработку
синхронизировано
замок
Блокировка DB
Вопрос: Два сервисных сервера, одна база данных, операция: запрос текущего баланса пользователя, вычитание 3% текущего баланса в качестве комиссии за обработку
Распределённые шлюзы
Какой распределённый замок нам нужен?
Он может гарантировать, что в распределённом кластере приложений один и тот же метод может выполняться только одним потоком на одной машине одновременно.
Если этот замок — реинтрантный замок (избегайте тупиковых замков)
Этот замок лучше всего использовать блокирующий замок (подумайте, хотите ли вы его в соответствии с потребностями вашего бизнеса).
Этот замок лучше всего иметь справедливый замок (подумайте, хотите ли вы его или нет в зависимости от потребностей бизнеса).
Доступны очень доступные функции захвата и блокировки
Производительность замков захвата и освобождения стала лучше.
1. Распределённые блокировки на базе данных
Распределённые блокировки на основе реализаций на основе таблиц
Когда мы хотим заблокировать метод, выполняем следующий SQL:
вставить в methodLock(method_name,desc) значения ('method_name','desc')
Поскольку мы установили ограничение на уникальность method_name, если одновременно в базу данных отправляется несколько запросов, база данных гарантирует, что успешна только одна операция, тогда можно предположить, что поток, успешно получивший метод, заблокирует и сможет выполнить содержимое тела метода.
Когда метод выполняется, если вы хотите снять блокировку, необходимо выполнить следующий SQL:
удалить из methodLock, где method_name ='method_name'
Эта простая реализация выше имеет следующие проблемы:
- Эта блокировка зависит от доступности базы данных, которая представляет собой одну точку и приводит к тому, что бизнес-система станет недоступной после завершения базы данных.
- У этого блокировки нет срока истечения, и после неудачи операции разблокировки запись блокировки останется в базе данных, и другие потоки больше не смогут получить блокировку.
- Эта блокировка может быть неблокирующей только потому, что операция вставки данных напрямую сообщает об ошибке после неудачи вставки. Потоки, не получающие блокировки, не попадут в очередь и должны запустить операцию захвата блокировки заново, чтобы получить блокировку заново.
- Блокировка не входит в себя, и тот же поток не может получить замок снова, пока он не будет освобождён. Потому что данные в данных уже существуют.
- Этот замок несправедливый, и все нити, ожидающие замка, конкурируют за него по удаче.
Конечно, мы можем решить вышеуказанные проблемы и другими способами.
- Является ли база данных одной точкой? Создайте две базы данных, и данные будут синхронизированы в обоих направлениях. После того как повесите трубку, быстро переключитесь на резервную библиотеку.
- Нет срока годности? Просто выполняйте запланированную задачу, чтобы регулярно очищать данные тайм-аута в базе данных.
- Не блокируя? Повторяйте некоторое время, пока вставка не получится, а затем результат не вернётся.
- Нереинтрант? Добавьте поле в таблицу базы данных для записи информации о хосте и потоке машины, которая в данный момент получает блокировку, затем в следующий раз, когда получите блокировку, сначала запросите базу данных — если информация о хосте и потоке текущей машины найдётся в базе, вы можете напрямую назначить блокировку ему.
- Несправедливо? Создайте ещё одну промежуточную таблицу для записи всех потоков, ожидающих блокировки, и отсортируйте их по времени создания, и только первый созданный может получить замок
Распределённые замки на основе эксклюзивных замков
Помимо добавления и удаления записей в таблице данных, распределённые блокировки также могут быть реализованы с помощью блокировок, входящих в комплект с данными.
Мы также используем только что созданную таблицу базы данных. Распределённые блокировки могут быть реализованы через эксклюзивные блокировки баз данных. Движок InnoDB на базе MySQL может использовать следующие методы для реализации операций блокировки:
Если добавить для обновления после запроса, база данных добавит эксклюзивную блокировку в таблице базы данных во время запроса. Когда в запись добавляется эксклюзивная блокировка, другие потоки больше не могут добавить эксклюзивный блок в запись на этой линии.
Можно предположить, что поток, получивший эксклюзивный замок, может получить распределённый замок, и когда блокировка получена, бизнес-логика метода может быть выполнена, а затем разблокирована с помощью следующих методов:
публичный разблокировка пустоты(){ connection.commit(); }
через connection.commit(); Операция по снятию замка.
Этот метод эффективно решает вышеупомянутые проблемы невозможности снять замок и заблокировать замок.
Блокировать замки? Оператор for update возвращается сразу после успешного выполнения и остаётся заблокированным до успешного завершения.
Служба отключена после блокировки, нельзя отпустить? Таким образом, база данных сама освобождает блокировку после отключения сервиса.
Однако это по-прежнему напрямую не решает проблему одиночной точки базы данных, реинтрантности и справедливого замка.
Кратко описывая способ использования базы данных для реализации распределённых блокировок, обе из которых зависят от таблицы в базе данных: один — определить наличие блокировки по наличию записей в таблице, а другой — реализовать распределённые блокировки через эксклюзивную блокировку базы данных.
Преимущества распределённого блокировки в базах данных
С помощью базы данных это легко понять.
Недостатки внедрения распределённых блокировок в базах данных
Будут возникать различные задачи, и всё решение становится всё более сложным в процессе их решения.
Работа с базой данных требует определённых накладных расходов, и необходимо учитывать вопросы производительности.
2. Распределённые блокировки на основе кэша
По сравнению с распределённым решением для блокировки на базе данных, реализация на основе кэша будет работать лучше по производительности.
В настоящее время существует множество зрелых кэшированных продуктов, включая Redis, memcached и др. Здесь приводим Redis в качестве примера для анализа схемы использования кэша для реализации распределённых блокировок.
В Интернете существует множество связанных статей о реализации распределённых блокировок на базе Redis, и основной метод реализации — использование метода Jedis.setNX.
Существует также несколько проблем с приведённой выше реализацией:
1. Задача с одним очком.
2. У этого блокировки нет срока действия, после неудачи операции разблокировки запись блокировки будет постоянно находиться в redis, и другие потоки больше не смогут получить блокировку.
3. Этот замок может быть только неблокирующим и возвращается напрямую, независимо от успеха или неудачи.
4. Этот замок не входит, после того как нить, полученная в замке, она не может получить замок снова, прежде чем освободить замок, потому что используемый ключ уже существует в redis. операции setNX больше не могут выполняться.
5. Эта блокировка несправедлива, все ожидающие потоки запускают операции setNX одновременно, и счастливые потоки могут получить блокировку.
Конечно, есть и способы её решить.
- В настоящее время основные сервисы кэширования поддерживают развертывание кластеров для решения задач с одной точкой с помощью кластеризации.
- Нет срока годности? Метод setExpire в Redis поддерживает входящее время истечения, и данные автоматически удаляются после этого времени.
- Не блокируя? в то время как его многократно казняли.
- Разве нельзя снова войти? После того как поток получит блокировку, сохраните актуальную информацию о хосте и потоке, а также проверьте, являетесь ли вы владельцем текущего замка, прежде чем получить его в следующий раз.
- Несправедливо? Поместите все ожидающие потоки в очередь до того, как поток получит блокировку, а затем приобретайте замок по принципу «первым пришёл — первым ушёл».
Политика синхронизации кластера redis занимает время, и возможно, что поток A получает блокировку после успешной установки NX, но это значение не обновляется на сервере, где поток B запускает setNX, что вызовет проблемы с параллельностью.
Сальваторе Санфилиппо, автор redis, предложил алгоритм Redlock, реализующий распределённое управление блокировками (DLM), более безопасный и надёжный, чем один узел.
Алгоритм Redlock предполагает, что существует N узлов Redis, независимых друг от друга, обычно установленных как N=5, и эти N узлов работают на разных машинах для сохранения физической независимости.
Шаги алгоритма следующие:
1. Клиент получает текущее время в миллисекундах.
2. Клиент пытается получить блокировку из N узлов (каждый узел получает блокировку так же, как и блокировка кэша, упомянутая ранее), и N узлов получают блокировку с тем же ключом и значением. Клиенту нужно установить тайм-аут доступа к интерфейсу, и время тайм-аута интерфейса должно быть значительно меньше тайм-аута блокировки, например, время автоматического освобождения блокировки составляет 10 секунд, тогда тайм-аут интерфейса устанавливается примерно на 5-50 мс. Это позволяет как можно быстрее использовать тайм-аут при доступе к узлу redis после его отключения и уменьшает обычное использование замка.
3. Клиент вычисляет, сколько времени требуется для получения замка, вычитая время, полученное на шаге 1, к текущему времени, только когда клиент получает более 3 узлов блокировки, а время на получение замка меньше времени тайм-аута замка, клиент получает распределённый замок.
4. Время клиента на получение замка — это установленное время блокировки минус время, затраченное на получение замка, рассчитанное на шаге 3.
5. Если клиенту не удаётся получить блокировку, он удалит все блокировки по очереди.
Используя алгоритм Redlock, можно гарантировать, что распределённый сервис блокировки сможет работать даже при подключении до двух узлов, что значительно повышает доступность по сравнению с предыдущими блокировками базы данных и блокировкой кэша.
Однако распределённый эксперт написал статью «Как сделать распределённое блокирование», ставя под сомнение правильность Redlock.
Эксперт отметил, что при рассмотрении распределённых замков есть два аспекта: производительность и корректность.
Если вы используете высокопроизводительный распределённый замок и правильность не требуется, то кэш-блокировка вполне достаточна.
Если вы используете высоконадёжный распределённый замок, нужно учитывать строгие вопросы надёжности. Redlock, напротив, не соответствует требованиям. Почему бы нет? Эксперты перечисляют несколько аспектов.
В настоящее время многие языки программирования используют виртуальные машины с функциями GC, в Full GC программа останавливается с обработкой GC, иногда Full GC занимает много времени, и даже программа имеет несколько минут задержки, в статье приводится пример HBase, HBase, иногда GC на несколько минут, что приводит к тайм-ауту аренды. Например, на рисунке ниже клиент 1 получает блокировку и собирается обработать общий ресурс, а когда он собирается обработать общий ресурс, Full GC действует до истечения срока блокировки. Таким образом, клиент 2 снова получает блокировку и начинает работать с общим ресурсом. Когда клиент 2 обрабатывает, клиент 1 завершает полный GC и начинает обрабатывать общие ресурсы, так что оба клиента обрабатывают общие ресурсы.
Эксперты предложили решение, как показано на рисунке ниже: это похоже на MVCC: приведите токен к блокировке, токен — это концепция версии, каждый раз после завершения операции блокировки токен добавляется 1, при обработке общих ресурсов токен, только указанная версия токена может обработать общий ресурс.
Эксперт также отметил, что алгоритм опирается на локальное время, а Redis использует метод getTimeOfDay для определения времени вместо монотонного часа при обработке срока действия ключа, что также приводит к временным неточностям. Например, в сценарии два клиента 1 и клиент 2 имеют 5 redis узлов (A, B, C, D и E).
1. Клиент 1 успешно получает блокировку от A, B и C и получает тайм-аут блокировки от D и E.
2. Тактовый сигнал узла C неточен, что приводит к тайм-ауту блокировки.
3. клиент 2 успешно получает блокировку от C, D и E и получает тайм-аут блокировки от A и B.
4. Таким образом, и клиент 1, и клиент 2 получают блокировку.
Подытоживая два момента, которые выдвигают эксперты относительно недоступности Редлока:
1. GC и другие сценарии могут возникнуть в любой момент, что приводит к получению блокировки клиентом, а тайм-аут обработки приводит к получению блокировки другого клиента. Эксперты также предложили решение для использования самоувеличивающихся токенов.
2. Алгоритм опирается на локальное время, и часы будут неточными, в результате чего два клиента получают блокировки одновременно.
Таким образом, эксперты делают вывод, что Redlock может работать нормально только при ограниченном сетевом задержке, ограниченном прерывании программы и ограниченном диапазоне ошибок тактового сигнала, но границы этих трёх сценариев не могут быть подтверждены, поэтому эксперты не рекомендуют использовать Redlock. Для сценариев с высокими требованиями к корректности эксперты рекомендуют Zookeeper, о котором позже будет рассмотрено использование Zookeeper как распределённого замка.
Ответ автора Redis
Автор Redis ответил, написав блог после просмотра статьи эксперта. Автор вежливо поблагодарил эксперта, а затем выразил несогласие с его мнением.
Обсуждение автором REDIS использования токенов для решения проблемы тайм-аута блокировки можно резюмировать в следующих пяти пунктах:
Пункт 1: использование распределённых блокировок обычно сводится к тому, что у вас нет другого способа контроля общих ресурсов, эксперты используют токены для обеспечения обработки общих ресурсов, тогда распределённые блокировки не нужны.
Пункт 2: Для генерации токенов, чтобы обеспечить надёжность токенов, полученных разными клиентами, сервис, генерирующий токены, всё равно необходимы распределённые блокировки для обеспечения надёжности сервиса.
Пункт 3: по словам экспертов, что самоувеличивающиеся токены — автор redis считает, что это совершенно не нужно: каждый клиент может сгенерировать уникальный UUID в виде токена и установить общий ресурс в состояние, которое может обработать только клиент с uuid, чтобы другие клиенты не могли обработать общий ресурс, пока клиент, получивший блокировку, не освободит блокировку.
Как показано на рисунке выше, если клиент токена 34 отправляет GC во время процесса записи и вызывает тайм-аут блокировки, другой клиент может получить блокировку токена 35 и начать запись заново, что приведёт к конфликту блокировок. Поэтому порядок токенов нельзя комбинировать с общими ресурсами.
Пункт 5, автор Redis считает, что в большинстве сценариев распределённые блокировки используются для решения проблем обновления в нетранзакционных ситуациях. Автор должен иметь в виду, что есть ситуации, когда сложно комбинировать токены для общих ресурсов, поэтому приходится полагаться на блокировки и обработку ресурсов.
Ещё одна проблема с часами, о которой говорят эксперты, — авторы Redis тоже дают объяснение. Если время, необходимое для получения замка, слишком долгое и превышает стандартное время тайм-аута, клиент не может получить замок в данный момент, и эксперты не приведут примеров.
Личные чувства
Первая проблема, которую я обобщаю, заключается в том, что после получения распределённой блокировки клиентом блокировка может быть снята после тайм-аута во время обработки клиентом. Ранее, когда речь шла о тайм-ауте, установленном блокировкой базы данных в 2 минуты, если задача занимает блокировку ордера более 2 минут, другой торговый центр может получить этот блокировочный блок, чтобы оба торговых центра могли одновременно обрабатывать один и тот же ордер. В обычных условиях задача обрабатывается за секунды, но иногда тайм-аут, установленный при присоединении к RPC-запросу, слишком длинный, и таких запросов в задаче много, тогда, скорее всего, автоматическое время разблокировки будет превышено. Если мы пишем на Java, то в центре может быть полный GC, поэтому после разблокировки блокировки клиент не может его воспринимать, что очень серьёзно. Я не думаю, что проблема в самом замке, если любой вышеупомянутый распределённый замок обладает характеристиками тайм-аута, такая проблема возникнет. Если вы используете функцию блокировки, клиент должен установить тайм-аут и принять соответствующие меры, вместо того чтобы продолжать обрабатывать общий ресурс. Алгоритм Redlock возвращает время блокировки, которое клиент может занять после получения блокировки, и клиент должен обработать это время, чтобы остановить задачу после этого времени.
Вторая проблема в том, что распределённые эксперты не понимают Redlock. Ключевая особенность Redlock заключается в том, что время на получение замка — это общее время, когда замок по умолчанию устанавливает тайм-аут, минус время, необходимое для его получения, так что время, необходимое клиенту на обработку, соответствует относительному времени, независимо от местного времени.
С этой точки зрения, правильность Redlock может быть полностью гарантирована. При тщательном анализе Redlock по сравнению с redis узла главной особенностью Redlock является повышенная надёжность, что является важной особенностью в некоторых случаях. Но, по-моему, Redlock потратила слишком много денег, чтобы добиться надёжности.
- Во-первых, необходимо развернуть 5 узлов, чтобы сделать Redlock более надёжным.
- Затем нужно запросить 5 узлов, чтобы получить блокировку, и с помощью метода Future можно сначала запросить 5 узлов одновременно, а затем получить результат ответа, что может сократить время отклика, но всё равно занимает больше времени, чем блокировка redis с одним узлом.
- Затем, поскольку необходимо получить более 3 из 5 узлов, может возникнуть конфликт замков, то есть у всех 1-2 замка, и в результате никто не может получить замок, эту проблему автор Redis заимствует суть алгоритма плота: через случайное столкновение время конфликта можно значительно сократить, но эту проблему невозможно избежать, особенно если замок получается впервые, и стоимость времени на получение замка увеличивается.
- Если 2 из 5 узлов не работают, доступность блокировки значительно сократится, во-первых, нужно дождаться окончания результатов этих двух погибших узлов, прежде чем вернуться, а узлов всего 3, и клиент должен получить блокировки всех трёх узлов, что тоже сложнее.
- Если есть сетевой раздел, то может возникнуть ситуация, когда клиент никогда не сможет получить блокировку.
После анализа множества причин я считаю, что самый критический момент проблемы Redlock — это то, что Redlock требует от клиентов обеспечивать согласованность записей, а бэкенд-5 узлов полностью независимы, и все клиенты должны управлять этими 5 узлами. Если лидер есть среди 5 узлов, клиент может синхронизировать данные лидера, пока клиент получает блокировку от лидера, чтобы избежать проблем с разбиением, тайм-аутом и конфликтами. Поэтому, чтобы обеспечить корректность распределённых блокировок, я считаю, что использование распределённого координационного сервиса с высокой согласованностью может лучше решить проблему.
Снова возникает вопрос: сколько времени нужно установить срок годности? Как установить время отмены, слишком коротко, и блокировка автоматически освобождается до запуска метода, тогда возникают проблемы с параллельностью. Если это займёт слишком много времени, другие резьбы, которые фиксируют блокировку, могут подождать долго.
Эта проблема также возникает при использовании баз данных для реализации распределённых блокировок.
Современный основной подход к этой проблеме — устанавливать короткое время тайм-аута для каждого полученного блокировки и запускать поток для обновления времени блокировки каждый раз, когда он приближается к этому времени. Заканчивайте эту тему одновременно с отпусканием замка. Например, Redisson, официальный компонент распределённого блокировки Redis, использует это решение.
Преимущества использования кэширования для реализации распределённых блокировок
Хорошая игра.
Недостатки использования кэширования для реализации распределённых блокировок
Реализация слишком ответственна, слишком много факторов, которые нужно учитывать.
Распределённые замки на основе реализации Zookeeper
Распределённые замки на основе временно упорядоченных узлов Zookeeper.
Общая идея такова: когда каждый клиент блокирует метод, в каталоге указанного узла, соответствующего методу на zookeeper, генерируется уникальный мгновенно упорядоченный узел. Способ определить, стоит ли получить замок, достаточно определить тот, у кого самый маленький серийный номер в упорядочённом узле. Когда блокировка снята, просто удалите мгновенный узел. В то же время это позволяет избежать проблемы блокировок, вызванных простоями сервиса, которые нельзя отпустить.
Посмотрим, сможет ли Zookeeper решить упомянутые выше проблемы.
- Замок не отпускается? Использование Zookeeper эффективно решает проблему неосвобождения блокировок, потому что при создании блокировки клиент создаёт временный узел в ZK, и как только клиент получает блокировку и внезапно его отключает (сессионное соединение разрывается), временный узел автоматически удаляется. Другие клиенты могут снова получить замок.
- Неблокирующие замки? После изменения узла Zookeeper уведомляет клиента, и клиент может проверить, является ли созданный им узел самым маленьким порядковым номером среди всех узлов.
- Не можешь войти снова? Когда клиент создаёт узел, он напрямую записывает информацию о хосте и потоке текущего клиента в узел, и в следующий раз, когда вы хотите получить блокировку, вы можете сравнить его с данными текущего самого маленького узла. Если информация совпадает с вашей, вы можете напрямую получить замок, а если он отличается — создать временный последовательный узел для участия в очереди.
Снова возникает вопрос: мы знаем, что Zookeeper нужно внедрять в кластерах, будут ли проблемы с синхронизацией данных, как в кластерах Redis?
Zookeeper — это распределённый компонент, который гарантирует слабую согласованность, то есть в конечном итоге согласованность.
Zookeeper использует протокол синхронизации данных, называемый Quorum Based Protocol. Если в кластере Zookeeper есть N серверов Zookeeper (N обычно нечетный, 3 могут соответствовать надёжности данных и обладают высокой производительностью чтения и записи, а 5 имеют лучший баланс между надёжностью данных и производительностью чтения/записи), то операция записи пользователя сначала синхронизируется с серверами N/2 + 1, а затем возвращается пользователю, что побуждает пользователя успешно записать. Протокол синхронизации данных, основанный на Протоколе Кворума, определяет согласованность мощности, которую может поддерживать Zookeeper.
В распределённой среде хранилище данных, соответствующее высокой согласованности, практически отсутствует, и при обновлении данных одного узла требуется, чтобы все узлы обновлялись синхронно. Эта стратегия синхронизации встречается в базе данных синхронной репликации мастер-слейв. Однако такая стратегия синхронизации слишком сильно влияет на производительность записи и редко встречается на практике. Поскольку Zookeeper записывает узлы N/2+1 синхронно, а N/2 не обновляются синхронно, Zookeeper не является строго согласованным.
Операция обновления данных пользователя не гарантирует, что последующие чтения прочитают обновленное значение, но в конечном итоге покажет согласованность. Жертва согласованности не означает полного игнорирования согласованности данных, иначе данные становятся хаотичными, поэтому независимо от высокой доступности системы, каким бы хорошим ни было распределение, это не имеет ценности. Жертва согласованностью — это просто то, что сильная согласованность в реляционных базах данных больше не требуется, но при условии, что система сможет достичь её в конечном итоге.
Вопрос на один пункт? Использование Zookeeper эффективно решает задачу одной точки: ZK развёртывается кластерами, пока выживают более половины машин в кластере, сервис может быть предоставлен внешнему миру.
Проблемы справедливости? Использование Zookeeper позволяет решить проблему справедливых замков: временные узлы, созданные клиентом в ZK, работают упорядочено, и каждый раз при освобождении замка ZK может уведомлять самый маленький узел о получении блокировки, обеспечивая справедливость.
Снова возникает вопрос: мы знаем, что Zookeeper нужно внедрять в кластерах, будут ли проблемы с синхронизацией данных, как в кластерах Redis?
Zookeeper — это распределённый компонент, который гарантирует слабую согласованность, то есть в конечном итоге согласованность.
Zookeeper использует протокол синхронизации данных, называемый Quorum Based Protocol. Если в кластере Zookeeper есть N серверов Zookeeper (N обычно нечетный, 3 могут соответствовать надёжности данных и обладают высокой производительностью чтения и записи, а 5 имеют лучший баланс между надёжностью данных и производительностью чтения/записи), то операция записи пользователя сначала синхронизируется с серверами N/2 + 1, а затем возвращается пользователю, что побуждает пользователя успешно записать. Протокол синхронизации данных, основанный на Протоколе Кворума, определяет согласованность мощности, которую может поддерживать Zookeeper.
В распределённой среде хранилище данных, соответствующее высокой согласованности, практически отсутствует, и при обновлении данных одного узла требуется, чтобы все узлы обновлялись синхронно. Эта стратегия синхронизации встречается в базе данных синхронной репликации мастер-слейв. Однако такая стратегия синхронизации слишком сильно влияет на производительность записи и редко встречается на практике. Поскольку Zookeeper записывает узлы N/2+1 синхронно, а N/2 не обновляются синхронно, Zookeeper не является строго согласованным.
Операция обновления данных пользователя не гарантирует, что последующие чтения прочитают обновленное значение, но в конечном итоге покажет согласованность. Жертва согласованности не означает полного игнорирования согласованности данных, иначе данные становятся хаотичными, поэтому независимо от высокой доступности системы, каким бы хорошим ни было распределение, это не имеет ценности. Жертва согласованностью — это просто то, что сильная согласованность в реляционных базах данных больше не требуется, но при условии, что система сможет достичь её в конечном итоге.
Соответствует ли Zookeeper причинно-следственной согласованности, зависит от того, как запрограммирован клиент.
Практики, не удовлетворяющие причинной последовательности
- Процесс A записывает данные в /z Zookeeper и успешно возвращает
- Процесс A информирует процесс B, что A изменил данные /z
- B считывает данные Zookeeper /z
- Поскольку сервер смотрителя зоопарка, подключённый к B, возможно, не был обновлён письменными данными A, то B не сможет прочитать письменные данные A
Практики, соответствующие причинно-следственной согласованности
- Процесс B отслеживает изменения данных в /z на Zookeeper
- Процесс A записывает данные в /z Zookeeper, и прежде чем он успешно вернутся, Zookeeper должен позвонить слушателю, зарегистрированному на /z, и лидер уведомит B об изменении данных
- После того как метод ответа на событие в процессе B, он принимает изменённые данные, так что B точно сможет получить изменённое значение
- Причинная согласованность здесь относится к причинно-следственной согласованности между лидером и B, то есть лидер уведомляет данные об изменении
Второй механизм прослушивания событий также является методом, который следует использовать для правильного программирования Zookeeper, поэтому Zookeeper должен соответствовать причинно-следственной согласованности
Поэтому, когда мы реализуем распределённые блокировки на базе Zookeeper, следует использовать практику удовлетворения причинно-следственной согласованности, то есть потоки, ожидающие блокировки, слушают изменения в блокировке Zookeeper, и когда замок освобождается, Zookeeper уведомляет ожидающий поток, который соответствует условиям справедливого замка.
Вы можете использовать напрямую сторонний клиент библиотеки Zookeeper, который инкапсулирует сервис реэнтрантного блокировки.
Распределённые блокировки, реализованные в ZK, кажутся именно тем, что мы ожидали от распределённого блокировки в начале этой статьи. Однако это не так, и распределённая блокировка, реализованная Zookeeper, на самом деле имеет недостаток — производительность может быть ниже, чем у кэширующего сервиса. Потому что каждый раз в процессе создания и освобождения блокировки мгновенные узлы должны быть динамически созданы и уничтожены, чтобы реализовать функцию блокировки. Создание и удаление узлов в ZK можно выполнять только через лидер-сервер, после чего данные передаются всем машинам-последователям.
Преимущества использования Zookeeper для реализации распределённых замков
Эффективно решают задачи с одиночной точкой, не входя в атмосферу, неблокирующие проблемы и сбой блокировки при освобождении. Это относительно просто в реализации.
Недостатки использования Zookeeper для реализации распределённых замков
Производительность не так хороша, как при использовании кэша для реализации распределённых блокировок. Требуется понимание принципов ZK.
Сравнение трёх вариантов
С точки зрения простоты понимания (от низкого к высокому)
База данных > кэш > Zookeeper
С точки зрения сложности реализации (от низкой к высокой)
Базы данных Zookeeper > кэша >
С точки зрения производительности (от высокого к низкому)
Кэширование > базы данных Zookeeper >
С точки зрения надёжности (от высокого к низкому)
Базы данных Zookeeper > кэша >
|
Опубликовано 30.08.2018 15:04:32
|
|
|
|
Хозяин|
Опубликовано 22.09.2020 17:34:33
|
