Интеллект-карты HD синхронизируются с Git:GitHub.com/so what1412/…

1. Базовые типы и базовая реализация

1.1 Строка

использовать:

Он подходит для простого хранения ключ-значение, значения ключа setnx для достижения распределенных блокировок, счетчиков (атомарности) и распределенных глобальных уникальных идентификаторов.

Нижний слой: Строка в языке Си представлена ​​массивом char[], а в исходном кодеSDS(простая динамическая строка) инкапсулирует char[], который хранится Redis最小单元, SDS может хранить до 512 МБ информации.

struct sdshdr{
  unsigned int len; // 标记char[]的长度
  unsigned int free; //标记char[]中未使用的元素个数
  char buf[]; // 存放元素的坑
}

Redis повторно инкапсулирует SDS и генерирует егоRedisObject, ядро ​​выполняет две функции:

1. Объясните, какой из 5 типов.
2. Внутри есть указатели, указывающие на SDS

когда вы выполняетеset name sowhatФактически, Redis создаст два объекта RedisObject, RedisObject для ключа и RedisOjbect для значения, где их тип = REDIS_STRING, а SDS хранит имя и строки sowhat соответственно.

И нижний слой Redis имеет следующие оптимизации для SDS:

1. Когда измененный размер SDS > 1M, система выделит больше места для空间预分配.
2. Паспорт безопасности惰性释放空间Да, у вас есть свободное место, но система записывает данные и может использовать их напрямую в следующий раз, когда вы захотите. Нет необходимости подавать заявку на новое место.

1.2. Список

Просмотрите нижний слой исходного кодаadlist.hВы обнаружите, что дноДвусторонний связанный список, максимальная длина связанного списка — 2^32-1. Эти комбинации широко используются.

lpush + lpop = стек первым в последнем из стека

lpush + rpop = очередь в порядке очереди lpush + ltrim = закрытая коллекция lpush + brpop = очередь сообщений очередь сообщений

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

1.3. Хэш

Хеширование отлично подходит для совместного хранения некоторых связанных данных, таких как корзина покупок пользователя. Таких типов в повседневном использовании довольно много.

Здесь нужно прояснить: в Redis есть только один K и один V. Где K определенно является строковым объектом, а V может быть любым из String, List, Hash, Set, ZSet.

Нижний слой хэша в основном принимает структуру словарного словаря, а общее представление инкапсулируется слой за слоем. От малого к большому следующим образом:

1.3.1, диктантри

Реальные узлы данных, включая ключ, значение и следующие узлы.

1.3.2, диктант

1. Массив данных типа dictEntry, элемент каждого массива может указывать на связанный список.

2. Размер длины массива. 3. sizemask равен size - 1. 4. Общее количество узлов, содержащихся в текущем массиве dictEntry.

1.3.3, дикт.

1,dictTypeтипы, включая некоторые пользовательские функции, которые позволяют хранить ключи и значения

2. rehashidx на самом деле является знаковой величиной, если она-1Указывает, что в настоящее время расширения нет, если不为 -1Затем запишите место расширения. 3, массив dicttht, две хеш-таблицы. 4. iterators записывает выполняемые итераторы для текущего словаря.

Комбинированная структура выглядит следующим образом:

1.3.4. Постепенное расширение

Почему dicttht ht[2] два?Цель состоит в том, чтобы расширить емкость, не затрагивая внешний CURD., медленно переносить данные из ht[0] в ht[1], и в то же времяrehashindexЧтобы записать ситуацию передачи, когда все передачи завершены, измените ht[1] на ht[0] для использования.

rehashidx = -1 указывает, что текущего расширения нет, а rehashidx != -1 указывает номер расширения массива.

Размер массива после расширения больше используемого*22 в энной степениминимальное значение , сHashMapпохожий. Затем просмотрите массив один за другим и настройте значение rehashidx, а затем просмотрите связанный список один за другим для каждого dictEntry[i], чтобы переназначить хэш данных на dicttht[1]. иdictht[0].useиdictht[1].useявляется динамическим.

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

После остановки, если вы воздействуете на объект, как он выглядит?

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

1.4. Установить

Если вы понимаете, что HashSet в JavaHashMapУпрощенная версия, то этот набор тоже следует понимать. Все так же. Здесь вы можете думать об этом как о Dict без значения. посмотреть исходный кодt.set.cпонять суть.

