Redis является незаменимым постоянным оружием в разработке интернет-продуктов. Он обладает высокой производительностью, богатой структурой данных и прост в использовании. Но в то же время он слишком прост в использовании. Нашим студентам-разработчикам все равно, какие данные, нет независимо от того, насколько велики данные, независимо от того, насколько они велики. можно ли его разделить и очистить.
Чтобы лучше использовать Redis, в дополнение к некоторым спецификациям использования Redis, вам также необходимо иметь полное представление о том, как Redis используется в Интернете. Тогда возникает вопрос: экземпляр Redis использует такой большой объем памяти, что именно в нем хранится? Что такое ключи? Сколько места занимает каждая клавиша?
В настоящее время Snowball имеет десятки кластеров Redis, почти тысячу экземпляров Redis и 5 Т данных памяти Мы также хотим проанализировать, не используется ли бизнес не по назначению для улучшения использования ресурсов. Конечно, когда-то мы были глубоко обеспокоены этой проблемой, и сегодня я поделюсь с вами тем, как я решил эту проблему, надеясь вдохновить вас.
Есть ли способ безопасно и эффективно просмотреть подробный отчет о потреблении памяти Redis? Решений всегда больше, чем проблем, и есть решения, когда есть необходимость. Команда Snowball SRE внедрила платформу визуализации данных Redis RDR (Redis Data Reveal) для решения этой проблемы. RDR может легко анализировать память Reids и понимать, какие ключи находятся в экземпляре Redis, сколько места занимают ключи какого типа, какие ключи потребляют больше всего памяти и каковы их пропорции, что очень интуитивно понятно.
Идеи дизайна
Давайте сначала разберемся, есть ли способ получить все данные Redis. С моей точки зрения, вероятно, есть следующие методы, давайте разберем преимущества и недостатки слова:
1. Сначала передайте команду keys *, чтобы получить все ключи, а затем получите все содержимое по ключу.
- Преимущества: Прямая передача по сети без использования жесткого диска машины Redis.
- Недостатки: если количество ключей очень велико, команда keys может привести к зависанию Redis и повлиять на бизнес; необходимо сделать много запросов к Redis, что потребляет много ресурсов; перемещение данных происходит слишком медленно
2. Откройте aof и получите все данные через файл aof.
- Преимущества: Нет необходимости влиять на службу Redis, полностью оффлайн операцию, достаточно безопасно;
- Недостатки: некоторые экземпляры Redis часто пишутся, поэтому они не подходят для включения AOF, и их универсальность не является сильной; файлы AOF могут быть очень большими, а передача и парсинг слишком медленными и неэффективными.
3. Используйте bgsave для получения файла rdb и получения данных после синтаксического анализа.
- Преимущества: зрелый механизм, хорошая надежность, относительно небольшие файлы, высокая эффективность передачи и разбора;
- Недостатки: хотя bgsave разветвляет дочерний процесс, это все равно может привести к зависанию основного процесса на определенный период времени, что может повлиять на бизнес;
Оценив вышеперечисленные методы, мы решили использовать период низкой нагрузки для выполнения bgsave с узла для получения файла rdb, который относительно безопасен и надежен, а также может охватывать все бизнес-кластеры Redis. То есть каждый экземпляр автоматически генерирует файл rdb каждый день в период низкой пиковой нагрузки, даже если данные отчета задерживаются на один день, это приемлемо.
Получение файла rdb эквивалентно получению всех данных экземпляра Redis, а следующим шагом является создание отчета:
- Разберите файл rdb и получите содержимое ключа и значения;
- В соответствии с соответствующей структурой данных и содержимым оценить потребление памяти и т.д.;
- формирование статистики и отчетов;
Логика очень проста, поэтому идеи дизайна очень ясны. Схема потока данных выглядит следующим образом:
Давайте посмотрим, как это реализовать.Во-первых, это выбор языка.Компоненты, разработанные Snowball SRE, в основном представляют собой серверные части, сделанные на языке Go, поэтому при выборе языка нет запутанности, и Go используется напрямую. Затем идут только что упомянутые процессы.
1. Разобрать РБД
Вы можете сделать это по протоколу Redis, вы можете найти много библиотек для разбора файлов rdb, выполнив поиск parse rdb на GitHub, и вы можете использовать их. Мы использовали https://github.com/cupcake/rdb.
2. Оцените потребление памяти
Какое использование памяти имеет запись?
Мы знаем, что в реализации Redis есть некоторые базовые структуры данных, и эти структуры используются для реализации различных типов данных, доступных для внешнего мира: таких как sds, dict, intset, zipmap, adlist, ziplist, quicklist, skiplist и т. д. . Пока вы выясняете, какие структуры данных используются в соответствии с типом данных этой записи, а затем вычисляете потребление памяти этими базовыми структурами данных, а также использование памяти данными и некоторые дополнительные накладные расходы, такие как время истечения срока действия, вы может точно оценить, сколько памяти используется.
Но поскольку Redis провел большую оптимизацию, один и тот же тип данных может использовать разные структуры данных в разных сценариях. Например, List , более старая версия Redis, будет решать, какую структуру использовать в зависимости от количества элементов в списке, adlist используется, когда он короткий, а ziplist используется, когда он длинный. Значение можно настроить с помощью список-макс-ziplist-записи.
Все версии, начиная с версии 3.2, используют быстрый список. Использование памяти различными структурами на самом деле отличается. Мы не можем получить конкретную конфигурацию при расчете, поэтому все рассчитываем в соответствии с конфигурацией по умолчанию. Окончательное значение является оценочным значением, но в основном оно может отражать использование. Если вас интересуют различные структуры данных, используемые Redis, и вы хотите понять его структуру и применимые сценарии, вы можете выполнить поиск дополнительных материалов и прочитать исходный код Redis.
Пример расчета использования памяти:
Если мы проанализируем rdb и получим запись, ключ которой — hello, значение — world, тип — строка, а ttl — 1440, использование памяти будет следующим:
- Потребление dictEntry, Redis db — это большой dict, каждая пара kv — одна из записей;
- Потребление robj, robj — это общая структура данных, используемая для хранения разных типов значений в одном и том же dict, полное название — Redis Object;
- Потребление sds для хранения ключей, sds — это структура данных, используемая для хранения строк в Redis;
- Расход времени истечения срока хранения;
- потребление sds для хранения значения;
Первые четыре элемента в основном используются для хранения любого ключа, а последний элемент зависит от структуры данных значения.
- dictEntry имеет 2 указателя, потребление памяти int64;
- robj с 1 указателем, int и несколькими полями, использующими битовые поля, потребляет в общей сложности 4 байта;
- Время истечения срока действия также сохраняется как dictEntry, а временная метка — int64;
- Для хранения sds требуется место для хранения заголовка и длины строки + 1, а длина заголовка зависит от длины строки;
Опираясь на приведенную выше информацию, мы можем рассчитать, сколько памяти действительно необходимо для подачи этой памяти на операционную систему. Так как Redis поддерживает множество алгоритмов malloc, мы рассчитываем по методу распределения jemalloc, и здесь могут быть ошибки.
Таким образом, запись с последним ключом приветствия займет всего 92 байта в 64-битной операционной системе.
Другие типы вычислений представляют собой примерно ту же идею, за исключением того, что нужно рассчитывать разное потребление памяти в соответствии с разными структурами данных.Не забывайте учитывать выравнивание памяти при расчетах. Кроме того, поскольку алгоритм zset предполагает случайную генерацию слоев, мы также используем тот же алгоритм для рандомизации, но вычисленное значение определенно не является точным, и это также является точкой ошибки.
3. Статистика
Наконец, можно получить информацию об использовании памяти для любого ключа.Какие данные являются наиболее значимыми и ценными?
- top N, несомненно, следует обратить внимание на самые большие верхние N ключей;
- Распределение количества ключей и элементов различных типов данных и использование памяти;
- В соответствии с классификацией префиксов унифицированный префикс обычно означает, что используется конкретный бизнес, и рассчитывается количество ключей и использование памяти для каждой классификации;
Эти требования также легко реализовать:
- Достаточно поддерживать небольшую верхнюю кучу для хранения первых N самых больших и, наконец, вынимать данные из кучи;
- считать;
- Как правило, будут специфические разделители, такие как :|._ и другие символы, по этим символам вырезать общий префикс и затем считать, и при этом заменить все цифры на 0, что удобно для классификации;
4. Данные отчета
Очень приятно иметь возможность открывать веб-страницу каждый день, чтобы увидеть подробности использования памяти экземпляром Redis, и использование памяти Redis больше не является черным ящиком.
Эта система предоставила нам очень важную поддержку данных для оптимизации использования ресурсов Redis, повышения эффективности и экономии затрат с момента ее запуска в течение одного года, и она полностью автоматизирована внутри.Сами разработчики могут видеть, соответствует ли текущее использование Redis соответствует ожиданиям.Очень важную роль сыграла и стабильность бизнеса. Это также является последовательной практикой команды инженеров Xueqiu.SRE предоставляет эффективные инструменты, а инженеры-разработчики могут эксплуатировать и поддерживать свои собственные бизнес-системы, что может значительно повысить эффективность производства.
Этот проект относится к проекту с открытым исходным кодом redis-rdb-tool, но его производительность в несколько раз эффективнее.Чтобы отдать должное сообществу и надеяться иметь возможность помочь всем, мы решили сделать его открытым.
Внутренняя система Snowball автоматизировала логику получения файлов rdb и их резервного копирования в соответствии со своими особыми сценариями Версия с открытым исходным кодом удаляет настройку и сохраняет логику анализа и страницы только после получения rdb.
Адрес проекта:github.com/xueqiu/rdr. Если у вас есть какие-либо вопросы, вы можете задать вопрос или связаться со мной напрямую: dongmx@xueqiu.com.
об авторе
Донг Минсинь, инженер Snowball SRE, в основном отвечающий за обеспечение стабильности Snowball, улучшение использования ресурсов и повышение эффективности разработки.
благодарныйГо ЛэйОбзор этой статьи.