⚠️Эта статья является первой подписанной статьей сообщества Nuggets, и её перепечатка без разрешения запрещена.
Большинство баз данных из-за частой работы с диском в условиях высокой параллельной работы реагируют очень медленно. Чтобы решить эту разницу в скорости, большинство систем обычно добавляют слой кэша для ускорения данных. Redis стал актом де-факто стандарта распределенного кэша благодаря своей превосходной пропускной способности и богатой структуре данных.
Но если вы можете сделать только этот кеш Redis, тогда он будет неправильно его оценивать.
Богатая структура данных Redis делает сценарии его бизнес-использования очень обширными, а с характеристиками постоянства rdb его можно даже использовать в качестве целевой базы данных. В этом случае Redis может поддерживать половину большинства интернет-компаний, особенно социальных, игровых и прямых трансляций.
1. Redis может работать с хранилищем
Redis предоставляет очень богатый режим кластера:主从,哨兵,cluster, чтобы удовлетворить потребности в высокой доступности услуг. В то же время Redis предоставляет два метода персистентности:aofиrdb, обычно используется rdb.
пройти черезbgsaveкоманда, основной процесс создаст новый процесс и запишет его на диск. bgsave эквивалентен созданию моментального снимка, но поскольку он не имеет журнала WAL и механизма контрольных точек, он не может выполнять резервное копирование в реальном времени. Если машина внезапно теряет питание, очень легко потерять данные.
К счастью, Redis — это база данных в памяти, а скорость синхронизации основного кластера очень высока. Если ваш кластер хорошо обслуживается и распределение памяти является разумным, то, если компьютерная комната не будет отключена, SLA Redis всегда будет оставаться на очень высоком уровне.
Звучит не совсем надежно, есть вероятность потери данных! Это невыносимо в общем CRUD-бизнесе. Но почему Redis может удовлетворить потребности большинства интернет-компаний? Это также определяется бизнес-атрибутами.
Прежде чем принять решение о максимальном использовании Redis, вам необходимо убедиться, что ваш бизнес обладает следующими характеристиками:
В дополнение к основному бизнесу, у большинства предприятий низкие требования к надежности данных, и допустима ли потеря одного или двух фрагментов данных?
- Столкнувшись с конечными пользователями C, один тип данных можно быстро найти по идентификатору пользователя, а набор данных, как правило, невелик? Нет необходимости в большом количестве запросов диапазона?
- Можете ли вы жить со стоимостью данных в памяти?
- Бизнес почти не требует транзакционных операций?
К счастью, эти типы бизнес-требований очень специфичны. Например, обычные социальные, игровые, прямые трансляции и операционные предприятия могут полагаться на Redis.
2. Сценарии применения Рейда
Redis имеет свободную структуру документа, богатые типы данных и может адаптироваться к постоянно меняющимся изменениям схемы.Далее я представлю большое количество сценариев применения Redis, кроме кэширования.
2.1 Базовые пользовательские данные хранения данных
В традиционном дизайне базы данных пользовательскую таблицу очень сложно спроектировать, и при изменении она будет травмировать мышцы. Использование Redishashструктура, которая позволяет разрабатывать модели свободных данных. Некоторые нефиксированные, проверенные функциональные свойства могут быть сохранены непосредственно в хэш-значении с использованием интерфейса JSON. Используя хэш-структуру, вы можете использовать такие инструкции, как HGET и HMGET, чтобы получить только нужные вам данные, что также очень удобно в использовании.
>HSET user:199929 sex m
>HSET user:199929 age 22
>HGETALL user:199929
1) "sex"
2) "m"
3) "age"
4) "22"
Этот нестатистический сценарий больше читать и меньше писать очень подходит для использования структуры KV для хранения. Хэш-структура Redis предоставляет очень подробные инструкции, а также можно использовать определенный атрибут.HINCRBYОчень удобно увеличивать и уменьшать.
2.2 Реализация счетчика
Чуть выше упоминалась инструкция HINCRBY, а для самого Redis Key тоже естьINCRBYкомандовать, осуществлять某个值увеличивается и уменьшается.
Например, следующие сценарии: подсчитать количество лайков поста; сохранить количество подписчиков темы; сохранить количество подписчиков тега; сохранить общее количество комментариев; популярность поста; количество красных точек. сообщений; , количество избранных и т. д.
> INCRBY feed:e3kk38j4kl:like 1
> INCRBY feed:e3kk38j4kl:like 1
> GET feed:e3kk38j4kl:like
"2"
Для бизнеса, который подвержен горячим точкам, таким как Weibo, традиционные базы данных определенно неустойчивы, поэтому необходимо полагаться на базы данных в памяти. Поскольку Redis работает очень быстро, нет необходимости использовать традиционную БД, которая очень медленная.countоперации, все такие инкрементные операции выполняются на миллисекундном уровне, а все эффекты происходят в реальном времени.
2.3 Таблица лидеров
Лидерборды могут повышать мотивацию участников, поэтому это дело очень распространенное, и по сути является топовой проблемой.
В Redis есть структура данных, называемая zset, которая использует упорядоченный список, реализованный таблицей пропуска, которая может легко реализовать такие задачи, как таблицы лидеров. Когда данные, хранящиеся в zset, достигают уровня десятков миллионов или даже 100 миллионов, он по-прежнему может поддерживать очень высокую скорость одновременного чтения и записи и имеет очень хорошее среднее время отклика (в пределах 5 мс).
использоватьzaddМожно добавить новые записи, мы будем использовать оценку, связанную с рангом, в качестве значения оценки записи, а затем использоватьzrevrangeкоманда для получения данных таблицы лидеров в реальном времени иzrevrankТогда очень легко получить рейтинг пользователей в реальном времени.
>ZADD sorted:xjjdog:2021-07 55 dog0
>ZADD sorted:xjjdog:2021-07 89 dog1
>ZADD sorted:xjjdog:2021-07 32 dog2
>ZCARD sorted:xjjdog:2021-07
>3
> ZREVRANGE sorted:xjjdog:2021-07 0 -10 WITHSCORES # top10排行榜
1) "dog1"
2) "89"
3) "dog0"
4) "55"
5) "dog2"
6) "32"
2.4 Дружба
setСтруктура представляет собой коллекцию без повторяющихся данных.Вы можете использовать отдельный zset для хранения списка подписчиков пользователя, списка поклонников, двустороннего списка подписчиков, черного списка, списка лайков и т. д.
использоватьZADD,ZRANKИ т. д., добавьте черный список пользователя с помощью ZADD, а ZRANK использует возвращенное исходное значение, чтобы определить, существует ли он в черном списке. использоватьsinterКоманда, вы можете получить общих друзей A и B.
В дополнение к дружеским отношениям, данные с четкими бизнес-сценариями черного и белого списков могут храниться с использованием структуры набора. Существует много других бизнес-сценариев, таких как адресная книга, загруженная пользователем, расчет дружественных отношений адресной книги и т. д.
На практике используйте zset для хранения большего количества этих отношений. Как и set, zset не допускает дублирования значений, но zset имеет дополнительное поле для оценки.Мы можем хранить отметку времени, чтобы указать время, когда связь была установлена, что имеет более четкое деловое значение.
2.5 Подсчитайте количество активных пользователей
Слишком много разбросанных потребностей, таких как статистика ежедневных активных пользователей, регистрация пользователей и онлайн-статус пользователя. Если вы сохраните логическую переменную для каждого пользователя, она займет слишком много места. В этом случае мы можем использоватьbitmapструктура, позволяющая сэкономить много места для хранения.
>SETBIT online:2021-07-23 3876520333 1
>SETBIT online:2021-07-24 3876520333 1
>GETBIT online:2021-07-23 3876520333
1
>BITOP AND active online:2021-07-23 online:2021-07-24
>GETBIT active 3876520333
1
>DEBUG OBJECT online:2021-07-23
Value at:0x7fdfde438bf0 refcount:1 encoding:raw serializedlength:5506446 lru:16410558 lru_seconds_idle:5
(0.96s)
Обратите внимание, что если ваш идентификатор большой, вам нужно сначала выполнить предварительную обработку, иначе он займет много памяти.
Битовая карта содержит серию последовательных двоичных чисел, используя 1 бит для представления истинных и ложных вопросов. В растровом изображении вы можете использовать и, или, xor и другие битовые операции (bitop).
2.6 Распределенная блокировка
Распределенная блокировка Redis — это легкое решение. Хотя его надежность не сравнима с такими системами, как Zookeeper, распределенные блокировки Redis имеют чрезвычайно высокую пропускную способность.
Одно из самых простых действий по блокировке можно выполнить с помощью команды redis set с параметрами nx и px. Ниже приведен небольшой фрагмент простого распределенного примера кода.
public String lock(String key, int timeOutSecond) {
for (; ; ) {
String stamp = String.valueOf(System.nanoTime());
boolean exist = redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
if (exist) {
return stamp;
}
}
}
public void unlock(String key, String stamp) {
redisTemplate.execute(script, Arrays.asList(key), stamp);
}
lua операции удаления .
local stamp = ARGV[1]
local key = KEYS[1]
local current = redis.call("GET",key)
if stamp == current then
redis.call("DEL",key)
return "OK"
end
RedLock от Redisson — это наиболее часто используемое решение для распределенных блокировок, которое отличается между блокировками чтения-записи и обработкой исключений в случае нескольких экземпляров Redis.
2.7 Распределенное ограничение тока
Использование счетчика для реализации простого ограничения тока очень удобно в Redis, просто используйте incr с командой expire.
incr key
expire key 1
Эта простая реализация обычно не представляет проблемы, но в случае относительно большого трафика существует риск внезапного всплеска трафика во временном промежутке. Основная причина в том, что этот метод разделения времени слишком фиксирован, и нет схемы плавного перехода, такой как скользящее окно.
Это также RRateLimiter от redisson, который реализует то же самое.guavaПодобные распределенные инструменты ограничения тока, очень удобное использование. Вот краткий пример:
RRateLimiter limiter = redisson.getRateLimiter("xjjdogLimiter");
// 只需要初始化一次
// 每2秒钟5个许可
limiter.trySetRate(RateType.OVERALL, 5, 2, RateIntervalUnit.SECONDS);
// 没有可用的许可，将一直阻塞
limiter.acquire(3);
2.8 Очередь сообщений
Redis может реализовать простые очереди. На стороне производителя используйте LPUSH для добавления в определенный список; на стороне потребителя постоянно используйте команду RPOP для получения данных или используйте блокирующую команду BRPOP для получения данных, что подходит для нужд мелкомасштабных панических закупок.
Redis также имеет режим PUB/SUB, но pubsub больше подходит для таких сервисов, как широковещательная рассылка сообщений.
В Redis 5.0 была добавлена структура данных потокового типа. Он похож на Kafka.В нем есть концепции тем и групп потребителей.Он может обеспечивать многоадресную рассылку и постоянство и уже может удовлетворить большинство потребностей бизнеса.
Приложение 2..9 фунтов
Еще в Redis 3.2 была запущена функция GEO. пройти черезGEOADDКоманда добавляет данные широты, долготы, широты и долготы, которые могут реализовывать такие функции, как расчет расстояния между координатами, включая расчет отношений и находящихся рядом людей.
Что касается функций GEO, наиболее мощным решением с открытым исходным кодом является PostGIS на основе PostgreSQL, но для сервисов GEO общего масштаба достаточно Redis.
2.10 Более расширенные сценарии применения
Чтобы увидеть, что может сделать Redis, вы должны упомянуть следующую библиотеку клиентских классов java redisson. Redisson содержит богатые распределенные структуры данных, разработанные на основе Redis.
Redisson предоставляет множество структур данных, таких как Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap, Queue, BlockingQueue и т. д., что делает программирование на основе Redis более удобным. На github вы можете увидеть сотни таких структур данных:GitHub.com/Редис сын/Горячие…
Для определенного языка базовые массивы, связанные списки, коллекции и другие API-интерфейсы могут работать вместе для завершения большей части бизнес-разработки. Redis не является исключением: он обладает этими базовыми возможностями работы с API, а также может быть объединен в распределенные потокобезопасные приложения с высокой степенью параллелизма.
Поскольку Redis основан на памяти, он очень быстрый, и мы также будем использовать его как место хранения промежуточных данных. Например, если в Redis используется общая конфигурация, она действует как центр конфигурации; например, если токен JWT хранится в Redis, он может обойти некоторые ограничения JWT и обеспечить безопасный выход из системы.
3. Проблемы, с которыми сталкивается универсальный Redis
Redis имеет богатые структуры данных и обычно не вызывает функциональных проблем. Однако с увеличением количества запросов и повышением требований SLA мы обязаны провести некоторую трансформацию и индивидуальную разработку Redis.
3.1 Проблема высокой доступности
Redis предоставляет три режима кластера, такие как master-slave, sentinel и cluster, Среди которых режим кластера в настоящее время используется большинством компаний.
Однако кластерный режим Redis имеет много недостатков. Кластер Redis использует концепцию виртуальных слотов для сопоставления всех ключей с целочисленными слотами от 0 до 16383, что является децентрализованной архитектурой. Однако стоимость его обслуживания высока, и ведомое устройство не может участвовать в операциях чтения.
Его основная проблема заключается в ограничениях некоторых пакетных операций. Поскольку ключи хешируются для нескольких машин, такие операции, как mget, hmset и sunion, очень недружественны, и часто возникают проблемы с производительностью.
Режим Redis Master-Slave Mode - самый простой режим, но не может выполнять автоматическое отработка, обычно из переключателя, также необходимо изменить код в основном бизнесе, который невыносимо. Даже при таком компонент балансировки нагрузки HAProxy нагрузки сложность очень высока.
Режим Sentinel может значительно отражать его значение, когда количество ведущих и ведомых устройств относительно велико. Дозорный кластер может отслеживать сотни или тысячи кластеров, но обслуживание самого дозорного кластера является более сложным. К счастью, текстовый протокол Redis очень прост, а в netty кодек Redis даже предоставляется напрямую. Целесообразно разработать комплекс дозорной системы и усилить ее функции.
3.2 Разделение горячих и холодных данных
Особенность Redis заключается в том, что независимо от того, какие это данные, все они выполняются в памяти для вычислений, что вызывает очень большие затраты для предприятий с концепциями временных рядов и горячими и холодными данными. Почему большинство разработчиков предпочитают хранить данные в MySQL, а не в Redis? Помимо транзакционных требований, большой причиной является проблема исторических данных.
Обычно это переключение горячих и холодных данных выполняется промежуточным программным обеспечением. Мы также говорили выше, Redis — это текстовый протокол, очень простой. Легче создать промежуточное ПО или сделать совместимое с протоколом аналоговое хранилище Redis.
Например, в нашем Redis сохраняются только активные пользователи за последний год. Пользователь, который был неактивен в течение нескольких лет, внезапно обращается к системе, и в это время, когда мы получаем данные, нам нужно промежуточное программное обеспечение, чтобы преобразовать их и найти из более крупного и медленного хранилища.
В настоящее время роль Redis больше похожа на горячую библиотеку, больше на то, что делает традиционный уровень кэширования, что происходит, когда бизнес уже масштабируется. Но обратите внимание, что до этого момента наш код бизнес-уровня всегда был работающим API Redis. Они используют эти многочисленные функциональные инструкции, и им все равно, действительно ли данные хранятся в Redis или ssdb.
3.3 Функциональные требования
Redis также может сыграть много трюков. Например, полнотекстовый поиск. Многие люди предпочтут es, но экосистема Redis предоставляет модуль: RediSearch, который может выполнять запросы и фильтры.
Но у нас обычно больше потребностей, таких как статистика, поиск, анализ последствий операций и т. д. Такие потребности связаны с большими данными, и даже традиционные БД не справляются с этой задачей. В это время, конечно, нам нужно импортировать данные в Redis на другие платформы для расчета.
Если вы выбираете базу данных redis, то dba имеет дело с rdb, а не с binlog. Существует множество инструментов синтаксического анализа rdb (таких как redis-rdb-tools), которые могут регулярно анализировать rdb в записи и импортировать их на другие платформы, такие как hadoop.
На этом этапе rdb становится основой всех команд и становится основным форматом обмена данными. Бизнес после импорта в другую базу данных, как играть, как играть, не сможет работать, потому что бизнес-система выбирает Redis.
4. Резюме
Большинство бизнес-систем работают на Redis, что невообразимо для многих студентов, использующих MySQL в качестве бизнес-систем. Я полагаю, что после прочтения приведенного выше введения вы сможете получить общее представление о функциях хранения, которые может реализовать Redis. Откройте свое социальное приложение, игровое приложение, видеоприложение и посмотрите, сколько они могут покрыть?
Здесь я хочу подчеркнуть, что некоторые данные не обязательно должны находиться в СУБД, чтобы считаться безопасными, и они не являются строгим требованием.
Тогда, поскольку Redis такой мощный, зачем тогда хранилище, такое как mysql и tidb? Ключ лежит в атрибутах бизнеса.
Если в бизнес-системе данные каждого взаимодействия представляют собой очень большой результирующий набор и включают в себя очень сложную статистику и работу по фильтрации, тогда необходима СУБД; но если система может быстро определить тип данных с помощью определенного идентификатора, этот тип данных в обозримом будущем ограничено, очень подходит для Redis存储.
В системе электронной коммерции выбор Redis в качестве хранилища — это смертный приговор, но социальная система гораздо счастливее. Выбор правильного инструмента в правильной сцене — это то, что мы должны сделать.
Однако ключом к успеху является способность системы быстро реагировать на изменения в период проверки продукта, быстро разрабатываться и запускаться. Это также самое большое преимущество использования Redis в качестве базы данных. Не пугайтесь крайне низкой вероятности потери данных. Ваша система, даже прочная, как сталь, ничего не стоит по сравнению с успехом вашего продукта.
⚠️Эта статья является первой подписанной статьей сообщества Nuggets, и её перепечатка без разрешения запрещена.