В статье запрашивались структуры данных Redis с точками инструкций, высокий параллелизм, постоянство, кластеризация, репликация, а также приложение Redis для синтаксического анализа.
Рисование записи карты для Redis с помощью XMind и некоторый анализ интервью (в исходных файлах есть подробные примечания и ссылки) для некоторых узлов.Добро пожаловать, чтобы обратить внимание на мою официальную учетную запись: примечания к архитектуре Afeng. Отправьте [Redis] в фоновом режиме, чтобы получить ссылку для скачивания, которая была улучшена и обновлена):
1. Структура данных Redis, связанная
1. Типы данных, поддерживаемые Redis
Нить
**Формат:**установить значение ключа
Строковый тип является двоично-безопасным. Означает, что строка redis может содержать любые данные. Например, изображения в формате jpg или сериализованные объекты.
Тип String является самым основным типом данных REDIS, и один ключ может хранить 512 МБ.
Хэш
Формат: hmset name key1 value1 key2 value2
Хэш Redis — это набор пар ключ-значение (ключ=>значение).
Хэш Redis — это таблица сопоставления поля и значения строкового типа, а хэш особенно подходит для хранения объектов.
Список
Списки Redis — это простые списки строк, отсортированные по порядку вставки. Вы можете добавить элемент в начало (слева) или хвост (справа) списка
**Формат:**lpush значение имени
Добавить строковый элемент в начало списка, соответствующий ключу
**Формат:**значение имени rpush
Добавить строковый элемент в конец списка, соответствующий ключу
**Формат:**указатель имён lrem
key соответствует удалению элементов count в списке, которые совпадают со значением
**Формат:**полное имя
Возвращает длину списка, соответствующего ключу
Набор
** формат: ** Садд имя Значение
Redis Set — это неупорядоченная коллекция строкового типа.
Наборы реализуются через хеш-таблицы, поэтому добавление, удаление и поиск выполняются за O(1).
zset (отсортированный набор: отсортированный набор)
**Формат:**значение оценки имени zadd
Redis zset, как и набор, также представляет собой набор элементов строкового типа и не допускает дублирования элементов.
Разница в том, что каждый элемент связан с дробью типа double. Redis сортирует элементы набора от меньшего к большему по количеству баллов.
Члены zset уникальны, но счет может повторяться.
2. Каковы наиболее часто используемые команды Redis?
3. Каковы сценарии применения Redis
2. Редис транзакции
1. Что такое транзакция
Транзакция в Redis — это набор команд, который является наименьшей исполнительной единицей Redis.Транзакция либо выполняется, либо не выполняется.Поставляется с тремя важными гарантиями:
- Массовые операции помещаются в буфер очереди перед отправкой команды EXEC.
- После получения команды EXEC транзакция выполняется, ни одна команда в транзакции не может быть выполнена, а остальные команды продолжают выполняться.
- Во время выполнения транзакции запросы команд, отправленные другими клиентами, не будут вставлены в последовательность команд выполнения транзакции.
Принцип транзакции Redis заключается в следующем.Первая часть команды транзакции отправляется на Redis, а затем выполняет команды в свою очередь.
2. Почему транзакции Redis не являются атомарными
Выполнение одной команды Redis является атомарным, но Redis не добавляет никакого механизма для поддержания атомарности в транзакциях, поэтому выполнение транзакций Redis не является атомарным.
Под транзакцией можно понимать упакованный пакетный сценарий выполнения, но пакетные инструкции не являются атомарными операциями.Сбой промежуточной инструкции не приведет к откату ранее выполненных инструкций, а также не приведет к тому, что последующие инструкции не будут выполняться.
3. Какие команды связаны с транзакциями Redis?
**DISCARD:** Отменяет транзакцию, отказываясь от выполнения всех команд в блоке транзакции.
** EXEC: ** Выполняет команды во всех блоках транзакций.
** MULTI: ** Отмечает начало блока транзакции.
**WATCH:** Команда Redis Watch используется для мониторинга одного (или нескольких) ключей. Если этот (или эти) ключи будут изменены другими командами до выполнения транзакции, транзакция будет прервана.
**UNWATCH :** Отменяет мониторинг всех ключей с помощью команды WATCH.
3. Постоянство Redis и стратегия кэширования
1. Что такое постоянство Redis?
Одним предложением постоянство можно резюмировать как: сохранение данных (например, объектов в памяти) на запоминающем устройстве, которое можно сохранить навсегда.
Основное применение постоянства — хранение объектов в памяти в базах данных или в дисковых файлах, файлах данных XML и т. д.
Постоянство также можно понимать на следующих двух уровнях:
**Прикладной уровень:** Если вы закроете (закроете) свое приложение, а затем перезапустите его, предыдущие данные все еще будут существовать.
**Системный уровень:** Если вы выключите (Завершите работу) свою систему (компьютер), а затем перезагрузите предыдущие данные, они все еще будут существовать.
2. Каковы механизмы сохранения Redis?
Redis предоставляет два способа сохранения.
**Постоянство RDB: **Принцип заключается в том, чтобы периодически создавать дамп записей базы данных Reids в памяти для сохранения RDB на диске.
** Сохранение AOF (добавлять только файл): ** Принцип работы Redis заключается в регистрации дополнительного способа записи файлов.
3. В чем разница между механизмом сохранения Redis AOF и RDB?
aof, rdb — это два механизма сохранения Redis. После сбоя повторное восстановление.
Характеристики РДБ следующие:
- Разветвите процесс, просмотрите хеш-таблицу и используйте копирование при записи, чтобы сохранить весь дамп базы данных.
- команды save, shutdown, slave запускают это действие.
- Степень детализации относительно велика. Если сохранение, завершение работы и ведомое устройство аварийно завершают работу до этого, промежуточные операции не могут быть восстановлены.
AOF имеет следующие функции:
- Инструкции по операции записи постоянно записываются в аналогичный файл журнала. (Аналогично экспорту sql из баз данных, таких как postgresql, записываются только операции записи)
- Степень детализации мала: после сбоя не могут быть восстановлены только те операции, которые не успели запротоколировать до сбоя.
**Двумя отличиями являются:** одно заключается в непрерывной записи операции записи в журнал и использовании журнала для восстановления после сбоя; второе заключается в том, что операция записи не запускается во время обычной операции записи, а только когда команда сохранения отправляется вручную или команда закрывается, инициируется операция резервного копирования.
Критерий выбора заключается в том, чтобы увидеть, готова ли система пожертвовать некоторой производительностью в обмен на более высокую согласованность кэша (aof) или готова не включать резервное копирование в обмен на более высокую производительность при частых операциях записи, а затем запускать сохранение вручную. резервная копия (rdb). rdb более последователен.
4. Преимущества и недостатки механизма сохранения RDB и AOF
Преимущества РБД
- RDB представляет собой компактный бинарный файл, который больше подходит для резервного копирования, полной репликации и других сценариев.
- RDB восстанавливает данные намного быстрее, чем AOF
Недостатки РБД
- RDB не может обеспечить постоянство в реальном времени или на втором уровне;
- Старая и новая версии несовместимы с форматом RDB.
Преимущества АОФ
- Может лучше защитить данные от потери;
- Режим только в Appen имеет более высокую производительность записи;
- Подходит для катастрофического аварийного восстановления при случайном удалении.
Недостатки АОФ:
- Для одного и того же файла файл AOF больше, чем снимок RDB;
- После включения AOF это повлияет на количество запросов в секунду при записи.По сравнению с RDB, количество запросов в секунду при записи уменьшится;
- Восстановление базы данных происходит относительно медленно и не подходит для холодного резервного копирования.
5. Каковы стратегии устранения Redis?
Стратегия устранения памяти Redis относится к тому, как обращаться с данными, которые необходимо записать заново и которые требуют дополнительного пространства, когда памяти, используемой Redis для кэширования, недостаточно.
Стратегии устранения кеша Redis:
**noeviction:** Если памяти недостаточно для размещения вновь записанных данных, новая операция записи сообщит об ошибке.
**allkeys-lru:** Удалите последний использованный ключ в пространстве ключей, если памяти недостаточно для размещения вновь записанных данных.
**allkeys-random:** Когда памяти недостаточно для размещения вновь записанных данных, в ключевом пространстве удалите ключ случайным образом.
**volatile-lru:** Когда памяти недостаточно для размещения вновь записанных данных, в ключевом пространстве с установленным сроком действия удалите последний использованный ключ.
**volatile-random:** Когда памяти недостаточно для размещения вновь записанных данных, ключ случайным образом удаляется в ключевом пространстве с установленным временем истечения срока действия.
6. Каковы стратегии аннулирования кеша Redis?
Политика истечения срока действия
Для каждого ключа со сроком действия необходимо создать таймер, и он будет очищен сразу же после достижения срока действия. Эта стратегия может немедленно очистить просроченные данные, что очень удобно для памяти, однако для обработки просроченных данных потребуется много ресурсов ЦП, что повлияет на время отклика и пропускную способность кэша.
Ленивая политика истечения срока действия
Только при доступе к ключу будет оцениваться, истек ли срок действия ключа, и если срок его действия истек, он будет очищен. Эта стратегия может максимизировать экономию ресурсов ЦП, но очень неблагоприятна для памяти. В крайних случаях большое количество ключей с истекшим сроком действия может быть недоступно снова, поэтому они не будут очищены, занимая много памяти.
Периодическая политика истечения срока действия
Через регулярные промежутки времени будет сканироваться определенное количество ключей в словаре с истекшим сроком действия определенного количества баз данных, и ключи с истекшим сроком действия будут очищаться. Эта стратегия представляет собой компромисс между первыми двумя. Регулируя временной интервал запланированного сканирования и ограниченное время каждого сканирования, можно оптимально сбалансировать ресурсы ЦП и памяти в различных обстоятельствах.
В Redis используются как ленивое, так и периодическое истечение.
Так называемое периодическое удаление означает, что по умолчанию REDIS случайным образом выбирает несколько клавиш с истечением срока действия каждые 100 мс, проверяет, истекают ли они и удаляют их, если они истекают.
**Предположим, что в Redis есть ключи 10w и установлено время истечения срока действия.**Если вы проверяете ключи 10w каждые несколько сотен миллисекунд, тогда Redis в основном умрет, а загрузка процессора будет очень высокой, что поглотит вас. включен. **Примечание** Это не означает, что все ключи со сроком действия каждые 100 мс будут проходиться, это приведет к снижению производительности. Фактически, Redis случайным образом выбирает некоторые ключи каждые 100 мс для проверки и удаления.
**Но проблема в том, что регулярное удаление может привести к тому, что многие ключи с истекшим сроком действия не будут удалены, когда придет время, так что же делать? ** Так лениво удалять. То есть, когда вы получаете ключ, Redis проверит его, если у ключа есть время истечения срока действия, он истек? Если он истечет, он будет удален в это время и ничего вам не вернет.
**При получении ключа, если срок действия ключа на данный момент истек, он будет удален и ничего не будет возвращено. **Но на самом деле проблема все же есть.Если регулярно удалять много ключей с истекшим сроком действия, а потом вовремя не проверять, то ленивое удаление не используется.Что будет в это время? Если в памяти накапливается большое количество ключей с истекшим сроком действия, что приводит к исчерпанию блока памяти Redis, что мне делать?Ответ таков: возьмем механизм устранения памяти.
В-четвертых, схема исключения кеша Redis
1. Лавина кеша
1.1 Что такое лавина кеша?
Если кеш централизован и недействителен в течение определенного периода времени, происходит большое количество проникновений в кеш, и все запросы падают на базу данных, вызывая лавину кеша.Поскольку исходный кеш недействителен, все запросы, которые должны были получить доступ к кешу, будут быть запрошены до прибытия нового кэша.База данных закрыта, что вызовет огромную нагрузку на ЦП и память базы данных, что приведет к серьезному простою базы данных.
Например, мы готовим рекламную операцию по срочным покупкам, которая вызовет большое количество запросов об информации о продукте, запасах и другой сопутствующей информации во время мероприятия. Чтобы избежать нагрузки со стороны базы данных товаров, данные о товарах хранятся в кэше. К сожалению, во время срочных закупок одновременно истек срок действия большого количества популярных товарных кешей, в результате чего на базу данных попал большой объем трафика запросов. Положите большое давление на базу данных.
1.2 Есть ли какое-нибудь решение для предотвращения лавины кеша?
1. Блокировка очереди
Блокировка взаимного исключения мьютекса решена. SETNX Redis устанавливает ключ мьютекса. При успешном завершении операции выполняется операция загрузки базы данных и сброс кеша. В противном случае повторяется весь метод получения кеша.
2. Предварительный нагрев данных
Предварительный прогрев кэша заключается в загрузке соответствующих данных кэша непосредственно в кэш-систему после того, как система подключена к сети. Это позволит избежать проблемы с базой данных, прежде чем вы сможете избежать данных в пользователе, а затем проблемы с кешем данных. Пользователь напрямую запрашивает данные предварительно нагретого кэша. Вы можете использовать механизм Cache RELOAD для предварительного обновления кеша, а затем вручную запускать загруженный буфер Different KEY до того, как у вас будет большой параллельный доступ.
3. Стратегия двухуровневого кэширования
C1 — это исходный кеш, C2 — это кеш-копия, когда C1 выходит из строя, можно получить доступ к C2, время аннулирования кеша C1 устанавливается на краткосрочный период, C2 — на долгосрочный.
4. Регулярно обновляйте стратегию кэширования
Для кешей, не требующих высокой эффективности, контейнер начинает первоначальную загрузку и использует временные задачи для обновления или удаления кеша.
5. Установите разные сроки действия, чтобы сделать момент аннулирования кеша как можно более однородным.
2. Кэш разминка
2.1 Что такое прогрев кеша
Предварительный прогрев кэша заключается в прямой загрузке соответствующих данных кэша в систему кэширования после того, как система подключится к сети. Это позволяет избежать проблемы, связанной с запросом сначала к базе данных, а затем с кэшированием данных по запросу пользователя.Пользователь напрямую запрашивает предварительно подогретые кэшированные данные. как показано на рисунке:
Если предварительный прогрев не выполняется, данные начального состояния Redis пусты, и на начальном этапе работы системы в режиме онлайн к базе данных будет обращаться большой одновременный трафик, вызывая нагрузку трафика на базу данных.
2.2 Какое решение?
- Когда объем данных невелик, действие загрузки кэша выполняется при запуске проекта;
- Когда объем данных велик, задайте сценарий задачи по времени для обновления кеша;
- Когда объем данных слишком велик, приоритетом является заблаговременная загрузка горячих данных в кэш.
3. Проникновение в кэш
3.1 Что такое проникновение в кеш?
Проникновение в кеш относится к данным запроса пользователя, которых нет в базе данных и, естественно, в кеше. Таким образом, когда пользователь запрашивает, значение соответствующего ключа не может быть найдено в кеше, и каждый раз пользователю приходится обращаться к базе данных для повторного запроса, а затем возвращать пустой (эквивалентно двум бесполезным запросам). Таким образом, запрос минует кеш и напрямую проверяет базу данных.
3.2 Есть ли решение для предотвращения проникновения в кеш?
1. Кешируйте пустые объекты
Простой и грубый метод, если данные, возвращаемые запросом, пусты (независимо от того, данные не существуют или система дает сбой), мы все равно кэшируем пустой результат, но время его истечения будет очень коротким, не более пяти минут максимум .
2. Фильтр Блума
**Преимущества: **Занимает мало места в памяти, битовое хранилище; производительность особенно высока, используйте хэш ключа, чтобы определить, существует ли ключ или нет
Хешируйте все возможные данные в достаточно большое растровое изображение, данные, которые не должны существовать, будут перехвачены этим растровым изображением, что позволит избежать давления запроса на базовую систему хранения.
4. Деградация кэша
В случае даунгрейда, то есть при сбое кеша или зависании службы кеша, мы не обращаемся к базе данных. Мы напрямую обращаемся к части памяти кэша данных или напрямую возвращаем данные по умолчанию.
Например:
Для домашней страницы приложения это, как правило, место с очень большим количеством посещений, а домашняя страница часто содержит отображаемую информацию о некоторых рекомендуемых продуктах. Эти рекомендуемые товары будут храниться в кеше, при этом, чтобы избежать нештатной ситуации с кешем, мы также храним в памяти данные о горячих товарах. В то же время в памяти сохраняется некоторая информация о товарах по умолчанию. Как показано ниже:
Понижение понижению, как правило, являются операциями потерь, поэтому старайтесь минимизировать влияние понижения по вашему бизнесу.
5. Разбивка кеша
5.1 Что такое разбивка кеша?
Поломка кеша означает, что в кеше нет данных, но есть данные в базе данных (обычно по истечении времени кеша), в это время из-за большого количества одновременных пользователей данные из кеша не считываются в одно и то же время, и данные извлекаются из базы данных одновременно, вызывая нагрузку на базу данных Мгновенное увеличение, вызывая чрезмерное давление
5.2, какие проблемы это принесет
В какой-то момент объем запросов к базе данных станет слишком большим, и давление резко возрастет.
5.3, как решить
5.3.1 Использование мьютекса
Идея этого решения относительно проста, то есть только один поток строит кеш, а остальные потоки ждут завершения выполнения потока, который строит кеш, а затем повторно извлекают данные из кеша. Если это один компьютер, вы можете использовать для его обработки синхронизацию или блокировку.Если это распределенная среда, вы можете использовать распределенные блокировки (для распределенных блокировок вы можете использовать операции memcache add, redis setnx и zookeeper add node).
5.3.2. "Бесконечно"
-
С точки зрения Redis действительно не установлено время истечения срока действия, что гарантирует отсутствие проблемы с истечением срока действия горячего ключа, то есть «физический» срок действия не истекает.
-
С функциональной точки зрения, если он не истекает, разве он не статичен? Поэтому мы храним время истечения в значении, соответствующем ключу.Если обнаруживается, что оно вот-вот истечет, кэш строится через фоновый асинхронный поток, то есть «логическое» истечение
5.3.3 Кэш-барьеры
Этот метод аналогичен первому: используйте методы countDownLatch и atomicInteger.compareAndSet() для реализации облегченных блокировок.
class MyCache{
private ConcurrentHashMap<String, String> map;
private CountDownLatch countDownLatch;
private AtomicInteger atomicInteger;
public MyCache(ConcurrentHashMap<String, String> map, CountDownLatch countDownLatch,
AtomicInteger atomicInteger) {
this.map = map;
this.countDownLatch = countDownLatch;
this.atomicInteger = atomicInteger;
}
public String get(String key){
String value = map.get(key);
if (value != null){
System.out.println(Thread.currentThread().getName()+"\t 线程获取value值 value="+value);
return value;
}
// 如果没获取到值
// 首先尝试获取token，然后去查询db，初始化化缓存；
// 如果没有获取到token，超时等待
if (atomicInteger.compareAndSet(0,1)){
System.out.println(Thread.currentThread().getName()+"\t 线程获取token");
return null;
}
// 其他线程超时等待
try {
System.out.println(Thread.currentThread().getName()+"\t 线程没有获取token，等待中。。。");
countDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
// 初始化缓存成功，等待线程被唤醒
// 等待线程等待超时，自动唤醒
System.out.println(Thread.currentThread().getName()+"\t 线程被唤醒，获取value ="+map.get("key"));
return map.get(key);
}
public void put(String key, String value){
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
map.put(key, value);
// 更新状态
atomicInteger.compareAndSet(1, 2);
// 通知其他线程
countDownLatch.countDown();
System.out.println();
System.out.println(Thread.currentThread().getName()+"\t 线程初始化缓存成功！value ="+map.get("key"));
}
}
class MyThread implements Runnable{
private MyCache myCache;
public MyThread(MyCache myCache) {
this.myCache = myCache;
}
@Override
public void run() {
String value = myCache.get("key");
if (value == null){
myCache.put("key","value");
}
}
}
public class CountDownLatchDemo {
public static void main(String[] args) {
MyCache myCache = new MyCache(new ConcurrentHashMap<>(), new CountDownLatch(1), new AtomicInteger(0));
MyThread myThread = new MyThread(myCache);
ExecutorService executorService = Executors.newFixedThreadPool(5);
for (int i = 0; i < 5; i++) {
executorService.execute(myThread);
}
}
}
Пять, redis кластер архитектуры
1. Два способа реализации репликации master-slave
1.1 подчиненная команда
- Создайте команду master-slave: slaveof ip port
- Отменить команду master-slave: slaveof no one
1.2.redis.conf конфигурация файла конфигурации
- Формат: slaveof ip port
- Подчиненный узел только для чтения: slave-только для чтения yes #Configure только для чтения
2. Вы понимаете процесс репликации? Позвольте мне рассказать об этом
- Выполните команду slaveof с узла.
- Подчиненный узел только сохраняет информацию о главном узле в команде slaveof и не инициирует репликацию немедленно.
- Задача синхронизации внутри узла находит информацию о главном узле и начинает использовать сокет для подключения к главному узлу.
- После того, как соединение будет успешно установлено, отправьте команду ping, надеясь получить ответ от команды pong, иначе произойдет повторное подключение.
- Если главный узел устанавливает разрешения, требуется проверка разрешений. Если проверка не удается, репликация прекращается.
- После прохождения проверки разрешений выполняется синхронизация данных, которая является самой длинной операцией. Мастер-узел отправит все данные на рабский узел.
- Когда главный узел синхронизирует текущие данные с подчиненным узлом, процесс установления репликации завершается. Затем главный узел продолжит отправлять команды записи подчиненным узлам, чтобы обеспечить согласованность данных ведущий-ведомый.
3. Структура master-slave в Redis
Структура master-slave может выполнять избыточное резервное копирование, а второе — обеспечивать разделение чтения и записи.
репликация master-slave
Избыточное резервное копирование (также известное как: репликация ведущий-ведомый, избыточность данных, резервное копирование данных, что может обеспечить быстрое аварийное восстановление)
Постоянство гарантирует, что данные будут потеряны даже в случае перезапуска службы Redis, поскольку постоянные данные на жестком диске будут восстановлены в памяти после перезапуска службы Redis.Однако, когда жесткий диск сервера Redis поврежден, данные могут Этой единственной точки отказа можно избежать с помощью механизма репликации. Например, мы создаем мастер с именем redis0 и два подчиненных устройства с именами соответственно redis1 и redis2. Даже если один сервер redis выходит из строя, две другие службы redis могут продолжать работу. оказывать услуги. Данные в главном Redis и данные в подчиненном Redis синхронизируются в режиме реального времени.Когда главный Redis записывает данные, они будут скопированы в две подчиненные службы Redis через механизм репликации master-slave.
1. Мастер может иметь несколько подчиненных серверов, не только главный сервер может иметь подчиненные серверы, но и подчиненные серверы также могут иметь свои собственные подчиненные серверы.
2. Репликация находится в неблокирующем режиме на стороне ведущего устройства, что означает, что даже когда несколько ведомых устройств выполняют первую синхронизацию, ведущее устройство все еще может предоставлять услуги запросов;
3. Репликация также находится в неблокирующем режиме на стороне слейва: если задать его в redis.conf, слейв по-прежнему может использовать старый набор данных для предоставления запросов при выполнении первой синхронизации, также можно настроить, когда мастер теряет связь с ведомым, пусть ведомый возвращает клиенту сообщение об ошибке;
4. Когда ведомое устройство хочет удалить старый набор данных и перезагрузить новую версию данных, ведомое устройство заблокирует запрос на подключение.
разделение чтения-записи
В архитектуре «ведущий-ведомый» вы можете отключить функцию сохранения данных главного сервера и позволить сохраняться только подчиненному серверу, что может повысить производительность обработки главного сервера. Подчиненный сервер обычно устанавливается в режим только для чтения, что может предотвратить ошибочное изменение данных подчиненного сервера.
4. Что такое медленный запрос Redis? Как настроить?
Это относится к медленному запросу, выполнить команду после того, как система подсчитает статистику для каждого времени выполнения инструкции, если время выполнения превышает установленное пороговое значение, это показывает, что команда была медленной инструкцией.
Параметры конфигурации медленного запроса Redis:
slowlog-log-slower-than: устанавливает порог для определения медленного запроса. Превышение этого порога является медленным запросом. Единица тонкая, по умолчанию 10000.
slowlog-max-len: максимальная длина списка журналов медленных запросов.Когда список журналов медленных запросов достигает максимальной длины, самая ранняя вставленная команда будет удалена из списка.
5. Какие архитектурные шаблоны есть в Redis? Расскажите об их характеристиках
Режим ведущий-ведомый обычно представляет собой главный узел и один или несколько подчиненных узлов.Чтобы гарантировать, что данные не будут потеряны после того, как наш главный узел выйдет из строя, мы создаем резервную копию данных главного узла на подчиненном узле, а подчиненный узел не выполняет фактических операций. Только выполнение операций синхронизации в реальном времени не может достичь цели высокого параллелизма.
Режим Sentinel состоит из кластера Sentinel и набора архитектур master-slave. Лучше, чем master-slave, то, что, когда наш главный узел выйдет из строя, часовой будет активно выбирать главный узел для продолжения предоставления услуг.
Архитектура кластера состоит из множества небольших мастеров и ведомых устройств, собранных вместе для предоставления услуг внешнему миру.Слоты для карт 16384 разделены и сохранены, что не является кластерной архитектурой со строгой согласованностью.В каждом маленьком мастере и подчиненный узел., для обеспечения внешней архитектуры высокой доступности.
6. Распределенная блокировка Redis
Иногда проще сказать
Видео объяснение правильной реализации распределенной блокировки Redis
Наконец
Вопросы для расширенного собеседования по Java, необходимые для собеседований в 2020 году, резюмируют документ в формате PDF объемом почти 500. Добро пожаловать в мой общедоступный аккаунт: заметки об архитектуре Ах Фэна и ответьте на [999], чтобы получить эти систематизированные материалы!
Если вам понравилась статья, не забудьте подписаться на меня и поставить лайк, спасибо за вашу поддержку!