Несколько друзей-испытателей пришли спросить меня, как протестировать Redis? Прежде всего нам нужно знать, что такое Redis? что оно может делать
Redis — это высокоскоростная база данных хранилища типа «ключ-значение».
Redis часто используется как кэш, очередь, публикация и подписка и т. д.
Поэтому вопрос «как тестировать Redis?» можно трансформировать в:
- Как проверить кеш?
- Как проверить очередь?
- Как протестировать подписку?
В стеке технологий, с которым я столкнулся, Redis редко используется для публикации и подписки, давайте в основном поговорим о кеше и очереди.
01. Классификация кеша
Существует несколько типов кешей: файловые кеши, кеши баз данных, кеши памяти, кеши браузера.
Кэширование браузера относится к собственным возможностям кэширования браузера. Чтобы ускорить загрузку страниц, современные браузеры часто загружают файлы ресурсов, такие как css и js, один раз, а затем кэшируют их в течение определенного периода времени, пока кеш не выйдет из строя или запрос явно не сообщит о необходимости их обновления.
Если интерфейс выводится посредством прямого рендеринга внутреннего языка , smarty и других методов рендеринга шаблона , обычно выбирается кеш типа файла.
Рисунок - файловый кеш
С быстрым развитием крупных фронтенд-технологий разделение фронтенда и бэкэнда становится все более и более популярным, а умный метод рендеринга используется все меньше и меньше, а требования к времени отклика интерфейса для бэкенд-сервисов снижаются. также становится все выше и выше Кэширование файлов больше не подходит для этого сценария Кэширование базы данных становится все более и более популярным.
Наиболее распространенными кэшами баз данных являются: redis и memcached. Обе они представляют собой распределенные системы кэширования ключ-значение.
Выше — кеш Redis
Кэш памяти аналогичен кешу базы данных, но ограничен стеком технологий, например, можно использовать Java, причем очень часто используется Java, но нельзя использовать PHP. Кэш памяти работает быстрее, чем кеш базы данных, но, поскольку объем памяти нельзя увеличивать все время, он имеет больше ограничений, и если не обращать внимания, возникнут такие проблемы, как утечка памяти.
В реальных условиях интерфейс Java часто помещает некоторые высокочастотные данные в кеш памяти в качестве кеша первого уровня, а субвысокочастотные данные помещает в Redis в качестве кеша второго уровня и, наконец, запрашивает данные из дБ.
Изображение выше — комбинированное использование
Роль кэширования:
Из приведенного выше контента вы, возможно, уже знаете, что две наиболее важные функции кэширования — ускорить доступ и снизить нагрузку на сервер и базу данных.
02. Сценарии использования кэширования
Вы спросите, а вышесказанное не имеет ничего общего с тестированием? Нет, я думаю, что знание вышеизложенного по-прежнему полезно для тестирования. Знаете ли вы , когда добавлять кеш, а когда не добавлять кеш с точки зрения технической реализации ? Это технический контроль интерфейса, который должны знать не только разработчики, но и тестировщики.
Разве вы не гордитесь, если обнаружите интерфейс, который должен добавлять кэширование без добавления кэширования перед испытанием под давлением? По сути, это соответствует роли кеша поочерёдно, когда qps интерфейса высокий (например, больше 100) или есть требование к скорости отклика, или плохая производительность сервера и производительность БД, вы можете попробовать использовать кеш для решения проблемы.
Позвольте мне привести несколько примеров:
1. В новой версии WeChat появилась дополнительная функция "статус" в личном центре.
Количество пользователей WeChat очень велико, а скорость доступа очень высока, одновременно посещают сотни тысяч человек, и каждый раз запрашивать базу данных невозможно.
Аналогично этому типу запроса, общий подход таков: сначала кэшируйте данные о состоянии пользователя в приложении (кэш браузера) и вызывайте внутренний интерфейс для запроса данных «состояния», активно отправляя или пассивно извлекая в течение определенного периода времени. time ;Интерфейс считывает данные из кэша redis/memcached и возвращает их; если объем данных не такой большой, интерфейс может напрямую читать данные из кэша памяти и возвращать их; после возврата данных кэш в пользовательское приложение обновлено.
Выше — пример 1
2. Существует страница с фоновым списком управления продуктами небольшой компании электронной коммерции.Количество посетителей невелико, а частота смены артикулов очень низкая.Его можно посетить десятки раз за 3 дня. В этом сценарии не нужно использовать кэширование, а во-вторых, вам нужно видеть обновленные данные сразу после обновления информации о продукте, что не подходит для кэширования, поэтому кэширование использовать не рекомендуется.
3. Тот же фон управления электронной коммерцией, на этот раз это страница статистики, которая подсчитывает продажи товаров вчера/сегодня/почти неделю.
Для этого сценария существует множество различных решений.
(Мы откладываем в сторону различные технические решения для статистики больших данных, и просто реализуем статистическую функцию системы)
- Нет необходимости в статистике в реальном времени
, нужно только делать регулярную статистику один раз, например, только просматривать вчерашние статистические данные: они могут быть сохранены непосредственно в БД после статистики с помощью сценария синхронизации и напрямую запрашивать БД, когда вам нужно просмотреть статистические данные - Необходимо запрашивать статистические данные в реальном времени
, но эффективность выполнения каждого статистического SQL, который необходимо запрашивать, соответствует ожиданиям: каждый раз, когда вы просматриваете данные, вы можете напрямую запрашивать базу данных, а нагрузка на базу данных невелика. в это время - Статистические данные в режиме реального времени необходимо запрашивать
, и из-за огромных бизнес-данных эффективность выполнения каждого статистического sql очень низкая или не может быть подсчитана напрямую: различные показатели могут быть суммированы, а статистические значения могут храниться в кеше. Например, требуется информация о продажах. Значение кеша +1, просто запросите кеш в это время при просмотре статистики.
03. Как создать кеш
Разобравшись со сценариями использования кеша, поговорим о том, как генерируется кеш.
Вообще говоря, есть два способа использования кеша, которые я кратко опишу как: снаружи и внутри .
Для начала поговорим о том, как в программе обрабатывается запрос интерфейса:
Рисунок выше - поток обработки программы
Это типичный MVC, Контроллер получает и обрабатывает данные запроса, Сервис обрабатывает данные, полученные в Модели, а затем Представление их выводит.
Для разных сценариев мы можем использовать несколько способов добавления разных кешей на нескольких узлах для решения разных проблем.
Например, в ответ на изменение параметров запроса, если возвращенные данные сильно связаны с параметрами запроса, целесообразно кэшировать запрошенные данные «снаружи» (после фильтрации параметров запроса). Этот тип данных обычно кэшируется на короткий период времени, например 5 минут. В основном это касается повторных запросов с одинаковыми параметрами запроса в течение короткого периода времени. Если вы столкнулись с атакой запроса, даже если срок действия кеша составляет всего 1 секунду, она все равно очень эффективна и может заблокировать большое количество запросов.
Выше — кэширование «там»
Например, в случае, если параметры запроса сильно не меняются, а возвращаемые данные очень близки к данным, хранящимся в бд, целесообразно кэшировать данные «внутри», то есть обновлять кеш при обновлении бд , В оптимальном состоянии этой ситуации достаточно только чтения кеша, и нет необходимости напрямую взаимодействовать с БД, что может значительно снизить нагрузку на БД. Этот срок действия кеша может быть установлен очень длинным.
Вверху — «внутри» тайника
04. Как обновить кеш
После разговора о генерации поговорим об обновлении кеша. После того, как кеш сгенерирован, он обычно не остается неизменным, поэтому кеш необходимо обновить.
Существует несколько способов обновления:
- Автоматическое продление после истечения срока действия: это самый ленивый способ продления. Установив срок действия кеша, новый кеш автоматически создается с помощью нового запроса после истечения срока действия кеша.
- Удалить кеш: после обновления данных базы данных удалите кеш напрямую и автоматически создайте новый кеш с помощью нового запроса.
- Сброс кеша: после обновления данных базы данных сбросьте кеш напрямую.
05. Контрольная точка кеша Redis
1. Угол тестирования производительности
Правильно ли работает функция увеличения/обновления кеша, проверьте правильность данных кеша
- Добавить связанные журналы, просмотреть журналы
- бэкдор инструмент
- Используя командную строку, memcached и reids могут войти в систему и просматривать напрямую
кеш удалить
- Действительный кеш, проверьте связанные бизнес-функции
- Кэш удаляется, а соответствующие бизнес-функции проверяются.
- Срок действия кеша истекает и истекает, memcached и redis могут устанавливать время истечения, проверять, есть ли время истечения, верно?
Чрезмерный механизм устранения: что делать, когда кэш достигает верхнего предела
проникновение в кеш
кеш-лавина
Служба кеша Redis остановлена
тайм-аут кеша
После того, как кешированные данные были изменены по ошибке, быстро восстановить указанную версию
После того, как данные кеша были удалены по ошибке, быстро восстановите данные
2. Угол проверки функции Redis
- Когда данные Redis вступают в силу, правильно ли читается?
- Данные Redis не существуют, можете ли вы нормально прочитать правильное значение из БД, записать его в Redis и вернуть на верхний уровень
- Является ли производительность нормальной, когда данные не существуют в Redis и db?
- При удалении данных согласуются ли данные в Redis и db?
Ниже приводится вспомогательная информация.Для друзей, которые занимаются [тестированием программного обеспечения], это должен быть самый полный и полный склад подготовки.Этот склад также сопровождал меня в самом сложном путешествии.Я надеюсь, что он может помочь и вам!
Апплет интервью по тестированию программного обеспечения
Банк вопросов по тестированию программного обеспечения заполнен миллионами людей! ! ! Кто знает! ! ! Самая полная мини-программа-викторина во всей сети, вы можете использовать свой мобильный телефон, чтобы делать викторины, в метро или в автобусе, сверните его!
Рассматриваются следующие разделы вопросов интервью:
1. Базовая теория тестирования программного обеспечения, 2. Веб, приложение, функциональное тестирование интерфейса, 3. Сеть, 4. База данных, 5. Linux
6. веб, приложение, автоматизация интерфейса, 7. тестирование производительности, 8. основы программирования, 9. вопросы на собеседовании, 10. вопросы открытого теста, 11. тестирование безопасности, 12. основы работы с компьютером
Метод получения информации:
