Данные часто используемой базы данных SQL хранятся на диске.Хотя соответствующий кеш также создается в нижней части базы данных, чтобы уменьшить нагрузку на ввод-вывод базы данных, кеш базы данных обычно предназначен для содержимого запроса, и степень детализации относительно невелика, как правило, только когда данные в таблице не изменились, кэш базы данных будет работать только, но это не снижает давление ввода-вывода бизнес-логики на операции добавления, удаления и модификации базы данных. Технология кэширования появляется по мере необходимости, и кэш может значительно снизить нагрузку на серверную базу данных.
Основная архитектура приложений
клиентКогда делается запрос к базе данных, первыйслой кэшаПроверяем, есть ли требуемые данные, если в слое кеша есть данные, требуемые клиентом, возвращаем их прямо из слоя кеша, в противном случае переходим кпроникающий запрос,правильнобаза данныхЗапрос, если данные запрашиваются в базе данных, запишите данные обратно в уровень кеша, чтобы в следующий раз, когда клиент снова запрашивает, данные можно было получить непосредственно из уровня кеша.
Промежуточное ПО для кэширования — разница между Memcache и Redis
Memcache: слой кода похож на Hash.
1. Поддержка простых типов данных 2. Не поддерживает постоянное хранение данных 3. Не поддерживает master-slave 4. Фрагментация не поддерживается
Redis
1. Богатые типы данных 2. Поддержка постоянного хранения данных на диске 3. Поддержка мастер-раб 4. Поддержка шардинга
Почему Redis такой быстрый
Redis очень эффективен, и официальные данные100000+QPS(query per second),Это потому что:
1. Redis полностью основан на памяти, большинство запросов — это операции с чистой памятью, а эффективность выполнения высока. 2. Redis использует базу данных однопоточной модели с одним процессом (K, V) для хранения данных в памяти, а доступ не ограничивается операциями ввода-вывода на жестком диске, поэтому скорость его выполнения чрезвычайно высока, и один поток также может обрабатывать большие объемы данных. Параллельные запросы также могут избежать частого переключения контекста и блокировки конкуренции, и вы можете запускать несколько экземпляров, если хотите работать на нескольких ядрах. 3. Структура данных проста, и операция с данными также проста. Redis не использует таблицы и не заставляет пользователей связывать каждое отношение, и не будет никаких сложных ограничений отношений. Его структура храненияпара ключ-значение, как и в случае с HashMap, самое большое преимущество HashMap заключается в том, что временная сложность доступа составляет O(1). 4. Redis использует многоканальную модель мультиплексирования ввода-вывода, котораянеблокирующий ввод-вывод(Неблокирующий ввод-вывод напишет другое объяснение, вы можете сначала перейти на Baidu).
Примечание: функция мультиплексирования ввода-вывода, используемая Redis:epoll/kqueue/evport/select Стратегия выбора: 1. В соответствии с местными условиями в качестве базовой реализации предпочтительнее использовать функцию мультиплексирования ввода/вывода с временной сложностью O(1). 2. Поскольку select должен пройти каждый ввод-вывод, его временная сложность составляет O(n), что обычно используется в качестве итогового решения. 3. Прислушивайтесь к событиям ввода-вывода на основе шаблона проектирования реагирования.
Типы данных Redis
String
Самый простой тип данных, его значение может хранить до 512 МБ, и он безопасен для двоичных файлов (Redis String может содержать любые двоичные данные, включая объекты jpg и т. д.).
Примечание. Если одна и та же пара «ключ-значение» с одним и тем же ключом записывается повторно, более поздняя запись перезапишет предыдущую.
Hash
Словарь элементов String, подходящий для хранения объектов.
List
Список, отсортированный по порядку вставки элементов String. Его порядокпоследний пришел первый вышел. Из-за своих характеристик стека он может достигать таких результатов, как "Таблица лидеров последних новостей"Такая функция.
Set
Неупорядоченная коллекция, состоящая из элементов String, реализуется через хеш-таблицу (время добавления, удаления, изменения и проверки составляет O(1)), а повторение не допускается.
Кроме того, когда мы используем smembers для обхода элементов в наборе, порядок также является неопределенным, что является результатом операции хеширования. Redis также предоставляет такие операции, как пересечение, объединение и различие для множеств, которые могут быть реализованы какобщие заботы, общие друзьяи другие функции.
Sorted Set
пройти черезДробная частьсортировать элементы множества от меньшего к большему.
Более продвинутые типы Redis
HyperLogLog для подсчета, Geo для поддержки хранения информации о геолокации.
Запрос ключа с фиксированным префиксом из большого количества ключей
Допустим, в redis миллиард ключей, как из такого количества ключей найти ключ с фиксированным префиксом?
Метод 1: Используйте KEYS[шаблон]: найдите все ключи, соответствующие заданному шаблону шаблона.
Используйте команду keys [pattern], чтобы найти все ключи, соответствующие условиям шаблона, но keys вернет все ключи, соответствующие условиям одновременно, поэтому это приведет к зависанию redis.Предполагая, что redis находится в рабочей среде на на этот раз использование этой команды вызовет скрытые опасности, и если все ключи возвращаются одновременно, потребление памяти также огромно при определенных условиях.
пример: keys test* //返回所有以test为前缀的key
Способ 2: Используйте курсор SCAN [Шаблон MATCH] [COUNT count]
курсор: курсор
Шаблон MATCH: условие для ключа запроса
count: количество возвращенных товаров
СКАН - этоитератор на основе курсора, который должен продолжить предыдущий итерационный процесс на основе последнего курсора. СКАНИРОВАНИЕ с0В качестве курсора начните новую итерацию, пока команда не вернется к курсору 0, чтобы завершить обход. Эта команда не гарантирует, что каждое выполнение вернет заданное количество элементов или даже 0 элементов, но пока курсор не равен 0, программа не будет считать команду SCAN окончанием, но количество возвращенных элементов, вероятно, чтобы соответствовать параметру count. . Кроме того, SCAN поддерживает нечеткие запросы.
пример: SCAN 0 MATCH test* COUNT 10 //每次返回10条以test为前缀的key
Как реализовать распределенные блокировки через Redis
Распределенная блокировка
Распределенная блокировкаЭто реализация блокировки, которая контролирует общий доступ к общим ресурсам между распределенными системами. Если система или ресурс совместно используются разными хостами разных систем, часто необходимовзаимоисключающий, чтобы устранить помехи и обеспечить согласованность данных. Проблемы, которые должны решить распределенные блокировки, следующие:
1.взаимная исключительность: только один клиент получает блокировку в любой момент времени, и два клиента не могут получить блокировку одновременно.
2.безопасность: Блокировка может быть удалена только клиентом, удерживающим блокировку, но не другими клиентами.
3.тупик: Клиент, получивший блокировку, по какой-то причине не работает и не может снять блокировку. Другие клиенты больше не могут получить блокировку, что приводит к взаимоблокировке. В настоящее время требуется специальный механизм, чтобы избежать взаимоблокировки.
4.Отказоустойчивость: когда каждый узел, например узел redis, выходит из строя, клиент все еще может получить или снять блокировку.
Как использовать Redis для реализации распределенных блокировок
Реализовано с помощью SETNX
SETNX key value: Если ключ не существует, создайте и присвойте значение. Временная сложность этой команды равна O(1).Если настройка выполнена успешно, возвращается 1, в противном случае возвращается 0.
так какSETNXКоманда проста в использовании иатомарность, поэтому люди часто использовались в качестве распределенных блокировок в первые дни. Когда мы применяем его, мы можем использовать команду SETNX перед общей областью ресурсов, чтобы проверить, успешна ли настройка.успешно установленоЭто означает, что ни один клиент впереди не обращается к ресурсу, еслиОшибка установкиЭто означает, что клиент обращается к ресурсу, и текущему клиенту нужно подождать. Но если это произойдет, это будетсуществует проблема,так какSETNX здесь, чтобы остаться, поэтому если предположить, что клиент обращается к ресурсу и блокирует его, то, когда клиент завершает доступ, блокировка все еще существует, и последний не может успешно получить блокировку.Как решить эту проблему?
так какSETNX не поддерживает входящие параметры EXPIRE, поэтому мы можем напрямую использовать инструкцию EXPIRE, чтобы установить время истечения срока действия для определенного ключа.
использование:EXPIRE key seconds
программа:
RedisService redisService = SpringUtils.getBean(RedisService.class);
long status = redisService.setnx(key,"1");
if(status == 1){
redisService.expire(key,expire);
doOcuppiedWork();
}
Проблемы с этой программой: Предположим, программа запускается на вторую строку и возникает исключение, тогда программа завершается до того, как будет установлено время истечения срока действия, и ключ всегда будет существовать, что эквивалентно удерживаемой блокировке и не может быть снято. Основная причина этой проблемы:Атомарность не удовлетворена. решать:отВерсия Redis 2.6.12Для начала мы можем использовать операцию Set для интеграции Setnx и истечения срока действия для выполнения следующим образом.
SET KEY value [EX seconds] [PX milliseconds] [NX|XX]
EX second: установить срок действия ключа на секундувторой. PX millisecond: установить время истечения срока действия ключа в миллисекундах.миллисекунда. NX: только включ не существуетКогда ключ установлен, ключ установлен. XX: только включ уже существуетКогда ключ установлен, ключ установлен. Примечание: OK будет возвращено только после успешного завершения операции SET, в противном случае будет возвращено nil.
С помощью SET мы можем реализовать распределенные блокировки в программе, используя следующий код:
Используйте список в упомянутой выше структуре данных Redis в качестве очереди Rpush для создания сообщений и LPOP для потребления сообщений.
На данный момент мы видим, что очередь использует производственную очередь rpush и очередь потребления lpop. В этой очереди производитель-потребитель, когда lpop не имеет сообщений, это доказывает, чтоВ очереди нет элементов, и производитель не успел создать новые данные. недостаток: lpop не ждет значения в очереди перед потреблением, а потребляет напрямую. макияж, мириться: может быть введен на прикладном уровнеМеханизм снаВызов LPOP для повторной попытки.
использовать клавишу BLPOP [клавиша...] тайм-аут
Тайм-аут клавиши BLPOP [клавиша ...]: Блокировка до тех пор, пока в очереди не появятся сообщения или не истечет время ожидания.
недостаток: Согласно этому методу, данные, которые мы производим, могут быть предоставлены только каждому отдельному потребителю для потребления.
Можно ли осознать, что одно производство может потребляться несколькими потребителями?
pub/sub: шаблон подписки на тему
Отправитель (pub) отправляет сообщения, а подписчики (sub) получают сообщения.
Подписчики могут подписаться на любое количество каналов
Недостатки шаблона pub/sub: Публикация сообщений не имеет состояния, и ее доступность не может быть гарантирована. Для издателя сообщение "мгновенно отправляется и теряется". В это время, если потребитель выходит из сети, когда производитель публикует сообщение, а затем возвращается в сеть, сообщение не может быть получено. Чтобы решить эту проблему, вам необходимо используйте профессиональные очереди сообщений, такие как kafka... Я не буду здесь вдаваться в подробности.
Стойкость Redis
что такое настойчивость
Постоянство означает, что данные хранятся постоянно, не влияя на целостность данных из-за сбоя питания или других сложных внешних условий. Поскольку Redis хранит данные в памяти, а не на диске, после отключения памяти данные, хранящиеся в Redis, исчезают, чего пользователи часто не ожидают, поэтому Redis имеет механизм сохранения для обеспечения безопасности данных.
Как Redis обеспечивает постоянство
Redis в настоящее время имеет два метода сохранения, а именноRDBиAOF, RDB реализует сохраняемость данных, сохраняя полные снимки данных в определенный момент времени.При восстановлении данных данные восстанавливаются непосредственно через снимки в файле rdb.
Постоянство RDB (моментального снимка): сохранение моментального снимка всего объема данных в определенный момент времени.
Постоянство RDB сохраняет моментальный снимок всего объема данных в этот момент времени с определенным интервалом.
Файл конфигурации РБД:
redis.conf:
save 900 1 #在900s内如果有1条数据被写入，则产生一次快照。
save 300 10 #在300s内如果有10条数据被写入，则产生一次快照
save 60 10000 #在60s内如果有10000条数据被写入，则产生一次快照
stop-writes-on-bgsave-error yes
#stop-writes-on-bgsave-error ：
如果为yes则表示，当备份进程出错的时候，
主进程就停止进行接受新的写入操作，这样是为了保护持久化的数据一致性的问题。
Создание и загрузка RDB
SAVE: заблокируйте серверный процесс Redis, пока не будет создан файл RDB. Команда SAVE используется редко, потому что она блокирует основной поток для обеспечения записи моментальных снимков.Поскольку Redis использует один основной поток для получения всех клиентских запросов, это блокирует все клиентские запросы. BGSAVE: эта команда разветвляет дочерний процесс для создания файла RDB, не блокируя серверный процесс.Дочерний процесс получает запрос и создает моментальный снимок RDB, а родительский процесс продолжает получать запрос клиента. Когда дочерний процесс завершает создание файла, он посылает сигнал родительскому процессу, в процессе получения клиентского запроса родительский процесс получает сигнал дочернего процесса путем опроса через определенный интервал времени. Мы также можем использоватьlastsaveкоманда для проверки успешности выполнения bgsave, lastsave может вернуть время последнего успешного выполнения bgsave.
Как автоматизировать запуск сохраняемости RDB
1. По таймингу SAVE m n в конфигурации redis.conf (фактически используется BGSAVE) 2. Во время репликации master-slave автоматически запускается главный узел. 3. Выполните перезагрузку отладки 4. Выполните завершение работы, и сохранение AOF не включено.
Принцип BGSAVE
запускать: 1. Проверьте, есть ли дочерний процесс, выполняющий задачи сохранения AOF или RDB. Возвращает false, если он есть. 2. Вызвать исходный код RedisrdbSaveBackgroundметод, выполните fork() в методе, чтобы создать дочерний процесс для выполнения операции rdb.
3. О копировании при записи в fork() fork() создает дочерние процессы в linux, используя Copy-On-Write (технология копирования-при-записи), т.е.Если несколько вызывающих объектов запрашивают один и тот же ресурс (например, память или хранилище данных на диске) одновременно, они совместно получат один и тот же указатель на один и тот же ресурс, и система фактически не будет копировать до тех пор, пока вызывающий не попытается изменить содержимое ресурса. ресурс Выделенная копия предоставляется вызывающему абоненту, в то время как исходный ресурс, видимый другим вызывающим абонентам, остается неизменным..
Метод сохраняемости RDBнедостаток
1. Данные в памяти полностью синхронизированы.В случае большого объема данных производительность будет серьезно снижена из-за операций ввода-вывода. 2. Данные от текущего до последнего моментального снимка могут быть потеряны из-за простоя Redis.
Сохранение AOF (Append-Only-File): сохранение состояния записи
Постоянство AOF записывает базу данных, сохраняя состояние записи Redis. По сравнению с RDB,постоянство RDBзаключается в записи базы данных путем резервного копирования состояния базы данных, иСохранение AOFКоманда, полученная резервной базой данных. 1. AOF записывает все инструкции по изменению состояния базы данных, кроме запросов. 2. СИнкрементныйФорма прилагается к файлу AOF.
Включить сохранение AOF
1. Откройте файл конфигурации redis.conf и измените атрибут appendonly на yes. 2. Измените атрибут appendfsync, который может принимать три параметра, а именно всегда, каждую секунду, нет,alwaysУказывает, что содержимое буфера всегда сразу же записывается в файл AOF.everysecУказывает, что содержимое буфера записывается в файл AOF каждую секунду.noУказывает, что операция записи в файл остается за операционной системой.Вообще говоря, учитывая эффективность, операционная система будет ждать заполнения буфера перед записью данных буфера в файл AOF.
appendonly yes
#appendsync always
appendfsync everysec
# appendfsync no
Перезапись журнала для решения проблемы роста файла AOF
С постоянным увеличением операций записи файл AOF будет становиться все больше и больше. Предполагая, что счетчик увеличивается 100 раз, если используется метод сохранения RDB, нам нужно только сохранить окончательный результат 100, а метод сохранения AOF должен записать инструкции этих операций увеличения 100. Фактически, чтобы восстановить эту запись , нужно всего лишь выполнить одну команду, чтобы сотни команд можно было сократить до одной. Redis поддерживает такую функцию, которая может перезаписывать файлы AOF без прерывания службы переднего плана, а также использует COW (копирование при записи). Процесс перезаписи выглядит следующим образом: 1. Вызовите fork(), чтобы создать дочерний процесс. 2. Дочерний процесс записывает новый AOF во временный файл, не полагаясь на исходный файл AOF. 3. Основной процесс продолжает одновременно записывать новые изменения в память и исходный AOF. 4. Основной процесс получает сигнал завершения подпроцесса, перезаписывающего AOF, и синхронизирует добавочные изменения с новым AOF. 5. Замените старый файл AOF новым файлом AOF.
Преимущества и недостатки AOF и RDB
Преимущества RDB: полные снимки данных, небольшие файлы и быстрое восстановление. Недостатки RDB: данные после последнего снимка не могут быть сохранены. Преимущества AOF: высокая читабельность, подходит для сохранения добавочных данных, данные нелегко потерять. Недостатки AOF: большой размер файла и долгое время восстановления.
Гибридный метод сохраняемости RDB-AOF
После redis4.0 этот метод персистентности был представлен, и RDB использовалась в качествеполная резервная копия, АОФ какИнкрементное резервное копированиеи используйте этот метод как метод по умолчанию. В приведенных выше двух методах метод RDB заключается в записи полного объема данных в файл RDB.Характеристики этой записи заключаются в том, что файл имеет небольшой размер и быстрое восстановление, но данные после последнего моментального снимка не могут быть сохранены. AOF хранит команду redis в файле, что приводит к большому размеру файла, длительному времени восстановления и другим недостаткам. существуетRDB-AOFВ этом режиме стратегия сохраняемости сначала записывает данные из кэша в файл в режиме RDB, а затем добавляет новые данные после записи в данные RDB в режиме AOF. добавляется в файл.Данные перезаписываются в файл в виде RDB. Этот метод позволяет не только повысить эффективность чтения, записи и восстановления, но и уменьшить размер файла, обеспечив при этом целостность данных. В процессе персистентности этой стратегии дочерний процесс будет считывать добавочные данные из родительского процесса через конвейер.При сохранении полного объема данных в формате RDB он также будет считывать данные через конвейер, не вызывая блокировки конвейера. Можно сказать, что в таком постоянном файле первая половина — это полные данные в формате RDB, а вторая половина — это инкрементные данные в формате AOF. В настоящее время этот метод является более рекомендуемым.
Восстановление данных Redis
Процесс восстановления при сосуществовании файлов RDB и AOF
Как видно из рисунка, когда Redis запускается, он сначала проверяет, существует ли AOF.Если AOF существует, AOF будет загружен напрямую.Если AOF не существует, будет загружен файл RDB напрямую.
Pineline
Конвейер похож на конвейер Linux, он позволяет Redis выполнять инструкции пакетами. Redis основан на модели «запрос/ответ», и для обработки одного запроса требуется ответ «один к одному». Если одновременно необходимо выполнить большое количество команд, каждая команда должна дождаться выполнения предыдущей команды, прежде чем продолжить выполнение, что не только увеличивает RTT, но также многократно использует системный ввод-вывод. Так как Pipeline может выполнять инструкции пакетами, это может сэкономить время на несколько операций ввода-вывода и запросить ответ туда и обратно. Но если между инструкциями есть зависимости, рекомендуется отправлять инструкции пакетами.
Механизм синхронизации Redis
Принцип синхронизации ведущий-ведомый
Redis обычно используетMasterузел для выполнения операций записи, в то время как несколькоSlaveУзлы выполняют операции чтения. Master и Slave представляют разные экземпляры RedisServer. Кроме того, Slave выбирается отдельно для регулярных операций резервного копирования данных, что может максимизировать производительность Redis для обеспечения данных.слабая консистенцияиокончательная согласованность. Кроме того, данные ведущего и ведомого не обязательно синхронизировать в реальном времени, но данные ведущего и ведомого обычно синхронизируются через определенный период времени, которыйокончательная согласованность.
Полный процесс синхронизации
1. Ведомое устройство отправляет команду синхронизации ведущему устройству. 2. Мастер запускает фоновый процесс для сохранения моментального снимка данных в Redis в файл. 3. Мастер кэширует команды записи, полученные во время моментального снимка данных. 4. После того, как Мастер завершит операцию записи файла, он отправляет файл на Ведомое устройство. 5. Замените старый файл AOF новым файлом AOF. 6. Ведущее устройство отправляет добавочные команды записи, собранные за этот период, подчиненному устройству.
Процесс инкрементной синхронизации
1. Ведущее устройство получает инструкцию пользователя и определяет, следует ли передать ее подчиненному устройству. 2. Добавьте запись операции в файл AOF. 3. Распространение операции на другие слейвы: 1. Выравнивание библиотеки master-slave 2. Запись инструкций в кеш ответов. 4. Отправьте данные в кэш на раб.
Редис Сентинел
Недостатки режима ведущий-подчиненный: когда ведущий не работает, кластер Redis не сможет выполнять внешние операции записи. Redis Sentinel решает эту проблему. Решить проблему переключения ведущий-ведомый после синхронизации ведущий-ведомый Ведущий не работает: 1. Мониторинг: проверьте, нормально ли работают главный и подчиненный серверы. 2. Напоминание: отправляйте уведомления об ошибках администраторам или другим приложениям через API. 3. Автоматическое аварийное переключение: переключение master-slave (после выхода мастера из строя один из слейв становится ведущим, а остальные слейвы синхронизируют данные с узла).
Кластер Redis
Принцип: Как быстро найти то, что вам нужно, из массива данных?
Фрагментация
Разделяйте данные по определенным правилам и храните их разбросанными по нескольким узлам. Уменьшите нагрузку на один сервер Redis, разделив данные между несколькими серверами Redis.
Последовательный алгоритм хеширования
Поскольку данные должны быть сегментированы, обычным методом является получение хеш-значения узла, а затем вычисление модуля в соответствии с количеством узлов, но у этого метода есть очевидные недостатки.Когда количество узлов Redis необходимо динамически увеличивается или уменьшается, это приведет к тому, что большое количество ключей не может быть нажато. Итак, Redis представилПоследовательный алгоритм хеширования. алгоритмВозьмите модуль 2 ^ 32 и сформируйте виртуальное кольцо из пространства значений хэша., запрессовано все кольцопо часовой стрелкеОрганизация направления, каждый узел имеет последовательность 0, 1, 2...2^32-1, а затем каждый сервер подвергается хэш-операции для определения адреса сервера в этом хеш-кольце.После определения адреса сервера используйте данные Тот же алгоритм хеширования находит данные на конкретном сервере Redis. Если в найденном местоположении нет экземпляра сервера Redis, продолжайте поиск по часовой стрелке, и первый найденный сервер будет конечным расположением сервера данных.
Проблема перекоса данных Hash Ring
Когда в хеш-кольце мало серверных узлов, легко столкнуться с проблемой неравномерных серверных узлов, что приведет кперекос данных, Перекос данных относится к тому факту, что большая часть кэшированных объектов сосредоточена на одном или нескольких серверах в кластере Redis.
Как показано на рисунке выше, большая часть данных после последовательного алгоритма хеширования хранится на узле A, в то время как узел B хранит только небольшой объем данных, и узел A со временем будет взрываться. По данному вопросу можноВнедрить виртуальные узлырешать. Проще говоря, это вычисление нескольких хэшей для каждого узла сервера и размещение узла сервера в каждом расположении результатов вычислений, называемое виртуальным узлом, что можно реализовать, поместив число после IP-адреса сервера или имени хоста.Например, на картинке выше: Разделите NodeA и NodeB на Node A#1-A#3 NodeB#1-B#3.
Эпилог
Эта статья готовилась (лан) довольно долго, потому что некоторые вещи всегда чувствуют, что я не уверен и не решаюсь написать, и я почти закрыл себя.Даже если она размещена сейчас, я чувствую, что есть много места, которые необходимо изменить. Если есть студенты, которые думают, что что-то не так, пожалуйста, прокомментируйте это в области комментариев или приватно пообщайтесь со мной... Ну, я не хочу, чтобы вы думали, я хочу, чтобы я думал.
Картинки в этой статье взяты из Интернета, захвачены и удалены.