На прошлой неделе я потратил некоторое время на изучение алгоритма RedLock, предложенного автором Redis для реализации распределенной блокировки.Адрес статьи. Я нашел такое предложение внизу официального документа.
Analysis of RedLock
Martin Kleppmann analyzed Redlock here. I disagree with the analysis and posted my reply to his analysis here.
Внезапно я почувствовал, что все не так просто, поэтому я щелкнул и посмотрел. Внимательно прочитав статью, я открыл для себя невероятный мир. Поэтому я остановился и изучил критику Мартина в адрес RedLock, а также контратаку автора RedLock на антирез.
Критика Мартина
Мартин подошел и спросил, на что мы будем запираться? Две причины:
- Чтобы повысить эффективность, используйте блокировки, чтобы задачу не приходилось выполнять дважды. как (очень дорогие вычисления)
- Чтобы обеспечить правильность, используйте блокировки, чтобы гарантировать, что задачи выполняются в соответствии с обычными шагами, предотвращая одновременную работу двух узлов с частью данных, что приводит к конфликтам файлов и потере данных.
По первой причине у нас есть определенная терпимость к блокировкам, даже если два узла работают одновременно, влияние на систему — это только дополнительные затраты на вычисления, а дополнительного воздействия нет. В настоящее время использование Redis в одной точке может очень хорошо решить проблему: нет необходимости использовать RedLock для поддержки такого количества экземпляров Redis и увеличения стоимости обслуживания системы.
Во-вторых, в сценариях со строгими требованиями к правильности (таких как заказы или потребление) корректность блокировки не может быть гарантирована даже при использовании алгоритма RedLock.
Разберем недостатки RedLock:
Автор Мартин дал такую картинку.Во-первых, как мы говорили в предыдущей лекции, в RedLock, для предотвращения дедлока, у блокировки есть время истечения. Это время истечения было поймано косичками Мартина.
- Если клиент 1 удерживает блокировку, возникает длинный FGC, который превышает время истечения блокировки. Замок разблокирован.
- В это время Клиент 2 получает еще одну блокировку и отправляет данные.
- В это время Клиент 1 просыпается от FGC и снова отправляет данные.
Все в порядке, данные неверны. RedLock только обеспечивает высокую доступность блокировки и не гарантирует правильность блокировки.
В это время вы можете сказать, если Клиент 1 проверяет держатель замка перед отправкой задачи, может ли он решить эту проблему сам?
Ответ — нет, FGC произойдет в любой момент, если FGC произойдет после запроса, возникнет та же проблема, что обсуждалась выше.
Затем перейти на язык программирования без GC?
Ответ по-прежнему отрицательный. FGC — это только одна из причин остановки системы. IO или перегрузка сети или колебания могут привести к остановке системы.
Прочитав статью, я был в отчаянии, но, к счастью, Мартин дал решение:
Добавьте токен-ограждение к замку.
- При получении блокировки вам также необходимо получить добавочный токен.На приведенном выше рисунке клиент 1 также получает ограждение с токеном = 33.
- После возникновения вышеуказанной проблемы FGC клиент получает блокировку с токеном = 34.
- При отправке данных необходимо оценивать размер токена.Если токен меньше, чем последние отправленные данные токена, он будет отклонен.
На самом деле мы можем понять, что это ограждение токенов — это оптимистическая блокировка или CAS.
Мартин также отметил, что RedLock — этоСильная зависимость от системных часовраспределенная система.
Или косички этого истекшего времени. Если системное время мастера Redis неправильное, что приводит к преждевременному истечению срока действия блокировки и ее освобождению.
- Клиент 1 получает блокировки с трех узлов A, B и C с пяти узлов A, B, D и E. Мы думаем, что он удерживает блокировку.
- В это время, поскольку системное время B работает быстрее, чем в других системах, B снимет блокировку раньше двух других узлов.
- Clinet 2 может получать блокировки от трех узлов B, D и E. Во всей распределенной системе два клиента одновременно удерживают блокировки.
В это время Мартин предложил очень важный момент проектирования распределенных систем:
Хорошая распределенная система должна быть асинхронной и небезопасной по времени. Поскольку в распределенной системе существуют программные паузы, задержки в сети и ошибки системного времени, ни один из этих факторов не может повлиять на безопасность распределенной системы, а только на свойство живучести системы. Другими словами, в крайних случаяхРаспределенные системы не могут давать результаты самое большее за ограниченное время, но не могут давать неправильные результаты.
Итак, резюмируя критику RedLock Мартином:
- Для сценариев, повышающих эффективность, RedLock слишком тяжел.
- Для сценариев, требующих очень высокой точности, RedLock не может гарантировать правильность.
В это время я чувствую себя уполномоченным, и это так хорошо написано.
Автор RedLock, а также автор Redis также ответили на статью Мартина, и порядок вполне ясен.
ответ антиреза
После того, как антирез увидел статью Мартина, он написал статью в ответ. Сюжет перевернется?
Антирез резюмировал обвинения Мартина в адрес RedLock:
- Распределенные замки имеют функцию автоматической разблокировки. Взаимное исключение блокировок действует только в течение времени истечения срока действия.После истечения срока действия и снятия блокировки несколько клиентов будут удерживать блокировку.
- Вся система RedLock построена на системной модели, которая не может быть гарантирована в реальной системе. В этом случае система предполагает, что время синхронизировано и является доверенным.
По первому вопросу:
Антирез много писал, и после долгого внимательного прочтения не разрешил сомнений в моем сердце. Просмотрите шаги для RedLock для получения блокировки:
- получить время начала
- Перейдите к каждому узлу, чтобы получить замки
- Получить время снова.
- Вычислите время получения блокировки и проверьте, меньше ли время получения блокировки, чем время получения блокировки.
- Держите замок, что делать
Если программа блокируется между шагами 1-3, RedLock может определить, что срок действия блокировки истек, и проблемы нет.
Если программа блокируется после шага 4? что делать? ? ?
Ответ в том, что другойРаспределенные блокировки с авторазблокировкой не решают эту проблему..
Для второго заряда:
Антирез считает, что прежде всего в реальной системе с двух сторон:
- Система зависает, сетевые задержки.
- Время системы ступенчатое.
На первый вопрос. Как упоминалось выше, RedLock выполняет некоторую незначительную работу, но полностью избежать ее невозможно. Для других распределенных замков с автоматической разблокировкой нет возможности.
Второй вопрос. Мартин считает, что шаг системного времени в основном исходит из двух аспектов:
- Модификация человека.
- Получено обновление часов времени перехода от службы NTP.
Что можно сказать о модификации человека? Нет никакого способа избежать разрушения.
NTP подлежит обновлению пошагового тактового сигнала, для решения этой проблемы он должен быть гарантирован эксплуатацией и обслуживанием. Когда вам нужно обновить время шага до сервера, вы должны делать небольшие шаги и бежать быстро. Изменяйте несколько раз, и время для каждого обновления будет как можно меньше.**
В качестве отступления, прочитав это, я вдруг понял письмо одноклассника по эксплуатации и обслуживанию:
Итак, строго говоря, RedLock построен на модели, что Время заслуживает доверия.Теоретически Время также имеет ошибки, но на самом деле некоторые механизмы хорошей эксплуатации, технического обслуживания и проектирования могут гарантировать доверие к Времени в наибольшей степени.
Наконец, антирез также подвергся критике, так как предложенная Мартином система использует заражающие токены, чтобы гарантировать упорядоченную обработку данных. Вам все еще нужен RedLock или другие распределенные блокировки? ?
обзор
Прочитав их переписку в блогах, мне захотелось посмотреть драму мастеров боевых искусств, что весьма освежает. У этих двоих был ясный ум, Мартин подошел, чтобы увидеть тупик РедЛока, сильно избил его, и антирез успешно разрешил его.
Что касается того, кто прав, а кто виноват?
На мой взгляд, каждая конструкция системы имеет свою направленность или ограничения. Инженерия тоже не идеальна. В реальной инженерии нет идеального решения. Мы должны иметь глубокое понимание того, как это работает, и понимать плюсы и минусы решения. Поймите ограничения вариантов. Приемлемы ли последствия ограничений программы.
Архитектура по своей сути является искусством баланса.
Наконец
Мартин рекомендует использовать ZooKeeper для реализации распределенных блокировок транзакций. В чем разница между замками Zookeeper и Redis? Решил ли Zookeeper проблему, которую не решил Redis? И слушайте следующее разложение.