В этой статье рассматриваются три режима репликации Redis master-slave, Sentinel и Cluster.

Обзор

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

Возможно, программисты в обычных компаниях в принципе могут решить проблему, используя автономную версию, данные, приведенные на официальном сайте Redis,10W QPS, чего более чем достаточно для работы с общей компанией, если же нет, то используется режим master-slave для реализации разделения всех операций записи, и производительность значительно повышается.

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

Я уже писал много статей о Redis, например:Базовые типы данных Redis и лежащие в их основе принципы реализации, транзакции, постоянство, распределенные блокировки, предварительная версия подпискиПодождите, можно сказать, что это относительно всеобъемлющий учебник.После того, как эта статья будет в основном завершена, я организую систему статей в формате pdf и поделюсь ею с вами.

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

автономный

Автономная версия Redis относительно проста, и в основном 90% программистов использовали ее.Официальный сайт рекомендует, чтобы сторонняя библиотека зависимостей для Redis была Jedis.В проекте SpringBoot следующие зависимости могут использоваться напрямую:

<dependency>
	  <groupId>redis.clients</groupId>
	  <artifactId>jedis</artifactId>
	  <version>${jedis.version}</version>
</dependency>

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

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

недостаток

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

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

Практичная конструкция

В Интернете есть много подробных руководств по построению автономной версии, что в основном является дурацкой операцией, особенно если она собирается локально, базовое использование yum быстрое и удобное, и оно может можно сделать с помощью нескольких команд.Вот рекомендуемый учебник по строительству:www.cnblogs.com/zuidongfeng/p/8032505.html.

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

Вот также часто используемые Redisredis.confПункт конфигурации, с примечанием, чтобы посмотреть, очень ли я теплый:

daemonize yes  // 设置后台启动，一般设置yes
pidfile /var/run/redis.pid // edis以守护进程方式运行时,redis默认会把pid写入/var/run/redis.pid文件
port 6379 // 默认端口为6379
bind 127.0.0.1 //主机地址，设置未0.0.0.0表示都可以访问。127.0.0.1表示只允许本机访问
timeout 900  // 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
logfile stdout // 日志记录方式，默认为标准输出
logfile "./redis7001.log"  # 指明日志文件名
databases 16 // 设置数据库的数量，默认数据库为0
save  //有多少次更新操作，就将数据同步到数据文件
	Redis默认配置文件中提供了三个条件：
	save 900 1 //900秒（15分钟）内有1个更改
	save 300 10 //300秒（5分钟）内有10个更改
	save 60 10000  // 60秒内有10000个更改
rdbcompression yes // 指定存储至本地数据库时是否压缩数据
dbfilename dump.rdb //指定本地数据库文件名
dir ./    //指定本地数据库存放目录
slaveof  // 主从同步设置，设置主数据库的ip和端口
# 如果非零，则设置SO_KEEPALIVE选项来向空闲连接的客户端发送ACK
tcp-keepalive 60
# 默认如果开启RDB快照(至少一条save指令)并且最新的后台保存失败，Redis将会停止接受写操作
# 这将使用户知道数据没有正确的持久化到硬盘，否则可能没人注意到并且造成一些灾难
stop-writes-on-bgsave-error yes
# 默认如果开启RDB快照(至少一条save指令)并且最新的后台保存失败，Redis将会停止接受写操作。
stop-writes-on-bgsave-error yes
# 当导出到 .rdb 数据库时是否用LZF压缩字符串对象
rdbcompression yes
# 版本5的RDB有一个CRC64算法的校验和放在了文件的最后。这将使文件格式更加可靠。
rdbchecksum yes
# 持久化数据库的文件名
dbfilename dump-master.rdb
# 工作目录
dir /usr/local/redis-4.0.8/redis_master/
# slav服务连接master的密码
masterauth testmaster123
# 当一个slave失去和master的连接，或者同步正在进行中，slave的行为可以有两种：
#1) 如果 slave-serve-stale-data 设置为 "yes" (默认值)，slave会继续响应客户端请求，可能是正常数据，或者是过时了的数据，也可能是还没获得值的空数据。
# 2) 如果 slave-serve-stale-data 设置为 "no"，slave会回复"正在从master同步
# （SYNC with master in progress）"来处理各种请求，除了 INFO 和 SLAVEOF 命令。
slave-serve-stale-data yes
# 配置是否仅读
slave-read-only yes
# 如果你选择“yes”Redis将使用更少的TCP包和带宽来向slaves发送数据。但是这将使数据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒
# 如果你选择了 "no" 数据传输到salve的延迟将会减少但要使用更多的带宽
repl-disable-tcp-nodelay no
# slave的优先级，优先级数字小的salve会优先考虑提升为master
slave-priority 100
# 密码验证
requirepass testmaster123
# redis实例最大占用内存，一旦内存使用达到上限，Redis会根据选定的回收策略（参见：
# maxmemmory-policy）删除key
maxmemory 3gb
# 最大内存策略：如果达到内存限制了，Redis如何选择删除key。
# volatile-lru -> 根据LRU算法删除带有过期时间的key。
# allkeys-lru -> 根据LRU算法删除任何key。
# volatile-random -> 根据过期设置来随机删除key, 具备过期时间的key。 
# allkeys->random -> 无差别随机删, 任何一个key。 
# volatile-ttl -> 根据最近过期时间来删除（辅以TTL）, 这是对于有过期时间的key 
# noeviction -> 谁也不删，直接在写操作时返回错误。
maxmemory-policy volatile-lru
# AOF开启
appendonly no
# aof文件名
appendfilename "appendonly.aof"
# fsync() 系统调用告诉操作系统把数据写到磁盘上，而不是等更多的数据进入输出缓冲区。
# 有些操作系统会真的把数据马上刷到磁盘上；有些则会尽快去尝试这么做。
# Redis支持三种不同的模式：
# no：不要立刻刷，只有在操作系统需要刷的时候再刷。比较快。
# always：每次写操作都立刻写入到aof文件。慢，但是最安全。
# everysec：每秒写一次。折中方案。 
appendfsync everysec
# 如果AOF的同步策略设置成 "always" 或者 "everysec"，并且后台的存储进程（后台存储或写入AOF
# 日志）会产生很多磁盘I/O开销。某些Linux的配置下会使Redis因为 fsync()系统调用而阻塞很久。
# 注意，目前对这个情况还没有完美修正，甚至不同线程的 fsync() 会阻塞我们同步的write(2)调用。
# 为了缓解这个问题，可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理时阻止主进程进行fsync()。
# 这就意味着如果有子进程在进行保存操作，那么Redis就处于"不可同步"的状态。
# 这实际上是说，在最差的情况下可能会丢掉30秒钟的日志数据。（默认Linux设定）
# 如果你有延时问题把这个设置成"yes"，否则就保持"no"，这是保存持久数据的最安全的方式。
no-appendfsync-on-rewrite yes
# 自动重写AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# AOF文件可能在尾部是不完整的（这跟system关闭有问题，尤其是mount ext4文件系统时
# 没有加上data=ordered选项。只会发生在os死时，redis自己死不会不完整）。
# 那redis重启时load进内存的时候就有问题了。
# 发生的时候，可以选择redis启动报错，并且通知用户和写日志，或者load尽量多正常的数据。
# 如果aof-load-truncated是yes，会自动发布一个log给客户端然后load（默认）。
# 如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
# 注意，如果在读取的过程中，发现这个aof是损坏的，服务器也是会退出的，
# 这个选项仅仅用于当服务器尝试读取更多的数据但又找不到相应的数据时。
aof-load-truncated yes
# Lua 脚本的最大执行时间，毫秒为单位
lua-time-limit 5000
# Redis慢查询日志可以记录超过指定时间的查询
slowlog-log-slower-than 10000
# 这个长度没有限制。只是要主要会消耗内存。你可以通过 SLOWLOG RESET 来回收内存。
slowlog-max-len 128
# 客户端的输出缓冲区的限制，可用于强制断开那些因为某种原因从服务器读取数据的速度不够快的客户端
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
# 当一个子进程重写AOF文件时，文件每生成32M数据会被同步
aof-rewrite-incremental-fsync yes

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