int setTypeAdd(robj *subject, robj *value) {
    long long llval;
    if (subject->encoding == REDIS_ENCODING_HT) {
         // 看到底层调用的还是dictAdd，只不过第三个参数= NULL
         if (dictAdd(subject->ptr,value,NULL) == DICT_OK) {
            incrRefCount(value);
            return 1;
        }
        ....

1.5 ZSet

Естественный враг поиска по диапазону — упорядоченный набор, смотрите внизуredis.hПозже вы обнаружите, что Zset можно сравнить с бинарным деревом.跳跃表добиться порядка. Пропускной стол многослойныйсвязанный списокКомбинация таблицы пропуска разделена на множество уровней (уровней), каждый уровень можно рассматривать как данныепоказатель,Смысл этих индексов в том, чтобы ускорить переход таблицы для поиска данных..

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

Таблица пропуска содержит заголовок, который при поиске данных从上往下，从左往右найти его. Теперь найдите узел со значением 37 в качестве примера, чтобы сравнить список пропуска и общий связанный список.

1. Нет запроса на пропуск таблицы

Например, если я запрашиваю данные 37, если выше нет индекса, маршрут будет следующим:3. Есть запрос на пропуск таблицы Когда есть таблица пропуска для запроса 37, маршрут выглядит следующим образом:Сценарии применения:

Таблица лидеров по очкам, сортировка новостей по времени, очередь задержки.

1.6. Редис Гео

написано раньшеАнализ основных принципов Redis Geo, вы можете прыгнуть прямо, чтобы увидеть это. Его основная идея состоит в том, чтобы аппроксимировать землю как сферу, а затем GEO использует GeoHash для преобразования двумерных значений широты и долготы в строки для достижения разделения местоположения и запроса заданного расстояния.

1.7. Гиперлоглог

HyperLogLog: это概率Структура данных, использующая вероятностные алгоритмы для подсчета приблизительного количества элементов коллекции. И самым основным источником его алгоритма является伯努利过程 + 分桶 + 调和平均数. Конкретную реализацию можно увидетьОбъяснение HyperLogLog.

Функции: Очень полезно при ведении кардинальной статистики в пределах допустимого диапазона ошибок (мощность относится к количеству различных значений в наборе), каждый ключ HyperLogLog может быть рассчитан близко к2^64Основание разных элементов, а размер всего 12Кб. Частота ошибок составляет около 0,81%. Таким образом, он подходит для УФ-статистики.

Нижний слой HyperLogLog разделен на2^14ведра, или 16384 ведра. Каждое ведро (регистры) представляет собой 6-битный массив. Здесь есть сложная операция. Большинство людей могут напрямую использовать байт в качестве ведра, чтобы тратить 2 бита пространства, но нижний уровень Redis использует только 6, а затем реализует использование памяти. путем сращивания туда и обратно.В крайнем случае, финал 16384 * 6/8/1024 = 12 КБ.

1.8, растровое изображение

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

Нижний слой BitMap в Redis реализован на основе строкового типа. Bitmap можно представить как массив битов. Каждая единица массива может хранить только 0 и 1. Нижний индекс массива называется смещением в Bitmaps. верхний предел значения смещения BitMap2^32 - 1.

1. Вход пользователя

ключ = год: смещение идентификатора пользователя = (день года сегодня) % (день года)

2. Статистика активных пользователей

Используйте дату в качестве ключа, а затем установите идентификатор пользователя в качестве смещения, чтобы установить другое смещение 0 1.

PS: протокол связи Redis — это протокол прикладного уровня, основанный на TCP.RESP(Протокол сериализации REdis).

1.9, Фильтр Блума

Результаты оценки, полученные с использованием фильтра Блума:不存在的一定不存在，存在的不一定存在.

Принцип фильтра Блума:

Когда элемент добавляется в набор, сопоставьте этот элемент с K точками в битовом массиве (эффективно уменьшая вероятность коллизий) с помощью K хэш-функций и установите для них значение 1. При извлечении нам нужно только увидеть, все ли эти точки равны 1, чтобы узнать, есть ли он в наборе: если какая-либо из этих точек равна 0, проверяемый элемент не должен присутствовать; если они все равны 1, то проверяемый элемент очень вероятно существует. Это основная идея фильтра Блума.

Если вы хотите играть, вы можете использоватьguavaПакуй и играй.

1.10 Публикация-подписка

Redis предоставляет发布、订阅Механизм сообщения шаблона, в котором подписчик сообщения не общается напрямую с издателем, издатель публикует сообщение в указанный канал (channel), и каждый клиент, подписанный на канал, может получить сообщение. Впрочем, по сравнению с профессиональным MQ (RabbitMQ RocketMQ ActiveMQ Kafka) упоминать не стоит, и эта функция — шар.

2. Настойчивость

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

2.1 РБД

Механизм сохраняемости RDB предназначен для периодического сохранения данных в Redis. Больше подходит для холодного приготовления. преимущество:

1. Сжатый двоичный файл подходит для резервного копирования, полной репликации и аварийного восстановления.Загрузка RDB для восстановления данных происходит намного быстрее, чем AOF, подходит для крупномасштабного восстановления данных.

2. Если бизнес не требует высокой целостности и непротиворечивости данных, хорошим выбором будет RDB. Восстановление данных происходит быстрее, чем AOF.

недостаток:

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

2. Память занята во время резервного копирования, потому что Redis самостоятельно разветвит ее во время резервного копирования.дочерний процесс, запишите данные во временный файл (данные в памяти в это время вдвое превышают исходный файл) и, наконец, замените временный файл предыдущим файлом резервной копии. Так что примите во внимание примерно удвоенную инфляцию данных.

Обратите внимание на ручной запуск иCOW:

1,SAVEвызовите rdbSave напрямую,阻塞Основной процесс Redis, приводящий к невозможности предоставления услуг. 2,BGSAVEЗатем разветвите дочерний процесс, и дочерний процесс отвечает за вызов rdbSave и отправку сигнала основному процессу, чтобы уведомить о завершении после завершения сохранения. Во время выполнения BGSAVEМожет продолжать обрабатывать запросы клиентов. 3. Механизм копирования при записи создает резервную копию данных в памяти в начале и копирует только измененные данные страницы памяти, а не все данные памяти.

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

2.2. АОФ

Механизм AOF использует каждую команду записи как журнал и записывает ее в файл журнала в режиме только добавления, поскольку этот режимпросто добавитьТаким образом, нет накладных расходов на какую-либо адресацию диска, поэтому он быстрый, вроде binlog в Mysql. AOF больше подходит для горячего резервного копирования.

преимущество:

AOF — это операция fsync через фоновый поток один раз в секунду, поэтому не нужно беспокоиться о потере данных.

недостаток:

1. Для того же количества наборов данных файлы AOF обычно больше, чем файлы RDB. РБД ввосстанавливатьсяСкорость выше, чем скорость восстановления AOF, когда набор данных большой.

2. В зависимости от стратегии синхронизации AOF, как правило, медленнее, чем RDB, по эффективности работы. Короче говоря, эффективность стратегии синхронизации в секунду относительно высока.

Весь процесс AOF делится на два этапа.: Первый шаг — это запись команд в реальном времени, и на разных уровнях может быть 1-секундная потеря данных. Команда сначала добавляется кaof_bufЗатем синхронизируйте с диском AO,Если запись на диск в режиме реального времени приведет к очень большому дисковому вводу-выводу, что повлияет на общую производительность.

Второй шаг — к файлу aofпереписать, цель состоит в том, чтобы уменьшить размер файла AOF, который может запускаться автоматически или вручную (BGREWRITEAOF), которая представляет собой операцию разветвления дочернего процесса, во время которой служба Redis по-прежнему доступна.

1. Во время перезаписи, так как основной процесс по-прежнему отвечает на команды, чтобы обеспечить целостность итоговой резервной копии;依然会写入旧В AOF в случае сбоя перезаписи можно гарантировать, что данные не будут потеряны.

2. Чтобы записать ответную информацию о записи во время перезаписи в новый файл, она также будет为子进程保留一个buf, чтобы предотвратить потерю данных вновь записанным файлом. 3. Рерайтинг — это прямое изложение当前内存的数据生成对应命令, не нужно читать старый файл AOF для анализа и объединения команд. 4.Будь то RDB или AOF, он сначала записывается во временный файл, а затем передается черезrenameЗавершите замену файла.

Совет по форку:

1. Уменьшите частоту форков, например, вы можете вручную запускать RDB для создания снапшотов и перезаписывать AOF;

2. Контролируйте максимальное использование памяти Redis, чтобы вилка не занимала слишком много времени; 3. Настройте точку Niubi и разумно настройте стратегию выделения памяти Linux, чтобы избежать сбоя форка из-за нехватки физической памяти. 4. Redis работаетBGSAVEиBGREWRITEAOFКоэффициент загрузки хэш-таблицы >=5, когда команда выполняется, и >=1, когда две команды не выполняются. Цель состоит в том, чтобыСвести к минимуму операции записи, чтобы избежать ненужной памяти пишет. 5.Коэффициент расширения хеш-таблицы: В хеш-таблице сохранено количество узлов/размер хеш-таблицы. Коэффициент определяет, следует ли расширять хеш-таблицу.

2.3 Восстановление

При запуске он сначала проверит, существует ли файл AOF (более полные данные), и если он не существует, попытается загрузить RDB.

2.4. Рекомендации

Поскольку использование только RDB приведет к потере большого количества данных. При использовании только AOF восстановление данных происходит не так быстро, как RDB, поэтому, если есть проблема, используйте RDB, чтобы восстановить ее как можно скорее, а затем AOF выполнит завершение данных до того, как станет главным.

3. Почему Redis такой быстрый

3.1 Реализация на основе памяти:

Данные хранятся в памяти, что в сто раз быстрее операций дискового ввода-вывода, а скорость операций очень высока.

3.2 Эффективная структура данных:

Базовые структуры данных Redis поддерживают различные типы данных, такие как HyperLogLog, который даже не хочет тратить 2 байта.

3.3 Богатое и разумное кодирование:

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

String: тип int сохраняется автоматически, а тип, отличный от int, кодируется в виде необработанных данных.

Список: длина строки и количество элементов меньше определенного диапазона.ziplistкодировать, иначе преобразовать вlinkedlistкодирование. Хэш: длина строк ключа и значения в паре ключ-значение, хранимой хэш-объектом, меньше, чем определенная пара значения и значения. Установить: сохранить элементы как целые числа и использовать кодировку intset, когда количество элементов меньше определенного диапазона.Если какое-либо условие не выполняется, используйтеhashtableкодирование. Zset: количество сохраняемых элементов меньше фиксированного значения, а длина элементов меньше фиксированного значения.ziplistкодирование, если какое-либо условие не выполняется, используйтеskiplistкодирование.

3.4. Подходящая модель потоков:

I/O 多路复用Модель одновременно прослушивает клиентские подключения, а многопоточность требует переключения контекста, что фатально для баз данных в памяти.

3.5 Представлено после Redis 6.0.多线程Ускорить:

Знать трудоемкую систему чтения/записи для чтения и записи в сети.>>Redis требует много времени для запуска и выполнения, а узким местом Redis в основном являетсяПотребление ввода-вывода в сети, можно выделить два основных направления оптимизации:

Повышение производительности сетевого ввода-вывода, типовые реализации, такие как использование DPDK для замены сетевого стека ядра.

Используйте многопоточность, чтобы использовать преимущества нескольких ядер, типичные реализации, такие как Memcached.

Этот метод оптимизации стека протоколов имеет мало общего с Redis, а поддержка многопоточности — самый эффективный и удобный способ работы. Итак, Redis поддерживает многопоточность по двум причинам:

Может полностью использовать ресурсы ЦП сервера, в настоящее время основной поток может использовать только одно ядро.

Многопоточные задачи могут совместно использовать синхронный ввод-вывод Redis для чтения и записи.

Примечания по многопоточности:

1. Многопоточность версии Redis 6.0 по умолчанию отключена io-threads-do-reads no
2. В версии Redis 6.0 количество потоков также требуется после включения многопоточности.Установите его тщательно.
3. Многопоточность может удвоить производительность, но многопоточность используется только для обработки чтения и записи сетевых данных и разбора протокола.Команды выполнения по-прежнему выполняются в однопоточном последовательном режиме..

4. Часто задаваемые вопросы

4.1 Лавина кеша

Определение лавины:

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

Лавинные решения:

1. Добавьте случайное значение к сроку действия кэшированных данных, чтобы предотвратить истечение срока действия большого объема данных одновременно. 2. Если база данных кэша развернута распределенным образом, распределите горячие данные равномерно по разным базам данных кэша. 3. Установите неограниченный срок действия данных точки доступа.

4.2, проникновение в кеш

Определение проникновения:

Проникновение кеша относится к кешу и базе данных都没有Например, если идентификатор по умолчанию > 0, если хакер будет продолжать запрашивать данные с идентификатором = -12, это приведет к тому, что база данных окажется под слишком большим давлением, что серьезно перегрузит базу данных.

Решения для проникновения:

1. Добавьте пользователей на уровень внутреннего интерфейсаПроверка подлинности,проверка параметровЖдать. 2. Количество посещений в секунду для одного IP превышает пороговое значениеНапрямую заблокировать IP, я был заперт в маленькой темной комнате на 1 день и был заблокирован, когда получил пул IP-прокси. 3. Данные, которые не могут быть извлечены из кеша, не извлекаются из базы данных.В это время пара ключ-значение также может быть записана как ключ-нуль, а время истечения может быть 15 секундпредотвратить вредоносные атаки. 4. Предоставлено RedisBloom FilterХарактеристики тоже в порядке.

4.3. Разбивка кеша

Определение разбивки:

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

Решение для разбивки:

Установите неограниченный срок действия данных точки доступа Плюс мьютекс тоже можно сделать

4.4. Двойная согласованность записи

Двойная запись:缓存и数据库Как обеспечить согласованность данных?

1. Сначала обновите базу данных, затем обновите кеш.

Проблема безопасности: поток A обновляет базу данных -> поток B обновляет базу данных -> поток B обновляет кеш -> поток A обновляет кеш.导致脏读. Бизнес-сценарий: больше читайте и меньше пишите сценарий, часто обновляйте базу данных и кеш вообще бесполезен. Более того, если кеш наложен, результат более浪费性能.

2. Сначала удалите кэш, затем обновите базу данных.

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

следовательноFackBookпридумалCache Aside Pattern

Инвалидация: приложение сначала извлекает данные из кеша, если не получается, то извлекает данные из базы данных и после успеха помещает их в кеш.

Попадание: приложение извлекает данные из кеша и возвращается после извлечения. обновить:先把数据存到数据库中，成功后，再让缓存失效.

4.5, мозги

Разделение мозга означает, что главный узел, подчиненный узел и дозорный кластер находятся в разных сетевых разделах по сетевым причинам.В настоящее время из-за дозорного кластеранеспособность восприниматьДля существования мастера подчиненный узел продвигается до главного узла.В это время есть два разных главных узла, точно так же, как мозг разделен на две части. по фактуHadoop,SparkТакая ситуация будет происходить в скоплении, но решение другое (используйте ЗК для сотрудничества с силой на поражение).

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

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

min-replicas-to-write 3  表示连接到master的最少slave数量
min-replicas-max-lag 10  表示slave连接到master的最大延迟时间

Если количество ведомых устройств, подключенных к ведущему,

4.6, дела

MySQLВ Redis по-прежнему много транзакций, а для транзакций в Redis нужны только следующие три шага:Конкретные выводы о бизнесе:

1. Транзакция Redis — это одноразовое, последовательное и монопольное выполнение транзакций в очереди.серия команд.​

2. Транзакция Redisнет уровня изоляцииКонцепция: пакетные операции помещаются в кеш очереди перед отправкой команды EXEC и фактически выполняться не будут, т.е.Запросы, не существующие в транзакции, должны видеть обновления в транзакции, а запросы вне транзакции не могут их видеть.. 3. РедисАтомарность не гарантируется: отдельная команда в Redis выполняется атомарно, но транзакции не гарантируют атомарность. 4. Весь код в транзакции ошибки компиляции Redis не выполняется, а инструкция используется неправильно. Исключения во время выполнения — это исключения, вызванные неправильными командами, а другие команды могут выполняться нормально. 5. Инструкция к часам аналогичнаоптимистическая блокировка, когда транзакция зафиксирована, если значение любого из KEY, отслеживаемых часами, было изменено другими клиентами, очередь транзакций не будет выполняться, когда транзакция выполняется с использованием EXEC.

4.7. Общие клиенты

1. jedis: классический инструмент, предоставляющий исчерпывающие инструкции по работе с Redis.
2. Redisson: предоставляет распределенные операции и масштабируемые структуры данных Java, включая распределенные блокировки и распределенные коллекции.
3. Lettuce: на основе реализации Netty нижний уровень — это асинхронная мобилизация, вы можете попробовать ее, если вам интересно.

4.8 Прогрев кэша и понижение версии

Прогрев кеша:

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

Понижение кэша:

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

4.9 Правильные этапы разработки

上线前: РедисВысокая доступность, master-slave+sentinel, кластер Redis, во избежание полного коллапса.

上线时: локальный кеш ehcache + текущее ограничение Hystrix + понижение версии для предотвращения перегрузки MySQL.上线后: РедисУпорствоRDB + AOF используется для обеспечения автоматической загрузки данных с диска после точек останова и возможности быстрого восстановления кэшированных данных.

5. Распределенная блокировка

В ежедневном развитии мы можем использоватьsynchronized,LockРеализовать параллельное программирование. Но замки в JavaТолько гарантированное выполнение в рамках одного и того же процесса JVM. Что делать, если блокировки используются в среде распределенного кластера? Обычно доступны два варианта.

5.1 Zookeeper реализует распределенные блокировки

Вы должны знать основыzookeeperзнание:

1. Постоянный узел: клиент отключает zk, не удаляя узлы постоянного типа.

2. Временный узел: клиент отключает zk для удаления узла эфемерного типа 3. Узел последовательности: число, подобное 0000001, будет автоматически сгенерировано после узла, чтобы указать последовательность. 4. Уведомление об изменении узла. Когда клиент регистрируется для отслеживания изменений узла, онвызов метода обратного вызова

Общий процесс выглядит следующим образом, в котором обратите внимание на каждый узел只следить за состоянием узла перед ним, чтобы избежать羊群效应. О коде шаблона Baidu можно.недостаток:

Частое создание и удаление узлов, а также регистрация событий наблюдения сильно нагружают кластер zookeeper, а производительность уступает распределенной блокировке, реализованной в Redis.

5.2 Redis реализует распределенные блокировки

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

SETNX

SETNX является сокращением для SET, если не существует, ежедневная командаSETNX key value, если ключ не существует, набор успешно возвращает 1 и возвращает 0, если ключ уже существует.

SETEX

Значение секунд ключа SETEX означает связать значение значения с ключом и установить время жизни ключа, равное количеству секунд. Если ключ уже существует, команда setex перезапишет старое значение. а сетекс это原子性(атомарная) операция.

Замок:

Как правило, уникальная строка символов, такая как UUID, используется с SETNX для обеспечения блокировки.

Разблокировать:

Здесь используется сценарий LUA, и LUA может гарантировать, что онатомарностьДа, идея состоит в том, чтобы судить, равны ли ключ и входной параметр, если да, удалить его, вернуть успех 1, 0 - неудача.

недостаток:

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

5.3 Redisson реализует распределенные блокировки

RedissonЭто служба, основанная на Redis, использующая платформу Netty на основе NIO, а не только в качестве базового драйвера Redis.клиент, а также может инкапсулировать нативные RedisHash, List, Set, String, Geo, HyperLogLog и другие структуры данных в наиболее привычные отображения (Map), список (List), набор (Set), общий объектный сегмент (Object Bucket) в Java. , Geospatial Bucket, алгоритм оценки мощности (HyperLogLog) и другие структуры.

Здесь мы просто используем несколько инструкций о распределенных блокировках, его общий принцип:

Блокировка и разблокировка RedissonОбщая блок-схема выглядит следующим образом:

6. Стратегия истечения срока действия Redis и стратегия ликвидации памяти

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

РедисПолитика истечения срока действияОбычно их три:

1,истечение срока действия по времени:

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

2,ленивый выдох:

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

3.Периодически истекает:

Через регулярные промежутки времени будет сканироваться определенное количество ключей в словаре с истекшим сроком действия определенного количества баз данных, и ключи с истекшим сроком действия будут очищаться. Эта стратегия представляет собой компромисс между первыми двумя. Регулируя временной интервал запланированного сканирования и ограниченное время каждого сканирования, можно использовать ресурсы ЦП и памяти в различных ситуациях.достичь оптимумаэффект баланса. Словарь expires сохранит данные о времени истечения срока действия всех ключей с установленным временем истечения срока действия, где ключ — это указатель на ключ в пространстве ключей, а значение — это время истечения срока действия, представленное отметкой времени UNIX с точностью до миллисекунды ключа. Пространство ключей относится ко всем ключам, хранящимся в этом кластере Redis.

Стратегия истечения срока действия, принятая Redis:惰性删除 + 定期删除. Стратегия истечения срока действия, принятая memcached:惰性删除.

6.2, 6 стратегий устранения памяти

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

1. volatile-lru: выберите из набора данных (server.db[i].expires) с установленным временем истечения срока действия.Наименее недавно использованныйудаление данных

2. volatile-ttl: выберите из набора данных (server.db[i].expires) с установленным временем истечения срока действия.скоро истечетудаление данных 3. volatile-random: из набора данных (server.db[i].expires), в котором установлено время истечения срока действия.Произвольный выборудаление данных 4. allkeys-lru: выбрать из набора данных (server.db[i].dict)Наименее недавно использованныйудаление данных 5. allkeys-random: из набора данных (server.db[i].dict)любое количество вариантовсогласно исключению 6, no-enviction (выселение): запретить выселение данных,не удалятьзначение.

Интервью часто задают и часто проверяют, т.LRUДа все знакомыLinkedHashMapтакже понялLRUАлгоритм реализуется следующим образом:

class SelfLRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int CACHE_SIZE;
    /**
     * 传递进来最多能缓存多少数据
     * @param cacheSize 缓存大小
     */
    public SelfLRUCache(int cacheSize) {
  // true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
        CACHE_SIZE = cacheSize;
    }
    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        // 当 map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
        return size() > CACHE_SIZE;
    }
}

