Контекст проекта

Redis является незаменимым средством в интернет-продуктовом развитии; его высокая производительность, богатая структура данных и удобство использования делают его популярным. Однако из-за своей простоты использование Redis может привести к проблемам с использованием памяти, особенно если студенты-разработчики не знают, как эффективно использовать данные, независимо от их объема. В результате Redis продолжает потреблять все больше памяти, но нет уверенности, что эти данные действительно нужны, а также нет понимания того, можно ли разделить и очистить данные. Чтобы лучше использовать Redis, помимо применения правил использования, требуется полное понимание его работы в реальных условиях. Вот вопрос: если экземпляр Redis использует так много памяти, то что именно хранится в нем? Какие ключи используются? Сколько места занимает каждый ключ?На данный момент у нас есть 4 кластера Redis команды EC Bigdata, включающие более 300 экземпляров Redis и более 500 ГБ данных. Мы хотим проанализировать, правильно ли используется бизнесом это оборудование, чтобы повысить эффективность использования ресурсов. В связи с широким применением командой бизнеса недавние темпы роста данных стали достаточно быстрыми, поэтому нам необходим инструмент для анализа данных, хранящихся в различных бизнес-приложениях, проверки наличия мертвых данных и потерь ресурсов. Одновременно отзывы бизнеса показывают, что в кластере E4 WWW Redis появились явные замедленные запросы, поэтому нам необходимо анализировать логи замедленных запросов и типы данных, такие как Hash, List и Set, выявлять большие ключи, вызывающие замедление запросов, а также наличие команд, имеющих большое количество таких ключей и некорректные установки TTL.Есть ли способ безопасно и эффективно получать детальные отчеты о потреблении памяти Redis? Решений больше, чем проблем, и где есть нужда, там найдется решение. Команда EC Bigdata реализовала платформу визуализации данных Redis (Redis Computer Tomography) для решения этой проблемы.

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

Проектный дизайн

Решение для анализа данных Redis

1. Используйте команду KEYS *, чтобы получить все ключи, затем получите содержимое каждого ключа. Преимущества: Нет необходимости использовать жесткий диск машины Redis, прямое сетевое передача

Недостатки: Если количество ключей чрезвычайно велико, команда keys может вызвать зависание Redis и повлиять на бизнес; Требуется очень много запросов для Redis, что потребляет большое количество ресурсов. Процесс прохождения данных слишком медленный

2. Откройте aof, получите все данные через файл aof

Преимущества: Не требуется влиять на работу Redis, полностью офлайн операция, достаточная безопасностьнедостатки: У некоторых экземпляров Redis частые записи, поэтому AOF не подходит для них, универсальность недостаточна; Файлы AOF могут быть чрезмерно большими, медленной передачи и парсинга, что делает процесс менее эффективным.

3. Использовать BGSAVE для получения файла RDB и получение данных после его парсинга.

преимущества: Материализованная механика и хорошая надёжность; Относительно небольшой размер файла, быстрая передача и высокая скорость парсинга;

недостатки: Хотя BGSAVE создаёт потомков процесса, это может вызвать зависание основного процесса на некоторое время, что может повлиять на бизнес;

После оценки вышеуказанных методов мы решили использовать BGSAVE для получения файла RDB с узла в период минимальной нагрузки, что является относительно безопасным и надёжным способом и также покрывает Redis кластеры всех бизнес-проектов. Получение файла RDB эквивалентно получению всех данных Redis-экземпляра. Следующий шаг — генерация отчёта:

Парсинг файла RDB для получения содержимого ключей и значений; По соответствующей структуре данных и её содержанию, оценка использования памяти; Статистика и генерация отчётов; Логика проста, поэтому идея дизайна ясна.

Схема потока данных

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