本章要点
- Redis主从
- Redis哨兵
- Redis集群
- 主从复制原理
1. Redis 主从
比较简单在redis.conf配置参数：
# 配置文件中增加
slaveof [ip] [port]
# 从服务器是否只读(默认yes) slave-read-only yes
- 从服务器通过psync命令发送服务器已有的同步进度(同步源ID、同步进度offset)，psync具有完整同步和部分同步的两种模式
1）完整同步主要在首次处理主从同步时：主服务器创建并发送RDB文件，以及向从服务器发送保存在缓存区的写命令，来进行数据同步
2）部分同步主要处理在发生断连时的续连的情况：主服务器只会将断连时的写命令发给从服务器，以进行数据同步 - master收到请求，同步源为当前master，则根据偏移量增量同步
- 同步源非当前master，则进入全量同步:master生成rdb，传输到slave，加载到slave内存
2. Redis 哨兵(Sentinel)机制
哨兵是Redis高可用的解决方案。有一个或多个Sentinel实例组成的Sentinel系统可以监控多个主服务器以及主服务器下的从服务器。
哨兵系统的作用就是监控Redis系统的运行状况。它的功能包括以下三个。
（1）监控主服务器和从服务器是否正常运行
（2）主服务器出现故障时自动将该主服务下的某个从服务器转换为主服务器
（3）监控已下线的主服务，并当此服务恢复时，将此设置成新主服务的从服务器
2.1 sentinel启动初始化
执行如下两条命令之一：
redis-sentinel sentinel.conf
或者
redis-server sentinel.conf --sentinel
其中sentinel.conf文件的内容
#运行一个 Sentinel 所需的最少配置如下所示
sentinel monitor mymaster 127.0.0.1 6379 2 #指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000 #指定了 Sentinel 认为服务器已经断线所需的毫秒数
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5 #故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步
1）初始化服务器
2）将普通的Redis服务器使用的代码替换成Sentinal专用代码
3）初始化sentinel状态
4）根据给定的配置文件，初始化sentinel的监控主服务器列表
5）创建连向主服务器的网络链接，包括两个链接命令链接（向master发送命令，并接受回复信息）、订阅链接（订阅master的sentinel:hello频道）
sentinel初始化和Redis不同，因他不需要使用数据库，固不需要加载RDB和AOF文件
2.2 哨兵如何获取redis集群信息
- maser 信息的获取
sentinel默认会以每十秒一次的频率，向master服务器发送info命令，master返回当前服务器信息
1）获取master服务器信息，包括run_id域记录的服务器运行ID以及role域记录的服务器角色
2）获取该master下所有从服务的IP和端口号
sentinel会根据run_id和role域记录的信息，对自己本身记录的master实例结构进行更新。如：master重启后可能run_id跟之前的有所不同，这时候sentinel会对实例结构进行更新；同样返回的从服务器信息，也会更新实例结构的slaves字典，记录所有从服务器名单。 - slave信息的获取
同样当sentinel发现master有新的slaves出现时，sentinel除了为这个slave创建相应的实例结构意外，还会创建从服务的命令链接和订阅链接。/
sentinel默认会以每十秒一次的频率，向从服务器发送info命令，从服务返回当前服务器信息
1） 获取从服务器信息，包括run_id域记录的服务器运行ID以及role域记录的服务器角色
2）该从服务所归属的主服务器列的master_ip跟master_port
3）主从服务器的链接状态master_link_status
4）从服务器的优先级slave_priority 和从服务器的复制偏移量slave_repl_offset
setinel 根据这些信息，更新从服务器的实例结构信息
2.3 哨兵的工作方式：
-
主观下线
默认，Sentinel（哨兵）会以每秒钟一次的频率向所有与它创建了命令连接的实例（包括master主服务器，slave从服务器以及其他Sentinel（哨兵）在内）进程在内发送PING命令，并通过返回ping命令的回复来判定实例是否在线。
如果一个实例（instance）距离最后一次有效回复PING命令的时间超过down-after-milliseconds 选项所指定的值，则这个实例会被Sentinel（哨兵）进程标记为主观下线（SDOWN） -
客观下线
如果一个Master主服务器被标记为主观下线（SDOWN），为了确认这个master主服务器是否真的下线，会向正在监视这个Master主服务器的所有 Sentinel（哨兵）进程进行询问，以每秒一次的频率确认Master主服务器是否进入了主观下线状态；
当sentinel从其他sentinel那里接收到有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）主观下线状态（SDOWN），则Master主服务器会被标记为客观下线（ODOWN），并对主服务器执行故障转移操作 -
选举领头sentinel
当一个master确定为客观下线之后，各个sentinel会协商选举一个领头sentinel，对下线对master进行故障转移，选举规则：
1）所有监控此master服务的sentinel都有选举资格
2）每次进行选举之后，所有sentinel节点的配置纪元（configuration epoch，可以理解为朝代的意思）都会自增1（计数器的作用）
3）在一个配置纪元里，所有的sentinel都有一次将某个sentinel设置成局部领头sentinel，并且一旦设置在这个配置纪元里就不能更改
4）每个发现master下线的sentinel都会要求其他sentinel，将自己设置成局部领头sentinel
5）超过半数以上，才能称为领头sentinel -
故障转移
鼓掌转移就是当master挂掉的时候，选举新master 的，当旧的master恢复正常的时候，将其设置成slaves的过程。
3. Redis集群（ Redis-Cluster）
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
工作方式：
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。
网友评论