Как распространяется Redis, давайте посмотрим на дизайн и практику JD Finance

предисловие

R2M — это распределенная система кэширования для крупномасштабных приложений в Jingdong Financial Online.В настоящее время общий объем памяти управляемых машин превышает 60 ТБ, почти 600 кластеров Redis Cluster и более 9200 экземпляров Redis.

К его основным функциям относятся:Полная веб-визуальная эксплуатация и техническое обслуживание,Развертывание кластеров кэша одним щелчком мыши,Общее управление пулом ресурсов,Онлайн-расширение емкости и быстрая миграция данных,Многокомнатная коммутация и аварийное восстановление,Полный мониторинг и оповещение,Совместимость с Redis APIЖдать.

В этой статье будет проведен глубокий анализ архитектуры системы R2M, управления ресурсами, расширения и миграции кластера, холодного и горячего обмена данными, аварийного восстановления в нескольких комнатах и ​​т. д. Надеюсь, читатели смогут что-то для себя почерпнуть.

Преимущества использования в бизнесе, эксплуатации и обслуживания

Чрезвычайно упрощенный доступ

Доступ к R2M прост, на примере Java-клиента вам нужно только ввести клиентский jar-пакет в бизнес-программу, настроить имя приложения и ZK-адрес, а затем использовать его.

Настроить автоматическую доставку

Клиент R2M предоставляет такие конфигурации, как пул подключений, время ожидания чтения и записи и количество повторных попыток. В некоторых случаях эти конфигурации необходимо настроить. Например, когда приближаются рекламные акции 618 и Double Eleven, некоторым предприятиям необходимо сократить число клиентов Время ожидания чтения и записи, чтобы избежать цепной реакции, вызванной проблемой тайм-аута.

Чтобы изменить конфигурацию, бизнесу приходится перезапускать всех клиентов, что не только отнимает много времени и сил, но и может привести к сбоям. Поэтому, чтобы избежать этой проблемы, в R2M предусмотрена функция автоматического распространения конфигурации, и бизнес-клиентам не нужно снова выходить в интернет, после того как административная сторона модифицирует конфигурацию, все клиенты вступают в силу немедленно.

Поддержка нескольких типов данных API

Он полностью совместим с API-интерфейсами различных типов данных Redis и предоставляет около 100 интерфейсов, включая хэш, набор, упорядоченный набор, список, публикацию/подписку и т. д.

Поддержка горячего и холодного обмена данными

На основе обеспечения высокой производительности и согласованности данных реализован динамический обмен холодными и горячими данными на основе статистики тепла LFU, так что холодные данные передаются на SSD, а горячие данные загружаются в Redis, обеспечивая высокую производительность и низкую стоимость. остаток средств.

Полная веб-визуальная эксплуатация и техническое обслуживание

R2M реализует визуальную работу и обслуживание всех функций, включая развертывание кластера, расширение емкости, миграцию данных, мониторинг, автономный режим кластера, очистку данных, замену неисправных узлов и отключенный компьютер и т. д., что значительно повышает эффективность и доступность эксплуатации и обслуживания.

Переключение одной кнопкой между несколькими компьютерными комнатами

Преобразовав Redis Cluster для поддержки аварийного восстановления в нескольких компьютерных залах, предотвращения разделения кластера и поддержки переключения и выбора нескольких компьютерных залов каждым системным компонентом, реализовано переключение нескольких компьютерных залов одним нажатием в веб-консоли.

Разнообразные инструменты кластерной синхронизации и переноса данных

R2M предоставляет специализированные компоненты инструмента миграции, поддерживает миграцию с собственного Redis на R2M и реализует механизм миграции, основанный на передаче файлов Redis RDB и инкрементной синхронизации.

В то же время можно указать правила, такие как частичный перенос данных в соответствии с префиксным соответствием или обратным соответствием. По внутренним историческим причинам некоторые предприятия JD.com использовали Jimdb с JD.com.R2M также поддерживает миграцию из кластера Jimdb.

Инструмент миграции R2M также поддерживает функцию синхронизации данных в реальном времени, включая синхронизацию данных между кластерами R2M и синхронизацию данных исходных кластеров Jimdb.

Агенты на языках, отличных от Java

Наши бизнес-разработчики в основном используют Java. Для клиентов, не использующих язык Java, таких как Python, C и т. д., доступ к ним осуществляется через компонент R2M Proxy. Различные операции по эксплуатации и обслуживанию выполняются на уровне Proxy, который защищен от деловых сторон. . В то же время Proxy также обеспечивает схему гарантии высокой доступности.

структура системы

Функция компонента

Web console

Это визуальная консоль управления и обслуживания кэш-системы R2M. Все операции и операции обслуживания выполняются в веб-консоли.

Manager

Управляющий компонент всей системы. Отвечает за выдачу всех операций по эксплуатации и техническому обслуживанию, сбор данных мониторинга и т. д. Операции по эксплуатации и техническому обслуживанию включают создание кластера, миграцию данных, расширение емкости и переключение между несколькими комнатами.

Agent

Компонент агента развертывается на каждой физической машине, и агент отвечает за развертывание и мониторинг локального экземпляра Redis, а также за отчетность по данным.

Кэшировать узлы кластера

Узлы каждого кластера распределены по разным машинам, а несколько узлов образуют распределенный кластер, который децентрализован и не имеет единой точки.

Client

Клиент вводится бизнес-стороной, например, Java вводится через пакет jar.

Proxy

Для клиентских служб, отличных от Java, доступ к кешу и службы предоставляются через прокси.

Развертывание кластеров кэша одним щелчком мыши

Развертывание распределенных кластеров обычно является трудоемким, включает в себя несколько машин, несколько узлов и ряд действий и конфигураций.Например, развертывание Redis Cluster включает установку и запуск узла, установление связи узла, выделение главного-ведомого и вставку.Распределение слотов, настройка шагов репликации.

Хотя официальный инструментальный скрипт для построения кластера предоставляется, рекомендация машины, установка и настройка узла по-прежнему не автоматизированы, что по-прежнему не является гибким и удобным для предприятий, которым необходимо развертывать и эксплуатировать Redis Cluster в больших масштабах.

Поэтому, основанный на Golang, R2M реализует выполнение одним щелчком мыши всех действий от рекомендации машины, развертывания узла, построения кластера до настройки узла в веб-консоли.Во время этого процесса компонент агента на каждой машине отвечает за загрузку и установку RPM. пакеты и указать, что экземпляр запущен на порту, а компонент Manager отвечает за завершение процесса построения кластера и настройки узла.

В процессе автоматического развертывания существуют некоторые необходимые условия проверки и правила приоритета, в основном следующие:

• Проверьте, соответствует ли количество главных узлов и стратегия ведущий-ведомый минимальным условиям конфигурации для распределенных выборов и высокой доступности: три или более главных узла, один главный и один подчиненный.

• Избегайте развертывания нескольких узлов в одном кластере на одном компьютере, чтобы предотвратить сбои компьютеров, и предпочтительно рекомендуйте подходящие компьютеры.

• В зависимости от доступной памяти машины предпочтение отдается машине с большим объемом свободной памяти.

• В зависимости от количества мастер-узлов количество слотов распределяется равномерно.

Планирование ресурсов и общее управление

Из-за большого количества компьютерных залов, машин и сервисов, чтобы эффективно управлять платформой, необходимо разумно заранее планировать ресурсы.Предварительное планирование включает в себя: при подаче заявки на доступ бизнес-сторона оценивает емкости и разумно распределяет размер и количество экземпляров кэша и машин.Для удобства управления и статистики обычно необходимо группировать машины по машинному залу или группировать машины по бизнесу.

При предварительном планировании также необходимо иметь четкое представление об использовании ресурсов, чтобы избежать чрезмерного использования или чрезмерного выделения ресурсов.

Сильно лишний вес, то есть фактическое использование намного меньше, чем предполагаемая мощность.Есть еще много случаев, потому что во многих случаях трудно точно оценить мощность, или какое-то развитие бизнеса ради страховки или беспокоит сложность расширение, а применяемая мощность часто намного больше, чем в реальных потребностях, в этом случае мы можем выполнить масштабирование одним щелчком мыши, чтобы предотвратить трату ресурсов.

засупер использование, то есть фактическое использование ресурсов машины превышает стандартное, необходимо уделять большое внимание Чрезмерное использование кэш-машины, например чрезмерное использование машины Redis, может привести к очень серьезным последствиям, таким как OOM, данные устранение и резкое снижение производительности.Во избежание чрезмерного использования необходимо осуществлять разумное резервирование ресурсов, выбирать соответствующую стратегию устранения, и в то же время платформа должна иметь совершенные функции мониторинга и оповещения в реальном времени.