6.2. Резюме

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

7. Высокая доступность кластера Redis

К проблемам с одним компьютером относятся сбои компьютеров, узкие места в емкости и узкие места в количестве запросов в секунду. В практических приложениях развертывание Redis на нескольких машинах потребуетredis主从复制,Sentinel哨兵模式,Redis Cluster.

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

7.1 Репликация Redis master-slave

Этот режим отличается высокой доступностью и разделением чтения и записи и будет использовать增量同步и全量同步два механизма.

7.1.1 Полная синхронизация

Полная репликация Redis обычно происходит вФаза инициализации подчиненного устройства, то ведомому необходимо изменитьвсе данныеСделайте копию обоих:

1. Ведомый подключается к ведущему и отправляетpsyncЗаказ.

2. Мастер получаетpsyncПосле присвоения имени начните выполнение команды bgsave для создания файла RDB и используйте буфер для записи всех команд записи, выполняемых после этого. 3. Ведущее устройство отправляет файл моментального снимка подчиненному устройству и продолжает записывать выполненные команды записи во время отправки. 4. После того, как ведомое устройство получает файл снимка, оно отбрасывает все старые данные и загружает полученный снимок. 5. После отправки ведущего снапшота он начинает посылать команду записи в буфер ведомому. 6. Ведомое устройство завершает загрузку моментального снимка, начинает получать запросы команд и выполняет команду записи из ведущего буфера.

