上面提到的主干思路看起来并不复杂，但实际以人工去操作每一个环节所需要解决的问题往往不止这些，比如对于node的不可用的判定、确认后的选举逻辑、程序客户端的事件通知处理、服务的同步处理细节等。在Redis中比较成熟的 HA方案，目前主要包括依赖独立 node的 Sentinel 和自身基于 Gossip 传播的 Cluster 方案。
从宏观角度来谈， Sentinel 和 Cluster 对于HA的设计均有互相借鉴，但后者 Cluster 更多是偏向提供一套可行性集群分片方案，与这里主题关联性不是很大（后续我会尝试单独写一篇，这里不延伸），围绕 Sentinel 的HA实践更直接。
Sentinel 的本质逻辑就是对所有node作定期巡视，当发现存在共同投票认为不可达的 master node， 会对其做下线标识，同时进行必要的 master选举升级，并将事件状态返回给信号方及客户端。Sentinel 的故障转移是针对 master node的，通常是把 slave node作为master的一个热备。
这里依然以Redis 3.x 为主，在 Redis Sentinel方案里，通常指 n个 Sentinel node来自动监听Redis普通node。准确的说，每个Sentinel node 其实会监听任何一个node，包括其他Sentinel node。
对于选举和审定的控制，可以调整配置 monitor的quorum 来确认严格性，比如， 在大多数场景里，设置为 (n / 2 + 1) 个，这样代表过半的票数认同，即认为指定node当前宕机。同时，当需要选举新的领导者master，这样也至少是趋势性客观判断。是否可以设置更小？当然可以，只是要注意的一个问题是，这样对失败的认定流程更短更快，但是误差也相对越大了，需要看看场景是否适配。个人在权衡时会尽量优先设置为前者。
对于内部故障转移自然可以得到相应的事件通知，一般还可以写入到对应执行脚本，理论上会适合自动化这块，但个人目前尚未应用，这个偏向纯运维了，个人这里依然保持针对架构和开发来做一些讨论。
对于监听通信，可以适度调整 failover-timeout等相关配置，这里并没有相应的计算方式，在大多数情况没太多讲究，但是也需要关注不能过度调整。个人目前采取的方式是，优先设置一个较大值，比如审定时间30秒，五个实例，那么同步转移超时时间则不低于150秒。
对于选举完成后，发起新的数据复制流程，由于master node会面向多个 slave node 进行瞬间同步， 默认并发复制，而很多时候服务器环境有限，没有很足够的配置，甚至经常同一服务器上存在几个理想上本应该独立的服务， 这里则需要重点考虑下网络IO和磁盘IO的问题，根据实际情况临时调整，除此之外，在高峰时这也起到了限流作用。
额外再强调一下，基于主从的HA方案，依然存在 master node同步到 slave node 的延迟问题，这个基本是任何类似热备方案均存在的问题，系统交互越是密集，或者 slave node 的不断增加，都会明显增大这个延迟，所以在权衡的时候，需要考虑业务的初衷，到底能够接受到什么程度。
任何服务里的应用，都不是看起来越多越好。假如你打算手动实现一套自定义的HA方案，或者相关的热备思路，你甚至可以考虑在业务程序里，具体点可以直接是在相关的驱动库（比如JAVA的Jedis、和.Net的 StackExchange.Redis）修改，插入数据的同时，插入到另一个备用库中。这在一些非缓存场景里，也有类似设计，并不是一定不被采用的，毕竟架构设计的初衷一定是考虑整体可行性和利弊权衡。
结语
本篇先写到这里，下一篇会围绕相关主题尝试扩展阐述。
PS：由于个人能力和经验均有限，自己也在持续学习和实践，文中若有不妥之处，恳请指正。
【预留占位：分布式系统之缓存的微观应用经验谈（三）【集群场景篇】https://www.cnblogs.com/bsfz/】