redis 主从复制，哨兵，和集群架构实践
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了redis 主从复制，哨兵，和集群架构实践，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5392字，纯文字阅读大概需要8分钟。
内容图文
Redis 单线程和提高性能：
一、redis单点（主从）
基本上就是一主一从，我们应用层主要使用的是主节点，从节点的主要工作是从主节点做主从复制。关键时刻，如果主服务器挂掉，可以手动启动从服务器，然后更改应用层的redis的ip即可。
二。scan命令
这个游标的方法，match 方法，
scan 0 match count 1000
常见的应用场景下我觉得redis没必要进行读写分离。
先来讨论一下为什么要读写分离：
读写分离使用于大量读请求的情况，通过多个slave分摊了读的压力，从而增加了读的性能。
过多的select会阻塞住数据库，使你增删改不能执行，而且到并发量过大时，数据库会拒绝服务。
因而通过读写分离，从而增加性能，避免拒绝服务的发生。
我认为需要读写分离的应用场景是：写请求在可接受范围内，但读请求要远大于写请求的场景。
再来讨论一下redis常见的应用场景：
-
1.缓存
-
2. 排名型的应用，访问计数型应用
-
3. 实时消息系统
读写分离：
对于读占比较高的场景，可以通过把一部分流量分摊导出从节点(salve) 来减轻主节点（master）压力，同时需要主要只对主节点执行写操作，如下图：
当使用从节点响应读请求时，业务端可能会遇到以下问题：
复制数据：
1.数据延迟
Redis 复制数的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点，实现逻辑如下图：
说明如下：
1） 监控程序(monitor) 定期检查主从节点的偏移量，主节点偏移量在info replication 的master_repl_offset 指标记录，从节点 偏移量可以查询主节点的slave0 字段的offset指标，它们的差值就是主从节点延迟的字节 量。
2）当延迟字节量过高时，比如超过10M。监控程序触发报警并通知客户端从节点延迟过高。可以采用Zookeeper的监听回调机制实现客户端通知。
3） 客户端接到具体的从节点高延迟通知后，修改读命令路由到其他从节点或主节点上。当延迟回复后，再次通知客户端，回复从节点的读命令请求。
这种方案成本较高，需要单独修改适配Redis的客户端类库。
1.数据延迟
Redis 复制数的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点，实现逻辑如下图：
说明如下：
1） 监控程序(monitor) 定期检查主从节点的偏移量，主节点偏移量在info replication 的master_repl_offset 指标记录，从节点 偏移量可以查询主节点的slave0 字段的offset指标，它们的差值就是主从节点延迟的字节 量。
2）当延迟字节量过高时，比如超过10M。监控程序触发报警并通知客户端从节点延迟过高。可以采用Zookeeper的监听回调机制实现客户端通知。
3） 客户端接到具体的从节点高延迟通知后，修改读命令路由到其他从节点或主节点上。当延迟回复后，再次通知客户端，回复从节点的读命令请求。
这种方案成本较高，需要单独修改适配Redis的客户端类库。
2.读到过期数据
当主节点存储大量设置超时的数据时，如缓存数据，Redis内部需要维护过期数据删除策略，删除策略主要有两种：惰性删除和定时删除。
惰性删除：主节点每次处理读取命令时，都会检查键是否超时，如果超时则执行del命令删除键对象那个，之后del命令也会异步 发送给 从节点
需要注意的是为了保证复制的一致性，从节点自身永远不会主动删除超时数据，如上图。
定时删除：
Redis主节点在内部定时任务会循环采样一定数量的键，当发现采样的键过期就执行del命令，之后再同步给从节点，如下图
如果此时 数据的大量超时，主节点采样速度跟不上过期速度且主节点没有读取过期键的操作，那么从节点将无法收到del命令，这时在从节点 上可以读取到已经超时的数据。Redis在3.2 版本解决了这个问题，从节点 读取数据之前会检查键的过期时间来决定是否返回数据，可以升级到3.2版本来规避这个问题。
3.从节点故障问题
对于从节点故障问题，需要在客户端维护可用从节点列表，当从节点故障时立刻切换到其他从节点或主节点上。
但是建议如果仅仅是为性能考虑的话最好使用集群。
运维操作：
准备三个redis服务，依次命名文件夹子master,slave1,slave2.这里为在测试机上，不干扰原来的redis服务，我们master使用6000端口。
配置文件（redis.conf）
master配置修改端口：
-
port 6000 -
requirepass 123456
三。一主多从的哨兵模式
三、一主多从的哨兵模式
工作原理:
1.用户链接时先通过哨兵获取主机Master的信息
2.获取Master的链接后实现redis的操作(set/get)
3.当master出现宕机时,哨兵的心跳检测发现主机长时间没有响应.这时哨兵会进行推选.推选出新的主机完成任务.
4.当新的主机出现时,其余的全部机器都充当该主机的从机
这就有一个问题，就是添加哨兵以后，所有的请求都会经过哨兵询问当前的主服务器是谁，所以如果哨兵部在主服务器上面的话可能会增加服务器的压力，所以最好是将哨兵单独放在一个服务器上面。以分解压力。然后可能还有人担心哨兵服务器宕机了怎么办啊，首先哨兵服务器宕机的可能性很小，然后是如果哨兵服务器宕机了，使用人工干预重启即可，就会导致主从服务器监控的暂时不可用，不影响主从服务器的正常运行。
四、集群模式
一、概述
Redis3.0版本之后支持Cluster.
1.1、redis cluster的现状
1):节点自动发现
2):slave->master 选举,集群容错
3):Hot resharding:在线分片
4):进群管理:cluster xxx
5):基于配置(nodes-port.conf)的集群管理
6):ASK 转向/MOVED 转向机制.
1.2、redis cluster 架构
(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.
(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value
2) redis-cluster选举:容错
参考博文：
(1)领着选举过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉.
(2):什么时候整个集群不可用(cluster_state:fail),当集群不可用时,所有对集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)错误。
缓存同步：
参考博文：https://blog.csdn.net/u012045045/article/details/86623691
thoughtCodes 发布了456 篇原创文章 · 获赞 10 · 访问量 8万+ 他的留言板 关注
内容总结
以上是互联网集市为您收集整理的redis 主从复制，哨兵，和集群架构实践全部内容，希望文章能够帮你解决redis 主从复制，哨兵，和集群架构实践所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。