#Обнаружение и обработка BigKey

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

#Что такое BigKey

BigKey в Redis — это не сам ключ, а размер значения, связанного с этим ключом. BigKey обычно оцениваются по двум критериям: потреблению памяти и количеству элементов. Распространённые пороговые значения включают:

• String: размер превышает 5 МБ
• List: количество элементов превышает 20 000
• Set: количество элементов превышает 10 000
• Sorted Set: количество элементов превышает 10 000
• Hash: количество полей превышает 10 000

Примечание: Эти пороговые значения приведены в качестве рекомендаций и могут потребовать корректировки в зависимости от вашей конкретной среды и требований.

#Влияние BigKey

BigKey могут негативно влиять на производительность и стабильность сервиса Redis несколькими способами:

• Блокировка потока: Redis обрабатывает данные в однопоточном режиме. Операции с BigKey могут занимать много времени, блокируя выполнение других команд и ухудшая общую производительность сервиса.
• Таймауты клиентов: Из-за однопоточной архитектуры операции с BigKey могут привести к тому, что Redis перестанет отвечать на запросы клиентов, вызывая таймауты соединений.
• Перегрузка сетевого канала: Передача BigKey требует значительной пропускной способности сети. Например, ключ размером 1 МБ, к которому обращаются 1000 раз в секунду, создаст нагрузку в 1 ГБ/с, что может перегрузить стандартную сетевую инфраструктуру.

В кластерах возникают дополнительные проблемы:

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

#Обнаружение BigKey

#Обнаружение с помощью инструментов инспекции

Alauda Application Services предоставляет Inspections для обнаружения BigKey в экземплярах Redis.

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

   На кластере, где расположен экземпляр, отредактируйте функцию RdsInstaller для включения обнаружения BigKey.

   # Сначала проверьте конфигурацию RdsInstaller
   $ kubectl -n rds-system get RdsInstaller rds -o yaml

   Вывод будет следующим:

   apiVersion: middleware.alauda.io/v1
   kind: RdsInstaller
   metadata:
     name: rds
   spec:
     ......
     inspection:
       concurrency: "10"
       dependency: true
       env:
       - name: ENABLE_REDIS_KEYS_INDICATOR
       image: xxx
       imagePullPolicy: Always
       instanceReportLimit: "10"
       name: inspection-operator
       namespace: rds-system
       ......

2. Измените значение переменной окружения ENABLE_REDIS_KEYS_INDICATOR и сохраните изменения.

   $ kubectl -n rds-system edit RdsInstaller rds

   Измените значение ENABLE_REDIS_KEYS_INDICATOR в spec.inspection.env на 1. Изменённый экземпляр будет выглядеть так:

   apiVersion: middleware.alauda.io/v1
   kind: RdsInstaller
   metadata:
     name: rds
   spec:
     ......
     inspection:
       concurrency: "10"
       dependency: true
       env:
       - name: ENABLE_REDIS_KEYS_INDICATOR
         value: "1"
       image: xxx
       imagePullPolicy: Always
       instanceReportLimit: "10"
       name: inspection-operator
       namespace: rds-system
       ......

   После сохранения инструмент инспекции Operator перезапустится. Вы можете проверить прогресс перезапуска с помощью следующей команды:

   $ kubectl -n rds-system get pods -l name.operator=inspection-operator

   Вывод будет следующим:

   $ kubectl -n rds-system get pods -l name.operator=inspection-operator
   NAME                                   READY   STATUS    RESTARTS   AGE
   inspection-operator-545468bd54-9g65p   1/1     Running   0          8s

   Примечание: указанное изменение не является постоянным; конфигурация будет перезаписана при обновлениях платформы.

3. Запустите инспекцию

   В разделе Redis -> Details Info нажмите кнопку Inspection для запуска инспекции экземпляра.

   После запуска кнопка отобразит Inspecting.... По завершении кнопка снова станет активной.

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

4. Просмотр результатов инспекции

   По завершении инспекции вы можете нажать кнопку Query в отчёте инспекции на странице Redis -> Detail Info для просмотра результатов.

   

   Если в экземпляре действительно есть BigKey, в результатах инспекции будет перечислен BigKey Top5, как показано на рисунке ниже:

   

#Ограничения использования

• Инструмент инспекции выполняет полный скан данных Redis, что может создавать нагрузку на сервис; рекомендуется использовать в периоды низкой нагрузки.
• В настоящее время инструмент инспекции поддерживает обнаружение только типов string, list и zset.

#Обнаружение с помощью командной строки

Сообщество Redis предоставляет возможность обнаружения BigKey с помощью redis-cli. При обнаружении происходит обход/выборка всех ключей в экземпляре Redis с возвратом общей статистики по ключам и самого большого ключа каждого типа данных. В настоящее время анализируются типы string, list, set, zset, hash и stream. Команда для запуска:

$ redis-cli -h <host> -a <password> --bigkeys

#Ограничения использования

• Обнаружение с помощью redis-cli также выполняет полный скан данных Redis, что может создавать нагрузку на сервис; рекомендуется использовать в периоды низкой нагрузки.

#Оптимизация BigKey

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

#Оптимизация структур хранения данных

Для коллекционных типов с большим количеством элементов (таких как list, set, zset, hash и др.) рекомендуется разбивать их на несколько ключей, обеспечивая разумное количество элементов на каждый ключ. В архитектуре Redis кластера разделение больших ключей значительно улучшает баланс памяти между шардированными данными.

#Сжатие данных

Если хранится большое количество JSON или HTML кэша, рассмотрите возможность сжатия данных. Также можно использовать протоколы сериализации, такие как ProtoBuffer или MessagePack, для уменьшения размера данных.

#Регулярная очистка устаревших данных

Для данных с определённым временем жизни можно автоматически очищать устаревшие данные, устанавливая время истечения. Для данных с неопределённым временем жизни рекомендуется периодическая очистка. Это особенно актуально для структур данных list, set, zset и hash, которые могут накапливать большое количество устаревших элементов; поэтому рекомендуется использовать комбинацию SCAN и DEL для удаления невалидных элементов.

Независимо от выбранной схемы оптимизации, необходимо проявлять особую осторожность при использовании команды DEL для очистки существующих BigKey, так как DEL блокирует сервис Redis. Рекомендуется использовать команду UNLINK, которая удаляет ключи асинхронно, не блокируя сервис Redis.