7.1.2 Инкрементальная синхронизация

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

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

7.1.3 Стратегия синхронизации Redis master-slave:

1,主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步. Конечно, ведомое устройство может инициировать полную синхронизацию в любое время, если это необходимо. Стратегия Redis заключается в том, что в любом случае сначала будет предпринята попытка инкрементной синхронизации, а в случае неудачи ведомому устройству потребуется выполнить полную синхронизацию. 2. Когда слейв синхронизирует данные мастера, если слейв потеряет соединение, не пугайтесь.После слейва переподключается丢失重补. 3. Как правило, разделение чтения и записи достигается через ведущее и ведомое устройства, но как обеспечить высокую доступность Redis, если ведущее устройство зависает? вводитьSentinelСделайте основной выбор.

7.2 Режим высокой доступности Sentinel

Redis-sentinelсам по себе являетсянезависимыйЗапущенный процесс, как правило, количество дозорных узлов кластера составляет не менее трех и нечетное число, он может отслеживать несколько кластеров ведущий-подчиненный, а дозорный узел может автоматически переключаться, когда ведущий не работает. Sentinel может отслеживать любое количество главных серверов и подчиненных серверов под главным сервером, и когда контролируемый главный сервер отключается,Автоматизируйте операции аварийного переключения. Обратите внимание здесь sentinelТакже естьsingle-point-of-failureпроблема. Приблизительно перечислите использование часовых:

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

7.3 Кластер Redis

RedisCluster — это распределенное решение для Redis. Решение, запущенное после версии 3.0, эффективно решает распределенные потребности Redis.

7.3.1 Правила разбиения

Общие правила разметки

1. 节点取余: хеш (ключ) % N
2. 一致性哈希: Постоянное хеш-кольцо
3. 虚拟槽哈希: CRC16 [ключ] и 16383

RedisCluster использует虚拟槽分区метод, детали реализации предмета следующие:

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

2. Автоматическая реализацияБалансировка нагрузки и высокая доступность, который автоматически реализуетсяfailoverи поддержкаДинамическое расширение, чиновник сыграл на низкой сложности, которую можно реализовать с помощью 1000 узлов. 3. Каждый ведущий также должен быть сконфигурирован с ведущим и ведомым, и он также используется внутриРежим стража, если половина узлов обнаружит аномальный узел, они совместно решат изменить состояние аномального узла. 4. Если у мастера в кластере нет подчиненного узла, весь кластер войдет после того, как мастер повесит трубкуfailстатус, потому что карта слотов кластера неполная.Если более половины мастеров в кластере выходят из строя, кластер переходит в состояние сбоя.. 5. Официальная рекомендацияДля развертывания кластера требуется как минимум 3 главных узла..

