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

Я организовал содержание книги по пяти пунктам:

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

Приступим к содержанию первой части и еще раз посмотрим на Redis.

Эта серия основана на: redis-3.2.12

Редис не панацея

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

Что может Редис

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

Таблица лидеров, если вы используете для этого традиционную реляционную базу данных, очень хлопотно, но очень удобно использовать структуру данных SortSet Redis;

Калькулятор/ограничитель скорости, используя операцию атомарного автоинкремента в Redis, мы можем подсчитывать похожие лайки пользователей, доступы пользователей и т. д. Если для таких операций используется MySQL, частое чтение и запись будут оказывать значительное давление; Типичный сценарий использования ограничитель скорости предназначен для ограничения частоты доступа пользователя к определенному API.Обычно используемый из них заключается в том, чтобы пользователи не лихорадочно нажимали, чтобы оказать ненужное давление;

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

Простая очередь сообщений, в дополнение к режиму публикации/подписки самого Redis, мы также можем использовать List для реализации механизма очереди, такого как: уведомление о прибытии, отправка почты и другие требования, не требующие высокой надежности, но приносящие очень большое давление DB, вы можете использовать список для завершения асинхронной развязки;

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

Что Redis не может сделать

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

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

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

Всегда есть причина выбрать

Выше упоминались некоторые сценарии использования Redis, поэтому есть много других вариантов решения этих сценариев, например, Memcache можно использовать для кеширования, MySql — для разделения сеансов, а RabbitMQ — для очередей сообщений. мы должны использовать Redis?

Быстрый, полностью основанный на памяти, реализованный на языке C, сетевой уровень использует epoll для решения проблем с высоким параллелизмом, а однопоточная модель позволяет избежать ненужного переключения контекста и условий гонки;

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

Богатые типы данных, Redis имеет 8 типов данных, наиболее часто используемыми являются String, Hash, List, Set, SortSet. Эти 5 типов организуют данные на основе ключевых значений. Каждый тип данных предоставляет очень богатые рабочие команды, которые могут удовлетворить большинство потребностей.Если есть особые потребности, вы можете создавать новые команды самостоятельно с помощью сценария lua (с атомарностью);

В дополнение к предоставленным богатым типам данных Redis также предоставляет персонализированные функции, такие как анализ медленных запросов, тестирование производительности, Pipeline, транзакции, пользовательские команды Lua, растровые изображения, HyperLogLog, публикация/подписка, Geo и т. д.

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

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

Личный общедоступный номер: