Redis在项目上的常用操作【二】

最新推荐文章于 2021-10-26 10:05:48 发布

Coding测试

最新推荐文章于 2021-10-26 10:05:48 发布

阅读量165

点赞数

分类专栏：中间件知识集

本文链接：https://blog.csdn.net/tester_runing/article/details/104444641

版权

中间件知识集专栏收录该内容

13 篇文章 3 订阅

订阅专栏

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。

Coding测试

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis在项目上的常用操作【二】

Redis的高级用法redis集群redis 主从复制概念：持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障。主从复制原理图：说明主redis中的数据有两个副本（replication）即从redis1...
复制链接

扫一扫

专栏目录