节点运维
节点上线和下线的对象
- 主节点
- 从节点
- Sentinel节点
节点下线原因
- 机器下线：节点所在的机器出现了不稳定或者即将过保被回收。
- 机器性能不足：节点所在的机器性能比较差或者内存比较小，无法支撑应用方的需求。例如CPU、内存、硬盘、网络等。
- 节点自身故障：节点自身出现服务不正常情况。例如机器或系统导致。
主节点下线
如果需要对主节点进行下线，比较合理的做法是选出一个“合适”（例如 性能更高的机器）的从节点，使用sentinel failover功能将从节点晋升主节点，只需要在任意可用的Sentinel节点执行如下操作即可。
sentinel failover <masterName>
注意：Redis Sentinel存在多个从节点时，如果想将指定从节点晋升为主节点， 可以将其他从节点的slave-priority配置为0，但是需要注意failover后，将 slave-priority调回原值。
从节点和 Sentinel 节点下线
- 从节点、 Sentinel 节点：临时下线还是永久下线，例如是否做一些清理工作；但是要考虑读写分离的情况。
注意：Sentinel 节点依然会对下线节点进行定期监控，这是由Redis Sentinel的设计思路所决定。下面日志显示（需要设置loglevel=debug），6379节点下线后，Sentinel节点还是会定期对其监控，会造成一定的网络资源浪费。
-cmd-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
#Connection refused
-pubsub-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
#Connection refused
...
节点上线
- 主节点：sentinel failover进行替换。
- 从节点：slaveof即可，sentinel节点可以感知。
- 使用场景：
- 使用了读写分离，但现有的从节点无法支撑应用方的流量。
- 主节点没有可用的从节点，无法支持故障转移。
- 添加一个更强悍的从节点利用手动 failover 替换主节点。
- Sentinel：添加sentinel monitor主节点的配置，使用redis-sentinel启动即可，它将被其余Sentinel节点自动发现。
- 使用场景：
- 当前Sentinel节点数量不够，无法达到Redis Sentinel健壮性要求或者无法达到票数。
- 原Sentinel节点所在机器需要下线。
高可用读写分离
从节点的作用
- 副本：当主节点出现故障时，作为主节 点的后备“顶”上来实现故障转移，Redis Sentinel已经实现了该功能的自动化，实现了真正的高可用。
- 扩展：扩展主节点的读能力，尤其是在读多写少 的场景非常适用。
通常的模型：
从节点不是高可用的，如果slave-1节点出现故障，首先客户端client-1将与其失联，其次Sentinel节点只会对该节点做主观下线，因为Redis Sentinel的故障转移是针对主节点的。所以很多时候，Redis Sentinel中的从节点仅仅是作为主节点一个热备，不让它参与客户端的读操作，就是为了保证整体高可用性，但实际上这种使用方法还是有一些浪费，尤其是在有很多从节点或者确实需要读写分离的场景，所以如何实现从节点的高可用是非常有必要的。
Redis Sentinel读写分离设计思路
Redis Sentinel在对各个节点的监控中，如果有对应事件的发生，都会发出相应的事件消息（Sentinel节点发布订阅频道），其中和从节点变动的事件有以下几个：
- +switch-master：切换主节点（原来的从节点晋升为主节点），说明减少了某个从节点。
- +convert-to-slave：切换从节点（原来的主节点降级为从节点），说明添加了某个从节点。
- +sdown：主观下线，说明可能某个从节点可能不可用（因为对从节点不会做客观下线），所以在实现客户端时可以采用自身策略来实现类似主观下线的功能。
- +reboot：重新启动了某个节点，如果它的角色是slave，那么说明添加了某个从节点。
所以在设计Redis Sentinel的从节点高可用时，只要能够实时掌握所有从 节点的状态，把所有从节点看做一个资源池（如下图所示），无论是上线还是下线从节点，客户端都能及时感知到（将其从资源池中添加或者删除），这样从节点的高可用目标就达到了。