Благодаря иерархическому управлению и мониторингу компьютерных залов, групп, машин и экземпляров R2M помогает нам лучше планировать ресурсы, а также максимизировать и сбалансировать использование ресурсов, чтобы предотвратить нерациональное использование ресурсов и чрезмерное использование машин.

Расширение и миграция данных

Когда бизнес подает заявку на кеш, мы всегда запрашиваем расчетную емкость и распределяем ее в соответствии с расчетным значением.Однако расчетное значение часто бывает неточным, и план никогда не поспевает за изменениями.Расширение бизнес-сценария, объем бизнеса, и рост данных всегда непредсказуем.

Поэтому особенно важен хороший механизм расширения.Удачное расширение или нет определяет масштабируемость системы. В R2M мы разделяем горизонтальное расширение на два этапа, добавляя новые узлы и перенос данных. Добавление новых узлов на самом деле представляет собой процесс автоматического развертывания. Многие шаги аналогичны процессу создания кластера, поэтому ключ заключается в том, как решить проблему с данными. , Проблема миграции.

Миграция данных в основном решает следующие проблемы:

• Как добиться нормального чтения и записи без ущерба для бизнеса, то есть бизнес-сторона в принципе не знает о миграции?

• Как обеспечить скорость миграции?

• Когда часть данных находится в процессе миграции, что должен делать клиент, если ему нужно прочитать и записать данные?

• Когда в процессе миграции получена операция чтения, будь то чтение исходного узла или целевого узла, как гарантировать, что клиент не читает грязные данные?

• В процессе миграции вы записываете исходный узел или целевой узел, если вы следите за тем, чтобы не было написано неправильное место, и что новое значение не будет перезаписано старым значением из-за миграции?

• Как после завершения миграции уведомить клиента о необходимости маршрутизации запросов на чтение и запись на новый узел?

Чтобы решить эти проблемы, мы полностью впитываем преимущества Redis Cluster, а также решаем некоторые его недостатки и недостатки.

Принцип переноса данных

На приведенном выше рисунке представлена ​​схема миграции данных Redis Cluster Процесс миграции завершается сотрудничеством исходного узла, целевого узла и клиента.

Redis Cluster делит набор данных на 16 384 слота. Слоты — это наименьшая единица разделения данных. Поэтому во время переноса данных необходимо мигрировать как минимум один слот. Минимальная степень детализации миграции — один ключ. Миграцию каждого ключа можно рассматривать как Атомарная операция временно заблокирует чтение и запись ключа на исходном узле и целевом узле, чтобы не было переходного «промежуточного состояния», то есть ключ находится либо на исходном узле, либо на целевом узле.

Как показано на рисунке выше, если предположить, что слот 9 переносится, он сначала пометит слот 9 как «мигрирующий» на исходном узле, пометит слот 9 на целевом узле как «импортирующий», а затем пройдет и перенесет все ключи. в слоте.

На этом этапе, если клиент хочет получить доступ к данным в слоте 9, если данные не были перенесены на целевой узел, он будет напрямую читать, записывать и возвращать, если данные были перенесены на целевой узел, он будет вернуть ответ Ask и передать адрес целевого узла и сообщить клиенту сделать еще один запрос к целевому узлу.

Если все данные в слоте 9 были перенесены, а клиент продолжает чтение и запись на исходном узле, он вернет клиенту ответ Moved.После получения ответа Moved клиент может повторно получить статус кластера и обновить его. информацию о слоте.Последующие обращения к слоту 9 будут осуществляться на новом узле. Таким образом, миграция одного слота завершена.

Многоузловая параллельная миграция данных

Redis Cluster основан на алгоритме CRC16 для хеш-шардинга.При одинаковом количестве слотов и отсутствии большого ключа распределение данных на каждом узле обычно очень сбалансировано.Поскольку миграция данных основана на ключе, миграция скорость относительно высокая, медленная.

Когда объем данных резко возрастает и требуется срочное расширение емкости, если миграция данных главного узла выполняется одна за другой, возможно, что некоторые узлы «взорвали» память до того, как миграция может произойти, что приведет к удалению данных или машина ООМ.