8. Текущий лимит Redis

Когда вы часто ездите в пекинском метро Xi'erqi или на Западном железнодорожном вокзале Пекина, вы часто сталкиваетесь с ситуацией, что если людей много, сотрудники метро дадут вам небольшую табличку и позволят проверить билет позже. это реальная жизнь Меры по борьбе с огромным трафиком.

При разработке системы с высокой степенью параллелизма есть три средства защиты системы:缓存,降级и限流. Так что же такое ограничение тока? Как следует из названия, текущее ограничение предназначено для ограничения трафика, точно так же, как ваш пакет широкополосного доступа составляет 1 ГБ трафика, и он исчезнет, ​​когда он закончится. Ограничивая ток, мы можем хорошо контролировать qps системы, чтобы достичь цели защиты системы.

1. Setnx, zset на основе Redis

1.2, установка

Например, нам нужно ограничить 20 запросов в течение 10 секунд, тогда мы можем установить время истечения 10, когда setnx, когда запросsetnxКогда число достигает 20, достигается эффект ограничения тока.

Недостатки: Например, при подсчете 1-10 секунд нельзя считать за 2-11 секунд, если нам нужно посчитать M запросов за N секунд, то наш RedisНеобходимо сохранить N ключей и т. д..

1.3, зсет

На самом деле, самая важная вещь, связанная с ограничением тока, это скользящее окно.Выше также упоминалось, как 1-10 становится 2-11. Фактически, начальное значение и конечное значение равны +1 каждое. Мы можем сделать запросмассив zset, при поступлении каждого запроса значение остается уникальным и может быть сгенерировано с помощью UUID, а оценка может быть представлена ​​текущей отметкой времени, так как оценка может использоваться для расчета количества запросов в пределах текущей отметки времени. Структура данных zset также обеспечиваетrangeМетод позволяет нам легко получить количество запросов в пределах 2 меток времени,

