如果客户端使用了读写分离，那么读请求可以在从库正常执行，不会受到影响。但是由于此时主库已经挂了，而且哨兵没有选出新的主库，所以在这期间请求会失败，失败的持续时间=哨兵切换
主从的时间+客户端感知到新主库的时间。
如果想要应用程序不感知服务的中断，还需要哨兵或需要做些什么？
客户端只能把写失败的请求先缓存起来或者写入消息队列的中间件中，等哨兵切换完主从后，再把这些写请求发给新的主库，但是这种场景只适合对写入请求返回值不敏感的业务，而且还需要业务层做适配，另外主从切换时间过长，也会导致客户端或消息队列中间件缓存写请求过多，切换完成之后重放这些请求的时间变长。
另外哨兵检测主库多久没有响应就提升从库为新的主库，这个时间是可以配置的(down-after-milliseconds参数)配置的越短，哨兵也就越敏感，
哨兵集群认为主库在短时间内连不上就会发起主从切换，这种配置很可能因为网路拥塞但主库正常而发生没有必要的切换，当然，当主库真正故障时，
因为切换得及时，对业务的影响最小，相反，哨兵越保守，虽然可以减少哨兵误判概率，但是主库故障发生时，业务写失败的时间会比较久，缓存
写请求数据量越多。