Поэтому R2M реализует многоузловую параллельную миграцию данных, чтобы предотвратить возникновение таких проблем, и в то же время значительно сокращается время, отнимающее время на миграцию данных.Кроме того, в сочетании с функцией миграции конвейера после Redis 3.0.7, это может еще больше сократить количество сетевых взаимодействий и сократить время миграции.

Контролируемая миграция данных

После горизонтального расширения и добавления новых узлов некоторые данные необходимо перенести на новые узлы, чтобы выполнить балансировку данных/нагрузки.Обычно процесс переноса данных занимает много времени.В зависимости от условий сети, размера экземпляра и конфигурации компьютера он может длиться от десятков минут до нескольких часов.

Миграция данных может оказать сильное давление на сеть.Кроме того, для переносимых слотов или ключей Redis Cluster сообщает клиенту направить запрос на новый узел с помощью механизма перенаправления ASK или MOVED, чтобы клиент и у Redis есть еще одно явление — взаимодействие запрос-ответ.

И обычно тайм-аут чтения и записи кеша клиента относительно короткий (обычно в пределах 100 ~ 500 мс).Под действием множества факторов это может вызвать большое количество тайм-аутов чтения и записи, что окажет большее влияние на онлайн-бизнес. .

Исходя из этого, мы реализовали приостановку задач миграции и продолжение задач миграции.Когда выяснится, что миграция влияет на бизнес, миграция может быть приостановлена ​​в любое время, а оставшаяся миграция данных может быть продолжена после завершения бизнеса. низкий пиковый период, чтобы быть гибким и контролируемым.

Автоматическое расширение

R2M также предоставляет механизм автоматического расширения емкости.После включения автоматического расширения емкости, когда доступной памяти машины достаточно, если используемая емкость экземпляра достигает или превышает заданный порог, емкость будет автоматически расширена.

Для некоторых более важных служб или служб, которые не могут удалить данные, вы можете включить автоматическое увеличение емкости. Конечно, автоматическое расширение также условно, например, неограниченное автоматическое расширение невозможно, когда размер экземпляра достигает относительно большого значения, автоматическое расширение отклоняется, а часть памяти резервируется для операций форка, чтобы избежать OOM на машине. .

Хранилище данных с холодной и горячей заменой

Поскольку у нас есть много кэш-кластеров большой емкости (сотни ГБ или несколько ТБ) онлайн, стоимость памяти кэш-машин огромна, а общий объем памяти онлайн-машин достиг около 66 ТБ.

После расследования мы обнаружили, что разрыв в себестоимости между основной памятью DDR3 и массовым твердотельным накопителем SATA составляет примерно 20 раз. Чтобы оптимизировать совокупную стоимость инфраструктуры (аппаратное обеспечение, компьютерные шкафы, энергопотребление и т. д.), мы рассматриваем возможность внедрения классификация данных на основе тепловой статистики.Динамический обмен хранилищем и данными между RAM/FLASH значительно снижает общую стоимость инфраструктуры и обеспечивает высокий баланс между производительностью и стоимостью.

Основная идея хранилища с холодной и горячей заменой R2M заключается в следующем: алгоритм тепловой статистики, основанный на количестве обращений к ключу (LFU), идентифицирует горячие данные и сохраняет горячие данные в Redis, а данные сбрасывает без доступа/маленький доступ к SSD. , если ключ на SSD снова нагреется, перезагрузите его в память Redis.

Идея очень проста, но реализовать ее на практике не так-то просто.Поскольку скорость чтения и записи SATA SSD по-прежнему сильно отличается от скорости чтения и записи памяти Redis, конструкция разработана таким образом, чтобы избежать такой асимметрии производительности. снижая производительность всей системы.Производительность, что приводит к резкому снижению времени отклика и общей пропускной способности, мы приняли многопроцессную асинхронную неблокирующую модель, чтобы обеспечить высокую производительность уровня Redis за счет хорошо спроектированного жесткого формат хранения данных на диске, ленивое удаление ключа с несколькими версиями, многопотоковое чтение и запись SSD и другие механизмы для максимизации производительности чтения и записи SSD.

Многопроцессная асинхронная модель в основном состоит из двух процессов: один — процесс чтения и записи SSD, который используется для доступа к ключам в SSD, а другой — глубоко модифицированный процесс Redis, который используется для чтения и записи памяти. В то же время, если ключ для чтения и записи найден, если он находится на SSD, запрос будет переадресован в процесс чтения/записи SSD для обработки.

