RedisСводка

Java

Преимущества Redis

  • Высокая скорость: скорость чтения и записи до 100 000/сек.
    • Все данные хранятся в памяти
    • Реализован на языке C, ближе к операционной системе
    • Однопоточная архитектура, позволяющая избежать проблем с конкуренцией, вызванных многопоточностью и проблемами производительности при многопоточном переключении.
  • Поддерживает несколько структур данных
    • Поддержка строк, хэшей, списков, наборов, упорядоченных наборов и расширенных растровых изображений, HyperLogLog, структур GEO.
  • Многофункциональный
    • Предоставляет функцию истечения срока действия ключа, которую можно использовать для реализации кэширования.
    • Предоставляет функцию публикации-подписки, которую можно использовать для реализации системы сообщений.
    • Поддержка функции сценария Lua, вы можете использовать Lua для создания новых команд Redis.
    • Предоставляет простую функцию транзакции, которая может в определенной степени обеспечить характеристики транзакции.
    • Предусмотрена функция конвейера, так что клиент может передавать пакет команд в Redis за один раз, уменьшая нагрузку на сеть.
  • Обеспечивает несколько реализаций клиентского языка
    • Предоставляет простой протокол связи TCP, и многие языки программирования могут легко получить доступ к Redis, например Java, PHP, C, C++, Nodejs и т. д.
  • Упорство
    • Помещать данные в память небезопасно, и данные могут быть потеряны в случае сбоя или сбоя питания. Redis предлагает две стратегии сохранения данных на жесткий диск: RDB и AOF.
  • репликация master-slave
    • Redis реализует функцию репликации и реализует несколько копий Redis одних и тех же данных.
  • Высокая доступность и распространение
    • Обеспечивает реализацию высокой доступности RedisSentinel, Redis Cluster

Общие структуры данных и сценарии использования Redis

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

String

Значение строкового типа на самом деле может быть строкой, Json, числом (целым числом, числом с плавающей запятой) или даже двоичным кодом, а максимальное значение не может превышать 512 МБ.

  • Внутренняя кодировка:

    • int: 8-байтовое длинное целое.
    • embstr: Строка меньше или равна 39 байтам.
    • raw: строка больше 39 байт.

    Redis решит, какую внутреннюю реализацию кодирования использовать, основываясь на типе и длине текущего значения.

  • используемые сцены:

    • Строка — это наиболее часто используемая структура данных типа "ключ-значение" для кэша Redis. Обычно в некоторых сценариях некоторые горячие данные кэшируются. При поступлении запроса сначала запрашивается кэш. Если кэш не существует, запросите БД, запись в кеш и возврат
    • счетчик, использованиеINCRКоманда добавляет 1 к значению, соответствующему значению ключа, которое можно использовать для подсчета воспроизведения видео, ограничения тока системы и т. д.

List

list — это упорядоченный список строк, отсортированных по порядку вставки. Вы можете добавить элемент в начало или конец списка, или вы можете изменить и удалить элементы в списке Список может содержать до 2 в степени 32 - 1 элемент

  • Внутренняя кодировка:
    • ziplist (сжатый список): когда количество элементов в списке меньше, чем в конфигурации list-max-ziplist-entries (по умолчанию 512), а значение каждого элемента в списке меньше, чем в list-max-ziplist- значение конфигурации (по умолчанию 64 байта), Redis будет использовать ziplist в качестве внутренней реализации списка для уменьшения использования памяти.
    • связанный список (связанный список): когда тип списка не может соответствовать условиям ziplist, Redis будет использовать связанный список в качестве внутренней реализации списка.
    • используемые сцены:
      • Пейджинг, упорядочение по списку, наиболее распространенным сценарием является использованиеlrange Команда реализует высокопроизводительный пейджинг, аналогичный функции непрерывного выпадающего пейджинга, показанной на некоторых веб-сайтах.
    • Очередь сообщений, поскольку список упорядочен, его можно использоватьlpush,brpopКоманда для вставки или извлечения элементов для реализации функции очереди сообщений

Hash