режим ведущий-ведомый

принцип

Принцип master-slave относительно прост, один master и несколько slave,Основная база данных (master) может быть прочитана или записана (read/write), а подчиненная база данных доступна только для чтения (только для чтения)..

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

Принцип режима master-slave настолько прост, так каков же процесс (рабочий механизм) его выполнения? Другая картинка:

Когда режим ведущий-ведомый включен, его конкретный механизм работы выглядит следующим образом:

Когда ведомое устройство запускается, оно отправляет ведущемуSYNCкоманда, перейти после мастер-секции к команде из базы данныхbgsaveсохранить снимок (постоянство RDB), а некоторые команды, выполненные в этот период, будут кэшированы.
Затем мастер отправит сохраненный снимок подчиненному устройству и продолжит запись команд в течение периода кэширования.
Подчиненное устройство получает моментальный снимок, отправленный основной базой данных, и загружает его в свою собственную базу данных.
Наконец, ведущий синхронизирует кэшированную команду с ведомым, а ведомый выполняет ее после получения команды, чтобы данные ведущего и ведомого были согласованы.

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

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

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

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

Синхронизация master-slave синхронизируется асинхронно, во время которой Redis по-прежнему может отвечать на запросы и запросы на обновление, отправленные клиентами.

недостаток

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

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

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

Практичная конструкция

Далее, давайте построим режим master-slave на практике.Создание режима master-slave относительно просто.У меня есть виртуальная машина Centos 7, и я использую метод включения нескольких экземпляров Redis для построения master-slave.

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

mkdir redis

затем вставьте копиюredis.confКонфигурационный файл:

cp /root/redis-4.0.6/redis.conf /root/redis/redis-6379.conf
cp /root/redis-4.0.6/redis.conf /root/redis/redis-6380.conf
cp /root/redis-4.0.6/redis.conf /root/redis/redis-6381.conf

Скопируйте три файла конфигурации, один главный и два подчиненных, порт 6379 используется как главная база данных (мастер), а 6380 и 6381 используются как подчиненные базы данных (ведомые).

Первый — это файл конфигурации, который настраивает основную базу данных:vi redis-6379.conf:

bind 0.0.0.0 # 注释掉或配置成0.0.0.0表示任意IP均可访问。
protected-mode no # 关闭保护模式，使用密码访问。
port 6379  # 设置端口，6380、6381依次为6380、6381。
timeout 30 # 客户端连接空闲多久后断开连接，单位秒，0表示禁用
daemonize yes # 在后台运行
pidfile /var/run/redis_6379.pid  # pid进程文件名，6380、6381依次为redis_6380.pid、redis_6381.pid
logfile /root/reids/log/6379.log # 日志文件，6380、6381依次为6380.log、6381.log
save 900 1 # 900s内至少一次写操作则执行bgsave进行RDB持久化
save 300 10
save 60 10000 
rdbcompression yes #是否对RDB文件进行压缩，建议设置为no，以（磁盘）空间换（CPU）时间
dbfilename dump.rdb # RDB文件名称
dir /root/redis/datas # RDB文件保存路径，AOF文件也保存在这里
appendonly yes # 表示使用AOF增量持久化的方式
appendfsync everysec # 可选值 always， everysec，no，建议设置为everysec
requirepass 123456 # 设置密码

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

slaveof 127.0.0.1 6379 # 配置master的ip，port
masterauth 123456 # 配置访问master的密码
slaveof-serve-stale-data no

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

./redis-server /root/redis/6379.conf
./redis-server /root/redis/6380.conf
./redis-server /root/redis/6381.conf

по командеps -aux | grep redis, чтобы просмотреть запущенный процесс Redis:Как показано на рисунке выше, это означает, что запуск прошел успешно, и следующим шагом является переход к этапу тестирования.

контрольная работа

Я использую SecureCRT в качестве клиента соединения redis, запускаю три SecureCRT одновременно, подключаюсь к трем экземплярам redis1 соответственно и указываю порт и пароль при запуске:

./redis-cli -p 6379 -a 123456

После запуска в ведущем (6379) введите: set name 'ldc', через get name в ведомом можно просмотреть:

Синхронизация данных прошла успешно.Есть несколько подводных камней.Одна из них заключается в том, что в redis.conf не задана привязка, что приведет к отфильтровыванию нелокального ip.Вообще можно настроить 0.0.0.0.

Другой заключается в том, что пароль requirepass 123456 не настроен, что приведет к тому, что соединение ввода-вывода все время будет ненормальным.Это яма, с которой я столкнулся.После настройки пароля позже он был успешным.

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

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

Режим стража

принцип

Режим Sentinel является модернизированной версией master-slave, потому что после выхода из строя master-slave он не будет автоматически восстанавливаться, и требуется вмешательство человека, что очень болезненно.

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

Итак, в целом дозорный режим имеет следующие преимущества (функциональные точки):

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

Информация о конфигурации мониторинга режима Sentinel получается из базы данных через конфигурациюsentinel monitor <master-name> <ip> <redis-port> <quorum>указать, например:

// mymaster 表示给master数据库定义了一个名字，后面的是master的ip和端口，1表示至少需要一个Sentinel进程同意才能将master判断为失效，如果不满足这个条件，则自动故障转移（failover）不会执行
sentinel monitor mymaster 127.0.0.1 6379 1

Связь узла

Конечно, есть и другая информация о конфигурации, и другая информация о конфигурации, которая будет обсуждаться при построении среды. Когда часовой запустится, он установит соединение с мастером, чтобы подписаться на его_sentinel_:helloканал.

Этот канал используется для получения информации о других Sentinels, контролирующих мастер. И он также установит соединение, которое регулярно отправляет команды INFO мастеру для получения информации о мастере.

Когда дозорный установит соединение с мастером, он будет периодически отправлять команды INFO мастеру и слейву (раз в 10 секунд), если мастер помечен как субъективно офлайн, частота станет раз в 1 секунду.

и регулярно_sentinel_:helloКанал отправляет свою собственную информацию, чтобы другие часовые могли подписаться на получение своей информации.IP-адрес и порт Sentinel, рабочий идентификатор, версия конфигурации, имя мастера, IP-порт мастера и версия конфигурации мастераи другая информация.

а также,Периодически (раз в секунду) отправлять команды PING мастеру, подчиненному и другим часовым, чтобы проверить, жив ли объект., если другая сторона получает команду PING, при отсутствии ошибок она ответит на команду PONG.

Таким образом, Sentinel реализует связь между Sentinel и Sentinel, а также между Sentinel и Master, устанавливая эти два соединения и регулярно отправляя команды INFO и PING.

Здесь есть некоторые понятия, которые необходимо понимать, такие как INFO, PING, PONG и другие команды, за которыми следуют команды MEET, FAIL и субъективный оффлайн, конечно, будет объективный оффлайн, здесь я в основном говорю о понимании эти понятия:

ИНФОРМАЦИЯ: Эта команда может получить самую свежую информацию из базы данных master-slave и может реализовать обнаружение новых узлов.
PING: Эта команда используется чаще всего.Эта команда инкапсулирует данные о состоянии своего собственного узла и других узлов.
PONG: когда узел получает MEET и PING, он ответит на команду PONG и отправит другой стороне свой собственный статус.
MEET: эта команда отправит команду на старый узел, когда новый узел присоединяется к кластеру, указывая, что он новичок.
FAIL: когда узел отключается, сообщение будет передано в кластер.

Онлайн и оффлайн

Когда часовой тот же, что и мастер, он будет регулярно поддерживать связь.Если PING, отправленный часовым в определенное время, не получает ответа в течение указанного времени (sentinel down-after-milliseconds master-name millisecondsконфигурация), то дозорный, отправляющий команду PING, будет думать, что мастерСубъективный офлайн(Subjectively Down).

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

Если нет достаточного количества сторожевых устройств, чтобы согласиться на автономный режим ведущего, объективная автономная идентификация ведущего будет удалена; если мастер ответит на команду PING сторожевого устройства, объективная автономная идентификация также будет удалена.

алгоритм выборов

Когда мастер считается объективно отключенным, как он выполняет восстановление после сбоя? Первоначальный страж сначала выбирает начальника стража для устранения неисправности.Алгоритм выбора начальника стража называетсяАлгоритм плота:

Страж (sentinelA), обнаруживший, что мастер находится в автономном режиме, отправит другим стражам команды для опроса с просьбой выбрать себя в качестве босса стража.
Если целевой страж не выберет другого стража, страж (страж A) будет выбран в качестве босса.
Если выбрано более половины стражей SentinelA (принцип половины), босс должен быть SentinelA.
Если одновременно работает несколько часовых и может быть одинаковое количество голосов, они будут ждать следующего случайного момента, чтобы снова инициировать запрос кампании, и проводить новый раунд голосования, пока не будет избран босс.

После того, как босс-страж избран, босс-страж автоматически ответит на ошибку и выберет ведомого из ведомых в качестве основной базы данных.Правила выбора следующие:

во всех рабахslave-priorityБудет выбран тот, у которого наивысший приоритет.
Если приоритеты совпадают, будет выбран тот, у которого наибольшее смещение, потому что смещение записывает приращение репликации данных, и чем больше смещение, тем полнее данные.
Если оба вышеперечисленных одинаковы, выберите тот, у которого наименьший идентификатор.

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

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

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

Стражи могут выполнять своевременный мониторинг, обнаружение пульса и своевременное обнаружение системных проблем между часовыми и между часовыми и ведущими, что компенсирует недостатки системы ведущий-ведомый.

недостаток

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

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

Практичная конструкция

Наконец, давайте построим дозорный режим.Настроить дозорный режим относительно просто.На основе сконфигурированного выше режима ведущий-подчиненный создается папка для хранения файлов конфигурации трех дозорных:

mkdir /root/redis-4.0.6/sentinel.conf  /root/redis/sentinel/sentinel1.conf 
mkdir /root/redis-4.0.6/sentinel.conf  /root/redis/sentinel/sentinel2.conf 
mkdir /root/redis-4.0.6/sentinel.conf  /root/redis/sentinel/sentinel3.conf

Добавьте следующую конфигурацию в эти три файла:

daemonize yes # 在后台运行
sentinel monitor mymaster 127.0.0.1 6379 1 # 给master起一个名字mymaster，并且配置master的ip和端口
sentinel auth-pass mymaster 123456 # master的密码
port 26379 #另外两个配置36379,46379端口
sentinel down-after-milliseconds mymaster 3000 # 3s未回复PING就认为master主观下线
sentinel parallel-syncs mymaster 2  # 执行故障转移时，最多可以有2个slave实例在同步新的master实例
sentinel failover-timeout mymaster 100000 # 如果在10s内未能完成故障转移操作认为故障转移失败

После настройки запустите три часовых соответственно:

./redis-server sentinel1.conf --sentinel
./redis-server sentinel2.conf --sentinel
./redis-server sentinel3.conf --sentinel

Затем пройти:ps -aux|grep redisСмотреть:Вы можете видеть, что три экземпляра Redis и три Sentinel были запущены нормально.Теперь войдите в систему 6379 и проверьте основную информацию через INFO Repliaction:

Текущий мастер — 6379, затем давайте проверим автоматическое восстановление после сбоя часового, уничтожим процесс 6379 напрямую, а затем снова проверим информацию мастера, войдя в 6380:

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

Кластерный режим

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

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

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

Принцип разделения данных

Схематическая диаграмма кластера все еще хорошо понятна.Алгоритм разделения виртуальных слотов, используемый в кластере Redis, делит кластер Redis на 16384 слота (0-16383).

Например, для трех мастеров, показанных на рисунке ниже, слоты в диапазоне 0-16383 могут быть разделены на три части (0-5000), (5001-11000) и (11001-16383) соответственно, которые data диапазоны слотов трех узлов кэша.

Когда клиент запрашивает, он сначала вычисляет слот, в котором находится ключ, выполняя проверку CRC16 для ключа и по модулю 16384 (CRC16(key)%16383), а затем переходит к соответствующему слоту для выборки или сохранения данных, так что Реализовано обновление доступа к данным.

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

Связь узла

Данные хранятся в осколках между узлами, так как же узлы взаимодействуют? Это в основном то же самое, что и команда, упомянутая в предыдущем режиме Sentinel.

Во-первых, новый онлайн-узел отправит сообщение Meet старому участнику через протокол Gossip, указав, что он является новым участником.

После того, как старые участники получат сообщение Meet, они восстановят сообщение PONG, если нет сбоя, указывая, что новые узлы могут присоединиться.За исключением первой отправки сообщения Meet, впоследствии будут отправлены обычные сообщения PING, чтобы реализовать связь между узлами.

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

запрос данных

Информация о слотах упоминается выше и хранится в нижней части Redis.unsigned char myslots[CLUSTER_SLOTS/8]Массив содержит информацию о слотах для каждого узла.

Поскольку это двоичный массив, в нем хранятся только значения 0 и 1, как показано на следующем рисунке:

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

Например, узел кластера 1 отвечает за хранение данных слотов от 0 до 5000, но только 0, 1 и 2 хранят данные в это время, а в других слотах нет данных, поэтому значение, соответствующее 0, 1 и 2, равно 1.

Кроме того, каждый нижний уровень redis также поддерживает массив clusterNode размером 16384, который используется для хранения ip, порта и другой информации узла, отвечающего за соответствующий слот, так что каждый узел поддерживает информацию метаданных других узлов. , которому несложно вовремя найти соответствующий узел.

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

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

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

Что делать, если выполняется миграция данных? Старый узел отправит клиенту запрос на перенаправление ASK и вернет IP и порт целевого узла, на который мигрировал клиент, чтобы данные также можно было получить.

расширяться и сжиматься

Расширение и сжатие — это онлайн и оффлайн узлы.Если узел выходит из строя, происходит процесс автоматического восстановления после сбоя (узла сужения).

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

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

А после сбоя, выбора контрольного узла-босса, переизбрания главного узла и того, как ведомый становится главным узлом, вы можете просмотреть предыдущий процесс выбора контрольного режима.

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

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

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

недостаток

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

Кроме того, кластерный режим приводит к резкому увеличению количества узлов.Для кластерного режима требуется не менее 6 машин.Из-за метода выбора, который соответствует принципу половины, это также усложняет архитектуру.

Ведомый действует только как холодная резервная копия и не может уменьшить нагрузку чтения ведущего.

Практичная конструкция

Развертывание режима кластера относительно простое, если в redis.conf добавлена следующая информация о конфигурации:

port 6379# 本示例6个节点端口分别为6379、6380、6381、6382、6383、6384
daemonize yes # r后台运行 
pidfile /var/run/redis_6379.pid # 分别对应6379、6380、6381、6382、6383、6384
cluster-enabled yes # 开启集群模式 
masterauth 123456# 如果设置了密码，需要指定master密码
cluster-config-file nodes_6379.conf # 集群的配置文件，同样对应6379、6380、6381、6382、6383、6384六个节点
cluster-node-timeout 10000 # 请求超时时间

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

./redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381  127.0.0.1:6382  127.0.0.1:6383  127.0.0.1:6384  -a 123456

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