В начале слоя процесса Redis мы фактически сделали его на основе Redis 3.2, но после того, как была выпущена RC-версия Redis 4, она особенно поддерживала такие функции, как LFU, Psync2 и дефрагментация памяти, поэтому мы решительно перешли на Redis 4. для трансформации.

Процесс чтения и записи SSD изначально был разработан на основе SSDB с открытым исходным кодом, однако из-за низкой производительности реализации репликации master-slave в SSDB дизайн формата хранения данных недостаточно хорош, и существует множество проблем несовместимости с Redis. API.В конце концов, в дополнение к базовой сетевой структуре Кроме того, SSDB в основном переписан.

Кроме того, поскольку механизм хранения, используемый SSDB по умолчанию, — leveldb, мы изменили его на более популярный RocksDB по таким причинам, как функциональные характеристики и проектная активность.Конечно, он также произошел от leveldb.

В настоящее время мы завершили внутреннюю разработку проекта и провели всестороннее тестирование функций, стабильности и производительности и скоро запустим. Поскольку в хранилище холода и теплообмена вовлечено много содержимого, из-за недостатка места это не будет здесь подробно описываться. Проект получил название swapdb и имеет открытый исходный код на Github.

GitHub.com/Jr Гц RD/своп…

Заинтересованные студенты могут обратить внимание, добро пожаловать, чтобы добавить звезду ~

Поддержка многокомнатной коммутации и аварийного восстановления

Мультирумная коммутация — это процесс координации и увязки компонентов сверху вниз.Существует множество факторов, которые следует учитывать.В R2M это в основном кластеры кеша, сервисы маршрутизации (такие как ZooKeeper и т. д.) и различные компоненты (Manager, Web консоль, Клиент) многокомнатной коммутации.

Многомашинное переключение уровня данных, то есть многомашинное переключение службы кэширования.

Для многокомнатной поддержки ключ заключается в том, как избежатьрасколотый мозгпроблема. Давайте начнем с рассмотрения того, как происходит расщепление мозга.

При нормальных обстоятельствах узлы кэш-кластера развертываются в одном и том же компьютерном зале и развертываются в соответствии с минимум тремя ведущими, одним ведущим и одним подчиненным.Каждый главный узел отвечает за часть данных.Если главный узел зависнет, оставшиеся главные узлы выберут своих подчиненных.Узел будет назначен новым ведущим, т. е. автоматический переход на другой ресурс.

Если вы хотите выполнить переключение компьютерного зала или аварийное восстановление нескольких компьютерных залов для важных служб, вам необходимо добавить еще один подчиненный узел к каждому главному узлу в другом компьютерном зале, тогда у каждого главного узла будет два подчиненных устройства.Во время работы, если кластер Если некоторые узлы автоматически переключаются при отказе, главный узел может переключаться в другой компьютерный зал, в результате чего главные узлы одного и того же кластера распределяются по разным компьютерным залам.

В этом случае, если есть проблема с сетевым соединением в компьютерном зале, главный узел в компьютерном зале A и главный узел в компьютерном зале B будут рассматривать друг друга в состоянии сбоя. узлы находятся в компьютерном зале A, главный узел компьютерного зала A будет выбран новый главный узел из подчиненных узлов в том же компьютерном зале, чтобы заменить главный узел компьютерного зала B, в результате чего те же осколки будут нести ответственность за главные узлы двух компьютерных залов одновременно, и клиент компьютерного зала A записывает данные этих осколков на вновь избранный главный узел в компьютерном зале A, клиент в компьютерном зале B по-прежнему записывает данные в главный узел в компьютерной комнате B, что приводит к разделению мозга и невозможности объединения данных.

Учащиеся, знакомые с Redis Cluster, могут знать, что Redis Cluster имеетcluster-require-full-coverageПараметр включен по умолчанию.Функция этого параметра такова: пока узел выходит из строя и осколки 16384 не полностью покрыты, весь кластер будет отказываться от обслуживания и сильно снизит доступность, поэтому на практике его необходимо отключить Приложения. Но проблема в том, что если возникнут вышеперечисленные проблемы, то это вызовет последствия раскола мозга.

Чтобы решить эту проблему, мы добавили Redis в сообщение о связи с кластером.datacenterID, при получении запроса на автоматическую отработку отказа главный узел сравнивает свой собственный идентификатор центра обработки данных с идентификатором центра обработки данных подчиненного узла, назначенного для отработки отказа.Если они совпадают, запрос на автоматическую отработку отказа узла будет одобрен, в противном случае запрос будет отклоненный.

Убедитесь, что автоматический переход на другой ресурс происходит только на ведомых узлах в одном и том же компьютерном зале, избегая ситуации, когда главный узел распределен в нескольких компьютерных залах. В случае ручного переключения или принудительного перехода на другой ресурс это не так. Для функции, поддерживаемой многокомпьютерной комнатой Redis, официальному лицу Redis был отправлен запрос на включение, Автор antirez сказал в дорожной карте Redis 4.2, что эта функция будет добавлена.

В настоящее время обычное переключение и переключение аварийного восстановления компьютерного зала R2M достигается переключением одним щелчком мыши на веб-консоли. Когда требуется обычное техническое обслуживание или миграция компьютерного зала, главный узел может быть переключен на подчиненные узлы через компьютерный зал в пакетном режиме посредством аварийного переключения вручную.

Стоит отметить, что нормальный процесс переключения гарантирует, что данные главного и подчиненного узлов непротиворечивы до и после переключения. Когда компьютерный зал выходит из строя из-за сбоя питания или по другим причинам, главный узел переключается на подчиненные узлы через компьютерный зал в пакетном режиме, принудительно переключаясь на другой ресурс.Из-за чрезвычайной ситуации небольшой объем данных может не синхронизироваться с подчиненными узлами. , но основная цель здесь заключается в том, чтобы для аварийного восстановления и своевременного восстановления обслуживания доступность гораздо важнее, чем несогласованность или потеря небольшого объема данных.

Мультирумное переключение компонентов системы

Многокомнатная коммутация для Cache Cluster Routing Service (ZK)

Бизнес-клиент получает через службу маршрутизации соответствующий адрес узла кэша.В нашей производственной среде ЗК каждого машинного зала развернуты независимо, то есть экземпляры ЗК разных машинных залов принадлежат разным кластерам ЗК, и бизнес каждого компьютерный зал Клиент напрямую обращается к ZK в компьютерном зале для получения кэш-узла.

В R2M конфигурация хранилища узла маршрутизации ZK в каждой компьютерной комнате одинаковая.Мы максимально упрощаем информацию в узле маршрутизации ZK.Все вещи, связанные со статусом кластера, не находятся в ZK, в основном статическая конфигурация, только расширение или автономный режим узлам нужно только изменить конфигурацию. Поэтому при переключении машинного зала никаких изменений в ЗК вносить не нужно.

Многокомнатная коммутация клиента

Сам бизнес-клиент развертывается в нескольких компьютерных залах, и проблем с несколькими компьютерными залами нет. Однако клиенту необходимо перенаправлять службы в переключаемый компьютерный зал вовремя после переключения кластера кэша между несколькими компьютерными залами. Для этого требуется уведомление каждому клиенту, распределенному по нескольким компьютерным залам, клиент, и поддержание или установление соединения с каждым клиентом, несомненно, является большой проблемой.

В R2M, поскольку клиент является интеллектуальным клиентом, при обнаружении аномалии состояние кластера может быть получено от уцелевшего узла, а изменение роли узла и переключение могут быть автоматически обнаружены, поэтому проблемы с уведомлением не возникает.

Мультирумное переключение компонентов Manager

Диспетчер является компонентом управления кэш-кластером, и через него выполняются операции по эксплуатации и обслуживанию, включая операции переключения машинных залов, поэтому Менеджер должен иметь несколько машинных залов, чтобы обеспечить возможность аварийного восстановления или нормального переключения машинных залов. выполняться в любое время.

Следует отметить, что поскольку ЗК разных машинных залов независимы, то переключение многокомпьютерного зала Менеджера не может быть реализовано непосредственно ЗК, т.к. может случиться так, что машинный зал, в котором находится зависимый от него ЗК , Поэтому мы реализовали переключатель менеджера.Функция выбора нескольких комнат (механизм, подобный плоту), несколько менеджеров могут автоматически выбирать лидеров и аварийное переключение.

Мультирумное переключение веб-консоли

Для многокомнатного переключения веб-консоли это относительно просто. Поскольку Интернет не имеет состояния, балансировка нагрузки выполняется непосредственно через Nginx, если доступны веб-компоненты любого компьютерного зала.