Недостаток: структура данных zset будет становиться все больше и больше.

2. Алгоритм дырявого ведра

Идея алгоритма дырявого ведра: сравнить воду с запросом, а дырявое ведро с пределом пропускной способности системы.В дырявое ведро сначала поступает вода, а в дырявое ведро водаотток с определенной скоростью, когда скорость истечения меньше скорости притока, из-за ограниченной вместимости негерметичного ведра последующая поступающая вода напрямую переливается (отклоняет заявку), тем самым реализуя ограничение тока.

3. Алгоритм Token Bucket

Принцип действия алгоритма token Bucket: это можно понимать как запись в больницу на прием к врачу, и только после номера можно поставить диагноз.

Подробный процесс примерно таков:

1. Все запросы необходимы перед обработкойПолучение действительного токена будет обработано только.

2. В соответствии с текущим предельным размером установите токен, который будет добавляться в корзину с определенной скоростью. 3. Установите максимальное значение ведра.Когда ведро будет заполнено, вновь добавленный токен будет отброшен или отклонен. 4. После того, как запрос достигнут, сначала необходимо получить токен в корзине токенов, а затем с токеном можно выполнить другую бизнес-логику.После обработки бизнес-логики токен напрямую удаляется. 5. Корзина токенов имеет минимальный лимит.Когда токен в корзине достигает минимального предела, токен не будет удален после обработки запроса, чтобы обеспечить достаточный текущий лимит.

