一引言
Redis 的基本数据类型, 高级特性, 与 Lua 脚本的整合等相关知识点都学完了, 说是学完了, 只是完成了当前的学习计划, 在以后的时间还需继续深入研究和学习从今天开始来讲一下有关 Redis 的集群模式, Redis 有三种集群模式, 第一个就是主从模式, 第二种哨兵模式, 第三种是 Cluster 集群模式, 第三种的集群模式是在 Redis 3.x 以后的版本才增加进来的, 我们今天就来说一下 Redis 第一种集群模式: 主从集群模式
二配置操作
实现主从复制 (Master-Slave Replication) 的工作原理: Slave 从节点服务启动并连接到 Master 之后, 它将主动发送一个 SYNC 命令 Master 服务主节点收到同步命令后将启动后台存盘进程, 同时收集所有接收到的用于修改数据集的命令, 在后台进程执行完毕后, Master 将传送整个数据库文件到 Slave, 以完成一次完全同步而 Slave 从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中此后, Master 主节点继续将所有已经收集到的修改命令, 和新的修改命令依次传送给 Slaves,Slave 将在本次执行这些数据修改命令, 从而达到最终的数据同步
如果 Master 和 Slave 之间的链接出现断连现象, Slave 可以自动重连 Master, 但是在连接成功之后, 一次完全同步将被自动执行
我先介绍一下我的环境, 操作系统是 Windows 10 企业版, Redis 有两个版本, 第一版本是以 Windows 服务形式安装的 Redis 服务器, IP 地址是: 192.168.131.1, 端口号: 6379, 当前没有设置密码; 第二个版本是在 Linux 系统下安装的 Redis 服务, IP 地址是: 192.168.127.128, 端口号是: 6379, 当前也没有设置密码今天测试两个情况, 一种情况: Windows 系统上的 Redis 服务做主服务节点, Linux 系统上的 Redis 服务做从服务节点, 第二种情况是: Linux 系统上的 Redis 服务做主服务节点, Windows 系统上的 Redis 服务做从服务节点其他情况就不测试了, 同系统之间测试就很容易了, 也不会出现什么问题
主从复制配置:
第一步: 修改从节点的配置文件: slaveof <masterip> <masterport>
第二步: 如果设置了密码, 就要设置: masterauth <master-password>
主从复制的配置很简单, 主要操作从节点的配置文件, 主节点不需要任何改动我们可以使用 info 查看 role 角色即可知道是主服务或从服务
1Windows 系统上的 Redis 服务做主服务节点, Linux 系统上的 Redis 服务做从服务节点(测试很顺利)
- // 主节点服务: 192.168.131.1 端口号: 6379 Windows 系统
- // 从节点服务: 192.168.127.128 端口号: 6379 Linux 系统
- // 现在主要修改从节点服务 Linux 系统上的 redis.conf 配置文件
- slaveof 192.168.131.1 6379
设置完成:
- // 主节点配置信息:
- 192.168.131.1:6379>info Replication
- #Replication
- role:master
- connected_slaves:1
- slave0:ip=192.168.131.1,port=6379,state=online,offset=239,lag=1
- master_repl_offset:239
- repl_backlog_active:1
- repl_backlog_size:1048576
- repl_backlog_first_byte_offset:2
- repl_backlog_histlen:238
- // 从节点配置信息:
- 192.168.127.128:6379>info Replication
- #Replication
- role:slave
- master_host:192.168.131.1
- master_port:6379
- master_link_status:up
- master_last_io_seconds_ago:8
- master_sync_in_progress:0
- slave_repl_offset:253
- slave_priority:100
- slave_read_only:1
- connected_slaves:0
- master_replid:7f2e5cde55803c8b78d26c16f0111695e3c1fb6f8
- master_replid2:000000000000000000000000000000000000000000
- master_repl_offset:253
- second_repl_offset:-1
- repl_backlog_active:1
- repl_backlog_size:1048576
- repl_backlog_first_byte_offset:2
- repl_backlog_histlen:252
2Linux 系统上的 Redis 服务做主服务节点, Windows 系统上的 Redis 服务做从服务节点(设置完成, 但是主节点不能连接, master_link_status:down, 该问题还没解决)
- // 主节点服务: 192.168.127.128 端口号: 6379 Linux 系统
- // 从节点服务: 192.168.131.1 端口号: 6379 Windows 系统
- // 现在主要修改从节点服务在 Windows 系统上的 redis.windows.conf 配置文件
- slaveof 192.168.127.128 6379
- // 如果需要密码
- //masterauth 123456
- // 主节点配置信息:
- 192.168.127.128:6379>info Replication
- #Replication
- role:master
- connected_slaves:0
- master_replid:23ed05016a5fdf45e45318281b7f827cbbf75025
- master_replid2:0000000000000000000000000000000000000000
- master_repl_offset:0
- second_repl_offset:-1
- repl_backlog_active:1
- repl_backlog_size:1048576
- repl_backlog_first_byte_offset:1
- repl_backlog_histlen:0
- // 从节点配置信息:
- 192.168.127.128:6379>info Replication
- #Replication
- role:slave
- master_host:192.168.127.128
- master_port:6379
- master_link_status:down
- master_last_io_seconds_ago:-1
- master_sync_in_progress:0
- slave_repl_offset:1
- master_link_down_since_seconds:jd
- slave_priority:100
- slave_read_only:1
- connected_slaves:0
- repl_backlog_active:0
- repl_backlog_size:1048576
- repl_backlog_first_byte_offset:0
- repl_backlog_histlen:0
三主从模式的配置
下面是我使用的配置, 使用主从模式, 持久化的模式要保持一致
- 1######Master config
- 1.1###General 配置
- daemonize yes #默认值是 no, 把只修改为 yes, 以后台模式运行
- pidfile /var/run/redis-6379.pid #pid 文件位置, 保持默认值, 不用修改
- port 6379 #使用默认端口
- timeout 30 # Client 端空闲断开连接的时间
- loglevel warning #日志记录级别, 默认是 notice, 我这边使用 warning, 是为了监控日志方便使用 warning 后, 只有发生告警才会产生日志, 这对于通过判断日志文件是否为空来监控报警非常方便
- logfile /root/application/program/redis-tool/logs/redis.log #日志文件的位置
- databases 16 #默认当前使用的是索引为 0 的 Redis 数据库, 使用 select n 命令可以选择要使用第几个 Redis 的数据库, 这样不同的应用程序使用相同的 key 也不会有问题
- 1.2###SNAPSHOTTING 设置:
为了保证数据相对安全, 在下面的设置中, 更改越频繁, SNAPSHOTTING 越频繁, 也就是说, 压力越大, 反而花在持久化上的资源会越多所以我选择了 master-slave 模式, 并在 master 关掉了 SNAPSHOTTING
- #save 900 1 #在 900 秒之内, redis 至少发生 1 次修改则 redis 抓快照到磁盘
- #save 300 100 #在 300 秒之内, redis 至少发生 100 次修改则 redis 抓快照到磁盘
- #save 60 10000 #在 60 秒之内, redis 至少发生 10000 次修改则 redis 抓快照到磁盘
- rdbcompression yes #使用压缩
- dbfilename dump.rdb #SNAPSHOTTING 的文件名
- dir /root/application/program/redis-tool/datas #SNAPSHOTTING 文件的路径
- 1.3### REPLICATION 设置:
- #slaveof# 如果这台机器是台 redis slave, 可以打开这个设置如果使用 master-slave 模式, 保持主从设置一致, 防止出现莫名其妙的问题
- #slave-serve-stale-data yes
- 1.4### SECURITY 设置:
- #requirepass aaaaaaaaa #redis 性能太好, 用个 passwd 意义不大
- #rename-command FLUSHALL "" #可以用这种方式关掉非常危险的命令, 如 FLUSHALL 这个命令, 它清空整个 Redis 服务器的数据, 而且不用确认且从不会失败
- 1.5### LIMIT 设置:
- maxclients 0# 无 client 连接数量的限制 maxmemory 14gb
- //redis 最大可使用的内存量, 我的服务器内存是 16G, 如果使用 redis SNAPSHOTTING 的 copy-on-write 的持久会写方式, 会额外的使用内存, 为了使持久会操作不会使用系统 VM, 使 redis 服务器性能下降,
建议保留 redis 最大使用内存的一半 8G 来留给持久化使用, 我个人觉得非常浪费我没有在 master 上不做持久化, 使用主从方式 maxmemory-policy volatile-lru #使用 LRU 算法删除设置了过期时间的 key, 但如果程序写的时间没有写 key 的过期时间,
建议使用 allkeys - lru, 这样至少保证 redis 不会不可写入
- 1.6###APPEND ONLY MODE 设置
- appendonly yes# 主从要保持一致, 防止出现一些莫名其妙的问题
- appendfsync always
- no-appendfsync-on-rewrite no
- auto-aof-rewrite-percentage 100
- auto-aof-rewrite-min-size 64mb
- 1.7###SLOW LOG 设置:
- slowlog - log - slower - than 10000# 如果操作时间大于 0.001 秒, 记录 slow log,
这个 log 是记录在内存中的, 可以用 redis - cli slowlog get 命令查看 slowlog - max - len 1024#slow log 的最大长度
- 1.8###VIRTUAL MEMORY 设置
- vm-enabled no #不使用虚拟内存, 在 redis 2.4 版本, 作者已经非常不建议使用 VM
- vm-swap-file
- vm-max-memory 0
- vm-page-size 32
- vm-pages 134217728
- vm-max-threads 4
- 1.9###ADVANCED CONFIG 设置, 下面的设置主要是用来节省内存的, 保持默认值
- hash-max-zipmap-entries 512
- hash-max-zipmap-value 64
- list-max-ziplist-entries 512
- list-max-ziplist-value 64
- set-max-intset-entries 512
- zset-max-ziplist-entries 128
- zset-max-ziplist-value 64
- activerehashing yes
- 1.10###INCLUDES 设置 , 可以配置一些其它的设置, 如 slave 的配置
- #include /path/to/local.conf
- #include /path/to/other.conf
- #include /opt/redis/etc/slave.conf 如果是 slave server, 把这个注释打开 slave 配置:$cat /opt/redis/etc/slave.conf
- 2######slave config
- 2.1###REPLICATION 设置:
- slaveof 192.168.127.1 6397
- slave-serve-stale-data no #如果 slave 无法与 master 同步, 设置成 slave 不可读, 方便监控脚本发现问题
- 2.2###APPEND ONLY MODE 设置:
- appendonly yes# 在 slave 上使用了 AOF, 以保证数据可用性
3 用 redis-cli bgsave 命令每天凌晨一次持久化一次 master redis 上的数据, 并 CP 到其它备份服务器上
4 用 redis-cli bgrewriteaof 命令每半小时持久化一次 slave redis 上的数据, 并 CP 到其它备份服务器上
5 写个脚本 , 定期 get master 和 slave 上的 key, 看两个是否同步, 如果没有同步, 及时报警
四主从模式的优缺点
Redis 的 Replication 的特点和优点:
1 同一个 Master 可以同步多个 Slaves
2Slave 同样可以接受其它 Slaves 的连接和同步请求, 这样可以有效的分载 Master 的同步压力因此我们可以将 Redis 的 Replication 架构视为图结构
3Master Server 是以非阻塞的方式为 Slaves 提供服务所以在 Master-Slave 同步期间, 客户端仍然可以提交查询或修改请求
4Slave Server 同样是以非阻塞的方式完成数据同步在同步期间, 如果有客户端提交查询请求, Redis 则返回同步之前的数据
5 为了分载 Master 的读操作压力, Slave 服务器可以为客户端提供只读操作的服务, 写服务仍然必须由 Master 来完成即便如此, 系统的伸缩性还是得到了很大的提高
6Master 可以将数据保存操作交给 Slaves 完成, 从而避免了在 Master 中要有独立的进程来完成此操作
7 支持主从复制, 主机会自动将数据同步到从机, 可以进行读写分离
缺点:
1Redis 不具备自动容错和恢复功能, 主机从机的宕机都会导致前端部分读写请求失败, 需要等待机器重启或者手动切换前端的 IP 才能恢复
2 主机宕机, 宕机前有部分数据未能及时同步到从机, 切换 IP 后还会引入数据不一致的问题, 降低了系统的可用性
3Redis 的主从复制采用全量复制, 复制过程中主机会 fork 出一个子进程对内存做一份快照, 并将子进程的内存快照保存为文件发送给从机, 这一过程需要确保主机有足够多的空余内存若快照文件较大, 对集群的服务能力会产生较大的影响, 而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行, 也就是网络波动都会造成主机和从机间的一次全量的数据复制, 这对实际的系统运营造成了不小的麻烦
4Redis 较难支持在线扩容, 在集群容量达到上限时在线扩容会变得很复杂为避免这一问题, 运维人员在系统上线时必须确保有足够的空间, 这对资源造成了很大的浪费
四结束
今天就写到这里了, 其实 redis 的主从模式很简单, 在实际的生产环境中是很少使用的, 我也不建议在实际的生产环境中使用主从模式来提供系统的高可用性, 之所以不建议使用都是由它的缺点造成的, 在数据量非常大的情况, 或者对系统的高可用性要求很高的情况下, 主从模式也是不稳定的虽然这个模式很简单, 但是这个模式是其他模式的基础, 所以必须深刻的理解, 对其他模式的学习才会有帮助作用
来源: https://www.cnblogs.com/PatrickLiu/p/8426610.html