Хэш представляет собой таблицу сопоставления поля (поля, примечания, а не ключа) и значения (значения) строкового типа.Хеш особенно подходит для хранения объектов. Может содержать до 2 в степени 32 - 1 элемент

  • Внутренняя кодировка:
    • ziplist (сжатый список): Когда количество элементов типа хэш меньше, чем конфигурация hash-max-ziplist-entries (по умолчанию 512), и все значения меньше, чем конфигурация hash-max-ziplist-value (по умолчанию 64 байт), Redis будет использовать ziplist в качестве внутренней реализации хэша, ziplist использует более компактную структуру для обеспечения непрерывного хранения нескольких элементов, поэтому он лучше, чем hashtable, с точки зрения экономии памяти.
    • hashtable (хэш-таблица): когда тип хэша не может соответствовать условиям ziplist, Redis будет использовать хэш-таблицу в качестве внутренней реализации хеширования, потому что эффективность чтения и записи ziplist в это время снизится, а сложность чтения и записи времени хеш-таблица равна O (1
  • Сценарий использования: в настоящее время считается, что объект необходимо сериализовать и сохранить в базе данных, и вместо этого можно рассмотреть структуру Redis Hash.

Set

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

  • Внутренняя кодировка:
    • INTSET (целочисленная коллекция): когда элементы в коллекции являются целыми числами, а количество элементов меньше, чем конфигурация set-max-int-entries (по умолчанию 512), Redis будет использовать int set для достижения внутренней реализации коллекции, тем самым сокращение использования памяти.
    • hashtable (хеш-таблица): когда тип коллекции не может соответствовать условиям intset, Redis будет использовать хеш-таблицу в качестве внутренней реализации коллекции.
  • Сценарий использования: вы можете выполнять некоторую статистику пересечения, объединения и разности данных на основе нескольких наборов наборов.

Sorted Set

Сортированный набор — это упорядоченная структура набора, которая также не допускает дублирования данных.Элементы можно сортировать, но он отличается от списка, в котором в качестве основы для сортировки используется нижний индекс индекса.Он устанавливает оценку для каждого элемента в качестве основы для сортировки. .

  • Внутренняя кодировка:
    • ziplist (сжатый список): когда количество элементов упорядоченного набора меньше, чем в конфигурации zset-max-ziplistentries (по умолчанию 128), а значение каждого элемента меньше, чем в конфигурации zset-max-ziplist-value (по умолчанию 64 байта) Когда Redis будет использовать ziplist в качестве внутренней реализации упорядоченной коллекции, ziplist может эффективно сократить использование памяти.
    • skiplist (список пропуска): когда условие ziplist не выполняется, упорядоченный набор будет использовать skiplist в качестве внутренней реализации, потому что эффективность чтения и записи ziplist в это время снизится.
  • используемые сцены:
    • Таблица лидеров

Лавина кеша Redis, проникновение, поломка, одновременная конкуренция

Лавина кеша Redis

  • Описание сценария: Предположим, система имеет 5000 запросов в секунду в пиковый период каждый день.Изначально кеш мог обрабатывать 4000 запросов в секунду в пиковый период.Однако кеш-машина неожиданно вышла из строя и кеш завис.В это время все 5000 запросы упали в базу данных. В какой-то момент кеш выходит из строя, и к базе данных попадает большое количество запросов — это и есть кеш-лавина.
  • решение:
    • Высокая доступность Redis, ведущий-ведомый + дозорный, кластер Redis, предотвращение полного сбоя
    • Ограничение тока системы
    • Для кешей с одинаковым установленным временем истечения срока действия к сроку действия может быть добавлено случайное число, чтобы избежать чрезмерного давления на базу данных из-за одновременной аннулирования кеша.

Проникновение Redis

  • Описание сценария:
    Обычный процесс использования кеша заключается в том, чтобы сначала выполнить кеш-запрос к запросу данных.Если ключ не существует или срок действия ключа истек, запрашивается база данных, и запрошенный объект помещается в кеш.Если объект запроса к базе данных пуст, он не будет помещаться в кеш. Злонамеренный запрос данных, которые не должны существовать в базе данных большими партиями, приведет к проникновению в кеш и попаданию в базу данных.
  • решение:
    • Добавьте контрольную сумму на уровне интерфейса. Неверные параметры возвращаются напрямую
    • 缓存空对象。缓存查不到，DB 中也没有的情况，可以将对应的 key 的 value 写为 null 。 This solution is suitable for scenarios with frequent data changes and high real-time performance. At the same time, it will lead to data consistency problems within a certain period of time. It may be possible that the storage layer has it but the cache is нулевой.
    • Используйте расширенный пользовательский фильтр Блума. Хешируйте все возможные данные в достаточно большое растровое изображение, данные, которые не должны существовать, будут перехвачены этим растровым изображением, что позволит избежать давления запросов на базовую систему хранения. Фильтр Блума может использовать эффективные структуры данных и алгоритмы. Быстро определить, существует ли ваш ключ в БД. Если он не существует, верните его. Если он существует, запросите БД, чтобы обновить KV, а затем вернуться. Это решение подходит для сценариев с относительно низкой фиксированной производительностью данных в реальном времени.

Разбивка Redis

  • Описание сценария:
    Срок действия кеша данных точки доступа истекает в определенный момент времени, и в этот момент существует большое количество одновременных запросов на этот ключ. Эти запросы обычно загружают данные из серверной БД и сбрасывают их в кеш, когда кеш истекает.Большое количество запросов вызовет резкое увеличение нагрузки на базу данных.
  • решение:
    • Блокировка мьютекса: вы можете использовать SETNX Redis для установки ключа мьютекса. Когда операция завершится успешно, выполните операцию load db и сбросьте кеш, в противном случае повторите весь метод получения кеша.

Соревнование параллелизма Redis

  • Описание сценария: Экземпляр с несколькими системами должен последовательно оперировать одним и тем же ключом в Redis в течение короткого периода времени, что может привести к тому, что Redis будет записывать данные в неправильном порядке из-за нестабильности сети и по другим причинам.
  • решение:
    • Распределенная блокировка: управляется на бизнес-уровне, каждая система получает распределенную блокировку перед запуском Redis и может работать только после получения блокировки, гарантируя, что в то же время только одна система использует определенный ключ.
    • Временная метка: Сохраняйте временную метку при записи. Перед записью сравните, является ли ваша временная метка более ранней, чем временная метка существующей записи. Если она раньше, она не будет записана.
    • Очередь сообщений: последовательная обработка с использованием очередей сообщений.

RDB и AOF стратегии сохраняемости Redis

Постоянство в основном используется для аварийного восстановления и восстановления данных. Redis поддерживает два механизма сохранения, RDB и AOF. Функция сохранения эффективно устраняет проблему потери данных, вызванную выходом из процесса. При следующем перезапуске ранее сохраненные файлы могут быть использованы для восстановления данных.

RDB

Постоянство RDB — это процесс создания моментального снимка текущих данных процесса и их сохранения на жесткий диск.Обычно процесс Redis разветвляется командой bgsave для создания подпроцесса.Процесс сохранения RDB отвечает за подпроцесс. процесс и автоматически завершается после его завершения.

  • Преимущества РДБ:
    • RDB — это компактный сжатый двоичный файл, представляющий моментальный снимок данных Redis в определенный момент времени. Очень подходит для резервного копирования, полной репликации и других сценариев
    • · Redis загружает RDB для восстановления данных намного быстрее, чем AOF
    • RDB очень мало влияет на службы чтения и записи, предоставляемые Redis, что может поддерживать высокую производительность Redis, поскольку основному процессу Redis нужно только разветвить дочерний процесс и позволить дочернему процессу выполнять операции ввода-вывода на диск для сохранения RDB.
  • Недостатки РДБ:
    • Невозможно добиться сохраняемости данных в режиме реального времени/второго уровня в режиме RDB. Поскольку bgsave необходимо выполнять операцию ветвления для создания дочернего процесса каждый раз при запуске, это тяжеловесная операция, а стоимость частого выполнения слишком высока.
    • Файлы RDB сохраняются в определенном двоичном формате. В процессе эволюции версии Redis существуют версии RDB в нескольких форматах. Существует проблема, заключающаяся в том, что старая версия службы Redis не может быть совместима с новой версией формата RDB.

AOF

Записывайте каждую команду записи в независимый журнал и повторно выполняйте команды в файле AOF при перезапуске для восстановления данных. Основная функция AOF — решить проблему сохранения данных в реальном времени, и в настоящее время это основной метод сохранения данных Redis. Операции рабочего процесса AOF: запись команды (добавление), синхронизация файлов (синхронизация), перезапись файла (перезапись), перезапуск загрузки (загрузка)

  • Преимущества АОФ
    • AOF может лучше защитить данные от потери.Как правило, AOF будет выполняться через фоновый поток каждую 1 секунду.fsyncоперации, теряя до 1 секунды данных.
    • Файлы журнала AOF начинаются сappend-onlyРежим записи, поэтому нет диска ищет накладных расходов, производительность записи очень высокая, и файл не легко поврежден, даже если конец файла поврежден, и очень легко исправить.
    • Даже если файл журнала AOF слишком велик, фоновая операция перезаписи не повлияет на операции чтения и записи клиента. Потому чтоrewriteПри ведении журнала инструкции в нем будут сжаты для создания минимального журнала, необходимого для восстановления данных. При создании нового файла журнала старый файл журнала по-прежнему записывается как обычно. Когда новый объединенный файл журнала будет готов, можно будет обменяться новыми и старыми файлами журнала.
    • Команды в файлах журнала AOF записываются в легко читаемом виде, что очень удобно для аварийного восстановления после катастрофического случайного удаления. как кто-то случайноflushallКоманда очищает все данные, пока на этот раз фонrewriteЕсли еще не произошло, то можно сразу копировать файл AOF, ставить последнийflushallКоманда удаляется, а затемAOFКогда файл возвращается, все данные могут быть автоматически восстановлены с помощью механизма восстановления.
  • Недостатки АОФ
    • Для одних и тех же данных файлы журнала AOF обычно больше, чем файлы моментальных снимков данных RDB.
    • После включения AOF поддерживаемое количество запросов в секунду при записи будет меньше, чем количество запросов в секунду при записи, поддерживаемое RDB, поскольку AOF обычно настраивается наfsyncлог-файл один раз, разумеется, каждую секундуfsync, производительность по-прежнему очень высока. (Если писать в реальном времени, то сильно снизится QPS, и сильно снизится производительность Redis)
    • В прошлом в AOF была ошибка, то есть при восстановлении данных через лог, записанный AOF, точно такие же данные не восстанавливались. Поэтому более сложный журнал на основе команд, такой как AOFmergeМетод воспроизведения более хрупок и подвержен ошибкам, чем основанный на RDB метод сохранения полного файла моментального снимка данных каждый раз. Однако AOF предназначен для предотвращения ошибок, вызванных процессом перезаписи, поэтому каждая перезапись основана не на старом журнале команд для слияния, а на данных в памяти в то время для перестроения команды, поэтому надежность будет намного лучше. .

Политика срока действия данных Redis

Политика истечения срока действия Redis:Периодическое удаление + ленивое удаление.

  • Периодическое удаление означает, что Redis случайным образом выбирает некоторые ключи со сроком действия каждые 100 мс по умолчанию, проверяет, истек ли срок их действия, и удаляет их, если срок их действия истек.
  • Ленивое удаление, при получении ключа Redis проверит, истек ли срок действия ключа, если установлено время истечения? Если он истечет, он будет удален в это время и ничего вам не вернет.

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

  • механизм устранения памяти
    • noeviction: Когда памяти не хватает для размещения только что записанных данных, новая операция записи сообщит об ошибке, это вообще не используется, это действительно отвратительно.
    • allkeys-lru: Когда памяти недостаточно для размещения вновь записанных данных, включевое пространство, удалить наименее использовавшийся ключ (этоНаиболее используемоеиз).
    • allkeys-random: когда памяти недостаточно для размещения вновь записанных данных, включевое пространство, случайным образом удалить ключ, это вообще не используется, зачем делать это случайным образом, это должно быть, чтобы убить последний использованный ключ.
    • volatile-lru: Когда памяти недостаточно для размещения вновь записанных данных, вКлючевое пространство с установленным сроком действия, удалите последний использованный ключ (как правило, это неуместно).
    • volatile-random: когда памяти недостаточно для хранения вновь записанных данных,Ключевое пространство с установленным сроком действиясередина,Случайное удалениеключ.
    • volatile-ttl: когда памяти недостаточно для хранения вновь записанных данных,Ключевое пространство с установленным сроком действияв, естьболее ранний срок годностиКлюч извлекается первым.

Влияние на РБД

Сохранение в RDB: при создании файла RDB он сначала проверяет, не истек ли срок действия ключа.Если срок его действия истек, он не войдет в RDB.

Восстановление из файла RDB: Сначала проверьте срок действия ключа, если он истечет, он не будет импортирован в базу данных (в случае с основной базой данных).

Влияние на АОФ

Сохранять данные в AOF: когда срок действия ключа истек и он не был удален, в это время выполняется операция сохранения (ключ не войдет в файл aof, поскольку не выполняется команда модификации). Когда срок действия ключа истекает, когда происходит операция удаления, программа добавит команду del к файлу aof (ключ с истекшим сроком действия будет удален, когда данные будут восстановлены с помощью файла aof в будущем) Перезапись AOF: при перезаписи она сначала определит, истек ли срок действия ключа, и ключ с истекшим сроком действия не будет перезаписывать в файл aof

Решение высокой доступности Redis

Мастер-раб Redis

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

Главный и подчиненный серверы Redis сначала попытаются выполнить добавочную синхронизацию, в случае неудачи будет выполнена полная синхронизация.

Когда система работает, если мастер зависает, вы можете вручную выполнять команды в подчиненной библиотеке (например, slave1)slaveof no one, сделать slave1 новым мастером, выполнять его отдельно на других подчиненных узлахslaveof IP:PORTНаправьте мастер-узел этой машины на нового мастера, в то же время зависший первоначальный мастер также будет указывать на новый мастер как на новый ведомый после его запуска.

  • преимущество
    • Поддержка репликации master-slave, хост автоматически синхронизирует данные с ведомым устройством, а также может быть выполнено разделение чтения и записи;
    • Чтобы разгрузить мастер-оператор от нагрузки на чтение, ведомый сервер может предоставить клиенту услуги только для чтения, а сервис записи все равно должен выполняться мастером;
    • Ведомые устройства также могут принимать запросы на подключение и синхронизацию от других ведомых устройств, что может эффективно снять нагрузку синхронизации со стороны ведущего;
    • Мастер обслуживает ведомые без блокировки. Таким образом, во время синхронизации Master-Slave клиенты по-прежнему могут отправлять запросы или изменять запросы;
    • Ведомый также выполняет синхронизацию данных блокирующим образом. Во время синхронизации, если клиент отправляет запрос на запрос, Redis возвращает данные перед синхронизацией.
  • недостаток
    • Redis не имеет функций автоматической отказоустойчивости и восстановления. Время простоя хоста и подчиненного устройства приведет к сбою некоторых запросов на чтение и запись во внешнем интерфейсе. Необходимо дождаться перезагрузки машины или вручную переключить внешний IP-адрес для восстановления. ;
    • Хост не работает, и некоторые данные не могут быть синхронизированы с ведомым устройством до времени простоя.После переключения IP будет введена проблема несогласованности данных, что снижает доступность системы;
    • Если несколько ведомых устройств отключены и их необходимо перезапустить, старайтесь не перезапускать их в одно и то же время. Поскольку, пока ведомое устройство запущено, будет отправлен запрос на синхронизацию с хостом в полном объеме, Когда несколько ведомых устройств перезапускаются, это может привести к резкому увеличению ведущего ввода-вывода и вызвать простои.
    • Redis сложно поддерживать онлайн-расширение, а онлайн-расширение станет очень сложным, когда емкость кластера достигнет верхнего предела;
    • Данные в главном узле и подчиненном узле Redis одинаковы, что снижает доступность памяти.

Редис Сентинел

В режиме master-slave при выходе из строя master-сервера необходимо вручную переключать slave-сервер на master-сервер, что требует ручного вмешательства, что является трудоемким и трудозатратным, а также приводит к недоступности сервиса для Период времени. Этот метод не рекомендуется.В реальном производстве мы отдаем приоритет дозорному режиму. В этом режиме, когда ведущий отключен, дозорный автоматически выберет главного и укажет другим подчиненным на нового главного.

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

  • преимущество
    • Режим Sentinel основан на режиме ведущий-ведомый, и все преимущества режима ведущий-ведомый доступны в режиме Sentinel.
    • Мастер-ведомый может переключаться автоматически, система более надежна, а доступность выше.
  • недостаток
    • Недостаток режима ведущий-ведомый, данные на каждой машине одинаковые, а доступность памяти низкая.
    • Redis сложнее поддерживать расширение в Интернете, расширение мощности в Интернете достигает верхнего предела, будет очень сложным в кластере.

Redis Cluster

Модель Redis Sentinel в основном была высокодоступной, с раздельным чтением и записью, но в этом режиме Redis каждый сервер хранит одни и те же данные, что приводит к расточительному расходу памяти, поэтому добавлен кластерный режим Cluster на redis3.0, реализованный Redis в распределенном хранилище фрагментации данных. , то есть на каждом содержании Redis разные узлы хранения, для клиента весь кластер виден как единое целое, клиент может подключить любой узел для работы с Redis как операция одного экземпляра одного и того же, когда ключ операция клиента не назначена узлу, Redis вернет управляющую команду, указав на правильный узел. Развертывание кластера не менее чем на трех и более мастер-узлах, желательно использовать 3-й мастер-узел из шести узлов.

Redis-cluster сопоставляет все физические узлы с [0-16383] слотами (не обязательно равномерно распределенными), а кластер отвечает за поддержание значения nodeslot. Каждый ключ будет соответствовать хеш-слоту с номером от 0 до 16383. С помощью этого значения найдите узел, соответствующий соответствующему слоту, а затем автоматически перейдите к соответствующему узлу для операций доступа.

Когда данные записываются на соответствующий главный узел, данные будут синхронизированы со всеми подчиненными узлами, соответствующими главному. Чтобы обеспечить высокую доступность, кластер redis-cluster вводит режим ведущий-подчиненный, в котором главный узел соответствует одному или нескольким подчиненным узлам. Когда другие главные узлы пингуют главный узел, ведущий 1, если более половины главных узлов взаимодействуют с ведущим 1 сверхурочно, то ведущий 1 считается отключенным, и подчиненный узел, ведомый 1 ведущего 1, будет включен, а ведомый 1 станет мастер-узел, чтобы продолжить предоставление услуг. Если и главный узел 1, и его подчиненный узел подчиненный 1 отключены, весь кластер перейдет в состояние сбоя, поскольку сопоставление слотов кластера не завершено. Если более половины мастеров в кластере откажут, независимо от того, есть ли ведомые, кластер войдет в состояние отказа.

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

  • преимущество
    • Используя идею децентрализации, данные распределяются по нескольким узлам в соответствии с хранилищем слотов, совместное использование данных между узлами и распределение данных можно динамически регулировать;
    • Масштабируемость: линейное масштабирование до более чем 1000 узлов, узлы можно динамически добавлять или удалять;
    • Высокая доступность: кластер по-прежнему доступен, когда некоторые узлы недоступны. Добавляя копии данных Slave к STANDBY, вы можете реализовать FAILOVER, и узлы обмениваются информацией о состоянии между протоколом Gossip и выполняют роль Slave к MASTER с механизмом голосования;
    • Сократите затраты на эксплуатацию и техническое обслуживание и улучшите масштабируемость и доступность системы.
  • недостаток
    • Redis Cluster — это кластерная архитектура без центрального узла, основанная на протоколе Госса (распространение слухов) для совместного и автоматического восстановления состояния кластера. Однако у GosSIp есть проблемы с задержкой сообщений и избыточностью сообщений: когда количество узлов кластера слишком велико, PING/PANG-связь между узлами должна осуществляться постоянно, а ненужный трафик отнимает много сетевых ресурсов. Хотя Reds4.0 оптимизировал это, эта проблема все еще существует.
    • Проблемы переноса данных Redis Cluster может динамически расширять и сжимать узлы, но в текущей реализации этот процесс все еще находится в полуавтоматическом состоянии и требует ручного вмешательства. При масштабировании вверх или вниз требуется миграция данных. Чтобы обеспечить согласованность миграции, все операции Redis являются синхронными операциями. При выполнении миграции Redis на обоих концах перейдет в состояние блокировки различной продолжительности. Для небольших ключей время можно игнорировать, но если память ключа Если он используется слишком большой, это вызовет отказоустойчивость в кластере в тяжелых случаях, вызывая ненужное переключение.
Категории