Redis数据库 --高可用与集群

实验环境：
server1 172.25.254.1
server2 172.25.254.2
server3 172.25.254.3

简介

Redis Sentinel是Redis官方的高可用性解决方案。

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

Sentinel 程序可以在编译后的 src 文档中发现， 它是一个命名为 redis-sentinel 的程序。

用cp命令，将sentinel的配置文件复制到三台主机的 /etc/redis/下：

cp sentinel.conf /etc/redis/

启动Sentinel

redis-server /path/to/sentinel.conf --sentinel

主观下线和客观下线

• 主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。

• 客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr
  命令来询问对方是否认为给定的服务器已下线。）

配置

server1 2 3 中配置哨兵;

vim /etc/redis/sentinel.conf

需要更改的为

protected-mode no                    不开启保护
sentinel monitor mymaster 172.25.254.1 6379 2            监控本机的6379端口，2代表有两个投票时才可以作为master主机
sentinel down-after-milliseconds mymaster 10000        当master主机挂掉了隔10s会进行切换master

server2 和server3 ，我们都设置为server1的slave结点:

vim /etc/redis/6379.conf

测试：
在三台主机中都启动sentinel

redis-server /etc/redis/sentinel.conf --sentinel

打开后是这个样子的:

可以看到当前的master和两个slave。还有两个哨兵，server1是server2和3，2是1和3，3是1和2.

我们在server1中进入 redis-cli 命令行，连接6379 端口，执行 info 命令
就可以看到：

看到复制的信息。
我们连接26379端口，查看哨兵信息：

redis-cli -p 26379

有两个slave，三个哨兵，因为我们三个结点都打开了哨兵。

我们现在关闭server1的redis，观察server2和server3如何产生新的master，这里需要等待10s，由于我们前面的设定。
server2中：

可以看出，server2已经成为了新的master。切换成功。

而且只有一个slave 是server3。

server3中;

它时slave结点，matser是server2.

现在恢复server1的redis：

 /etc/init.d/redis_6379 start

它会自动变成slave结点加入到server2的matser中。

集群

概念

Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。

Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.

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

Redis 集群的优势:

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

配置部署

我们先关闭前面开启的哨兵和redis。
server1 中

mkdir /usr/local/rediscluster         建立集群目录
[root@server1 rediscluster]# mkdir 700{1..6}         建立6个结点目录（实例）
[root@server1 rediscluster]# ls
7001  7002  7003  7004  7005  7006

在七个目录中都写一个配置文件（按序号替换）：

cd 7001
vim redis.conf

port 7001
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
pidfile "/usr/local/rediscluster/7001/redis.pid"
logfile "/usr/local/rediscluster/7001/redis.log"
daemonize yes
dir "/usr/local/rediscluster/7001"

然后我们就可以打开redis了：

[root@server1 7001]# redis-server redis.conf 

依次打开：

端口打开。

[root@server1 7001]# redis-cli -p 7001
127.0.0.1:7001> info

集群已经打开。

创建集群

server1 中：
用help查询集群的搭建

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

cluster-replicas 是创建复制结点，我们当前有6个结点，所以应该是三主三从。

以M开头的就是master结点，并分配16384个哈希槽，

我们用7001的登陆redis：

[root@server1 src]# redis-cli -c -p 7001
127.0.0.1:7001> set name westos
-> Redirected to slot [5798] located at 127.0.0.1:7002
OK

我们设置变量时就会从及群众自动重定向到7002上的5798槽上。

我们在 7003 上访问时

[root@server1 src]# redis-cli -c -p 7003
127.0.0.1:7003> get name
-> Redirected to slot [5798] located at 127.0.0.1:7002
"westos"

就会自动跳转到7002上。

7002当前是master，我们挂掉它测试高可用是否能生效：

127.0.0.1:7002> SHUTDOWN          挂掉7002
not connected> 

[root@server1 ~] redis-cli --cluster info 127.0.0.1:7001
Could not connect to Redis at 127.0.0.1:7002: Connection refused
127.0.0.1:7001 (da2992a7...) -> 0 keys | 5461 slots | 1 slaves.
127.0.0.1:7004 (c1f385c9...) -> 1 keys | 5462 slots | 0 slaves.
127.0.0.1:7003 (3cb02773...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 1 keys in 3 masters.
0.00 keys per slot on average.

可见7004当前就接替7002作为了master了，它没有slave.
此时我们还可以获取到值：

因为7002 和7004 是主从关系。
但当我们在挂掉7004 时：


就获取不到值了，因为它存储在第5798个哈希槽上。他还告诉我们集群已经挂了。
这样的集群性能就不是很高了，这也是redis不被广泛应用的弊端。

这就是保存在7002上面的建值对。

我们在开启刚才挂掉的7002 7004：

就又可以看到值了。