Инжиниринг:

1,Пользовательские аннотации, aop, Redis + LuaРеализовать ограничение тока. 2. РекомендуетсяguavaизRateLimiterвыполнить.

9. Общие точки зрения

1. Используется для строкового нечеткого запросаKeysМожет вызвать блокировку потока, попробуйте использоватьscanИнструкция выполняет неблокирующую выборку данных, а затем перезагружает их.
2. Не забудьте использовать в случае нескольких операцийpipeLineОтправляйте все команды одновременно, избегайте перегрузки сети, вызванной частой отправкой и получением, и повышайте производительность.
3. Bigkeys может сканировать большие ключи в redis.Нижний слой — использовать команду сканирования для обхода всех ключей и выполнения команд STRLEN, LLEN, SCARD, HLEN, ZCARD для каждого ключа, чтобы получить его длину или количество элементов. Недостаток в том, что онлайн-пробная версия и большое количество не обязательно могут иметь большое пространство.
4. Не забудьте включить журнал медленных запросов Redis для онлайн-приложений.Основная идея аналогична MySQL.
5. В Redis стратегия выделения памяти, а также добавление и удаление данных приведет к内存碎片, вы можете перезапустить службу или выполнитьactivedefrag yesВыполните обновление памяти, чтобы решить эту проблему.

Соотношение >1 указывает на наличие фрагментации памяти, и чем больше соотношение, тем серьезнее.

10. Конец

Там столько ударов про Redis сначала (хотел написать второй килл, боялся, что будет слишком длинно), если чувствуете, что мало прочитали, то得价钱.

Прошлые выборы:

1. SF Express: Пожалуйста, подпишитесь на MySQL Soul Ten Connect
2. Интервью HashMap достаточно прочитать это
3. Как сказать Spring Circular Dependency of Rotten Street
4. Узнайте о Synchronized шаг за шагом
5. Быстрое начало работы с обычными одновременными контейнерами в JUC
6. 3W Word Fun с SpringCloud

---