Redis（介绍、安装配置、主从复制、集群配置、新节点配置）

1、基本信息介绍

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支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

2、下载及安装

下载链接：http://117.128.6.11/cache/download.redis.io/releases/redis-5.0.5.tar.gz?ich_args2=502-25165515014245_77fbd9dd440d42206c2bc7a761a751dc_10001002_9c896d2cd4caf7d89238518939a83798_8940b2a470aa181b05d09f7a7d8e09ff

安装过程：

1、对安装包进行解压和安装：

图 1 解压及安装

因为没有预编译过程，文件中Makefile文件，所以可以直接进行编译安装。

2、编译安装后，安装配置目录：
 

####安装相关目录
[root@server1 utils]# cd /opt/redis-5.0.3/utils/

[root@server1 utils]# ./install_server.sh

 

图 2 安装配置目录

图 3 安装后的信息

 

3、 安装完成配置相关目录

####编辑配置文件:/etc/redis/6375.conf，将监听范围改为所有主机
###更改内容（其中save参数表示有多少键值对更新，以及相应的刷新时间）
....
70 bind 0.0.0.0
....

####完成配置后重启

图 4 编写完配置并重启

图 5 键值对测试

3、 Redis的主从复制

此时需要在server1（192.168.1.110） server2（192.168.1.120）上分别配置redis操作。

####对从属主机进行配置：/etc/redis/6379.conf
##配置内容：
slaveof 192.168.1.110 6379        ##指定主节点即可

图 6 测试结果

此时文件存储的位置为：/var/lib/redis/6379

4、Redis的高可用：Redis Sentinel

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel 是一个分布式系统， 可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 可以在启动一个普通 Redis 服务器时通过给定 - -sentinel 选项来启动 Redis Sentinel 。

同样在出现故障时，Sentinel有两种解释：

• 主观下线（Subjectively Down， 简称 SDOWN) 指的是单个 Sentinel 实例对服务器做出的下线判断。如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 在 master-down-after-milliseconds 毫秒内一直返回无效回复， 那么 Sentinel 就会将这个服务器标记为主观下线。
• 客观下线（Objectively Down， 简称 ODOWN) 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就会被移除。客观下线条件只适用于主服务器。只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

4.1 服务配置

因为有一台主机将模拟下线，还要选取新的master节点出来，故设置三台服务器server1(192.168.1.110)、server2(192.168.1.120)、server3(192.168.1.130)，且上述三台主机均安装Redis服务，且设好主从复制。

####编辑配置哨兵的文件（sentinel.conf）
[root@server1 redis-5.0.3]# cp /opt/rpms/redis-5.0.3/sentinel.conf /etc/redis/
[root@server1 redis-5.0.3]# vim /etc/redis/sentinel.conf
###配置内容：
...
17  protected-mode no                                    ##关闭保护程序
...
84 sentinel monitor mymaster 192.168.1.110 6379 2        ##设置主节点及客观下线数
...
113 sentinel down-after-milliseconds mymaster 10000      ##访问测试时间
...

图 7 修改配置并启动

图 8 可以查看到信息

查看哨兵信息：

在主机中查看哨兵信息：redis-cli -p 26379

图 9 查看哨兵信息

测试：

#### 测试
##关闭server1的服务
[root@server1 utils]# redis-cli
127.0.0.1:6379> SHUTDOWN
not connected> 

##在server2中查看信息

图 10 server1中关闭服务

server2出查看哨兵：master切换

图 11 master切换

查看信息：

图 12 查看信息

重新起动server1（/etc/init.d/redis_6375 start）后，查看server2的信息：

图 13 server2信息

5、 Redis集群

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令。

Redis 集群的优势：

• 自动分割数据到不同的节点上。
• 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。

Redis 集群的主从复制

假设具有A，B，C三个节点的集群，在集群创建的时候为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了。不过当B和B1 都失败后，定义在B中哈希槽中的数据不可用。

Redis的集群功能是基于内存分区的，所以在很大程度上均为配合使用。

配置：

在server1上建立实例：

###建立集群
[root@server1 ~]# mkdir /usr/local/rediscluster
[root@server1 ~]# cd /usr/local/rediscluster
[root@server1 rediscluster]# mkdir 700{1..6}
[root@server1 rediscluster]# ls
7001  7002  7003  7004  7005  7006
[root@server1 rediscluster]# cd 7001            ##建立集群及实例
[root@server1 7001]# vim redis.conf
[root@server1 7001]# cp redis.conf ../7002
[root@server1 7001]# cp redis.conf ../7003
[root@server1 7001]# cp redis.conf ../7004
[root@server1 7001]# cp redis.conf ../7005
[root@server1 7001]# cp redis.conf ../7006


###实例内容
  1 port                     7001
  2 cluster-enabled          yes
  3 cluster-config-file      nodes.conf
  4 cluster-node-timeout     5000
  5 appendonly               yes
  6 pidfile                  "/usr/local/rediscluster/7001/redis.pid"
  7 logfile                  "/usr/local/rediscluster/7001/redis.log"
  8 daemonize                yes
  9 dir                      "/usr/local/rediscluster/7001"
###################端口号，与设定端口相同，其他一致

图 14 建立与集群相关的目录即实例

配置完成启动6个实例：

图 15 启动实例

图 16 启动结果

启动完成，查看实例内容：

图 17 集群处于集群中

建立集群：

####建立相应的集群
redis-cli --cluster create --cluster-replicas 1 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 127.0.0.1:7006
                ##为每个主节点创建一个从属节点

查看创建结果，并分配哈希槽

图 18 创建主节点和从属节点

测试：

图 19 创建数据并获取

查看集群信息：

图 20 集群信息

此时数据存储位置：

图 21 数据存储位置

当关闭7002时，从从属7004获取数据

图 22 7002宕机

7002，7004同时宕机：

图 23 7002 7004 同时宕机

恢复数据，开启7004，7002即可。

6、在集群中插入新节点

Redis是在内存中分配的哈希槽进行存储数据的，然后根据键值进行查询调用。当集群大小固定时，新加入的节点是不会自动分配哈希槽的，下面我们就来解决问题。

设之前存在3组Redis的集群服务，现需要重新添加一组服务。

首先查看新的服务：

图 24 查看原服务

然后新建新节点的文件夹，并启动服务：

图 25 新建文件夹

将建立的新节点加入服务无器中，并查看相应的信息：

###新节点加入服务器
[root@server1 rediscluster]# redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001

###节点信息
[root@server1 rediscluster]# redis-cli -c -p 7007

图 26 加入新节点

上述结果发现7007没有哈希槽和slave,下面将7008添加位slave：

#### 添加节点为slave
[root@server1 rediscluster]# redis-cli --cluster add-node 127.0.0.1:7008 127.0.0.1:7007 --cluster-slave --cluster-master-id 74c50c0927d88bcf99161722cd45c393b1422c2c
                        ###这里的ID为主服务的ID

图 27 添加新节点

 查看7007的信息，可以看到7008为其节点：

####查看节点信息
[root@server1 rediscluster]# redis-cli -c -p 7007
127.0.0.1:7007> info

图 28 7007的信息

经过上面步骤，我们可以将新节点加入集群中，但是加入的新节点没有分配哈希槽，此时还不能使用，下面我们进行哈希槽的分配：

####手册信息：[root@server1 rediscluster]# redis-cli --cluster help

####查看当前哈希槽状态：
[root@server1 rediscluster]# redis-cli --cluster info 127.0.0.1:7001

####分配指定大小的哈希槽
[root@server1 rediscluster]# redis-cli --cluster reshard 127.0.1.01:7001


####分配过程中回答相应的问题
How many slots do you want to move (from 1 to 16384)? 3000
What is the receiving node ID? 74c50c0927d88bcf99161722cd45c393b1422c2c
Please enter all the source node IDs.
  Type 'all' to use all the nodes as source nodes for the hash slots.
  Type 'done' once you entered all the source nodes IDs.
Source node #1: all


####分配结束，查看指定信息
[root@server1 rediscluster]# redis-cli --cluster check 127.0.0.1:7001

 查看当前状态：

图 29 查看当前状态

分配哈希槽：

图 30 分配哈希槽

 

分配哈希槽的过程：

图 31 指定分配参数

 

分配结束后查看指定信息：

图 32 查看分配细节

因为上述分配过程，是采用在每个现有的哈希槽中，截取一部分给新的哈希槽，若想直接平均分配，则直接进行如下设置：

平均分配哈希槽：

#### 平均分配
[root@server1 rediscluster]# redis-cli --cluster rebalance 127.0.0.1:7001 --cluster-threshold 1 --cluster-use-empty-masters

        ###--cluster-use-empty-masters      #设置可以让没有分配slot的主节点参与，默认不允许
        ###--cluster-threshold <arg>        #迁移的slot阈值超过threshold，执行rebalance操作

均分哈希槽：

图 33 均分过程

 查看分配结果：

图 34 分配结果

 数据测试：

图 35 测试结果

 

【注】更多参数可参考官方文档或者博客：https://www.cnblogs.com/zhoujinyi/p/11606935.html

 参考资料：百度百科