Мониторинг, оповещение и устранение неполадок

• Что делать, если служба вызывает тайм-аут, а индикатор производительности дрожит?

• Деловой вызов может включать несколько служб, таких как очереди сообщений, базы данных, кэши и RPC.Как убедиться, что проблема не в кэше?

• Если проблема связана со службой кэширования, является ли это проблемой машины, проблемы сети, проблемы системы или проблемы неправильного использования в бизнесе?

Когда возникают вышеперечисленные проблемы, в условиях большого количества машин, кластеров и бесчисленных экземпляров, если нет полноценной системы мониторинга и сигнализации, а также нет удобного и простого в использовании визуального интерфейса работы, остается только в растерянности, в растерянности и терпеливо Примером просмотра журналов, проверки вывода информации, проверки сетей и проверки машин является так называемая эксплуатация и техническое обслуживание человеком.

Таким образом, R2M предоставляет индикаторы мониторинга и функции сигнализации различных размеров, которые могут своевременно предупреждать о нештатных ситуациях, а также быстро обнаруживать и устранять неполадки при возникновении проблем.

Машинные и сетевые метрики

QoS сети каждой машины (коэффициент потери пакетов, количество повторных передач пакетов, количество ошибок отправки и получения), входящая и исходящая пропускная способность, ЦП, использование памяти, скорость чтения и записи на диск и т. д.

Индикаторы системных параметров

Использование памяти каждым узлом, сетевой входящий и исходящий трафик, TPS, частота совпадений запросов, количество клиентских TCP-соединений, количество исключений ключей, записи команд медленных запросов, журналы работы экземпляров и т. д.

Мониторинг в реальном времени и исторические статистические графики

Статистические диаграммы в реальном времени и исторические статистические диаграммы представляют собой обратную связь в реальном времени с различными индикаторами параметров и интуитивно понятным отображением исторических трендов.Они могут не только быстро указать направление позиционирования при возникновении проблемы, но также предоставить ценные справочные данные для работы и техническое обслуживание и развитие бизнеса.Эти справочные данные, в свою очередь, способствуют оптимизации бизнес-систем и улучшению эксплуатации и обслуживания.

Историческая статистика мониторинга экземпляров собирается и передается компонентом агента, развернутым на каждой машине. Из-за большого количества экземпляров и элементов мониторинга объем данных мониторинга может быть очень большим.

Чтобы данные мониторинга не занимали много места в базе данных, для исторической статистики мы будем хранить данные, показывающие последние 12 часов в минутах, последний месяц в часах, последний год в днях и минуты до 12 часов. , Данные автоматически объединяются с данными часового измерения, а почасовые данные одного месяца назад автоматически объединяются с данными дневного измерения.При объединении наибольшее значение, наименьшее значение и накопленное среднее значение показатели в этот период времени сохраняются.

Для диаграмм мониторинга в реальном времени соединение с соответствующим экземпляром кэша устанавливается только тогда, когда пользователь запрашивает его просмотр, а информация в реальном времени получается непосредственно из экземпляра.

Показатели производительности клиента

Отнимающая много времени статистика запросов TP50, TP90, TP99 и TP999 каждого клиента для быстрого определения проблемного IP.

Тревожный элемент

Аварийные сигналы емкости, входящий и исходящий трафик, TPS, блокировка экземпляра, сбой экземпляра, количество клиентских подключений и т. д.

Суммировать

Из-за нехватки места здесь мы можем дать только краткое введение в общие идеи дизайна и функции кэш-системы R2M, многие детали и принципы не были подробно описаны, например, горячий и холодный обмен данными, что на самом деле делается. В процессе мы столкнулись со многими проблемами, и мы надеемся подробно рассказать об этом в будущем. Наконец, я также надеюсь, что больше технических коллег примут и примут участие в открытом исходном коде, чтобы каждый мог использовать больше и лучшие колеса.

об авторе

Ли Цзинчэн (WeChat: lijingcheng87), работает в научно-исследовательском центре JD Finance в Ханчжоу, возглавляет систему распределенного кэширования JD Finance R2M, имеет краткое представление о ядре Redis, любит открытый исходный код и фокусируется на хранилище KV, распределенной архитектуре и областях, связанных с согласованностью данных. .

благодарныйЮтада ХикаруОбзор этой статьи.