Redis的高级用法
redis集群
- redis 主从复制
概念：持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障。
主从复制原理图：
- 说明
- 主redis中的数据有两个副本（replication）即从redis1和从redis2，即使一台redis服务器宕机其它两台redis服务也可以继续提供服务。
- 主redis中的数据和从redis上的数据保持实时同步，当主redis写入数据时通过主从复制机制会复制到两个从redis服务上。
- 只有一个主redis，可以有多个从redis。
- 主从复制不会阻塞master，在同步数据时，master 可以继续处理client 请求。
- 主从复制实现过程
由于资源有限，这是测试使用一台Linux系统搭建redis伪集群演示示例：- 复制三份redis编译后的文件(编译后的文件默认路径：[/usr/local/redis]
cp -r redis-3.0.0 /usr/local/redis-6379
cp -r redis-3.0.0 /usr/local/redis-6380
cp -r redis-3.0.0 /usr/local/redis-6381
- 分别修改redis-6380和redis-638的redis.conf配置文件的端口分别改为：6380/6381。并配置master主机地址为：192.168.1.90 6379
# 3) Replication is automatic and does not need user intervention. After a
# network partition slaves automatically try to reconnect to masters
# and resynchronize with them.
#
slaveof 192.168.1.90 6379
# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the slave to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the slave request.
- 依次启动三个redis服务，6379为master主机，6380/6381为slave从机
[root@bogon local] ./redis-6379/bin/redis-server ./redis-6379/bin/redis.conf
[root@bogon local] ./redis-6380/bin/redis-server ./redis-6380/bin/redis.conf
[root@bogon local] ./redis-6381/bin/redis-server ./redis-6381/bin/redis.conf
[root@bogon local ps -ef |grep redis
root 53847 1 0 12:07 ? 00:00:00 ./redis-6379/bin/redis-server *:6379
root 53865 1 0 12:08 ? 00:00:00 ./redis-6380/bin/redis-server *:6380
root 53887 1 0 12:08 ? 00:00:00 ./redis-6381/bin/redis-server *:6381
root 53898 53314 0 12:08 pts/1 00:00:00 grep --color=auto redis
- 分别在三个redis的bin下执行：./redis-cli -p 6379，./redis-cli -p 6380，./redis-cli -p 6381 启动redis客户端，并查看响应服务器信息命令：info replication
[root@bogon bin]# ./redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.90,port=6380,state=online,offset=1527,lag=1
slave1:ip=192.168.1.90,port=6381,state=online,offset=1527,lag=1
master_repl_offset:1527
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1526
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:192.168.1.90
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:1555
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
[root@bogon bin]# ./redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:192.168.1.90
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:1597
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
- 测试redis集群数据读写
redis的master主机可进行数据的读写操作，salve主机只能进行数据的读操作。一定意义上也实现了数据的读写分离。
测试数据如下：master主机读写
127.0.0.1:6379> set name test
OK
127.0.0.1:6379> get name
"test"
6380salve从机读数据：
127.0.0.1:6380> get name
"test"
6381salve从机读数据
127.0.0.1:6381> get name
"test"
127.0.0.1:6381> set name user
(error) READONLY You can't write against a read only slave.
从上面的数据可以看出redis主从复制，数据的写操作只在master主机有效，从机无效。
redis容灾处理-高可用Sentinel哨兵策略
- Sentinel哨兵介绍：
Sentinel哨兵是redis官方提供的高可用方案，可以用它来监控多个Redis服务实例的运行情况。RedisSentinel是一个运行在特殊模式下的Redis服务器。RedisSentinel是在多个 Sentinel进程环境下互相协作工作的。
- Sentinel哨兵系统的主要任务
- 监控：Sentinel不断的检查主服务和从服务器是否按照预期正常工作。
- 提醒：被监控的Redis出现问题时，Sentinel会通知管理员或其他应用程序。
- 自动故障转移：监控的主Redis不能正常工作，Sentinel会开始进行故障迁移操作。将 一个从服务器升级新的主服务器。让其他从服务器挂到新的主服务器。同时向客户端 提供新的主服务器地址。
-
哨兵策略图解
- redis的哨兵策略实现过程
这里依然使用同一台Linux机器演示redis的哨兵策略的实现
- Sentinel 配置文件 复制三份sentinel.conf文件,分别修改端口为：26379/26380/26381
drwxr-xr-x. 11 root root 4096 2月 9 20:28 nginx
drwxr-xr-x. 3 root root 16 2月 17 19:41 redis
drwxr-xr-x. 3 root root 16 2月 22 12:01 redis-6379
drwxr-xr-x. 3 root root 16 2月 22 12:02 redis-6380
drwxr-xr-x. 3 root root 16 2月 22 12:02 redis-6381
drwxr-xr-x. 2 root root 6 4月 11 2018 sbin
-rw-r--r--. 1 root root 7109 2月 22 13:09 sentinel26379.conf
-rw-r--r--. 1 root root 7109 2月 22 13:12 sentinel26380.conf
-rw-r--r--. 1 root root 7109 2月 22 13:12 sentinel26381.conf
- 分别启动这三个哨兵服务，其中一个启动示例如下：
./redis-sentinel /usr/local/sentinel26379.conf
58233:X 22 Feb 13:15:29.070 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.0.0 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 58233
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
58233:X 22 Feb 13:15:29.074 # Sentinel runid is a624b22b704383502ea7c1c122f8f6204c5fecfd
58233:X 22 Feb 13:15:29.075 # +monitor master mymaster 127.0.0.1 6379 quorum 2
58233:X 22 Feb 13:15:30.080 * +slave slave 192.168.1.90:6380 192.168.1.90 6380 @ mymaster 127.0.0.1 6379
58233:X 22 Feb 13:15:30.080 * +slave slave 192.168.1.90:6381 192.168.1.90 6381 @ mymaster 127.0.0.1 6379
- redis通过哨兵策略实现故障转移
- 查看redis的服务与哨兵服务的运行状况,可以看到运行正常
[root@bogon ~]# ps -ef |grep redis
root 53847 1 0 12:07 ? 00:00:07 ./redis-6379/bin/redis-server *:6379
root 53865 1 0 12:08 ? 00:00:07 ./redis-6380/bin/redis-server *:6380
root 53887 1 0 12:08 ? 00:00:07 ./redis-6381/bin/redis-server *:6381
root 55208 55055 0 12:26 pts/1 00:00:00 ./redis-cli -p 6380
root 55245 55111 0 12:27 pts/2 00:00:00 ./redis-cli -p 6381
root 58233 55000 0 13:15 pts/0 00:00:01 ./redis-sentinel *:26379 [sentinel]
root 58627 58300 0 13:20 pts/3 00:00:00 ./redis/bin/redis-sentinel *:26380 [sentinel]
root 58718 58646 0 13:21 pts/4 00:00:00 ./redis/bin/redis-sentinel *:26381 [sentinel]
root 58798 58753 0 13:21 pts/5 00:00:00 grep --color=auto redis
- 假如6379的master主机宕掉，再次观察下剩余两个slave从机的状态变化，通过其中一个6381的salve从机可以看到master已经变成了6380了
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:12
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
- 假如之前宕机的6379服务再次恢复后再次查看6379的服务状态。，可以看到master主机又变成了6379。
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=39828,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=39562,lag=1
master_repl_offset:39828
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:39827
- 再次进行数据的读写操作
127.0.0.1:6379> set password 123456
OK
127.0.0.1:6379> get password
"123456"
127.0.0.1:6381> get password
"123456"
redis通过哨兵策略很好的实现了redis高可用容灾处理。
Sentinels哨兵监控 ：
1）Sentinel会不断检查Master和Slave是否正常。
2）如果Sentinel挂了，就无法监控，所以需要多个哨兵，组成Sentinel网络，一个健康的 Sentinel至少有3个Sentinel应用。彼此在独立的物理机器或虚拟机。
3）监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信 并交换彼此关于被监控服务器的信息。
4）当一个Sentinel认为被监控的服务器已经下线时，它会向网络中的其它Sentinel进行确 认，判断该服务器是否真的已经下线 。
5）如果下线的服务器为主服务器，那么Sentinel网络将对下线主服务器进行自动故障转移， 通过将下线主服务器的某个从服务器提升为新的主服务器，并让其从服务器转移到新的主服 务器下，以此来让系统重新回到正常状态 。
6）下线的旧主服务器重新上线，Sentinel会让它成为从，挂到新的主服务器下。
redis哨兵机制总结
- 总结 主从复制，解决了读请求的分担，从节点下线，会使得读请求能力有所下降，Master下 线，写请求无法执行 Sentinel会在Master下线后自动执行故障转移操作，提升一台Slave为Master，并让其它 Slave成为新Master的Slave。
- 推荐阅读
redis项目实战一
更多测试技术分享、学习资源以及一些其他福利可关注公众号：【Coding测试】获取：
