Ставьте лайк и смотрите снова, формируйте привычку, ищите в WeChat【Третий принц Ао Бин] Обратите внимание на этот инструмент человека, который борется за выживание в Интернете.
эта статьяGitHubgithub.com/JavaFamilyВключено, и есть полные тестовые площадки, материалы и мой цикл статей для интервью с производителями первой линии.
предисловие
Я не думаю, что мне нужно слишком много говорить о замке.Все знают, что происходит, верно?
В многопоточной среде данные могут быть несогласованными или загрязненными из-за переключения контекста.Нам необходимо обеспечить безопасность данных, поэтому мы думаем о блокировке.
Так называемый механизм блокировки означает, что когда поток обращается к определенным данным этого класса, они защищаются, и другие потоки не могут получить к ним доступ, а другие потоки не могут их использовать, пока поток не закончит чтение.
Помните, я говорил ранее, что Redis должен блокировать данные с конкурентной конкуренцией при их распределении. Вы очень озадачены. Является ли Redis однопоточным? Зачем вообще запирать?
Вроде молод еще.Ситуация о которой вы говорите не требующая блокировки следующая:
Когда один сервис обращается к Redis, ему не нужно учитывать безопасность потоков, поскольку Redis сам по себе является однопоточным. Это должен быть распределенный кластер.
У вас есть проблемы с этой сценой:
Разве вы не часто говорите, что всплески, если вы получите оценку запасов, то жена скажет вам, что ситуация с распределением вызовет проблемы.
Для того, чтобы снизить нагрузку на БД, мы предварительно подогрели инвентарь до КВ, и теперь инвентарь КВ равен 1.
Сервис А заходит в Redis и обнаруживает, что инвентарь равен 1, а значит, я могу захватить этот товар, да? Потом я планирую уменьшить его на 1, но он еще не уменьшен.
При этом сервис Б тоже пошел забирать и обнаружил, что тоже 1, поэтому я тоже захватил, потом еще и уменьшил.
С такой же.
После того, как все услуги были оценены, вы узнаете, почему он стал -2, он перепродан и закончился.
Есть ли проблема? Это требует вмешательства распределенных блокировок. Я представлю три реализации распределенных блокировок (Zookeeper, Redis, MySQL) в трех главах и укажу их преимущества и недостатки, а также общую Практическая сцена большого фабрика.
текст
Зашел наглый интервьюер, ничего не взяв. Видите ли, это не ваша жена. Когда вы собирались ему звонить, вы застали его с серьезным лицом, а он притворялся серьезным. Я налью воды.
Поиск станции B: Третий принц Ао Бин
Кхм, мы ничего не будем говорить, давайте начнем сегодняшнее интервью.
Каковы механизмы нормальной синхронизации процессов потоков?
Взаимное исключение: механизм взаимного исключения гарантирует, что только один поток может одновременно управлять общими ресурсами, синхронизировать, блокировать и т. д.
Порог: разрешить многопоточным последовательным диалогам доступ к ресурсам
Уведомление о событии: убедитесь, что каждый может получить доступ к общим ресурсам упорядоченным образом с помощью уведомления о событии.
Семафор: Одновременный доступ несколькими задачами с ограничением количества, например запуск CDL пистолета, семафор и т. д.
Какие распределенные блокировки вы знаете?
Реализация распределенных блокировок в основном основана на Zookeeper (далее zk), Redis и MySQL.
Тогда поговорите со мной сначала о zk, можете ли вы рассказать нам о его распространенных сценариях использования?
Основные сценарии его применения следующие:
Регистрация службы и подписка (общий узел)
Распределенные уведомления (прослушивание znodes)
Именование службы (функция znode)
Подписка на данные и публикация (наблюдатель)
Распределенные блокировки (эфемерные узлы)
что такое зк?
Он представляет собой базу данных, систему хранения файлов и имеет механизм мониторинга уведомлений (паттерн наблюдателя)
Сохранить файловую систему, что он сохраняет?
узел
Существует 4 категории типов узлов zk
Постоянный узел (отключенный узел zk все еще существует)
Сохранение последовательно пронумерованных узлов каталога
Узел временного каталога (узел удаляется после отключения клиента)
узел каталога с временным номером каталога
Все имена узлов уникальны.
Как создаются узлы?
Что я спрашиваю? Но в интервью я видел только распределенные замки, надо подумать! ! !
К счастью, я раньше собирал zk-кластер на своем сервере, и просто вспоминал его со всеми.
create /test laogong // 创建永久节点
Как насчет временных узлов?
create -e /test laogong // 创建临时节点
Временный узел успешно создан.Если я отключу эту ссылку, узел исчезнет естественным образом.Это один из моих инструментов управления zk, и каталог может быть более четким.
Что, если вы создадите последовательные узлы?
create -s /test // 创建顺序节点
Как насчет временных последовательных узлов?
думаю умные товарищи спешат ответить
create -e -s /test // 创建临时顺序节点
После того, как я вышел из системы, я снова подключился и обнаружил, что все временные узлы, которые я только что создал, исчезли.
В начале так много демонстраций, я просто хочу показать вам общий процесс работы и структуру данных zk.Я не буду говорить о построении и других навыках, задействованных в середине. Давайте сосредоточимся на его реализации в распределенных блокировках.
Zk реализует различные распределенные блокировки на основе узлов.
Взяв в качестве примера сцену в начале, как zk должен обеспечивать безопасность потоков в распределенных ситуациях? Как он контролирует одновременную конкуренцию?
Чтобы смоделировать ситуацию параллельной конкуренции, я написал некоторый псевдокод, вы можете сначала взглянуть
Я определил значение инвентаря равным 1, а также использовал стартер CountDownLatch для вычета инвентаря, когда 10 потоков готовы.
Это похоже на то, что 10 машин работают вместе, чтобы получить инвентарь, а затем вычесть инвентарь?
Я пошел собирать все машины и обнаружил, что все они равны 1. Потом все подумали, что сами схватили, и все выполнили операцию вычитания единицы. значение, они обнаружили, что это было на самом деле перепродано. Я распечатаю это для всеобщего обозрения.
image-20200406143556640
Да, это не проблема одного или двух перепроданности. Существует 7 перепроданок. Код явно судит, что инвентарь больше 0, прежде чем уменьшить его. Я объяснил, что произошло в начале.
Итак, как решить эту проблему?
Синхронизация и блокировка могут гарантировать только потокобезопасность вашей текущей машины, поэтому проблемы с распределенным доступом все еще существуют.
Упомянутый выше узел zk может решить эту проблему.
У узла zk есть уникальная особенность, то есть мы создали этот узел, если вы создадите zk еще раз, будет сообщено об ошибке, тогда мы воспользуемся его уникальностью, чтобы реализовать его.
Как этого достичь?
Разве нет 10 тем выше?
Мы создаем их все.Первый успешно созданный возвращает true, и он может продолжать следующий вывод операций инвентаризации.Последующие обращения к узлу будут все сообщать об ошибках, и вывод не будет выполнен.Мы бросаем их в очередь в очередь.
Так как снять блокировку?
Удалите узел, удалите его, а затем уведомите других людей, чтобы они пришли и заблокировали его, и так далее.
Давайте реализуем сценарий блокировки zk.
image-20200406151627845
Не правда ли, только первый поток может успешно вычитать, остальные терпят неудачу.
Но вы обнаружите, что проблемы нет, вы добавили блокировку, вы должны ее снять, и вы не будете пытаться снова, если не сбросите следующую ошибку.
Это просто, блокировка удаления снимается, блокировка в конце разблокируется, и теперь мы, наконец, удаляем узел.
Мы знаем, что создание узла достаточно заблокировано, но вы должны добиться эффекта блокировки. Да, что вы делаете?
Бесконечный цикл, рекурсия продолжается до тех пор, пока она не увенчается успехом, эффект блокировки камуфляжа.
Откуда вы знаете, что предыдущий брат удалил узел?
Слушайте событие удаления узла
Но нашли ли вы свою проблему в этом?
Да, будут тупики.
Первый дочерний узел был успешно заблокирован. При выполнении кода машина была отключена. Можно ли удалить узел?
Хочешь задуматься, спроси себя, смотри вдаль, а потом смотри на интервьюера, делай вид, что ничего не знаешь.
О, я вспомнил, просто создайте временный узел.Как только клиентское соединение будет отключено, другие смогут следить за изменениями узла.
Ну не плохо, тогда других проблем не нашел?
Кажется, что этот механизм мониторинга не является хорошим.
Что случилось?
Вы можете видеть, что все службы наблюдают за узлом, и освобождение узла также уведомит все серверы.Что, если серверов 900?
Это большой вызов для сервера.Сообщение об освобождении - это как пастух, входящий в стадо.Все разбросаны, и машину могут убить в любой момент, что займет ресурсы сервиса, пропускную способность сети и так далее.
Это эффект стада.
Итак, как решить эту проблему?
Продолжайте делать вид, что медитируете, ах ах ах, так тяжело, моя голова. . . .
Ты, ТМ, не притворяйся, ладно?
Хорошо, узел временной последовательности может легко решить эту проблему.
Как этого добиться, не смотрите вниз, думайте сами.
Я уже говорил, что мониторить все одну ноду большая проблема, потом будем мониторить нашу предыдущую ноду, потому что она последовательная, легко найти свою до и после.
Отличие от мониторинга постоянной ноды раньше в том, что каждая нода отслеживает только свою предыдущую ноду, а выпуск, конечно же, происходит по одной, так что эффекта стада не будет.
Я открою исходный код всего приведенного выше кода на своем https://github.com/AobingJava/Thanos. На самом деле, в приведенном выше все еще есть недостатки, вы можете пойти и сбросить его и изменить представление pr, я посмотрю, если это подойдет и пройдет.
Вы так много сказали, и это очень хорошо.Можете ли вы рассказать о каких-то недостатках практики ЗК в распределенных блокировках?
Производительность Zk может быть не такой высокой, как у службы кеша.
Потому что каждый раз в процессе создания и снятия блокировки мгновенные узлы должны динамически создаваться и уничтожаться для реализации функции блокировки.
Создание и удаление узлов в ZK возможно только через сервер-лидер, а затем данные синхронизируются на все машины-последователи. (Здесь задействовано знание zk кластера, я не буду его расширять, а подробно поговорю с вами в главе zk позже)
Больше?
Использование Zookeeper также может привести к проблемам с параллелизмом, но это не является распространенным явлением.
Из-за сетевого джиттера сессионное соединение клиента с кластером ZK разрывается, тогда ZK думает, что клиент завис, и удалит временный узел, в это время другие клиенты могут получить распределенные блокировки.
Могут возникнуть проблемы с параллелизмом. Эта проблема не является распространенной, поскольку zk имеет механизм повторных попыток. Как только кластер zk не может обнаружить сердцебиение клиента, он повторяет попытку. Клиент Curator поддерживает несколько стратегий повторных попыток.
Временный узел будет удален, если он не работает после нескольких попыток.
Совет: Поэтому также более важно выбрать подходящую стратегию повторных попыток и найти баланс между степенью детализации блокировки и параллелизмом.
Есть ли лучшая реализация?
Распределенная блокировка на основе Redis
Ты можешь поговорить со мной?
Я посмотрел на часы в руке.Сегодня уже поздно.Вы задали все вопросы.Как мне написать больше статей?
Уже очень поздно, так почему бы тебе не пойти домой и не заняться домашними делами?
Я? ? ? ?
=
Суммировать
zk решил это через временные узлытупикКак только клиент внезапно зависает после получения блокировки (сеансовое соединение разрывается), временный узел будет автоматически удален, а другие клиенты автоматически получат блокировку.
zk также реализует механизм постановки в очередь и прослушивания узлов.блокироватьПринцип на самом деле представляет собой рекурсивный процесс бесконечного ожидания освобождения наименьшего узла.
Я не реализовал блокировку вышевозвращающийся, но это также очень легко реализовать.Вы можете ввести информацию о потоке или уникальный идентификатор, такой как информация о машине.Судите об этом, когда получите его.
кластер zk такжеВысокая доступностьДа, если более половины из них являются или могут предоставлять услуги внешнему миру.
На этой неделе я закончу писать распределенные блокировки для Redis и баз данных, подождите.
Я Ао Бин, мастер по инструментам, который живет в Интернете.
Лучшие отношения - это достигать друг друга,мужНаш **"Sanlian"** является самой большой движущей силой для создания Bing Bing, увидимся в следующем выпуске!
Примечание. Если в этом блоге есть какие-либо ошибки и предложения, вы можете оставить сообщение,Муж, пожалуйста, говори!
Статья постоянно обновляется, вы можете искать в WeChat "Третий принц Ао Бин"Прочтите это в первый раз, ответьте [материал】【интервью】【резюме] Подготовленные мной материалы интервью и шаблоны резюме крупных заводов первой линии, эта статьяGitHubgithub.com/JavaFamilyОн был включен, и есть полные тестовые сайты для интервью с крупными заводами.Добро пожаловать в Star.