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：
就又可以看到值了。