От имени Alibaba Cloud я принял участие в RedisConf 2018. Находясь там, у меня было интервью с Руй Гу - создателем клиента Redisson с открытым исходным кодом. Влияние Руи Гу на международное сообщество Redis и его работа с открытым исходным кодом произвели на меня глубокое впечатление. Ниже приводится подробное содержание нашего интервью.
На изображении выше изображены Сячжоу из Alibaba Cloud, Руй Гу, Байчэнь из Alibaba Cloud и Зексиан из Alibaba Group.
Почему вы участвовали в проектировании и разработке Redisson?
Еще в 2004 году, когда я занимался промышленной автоматизацией и промышленным IoT, я встречал множество сценариев, которые требовали мониторинга и обработки сигналов ряда единиц оборудования. Такие сценарии предъявляют очень высокие требования к возможностям обработки в реальном времени, стабильности системы, высокой доступности и устойчивости к сбоям. С 2012 года, когда я решил использовать Redis в качестве базы данных в реальном времени, у меня появилось много идей. Redis и общие структуры данных в языках программирования, таких как Java, кажутся похожими, но на самом деле сильно отличаются. Я всегда надеялся, что смогу связать их. Начиная с 2013 года, когда Redis был коммерциализирован, это мое желание усилилось. Итак, я начал некоторые связанные исследования вне работы и, наконец, решил принять форму динамического класса, чтобы структуры данных Redis работали больше, чем соответствующие структуры Java. У Никиты, который находится далеко в Москве, похоже, возникла похожая идея. Он начал практическую разработку приложений под Новый год 2014 года и вскоре сделал Redisson открытым. В то же время в моей практике был некоторый прогресс и изначально были реализованы некоторые основные функции. Однако из-за различных рабочих проблем, вкупе с отсутствием уверенности в то время, прогресс за последние шесть месяцев замедлился. В конце концов, это была работа, которой раньше никто не занимался. Неожиданно Никита столкнулся с той же проблемой, но он изо всех сил пытался упорствовать и не собирался сдаваться. Со второй половины 2014 года я стал обращать внимание на проект Redisson. После глубокого понимания у меня внезапно возник сильный резонанс: у меня была та же идея, что и у моей практики, но с другой отправной точки. После этого мы начали общаться друг с другом. Наконец, в начале 2015 года мы решили отказаться от наших практических проектов, и мы оба присоединились к Redisson. К этому моменту мы уже не были одни на этом пути.
Какие вопросы решает Redisson? Какие преимущества у него перед другими клиентами Redis?
Соединение Redis Hash и Java HashMap
В индустрии Интернета вещей различные значения состояния набора устройств в реальном времени часто используются как бизнес-ориентированный объект, управляемый JVM в памяти. Если этот объект хранится в базе данных Redis в виде строки, каждый раз, когда значение состояния обновляется, требуются как сериализация, так и десериализация. В то же время также можно столкнуться с проблемой параллелизма, вызванной одновременным использованием разных значений состояния одного и того же объекта. Фактическое приложение использует структуру данных Hash, предоставленную Redis, для хранения этого объекта, чтобы эффективно избежать таких проблем. Хотя структура хэша Redis очень похожа на HashMap в Java, приложение не может управлять Redis так же просто, как работать с HashMap. И если вы не освоили команды, связанные с Redis, или неправильно обрабатываете детали, это в конечном итоге вызовет различные проблемы во время работы. Redisson's Map была создана, чтобы заполнить пробел между Redis Hash и Java HashMap.
Операция хеширования в Jedis
ConcurrentHashMap в Java
ConcurrentHashMap в Redisson
Решение проблем параллелизма
Промышленный контроль и определенные сценарии IoT требуют высоких возможностей обработки в реальном времени, а отклик на уровне миллисекунды должен быть достигнут для всех сигналов. Такие сценарии также имеют высокую степень параллелизма. В отличие от таких сценариев, как социальные сети или электронная коммерция, такие сценарии приложений в основном не имеют пикового / минимального трафика и всегда работают на пике. Следовательно, обычные меры компенсации пиков в других сценариях могут только увеличить нагрузку здесь. В таком сценарии, если вы используете такой клиент, как Jedis, который использует модель синхронного программирования, вам необходимо убедиться, что количество параллельных потоков соответствует количеству подключений. В противном случае возникнет ошибка, если невозможно получить доступные соединения. Напротив, Redisson использует структуру асинхронного программирования Netty, использует пул потоков EventLoop, аналогичный серверной архитектуре Redis, и эластично управляет соединениями в виде пула соединений. В конце концов, использование небольшого количества соединений может удовлетворить потребности большого количества потоков и существенно облегчить конкуренцию между потоками. Кроме того, асинхронный режим работы может предотвратить блокировку бизнес-потока запросом данных.
Удобный метод настройки файлов
Разработка Redis претерпела множество технологических изменений. Официальная версия не только добавила много полезных функций во время этой итерации, но также разработала несколько решений высокой доступности. В то же время сообщества и поставщики облачных вычислений разработали множество решений высокой доступности на основе прокси на основе официальной версии. Для сравнения, у этих решений есть свои преимущества и недостатки, и они применимы для разных сценариев. Разнообразные решения доставляют не только неприятности, но и удобство. Сценарии включают, например, изменение размера бизнеса, переключение из простого автономного режима или режима Master / Slave в режим дозорного или кластерного, миграцию из самостоятельно созданной среды Redis в облако или использование разных режимов работы Redis на разных этапах во время непрерывной работы. поставка процесса CD / CI на разных этапах проекта. Разработчикам часто требуется разработать соответствующий набор методов использования для различных сценариев высокой доступности. Это делает проект тесно связанным с режимом работы Redis, и бизнес-код должен быть изменен при изменении режима работы Redis. Redisson предоставляет удобный метод настройки файлов для этой ситуации и, без изменения кода, поддерживает различные режимы работы и среды Redis с помощью разных файлов JSON, YAML или SpringXML. Это снижает сложность как разработки, так и эксплуатации и технического обслуживания.
Redisson много работал над распределенными блокировками. Можете ли вы познакомить с практикой в этой области?
О реализации распределенных блокировок Redis уже есть много статей, доступных в Интернете. Однако почти во всех связанных введениях используется простой пакет, основанный на команде setnx, и в нескольких статьях анализируются дефекты этого дизайна. В нашу эпоху, когда блоги и коды публикуются случайно, такая ситуация дает всем иллюзию, что распределенные блокировки Redis могут существовать только в такой простой форме, и даже если есть дефекты, их можно избежать только в коде. Подумайте, стоит ли в обмен на гибкость бизнеса использовать немного более сложную конструкцию, чтобы компенсировать ее недостатки? Прежде чем говорить о переработке распределенных блокировок Redis, давайте взглянем на недостатки распределенных блокировок, которые просто упаковываются с помощью команды setnx.
1. Не повторно входим
При выполнении команды setnx имя, указанное для компании, обычно используется в качестве имени ключа с отметкой времени или случайным значением в качестве значения. Такие реализации не имеют возможности отслеживать потоки запросов или подсчитывать количество попыток повторного входа, а некоторые реализации даже не имеют атомарности операций. Когда дело доходит до бизнеса, который требует одной и той же блокировки в нескольких местах, очевидно, что использование блокировки без повторного входа может легко привести к тупиковым ситуациям. Вероятность тупиковой ситуации выше, особенно в сценариях с рекурсивной логикой. Объект Lock и синхронизированный фрагмент в инструментах параллелизма Java являются реентерабельными. Тем, кто знаком с этими инструментами, легко игнорировать дефект setnx.
2. Не поддерживает продление
В распределенной среде, чтобы гарантировать активность блокировки и избежать тупиковой ситуации, вызванной простоем приложения, распределенные блокировки часто вводят время истечения срока действия, после которого они автоматически разблокируются. Предпосылка этой конструкции заключается в том, что разработчик хорошо понимает степень детализации этого времени автоматической разблокировки. Слишком короткое может привести к истечению срока действия блокировки до завершения задачи, а слишком долгое может привести к тому, что другие узлы будут ждать долгое время перед восстановлением, когда приложение или узел службы не работает, что затрудняет гарантию SLA службы. В конструкции setnx отсутствует механизм продления, который продлевает срок действия. Он не может гарантировать, что бизнес может быть завершен до разблокировки, и не может гарантировать, что другие узлы могут быстро восстановить бизнес-обработку, когда приложение или сервисный узел не работает.
3. Отсутствие препятствий
Все более или менее знакомы с блокировками, и каждая блокировка имеет разные характеристики из-за разницы в стратегии блокировки. Но в целом эти блокировки имеют две общие черты: одно - взаимное исключение, а другое - препятствие. Взаимное исключение означает, что только один поток может получить доступ в любое время. Препятствие означает, что в случае конкуренции потоки, не получившие ресурс, остановятся до тех пор, пока ресурс не будет успешно получен или операция не будет отменена. Понятно, что команда setnx только обеспечивает функцию взаимного исключения, но не создает препятствий. Хотя механизм вращения может быть введен в бизнес-код для повторного приобретения, он предназначен только для передачи функций, которые должны быть реализованы в блокировке, в бизнес-код. Упростить реализацию блокировки за счет увеличения сложности бизнес-кода - не лучший вариант.
Распределенные блокировки Redisson имеют функцию защиты потоков, удовлетворяющую этим трем основным требованиям. Хеш-структура Redis используется в качестве единицы хранения, имя, указанное службой, используется в качестве ключа, случайный UUID и идентификатор потока используются в качестве поля, а количество блокировок сохраняется в качестве значения. В то же время UUID сохраняется на клиенте как переменная экземпляра блокировки. При запуске нескольких потоков с использованием экземпляра одной и той же блокировки использование UUID и идентификатора потока в качестве тегов по-прежнему обеспечивает независимость операции и отвечает требованиям безопасности потока.
При блокировке проверьте, существует ли блокировка, с помощью сценария Lua. Если нет, создайте поле, связанное с хешем, установите срок действия и вернитесь. Это означает, что блокировка прошла успешно. Если хэш-поле уже существует, проверьте, согласованы ли случайное поле и идентификатор потока. Если согласовано, значение увеличивается, а время истечения срока действия обновляется. Это означает, что один и тот же поток того же узла снова успешно заблокирован, что обеспечивает повторный вход. Если хэш существует, а поле и идентификатор потока несовместимы, это означает, что другой узел или поток уже имеет эту блокировку. Таким образом, сценарий Lua возвращает текущую достоверность хэша. Когда результат возвращается клиенту, если блокировка успешна, обновление выполняется через пул потоков в соответствии с установленным параметром времени, и, наконец, запрашивающий поток уведомляется о продолжении последующей операции. Если блокировка не удалась, слушайте канал pubsub с суффиксом этого ключа, пока не получите сообщение о разблокировке, и повторите попытку.
При разблокировке проверьте, существует ли блокировка, с помощью сценария Lua. В противном случае выдайте сообщение о разблокировке и вернитесь. Если он все еще существует, проверьте, существует ли тег. В противном случае это означает, что блокировка не принадлежит этому потоку. В этом случае запрашивающий поток получит сообщение об ошибке. Если тег существует, это означает, что блокировка принадлежит этому потоку. В этом случае после уменьшения значения поля тега определите, больше ли возвращаемое количество блокировок, чем 0. Если да, то текущая блокировка все еще действительна, и уменьшается только количество попыток повторного входа. Напротив, это означает, что он был полностью разблокирован, блокировка немедленно удаляется и выдается сообщение о разблокировке.
Реентерабельная блокировка Redisson устраняет многие недостатки, присущие блокировкам setnx, но, поскольку она по-прежнему хранится в виде единого ключа на фиксированном узле Redis, срок ее действия истекает автоматически. Хотя такая конструкция может значительно избежать воздействия простоя клиента или бизнес-узла, недостатком является то, что когда серверный процесс Redis или узел не работает, это может привести к отсутствию информации о блокировке, и такой недостаток, очевидно, не может соответствовать высоким требованиям определенных сценариев. требования доступности.
В этом случае создатель Redis Сальваторе предложил алгоритм распределенной блокировки высокой доступности, основанный на нескольких узлах, названный RedLock: https://redis.io/topics/distlock. С помощью этого алгоритма клиенту необходимо получить независимую блокировку на каждом из нескольких узлов одновременно. Только тогда, когда большинство блокировок успешно установлено за один раз, это можно рассматривать как достижение распределенных блокировок высокой доступности, в противном случае необходимо снять частично установленные блокировки и повторить попытку через случайный период.
При разработке алгоритмов Сальваторе по-прежнему использует setnx в качестве примера для объяснения функции взаимного исключения распределенных блокировок. В реализации алгоритма RedissonRedLock использует более гибкую и удобную блокировку повторного входа, упомянутую выше. Алгоритм расширения Redisson - единственная реализация Java, одобренная на официальном сайте Redis.
Хотя алгоритм Redlock обеспечивает высокую доступность, его применимость по-прежнему ограничена по принципу максимальной наглядности. Redisson обеспечивает высокую доступность распределенной блокировки RedissonMultiLock на основе усовершенствованного алгоритма. Этот алгоритм требует, чтобы клиент успешно получил блокировки всех узлов, прежде чем это будет считаться успешным блокированием, что дополнительно повышает надежность алгоритма.
Можете ли вы представить передовые направления развития Redisson?
Направление развития Redisson определяет, что он всегда был в авангарде методов расширения функций и приложений Redis. Самым представительным из них является функция локального кеширования. В 2016 году эта функция была разработана для решения проблемной точки конкретного корпоративного пользователя. Принцип состоит в том, чтобы жертвовать собственной памятью клиента в обмен на время, проводимое в сети для частого получения некоторых общих данных. Эта функция сразу привлекла внимание пользователей после того, как ее источник был открыт в сентябре того же года. Появление этой функции ускоряет миграцию традиционных ИТ-пользователей с других аналогичных платформ на Redis. Его популярность намного превосходит Никиты и мое воображение. Таким образом, каждый год корпоративные пользователи посещают RedisConf и другие подобные международные конференции по обмену и рассказывают о своем использовании Redisson и процессе миграции с других платформ на Redis. Эта тенденция привлекла внимание создателя Redis Сальваторе. После некоторого личного общения с другими пользователями Сальваторе решил использовать функцию клиентского кеширования в качестве важного направления для будущего развития Redis и предложил для этой цели протокол RESP3. Появление RESP3 обеспечит возможности координации на стороне сервера для функции кэширования клиента. Сальваторе также пригласил команду Redisson в качестве члена экспертной группы для участия в разработке стандарта кеширования клиента Redis.
Как обеспечить устойчивое развитие Redisson как проекта с открытым исходным кодом?
Чтобы обеспечить устойчивое развитие проекта Redisson и избежать простоя по прошествии определенного периода времени, как некоторые другие проекты с открытым исходным кодом, в начале 2017 года мы с Никитой решили предоставить дополнительные платные консультационные услуги на основе открытого исходного кода. проект, чтобы поддерживать нормальную работу проекта. В то же время мы предлагаем комплексные корпоративные решения для особых сценариев, с которыми сталкиваются крупные корпоративные пользователи. Наконец, все эти решения и службы поддержки SLA были упакованы как Redisson PRO для корпоративных пользователей.
По сравнению с другими клиентами, хотя проект Redisson имеет короткую историю, он уже завоевал доверие предприятий в различных отраслях, многие из которых являются лидерами в своих отраслях. Наиболее достойны представления следующие корпоративные пользователи мирового класса:
IBM в компьютерной индустрии. Я уверен, что все знакомы с IBM, создателем ПК. Это одна из немногих компаний в отрасли, которые обладают мощными возможностями разработки как аппаратного, так и программного обеспечения. Даже в этом случае IBM готова использовать Redisson, и это доверие является для нас величайшей поддержкой.
Боинг в авиастроении. До того, как они связались с нами, трудно было представить, что Boeing интересуется Redisson. Фактически, помимо самолетов, Boeing также является крупнейшим в мире поставщиком полетных карт и мобильной электронной полетной сумки. Почти каждая авиакомпания является пользователями Boeing. Redisson обеспечивает прочную основу для своей онлайн-службы навигации по полетам.
American International Group (AIG) в страховой отрасли. Основанная в 1919 году в Шанхае, Китай, AIG стала первой западной компанией, которая представила китайцам концепцию страхования. Сейчас они работают более чем в 130 странах и регионах по всему миру. Хотя во время финансового кризиса 2008 года внезапный обвал цен на акции сделал AIG доступным для общественности, это по-прежнему международное крупное предприятие с 99-летней историей и совокупными активами более 600 миллиардов долларов США. После длительного периода исследований, проведенных командой AIG, Redisson использовался для поддержки своих многочисленных финансовых и страховых предприятий.
S&P Global в финансовой индустрии. Что касается финансового кризиса, я должен упомянуть ведущее в мире агентство финансового анализа Standard & Poor’s. Это одна из трех основных кредитных рейтинговых организаций, признанных Комиссией по ценным бумагам и биржам США (SEC), и предоставляет инвесторам кредитные рейтинги, инвестиционные исследования и консультационные услуги. Он хорошо известен в отрасли, и знаменитый индекс S&P 500 создается и поддерживается им. Standard & Poor’s не только предоставляет внешние рейтинги для листинговых компаний, но также предоставляет рейтинги для национальных правительств. В 2011 году он резко снизил рейтинг правительства США и изменил прогноз на негативный, что немедленно вызвало резкие колебания в финансовой индустрии. Но даже такая мощная организация стала пользователем Redisson и использует его для анализа и обработки сложных финансовых данных.
Ссылка:
