文章目录

  • Redis
  • Redis应用场景
  • 下载及安装
  • Redis常用指令
  • Redis持久化
  • Redis主从复制
  • Redis的Sentinel分布式系统（主从切换）
    • sentnel（Redis的高可用方案）
    • Sentinel作用
    • Sentinel工作方式
    • 主观下线和客观下线
    • Sentinel配置
  • 通过Twemproxy配置Redis集群
    • Twemproxy
    • Twemproxy下载
    • 安装
    • 配置
    • 测试
  • 官方Redis集群
    • Redis 集群介绍
    • Redis 集群的端口
    • Redis 集群和数据分片
    • Redis 集群主从模式
    • Redis 集群一致性保证
    • 总结
    • 配置
      • 创建6个redis实例
      • 创建集群
    • 测试
    • 节点的热添加

实验环境：rhel7.6

Redis

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便.\

Redis应用场景

  • 热点数据的缓存
  • 限时业务的运用
  • 数据库
  • 消息中间件

下载及安装

下载源码包，这里下载的版本为5.0.8
下载地址：
redis官网：redis.io

下载完成后，对压缩包进行解压：
解压完成后直接make：


make完成后直接使用make install：
进入utils目录,执行脚本install_server.sh：

确定端口、配置文件、日志文件、数据目录、命令位置

Redis常用指令

Redis 命令用于在 redis 服务上执行操作。
执行/etc/init.d/redis_6379 start来启动redis服务

启动 redis 服务器，打开终端并输入命令 redis-cli，该命令会连接本地的 redis 服务
所有的命令可在官方文档中查找用法。

指令 含义
config get * 查看配置
select 1 选择数据库
flushdb 清空当前数据库
flushall 清空所有数据库
move key 1 移动key
rename 【oldkey】【newkey】 改名
expire key 10 设置过期时间
persist key 设置持久化，移除key的生存时间
exists key 判断是否存在

查看配置：所有的配置以key-value方式展现

redis共有16个数据库, 默认进入的是数据库0：


在一个数据库中存入的信息只能在该数据库中查询，在其他数据库不能查询：

清空当前数据库：

为数据设置10秒过期时间,TTL为查询过期时间：

Redis持久化

默认使用RDB快照存储。
RDB格式（适合主从复制）：
三种：

  • SAVE：

    使用set存入的name值是在内存中，执行SAVE命令后，该数据就会保存在redis的数据目录中[/var/lib/redis/6379/]：生成rdb文件。 RDB快照存储（默认）
  • BGSAVE：当数据量特别庞大时，执行SAVE指令会阻塞命令的输入，此时可以使用bgsave会进行后台执行SAVE
  • 由服务自动执行
    使用CONFIG GET SAVE指令可看到服务自动执行持久化情况服务自动执行持久化情况：

    或者在配置文件中（/etc/redis/6379.conf）中看到服务自动执行持久化情况服务自动执行持久化情况：
    在配置文件中可定义多条自动执行永久化的规则，默认规则为：
    触发条件为：一条Key数据被改变时，900秒会进行BGSAVE，十条Key数据被改变时，300秒会进行BGSAVE；一万条Key数据被改变时，60秒会进行BGSAVE。
    注意：不宜设置太过于频繁，BGSAVE动作耗内存，容易造成性能瓶颈。

AOF(适合数据据恢复)：
默认不开启，可在配置文件中开启：

三种方式：

appendfsync always ##写一条记录一条
appendfsync everysec##每秒钟记录一次
appendfsync no ##自己不定义，跟随操作系统（30s一次）

修改完成后重启redis，可以看到aof文件已经生成了：


在redis中作操作：
INCR nu（计数）
查看刚才生成的aof文件，可以看到，将所有操作记录：
有点类似于mysql中的binlog
但是在此文件中有许多冗余数据，比如刚才的技术操作执行了50次，在aof文件中记录了到50，而rdb中则记录的最终的数值50。所以主从复制使用的是rdb文件，而aof文件则适合数据恢复。

Redis主从复制

我们在本机在开一个端口6380为从redis,制定主redis主机为本机的6379：
6380端口已经打开：

在6379的主redis中写入数据，写入后在6380的从redis中进行查询，成功查询到：

当redis为slave状态时，本地数据会丢失，redis为readonly：

实验环境 redis主机：
server1[172.25.1.1]<主>
server2[172.25.1.2]
server3[172.25.1.3]

在server2、server3上的redis配置文件中，添加主redis信息，监听本机所有接口：
注意：在server1<主>上也要监听所有接口，默认监听本机回环接口127.0.0.1
此时主从复制就配置完成。
测试：
server1的rediss数据：

[root@server1 ~]# hostname
server1
[root@server1 ~]# redis-cli
127.0.0.1:6379> get name
"xng"
127.0.0.1:6379>

在server2，server3上进行查询：

[root@server2 redis]# hostname
server2
[root@server2 redis]# redis-cli
127.0.0.1:6379> get name
"xng"[root@server3 ~]# hostname
server3
[root@server3 ~]# redis-cli
127.0.0.1:6379> get name
"xng"

主从复制原理：
slave向master发送连接请求（认证）
认证通过后，slave发送同步指令给master，触发master执行bgsave动作，产生rdb文件。同时开辟缓冲区，记录bgsave动作之后的写操作。gbsave完成后，发送给slave。
slave收到rdb文件后在本机首先执行flushall操作，清空所有数据，导入rdb文件（全量）。
master上perlicationfeedslave（）缓冲区的写操作再发送给slave，最终达到数据一致。
至此实现主从复制。

Redis的Sentinel分布式系统（主从切换）

之前已经实现了主从复制，但是当master挂掉之后，还无法进行故障切换。
问题的引出：
一般的主从切换;
当master挂掉之后，从节点转化为master，接受新的用户请求。另外一台slave开始复制新的master上的数据。但是如果master和slave之间有了网络隔离，master没有挂，但是两台slave认为master挂了，会有一个slave节点身份提升为master，当网络隔离取消后，原master发现集群已经有master，身份降级为slave。但是！！！在成为slave的时候会进行flushall操作！

要实现redis的主从切换，每个节点需要配置sentinel。

sentnel（Redis的高可用方案）

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中。

Sentinel作用

  • Master状态检测。
  • 如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。
  • Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

Sentinel工作方式

  • 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
  • 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
  • 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
  • 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
  • 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
  • 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
  • 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
    　　若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

主观下线和客观下线

  • 主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
  • 客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
    　　SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。
    　　ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。

Sentinel配置

首先在redis源码包中将redis自带的配置文件sentinel拷贝到redis的配置目录（所有节点都需要做）：

编辑sentinel的配置文件：
关闭保护模式：
指定master的地址及端口：
其中，作后边的2的含义为：最少需要两个节点判断master存活才认为master为存活状态

down-after-milliseconds 选项所指定的值默认为30秒：

sentinel parallel-syncs mymaster 值默认为1
新的master只允许每次一个slave同步数据
这里有好多人问：将此值设置大不是会同步更快吗？
虽然将此值设置大会一次同步多台slave，会更快完成切换。但是在同步数据的过程中，slave是不可读的，那么据群众能被用户访问的活跃节点数就越少。将此值设置小的优点就是集群可用度高，缺点是切换速度慢。

切换默认超时时间默认是3分钟：

到此，配置完成。
使用 redis-sentinel /etc/redis/sentinel.conf (redis-sentinel + 配置文件)启动sentinel（每台节点都做）：

此时关掉server1（master）上的redis，查看sentinel输出内容的变化：

master成功从server1切换到server3。

此时开启server1上的redis服务，server1自动加入集群，身份为slave：

通过Twemproxy配置Redis集群

配置完Redis的主从复制、主从切换可以清晰的感受到，这仅仅只是增加了Redis读的性能，写的性能依旧是没有增加（只有一个点）。
设想：
能不能多点对redis进行写操作？
能不能让客户端通过调度器访问后端的多台Redis服务器？

Twemproxy

Twemproxy是一种代理分片机制，由Twitter开源，主要用于减少后端缓存服务器的连接数量。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis或memcached服务器，再原路返回。该方案很好的解决了单个Redis或memcached实例承载能力的问题。Twemproxy本身也是单点，需要用Keepalived做高可用方案，可以使用多台服务器来水平扩张redis或memcached服务，可以有效的避免单点故障问题。

Twemproxy下载

Twemproxy源码托管在GIthub上，直接可以下载源码。
https://github.com/twitter/twemproxy

实验环境：
twemproxy：server4[172.25.1.4]
master:
server1[172.25.1.1]
server2[172.25.1.2]
server3[172.25.1.3]
将刚才做实验时身份为slave的redis改为master：

127.0.0.1:6379> SLAVEOF no one
OK

安装

解压完成后，进入解压目录，没有找到configure
按照github上指定的命令：
下载相关工具：

yum install automake libtool autoconf -y

在解压目录中：
执行：

[root@server4 twemproxy-master]# autoreconf -fvi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: adding subdirectory contrib/yaml-0.1.4 to autoreconf
autoreconf: Entering directory `contrib/yaml-0.1.4'
autoreconf: configure.ac: not using Autoconf
autoreconf: Leaving directory `contrib/yaml-0.1.4'
autoreconf: configure.ac: creating directory config
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:36: installing 'config/config.guess'
configure.ac:36: installing 'config/config.sub'
configure.ac:16: installing 'config/install-sh'
configure.ac:16: installing 'config/missing'
src/Makefile.am: installing 'config/depcomp'
autoreconf: Leaving directory `.'

此时configure出现：

编译：./configure
make:
make install:

配置

创建配置文件： vim /etc/twemproxy.yml

lpha:listen: 172.25.1.4:22121hash: fnv1a_64distribution: ketamaauto_eject_hosts: trueredis: trueserver_retry_timeout: 20000server_failure_limit: 1servers:- 172.25.1.1:6379:1- 172.25.1.2:6379:1- 172.25.1.3:6379:1

配置完成后启动服务：

nutcracker -d -c /etc/twemproxy.yml ##-d打入后台 -c制定配置文件

测试

注：若twemproxy端没有redis-cli命令可从其他主机拷贝。

redis-cli -p 22121 -h 172.25.1.4

可以取到之前的信息：

[root@server4 twemproxy-master]# redis-cli -p 22121 -h 172.25.1.4
172.25.1.4:22121> get name
"xng"

通过twemproxy往后端redis写入数据：

172.25.1.4:22121> set key1 111
OK

在后端redis中进行查询：
server1：
server2：
server3：

可以看到，数据key1被存放在server1上的redis。当server1上的redis挂掉：

[root@server1 ~]# /etc/init.d/redis_6379 stop
Stopping ...
Redis stopped

代理端不能取到在server1上的数据，但是还能继续写入数据：

172.25.1.4:22121> get key1
(error) ERR Connection refused
172.25.1.4:22121> set key6 666
OK

新的数据被写入到server2上的redis：

127.0.0.1:6379> get key6
"666"
127.0.0.1:6379>
[root@server2 ~]# hostname
server2

挂掉的节点被踢出集群。

将server1的redis启动，服务恢复：

[root@server1 ~]# /etc/init.d/redis_6379 start
Starting Redis server...

查询刚才存放在server1的redis中的数据：

172.25.1.4:22121> get key1
(nil)
172.25.1.4:22121> get key1
"111"
172.25.1.4:22121>

可以查到。

  • 可以看到，最大的问题就在于一个节点挂掉之后，那么此节点上的数据也就没有了，所以一般对每个master做高可用，配置主从复制及主从切换。但是还是有很大的数据丢失风险，且还需要解决调度器twemproxy单点问题。

官方Redis集群

Redis 集群介绍

Redis Cluster 提供一种Redis安装方式：数据自动在多个Redis节点间分片。

Redis Cluster 提供一定程度的高可用，在实际的环境中当某些节点失败或者不能通讯的情况下能够继续提供服务。大量节点失败的情况下集群也会停止服务（例如大多数主节点不可用）。

Redis集群提供的能力：

  • 自动切分数据集到多个节点上。
  • 当部分节点故障或不可达的情况下继续提供服务。

Redis 集群的端口

每个Redis集群节点需要打开两个TCP连接。端口6379提供给客户端连接，外加上一个端口16379，记起来也比较容易，在6379的基础上加10000。

端口16379提供给集群总线使用，总线用来集群节点间通信，使用的是二进制协议。集群总线的作用：失败检测、配置升级、故障转移授权等。客户端只能连接6379端口，不能连接端口16379。防火墙需要确保打开这两个端口，否则集群节点之间不能通信。

命令端口和总线端口之间总是相差10000 。

每个节点的端口原则:

  • 客户端通讯端口需要开放给所有与集群交互的客户端，和集群内的其它节点(主要是用来做keys迁移)。
  • 集群总线端口（命令端口+10000）需要被所有其它集群节点能访问到。

集群总线使用二进制协议（不同于跟客户端通信协议）来进行节点之间数据交换，这个协议更适合节点间使用小的带宽和处理时间来交换数据。

Redis 集群和数据分片

Redis集群不是使用一致性哈希，而是使用哈希槽。整个redis集群有16384个哈希槽，决定一个key应该分配到那个槽的算法是：计算该key的CRC16结果再模16834。

集群中的每个节点负责一部分哈希槽，比如集群中有３个节点，则：

  • 节点Ａ存储的哈希槽范围是：0 – 5500
  • 节点Ｂ存储的哈希槽范围是：5501 – 11000
  • 节点Ｃ存储的哈希槽范围是：11001 – 16384

这样的分布方式方便节点的添加和删除。比如，需要新增一个节点Ｄ，只需要把Ａ、Ｂ、Ｃ中的部分哈希槽数据移到Ｄ节点。同样，如果希望在集群中删除Ａ节点，只需要把Ａ节点的哈希槽的数据移到Ｂ和Ｃ节点，当Ａ节点的数据全部被移走后，Ａ节点就可以完全从集群中删除。

因为把哈希槽从一个节点移到另一个节点是不需要停机的，所以，增加或删除节点，或更改节点上的哈希槽，也是不需要停机的。

集群支持通过一个命令（或事务, 或lua脚本）同时操作多个key。通过“哈希标签”的概念，用户可以让多个key分配到同一个哈希槽。哈希标签在集群详细文档中有描述，这里做个简单介绍：如果key含有大括号”{}”,则只有大括号中的字符串会参与哈希，比如”this{foo}”和”another{foo}”这２个key会分配到同一个哈希槽，所以可以在一个命令中同时操作他们。

Redis 集群主从模式

为了保证在部分节点故障或网络不通时集群依然能正常工作，集群使用了主从模型，每个哈希槽有一（主节点）到N个副本（N-1个从节点）。

在我们刚才的集群例子中，有A,B,C三个节点，如果B节点故障集群就不能正常工作了，因为Ｂ节点中的哈希槽数据5501-11000没法操作。

但是，如果我们给每一个节点都增加一个从节点，就变成了：A,B,C三个节点是主节点，A1, B1, C1 分别是他们的从节点，当B节点宕机时，我们的集群也能正常运作。

B1节点是B节点的副本，如果B节点故障，集群会提升B1为主节点，从而让集群继续正常工作。但是，如果B和B1同时故障，集群就不能继续工作了。

Redis 集群一致性保证

Redis集群不能保证强一致性。一些已经向客户端确认写成功的操作，会在某些不确定的情况下丢失。

产生写操作丢失的第一个原因，是因为主从节点之间使用了异步的方式来同步数据。

一个写操作是这样一个流程：

  • 客户端向主节点B发起写的操作
  • 主节点B回应客户端写操作成功
  • 主节点B向它的从节点B1,B2,B3同步该写操作

从上面的流程可以看出来，主节点B并没有等从节点B1,B2,B3写完之后再回复客户端这次操作的结果。所以，如果主节点B在通知客户端写操作成功之后，但同步给从节点之前，主节点Ｂ故障了，其中一个没有收到该写操作的从节点会晋升成主节点，该写操作就这样永远丢失了。

就像传统的数据库，在不涉及到分布式的情况下，它每秒写回磁盘。为了提高一致性，可以在写盘完成之后再回复客户端，但这样就要损失性能。这种方式就等于Redis集群使用同步复制的方式。

基本上，在性能和一致性之间，需要一个权衡。

如果真的需要，Redis集群支持同步复制的方式，通过WAIT 指令来实现，这可以让丢失写操作的可能性降到很低。但就算使用了同步复制的方式，Redis集群依然不是强一致性的，在某些复杂的情况下，比如从节点在与主节点失去连接之后被选为主节点，不一致性还是会发生。

这种不一致性发生的情况是这样的，当客户端与少数的节点（至少含有一个主节点）网络联通，但他们与其他大多数节点网络不通。比如６个节点，A,B,C是主节点，A1,B1,C1分别是他们的从节点，一个客户端称之为Z1。

当网络出问题时，他们被分成２组网络，组内网络联通，但２组之间的网络不通，假设A,C,A1,B1,C1彼此之间是联通的，另一边，B和Z1的网络是联通的。Z1可以继续往B发起写操作，Ｂ也接受Z1的写操作。当网络恢复时，如果这个时间间隔足够短，集群仍然能继续正常工作。如果时间比较长，以致B1在大多数的这边被选为主节点，那刚才Z1发给Ｂ的写操作都将丢失。

注意，Z1给Ｂ发送写操作是有一个限制的，如果时间长度达到了大多数节点那边可以选出一个新的主节点时，少数这边的所有主节点都不接受写操作。

这个时间的配置，称之为节点超时（node timeout），对集群来说非常重要，当达到了这个节点超时的时间之后，主节点被认为已经宕机，可以用它的一个从节点来代替。同样，在节点超时时，如果主节点依然不能联系到其他主节点，它将进入错误状态，不再接受写操作。

总结

16384个hash槽不可或缺，当hash槽不完整时，集群不可用。
无中心化，6个节点3主3从，当数据是在本机，直接返回，当数据不在本机，进行重写。

配置

创建6个redis实例

在/usr/local下新建目录test-cluster
进入test-cluster新建7000 7001 7002 7003 7004 7005五个目录
在每个目录下编写redis配置文件redis.conf

[root@server1 local]# pwd
/usr/local
[root@server1 local]# mkdir cluster-tset
[root@server1 local]# cd cluster-tset/
[root@server1 cluster-tset]# mkdir 7000 7001 7002 7003 7004 7005
[root@server1 cluster-tset]# ls
7000  7001  7002  7003  7004  7005
[root@server1 cluster-tset]# cd 7000
[root@server1 7000]# vim redis.conf

编写完配置文件后开启服务：

root@server1 7000]# redis-server redis.conf
3432:C 29 Aug 2020 07:10:05.718 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3432:C 29 Aug 2020 07:10:05.718 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3432, just started
3432:C 29 Aug 2020 07:10:05.718 # Configuration loaded

配置文件：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
daemonize yes

注意：此配置文件为目录7000下的配置文件，7001的配置文件中port应为7001，以此类推，相同操作，打开服务。
端口成功打开：

创建集群

直接可以通过redis-cli创建集群：

[root@server1 7001]# redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \
> 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
> --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 127.0.0.1:7004 to 127.0.0.1:7000
Adding replica 127.0.0.1:7005 to 127.0.0.1:7001
Adding replica 127.0.0.1:7003 to 127.0.0.1:7002
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: 27b428bc9cdb396da31a11126d86585dd155f0a2 127.0.0.1:7000slots:[0-5460] (5461 slots) master
M: 97c8d22ad9a8c312a07c1a6c61ad678d3f4abc50 127.0.0.1:7001slots:[5461-10922] (5462 slots) master
M: 147ecda2bfb075158a347277010d0b32297b80ea 127.0.0.1:7002slots:[10923-16383] (5461 slots) master
S: 210c5e3d09345f479131fc09e0a0058f6d382467 127.0.0.1:7003replicates 27b428bc9cdb396da31a11126d86585dd155f0a2
S: 7a862d7fcf8c160f59029ae536fd2d70a6461455 127.0.0.1:7004replicates 97c8d22ad9a8c312a07c1a6c61ad678d3f4abc50
S: 006e1403670f7dc30bd994063f41a1364d7a072e 127.0.0.1:7005replicates 147ecda2bfb075158a347277010d0b32297b80ea
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
..
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 27b428bc9cdb396da31a11126d86585dd155f0a2 127.0.0.1:7000slots:[0-5460] (5461 slots) master1 additional replica(s)
S: 210c5e3d09345f479131fc09e0a0058f6d382467 127.0.0.1:7003slots: (0 slots) slavereplicates 27b428bc9cdb396da31a11126d86585dd155f0a2
M: 97c8d22ad9a8c312a07c1a6c61ad678d3f4abc50 127.0.0.1:7001slots:[5461-10922] (5462 slots) master1 additional replica(s)
S: 006e1403670f7dc30bd994063f41a1364d7a072e 127.0.0.1:7005slots: (0 slots) slavereplicates 147ecda2bfb075158a347277010d0b32297b80ea
S: 7a862d7fcf8c160f59029ae536fd2d70a6461455 127.0.0.1:7004slots: (0 slots) slavereplicates 97c8d22ad9a8c312a07c1a6c61ad678d3f4abc50
M: 147ecda2bfb075158a347277010d0b32297b80ea 127.0.0.1:7002slots:[10923-16383] (5461 slots) master1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

集群配置成功，（7000为主 7003为从，7001为主 7004为从，7002为主7005为从）！

测试

[root@server1 ~]# redis-cli -c -p 7000
127.0.0.1:7000> set k1 111
-> Redirected to slot [12706] located at 127.0.0.1:7002
OK
127.0.0.1:7002> set k2 222
-> Redirected to slot [449] located at 127.0.0.1:7000
OK
127.0.0.1:7000> get k1
-> Redirected to slot [12706] located at 127.0.0.1:7002
"111"
127.0.0.1:7002> get k2
-> Redirected to slot [449] located at 127.0.0.1:7000
"222"

写入的节点随机，在读取数据时，数据不在本地则进行重写。
可以看到，k1的值是储存在7002上，在查询时，自动重写到7002。

127.0.0.1:7002> SHUTDOWN
not connected>
[root@server1 ~]# redis-cli -c -p 7000
127.0.0.1:7000> get k1
-> Redirected to slot [12706] located at 127.0.0.1:7005
"111"
127.0.0.1:7005>

将7002的redis关掉后，再次查询保存在7002的数据依然可以查询到，自动重写到了7005（7002的从节点）

127.0.0.1:7005> SHUTDOWN
not connected>
[root@server1 ~]# redis-cli -c -p 7000
127.0.0.1:7000> get k1
(error) CLUSTERDOWN The cluster is down

将7002的从节点7005关掉之后，再次查询7002上的数据，因为hash槽已经缺少一部分了，集群不可用。

[root@server1 local]# cd cluster-tset/7002
[root@server1 7002]# redis-server redis.conf
3787:C 29 Aug 2020 07:55:53.791 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3787:C 29 Aug 2020 07:55:53.791 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3787, just started
3787:C 29 Aug 2020 07:55:53.791 # Configuration loaded
[root@server1 7002]# cd /usr/local/cluster-tset/7005
[root@server1 7005]# redis-server redis.conf
3794:C 29 Aug 2020 07:57:18.061 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3794:C 29 Aug 2020 07:57:18.061 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3794, just started
3794:C 29 Aug 2020 07:57:18.061 # Configuration loaded
[root@server1 7005]# redis-cli -c -p 7000
127.0.0.1:7000> get k1
-> Redirected to slot [12706] located at 127.0.0.1:7005
"111"

将关闭的节点启动，集群恢复正常！

节点的热添加

再新创建两个redis实例，端口为7006 7007

[root@server1 7007]# redis-server redis.conf
3825:C 29 Aug 2020 08:14:20.903 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3825:C 29 Aug 2020 08:14:20.903 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3825, just started
3825:C 29 Aug 2020 08:14:20.903 # Configuration loaded
[root@server1 7007]# cd ../7006
[root@server1 7006]# redis-server redis.conf
3830:C 29 Aug 2020 08:14:29.373 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3830:C 29 Aug 2020 08:14:29.373 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3830, just started
3830:C 29 Aug 2020 08:14:29.373 # Configuration loaded

将两个实例添加进集群：

redis-cli --cluster add-node 127.0.0.7:7006 127.0.0.1:7000

[root@server1 7006]# redis-cli --cluster add-node 127.0.0.7:7007 127.0.0.1:7000 --cluster-slave --cluster-master-id 38ecdbedc41959519385b6768e0844df117f45cc  (7006d的id)

此时7006上还没有hash槽。
可以使用

[root@server1 7006]# redis-cli --cluster reshard 127.0.0.1:7000 --cluster-from xxxxxxxxxxxx（7000的id） --cluster-to xxxxxxxxxxxx （7006的id）--cluster-slots 1000（分配的hash槽数） --cluster-yes

进行添加。

Redis（持久化、主从复制、主从切换、twemproxy、redis集群）相关推荐

  1. Redis（主从复制、哨兵模式、集群）概述及部署

    Redis(主从复制.哨兵模式.集群)概述及部署 前言 一.主从复制 (1)主从复制原理 (2)主从复制作用 (3)主从复制流程 (4)搭建主从复制 ①修改master节点配置文件 ②修改Slave节 ...

  2. Redis单机模式主从模式哨兵模式集群模式搭建

    文章目录 一.Redis下载及安装 1.1.下载 1.2.环境安装 1.3.编译安装 1.4.修改配置 1.5.启动Redis 1.6.验证Redis是否启动 1.7.进入到Redis客户端 1.8. ...

  3. Linux企业运维 6.6 -- Redis部署及主从切换、Redis+Mysql读写分离

    目录 Redis简介 redis的编译.安装 1.server1的redis配置 2.server2的redis安装 3.server3配置redis 三.redis主从复制 四.Sentine主从自 ...

  4. 对Redis中主从复制、哨兵模式和集群进行部署

    目 录 前言 一.Redis主从复制的部署 ①作用 ②过程 ③搭建redis主从复制 1)安装Redis 2)修改Redis配置文件(Master节点操作) 3)修改Redis 配置文件(两个Slav ...

  5. redis 一般启动几个 哨兵_Redis6.0主从、哨兵、集群搭建和原理

    点击上方蓝色字体,选择"设为星标" 回复"资源"获取更多资源 大数据技术与架构点击右侧关注,大数据开发领域最强公众号! 暴走大数据点击右侧关注,暴走大数据! 由 ...

  6. redis哨兵主从不切换_Redis的三种模式：主从、哨兵、集群

    前言 Redis是一个开源的使用ANSI C语言编写.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库,并提供多种语言的API.普遍用于目前主流的分布式架构系统中,关于redis的详细 ...

  7. Redis数据库（三）——（主从复制、哨兵模式、集群）

    Redis数据库(三)--(主从复制.哨兵模式.集群) 一.Redis主从复制 1.Redis主从模式介绍 2.Redis主从复制的流程 3.Redis主从复制的作用 4.Redis主从复制的搭建 环 ...

  8. redis主从搭建和分片集群搭建

    文章目录 redis主从搭建 搭建一主一从: 下载安装redis:两台机器都需要操作 权限认证 理解主从复制原理.同步数据集 全量同步三个阶段: 增量同步: 心跳检测 redis哨兵模式 部署方案 搭 ...

  9. redis专题：redis的主从、哨兵、集群架构的配置和部署详情、以及问题分析

    文章目录 1. 在linux下安装redis 2. redis主从架构 2.1 redis主从架构搭建步骤 2.2 redis主从架构数据同步原理 2.3 如果在主从传输过程中,从节点挂了怎么办? 2 ...

  10. redis的三大模式主从，哨兵和集群

    一.前言 二.redis主从复制 1.主从复制的作用: 2.主从复制的流程 3.搭建主从复制 3.1.搭建环境 3.2.安装redis 3.3.主服务器配置查看以下行 3.4.从服务器配置查看以下行 ...

最新文章

  1. HBase常用功能和HBase+MapReduce使用总结
  2. Oracle数据库分组排序
  3. vulnhub_内网渗透测试的记录——网络安全
  4. labview求n阶乘的和_求极限方法总结
  5. .NET 4.0 调用 C dll 触发 AccessViolationException 异常的处理方案
  6. Linux移植随笔：让内核支持nor flash
  7. mac XAMPP环境下, 使用php函数mkdir()添加新目录(文件)报错,报错信息:permission denied;...
  8. 在不用第三方参数的情况下，交换两个参数的值
  9. 使用WinSCP命令上传文件到CentOS
  10. 一个OpenMP的学习程序
  11. 机器学习中数据预处理的几种方法
  12. DataParallel使用
  13. 你在被窝里刷手机岁月静好，一个名叫 Flink 的 ​“神秘引擎” 却在远方和时间赛跑...
  14. [后端开发]支付宝支付接口调试 （Python v3.6）
  15. Android resource compilation failed 一定能搞定的办法
  16. 信托购买高搜索产品容易推10元[奥运]门槛
  17. 计算机方向 会议级别
  18. C++ this指针详解
  19. python opencv 读取显示图片
  20. 中国“计算机天才”魏延政：入职华为年薪百万，抗癌5年41岁去世

热门文章

  1. 板绘技巧：水晶怎么画？如何画出晶莹剔透的效果？
  2. c++笔记（超详细超完整）
  3. 二维彩虹产品功能更新（H5编辑二维码）
  4. html5中分镜图文脚本,企业宣传片脚本如何撰写分镜头?
  5. 准备Scrum之旅 之 Hello，温哥华——《轻松Scrum之旅》（16）
  6. 防雷器和电涌保护器的区别
  7. 贝叶斯分析-学习笔记(超干的干货)
  8. 河北省会计证年检流程
  9. js之捕捉冒泡和事件委托
  10. 【开源“青女四轴”，DIY小四轴】