redis的哨兵高可用架构(中小型公司大部分在使用)
sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端（这里面的redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。）
哨兵集群搭建
1. 复制一份sentinel.conf 文件，该文件在redis目录下 cp sentinel.conf sentinel-26369.conf 2.将相关配置改成如下值 port 26379 daemonize yes pidfile "/var/run/redis-sentinel-26379.pid" logfile "26379.log" dir /data/redis/ # sentinel monitor <master-name><ip><redis-port><quorum> # quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为:sentinel总数/2+1)，master才算真正失效 sentinel monitor mymaster 192.168.0.60 6379 2 3.启动sentinel哨兵实例 src/sentinel-server sentinel-26379.conf 4.查看sentinel的info信息 src/redis-cli -p 26379 连接上后执行 info 命令,可以看到sentinel的info里面已经识别出了redis的主从 5. 可以再配置两个sentinel，端口26380，26381，注意上述配置文件里的对应数字也要更改，注意26380监听6379,26381监听6379
info命令打印信息
# Server redis_version:4.0.6 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:3dae75092337245f redis_mode:sentinel os:Linux 3.10.0-1160.66.1.el7.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:4908 run_id:82761f887d79fe7fe988f9b0f9ff02c67105083f tcp_port:26381 uptime_in_seconds:13 uptime_in_days:0 hz:10 lru_clock:10527275 executable:/usr/local/redis/master-slave/redis/redis-4.0.6/src/redis-sentinel config_file:/usr/local/redis/master-slave/sentinel/sentinel-26381.conf # Clients connected_clients:3 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 # CPU used_cpu_sys:0.01 used_cpu_user:0.01 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 # Stats total_connections_received:3 total_commands_processed:35 instantaneous_ops_per_sec:4 total_net_input_bytes:1797 total_net_output_bytes:243 instantaneous_input_kbps:0.31 instantaneous_output_kbps:0.05 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0 # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
jedis连接sentinel集群
public static void main(String[] args) { JedisPoolConfig jedisPoolConfig = new JedisPoolConfig(); jedisPoolConfig.setMaxIdle(10); jedisPoolConfig.setMaxTotal(20); jedisPoolConfig.setMinIdle(5); String masterName = "mymaster"; Set<String> sentinels = new HashSet<>(); sentinels.add(new HostAndPort("192.168.56.102",26379).toString()); sentinels.add(new HostAndPort("192.168.56.102",26380).toString()); sentinels.add(new HostAndPort("192.168.56.102",26381).toString()); JedisSentinelPool jedisSentinelPool = new JedisSentinelPool(masterName,sentinels,jedisPoolConfig,3000,null); Jedis jedis = jedisSentinelPool.getResource(); System.out.println(jedis.set("sentinel66666","1")); System.out.println(jedis.get("sentinel66666")); }
关于DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface.报错
这是由于没有设置密码，或者没有关闭保护模式.
关闭哨兵的保护模式
关闭哨兵的保护模式 protected-mode no 设置密码 requirepass 123456
哨兵leader选举流程
当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作，每个发现master服务器进入下线状态的sentinel都可以要求其他sentinel选自己为sentinel的leader，选举是先到先得。同时每个sentinel再次选举都会自增配置纪元（选举周期），每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader，之后该sentinel进行故障转移操作，从存活的slave中选举出新的leader，这个选举过程跟集群的master选举很类似。哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举leader。如果master挂了，那唯一的哨兵节点就是哨兵leader了，可以正常选举新的master。不过为了高可用一般都推荐至少三个哨兵节点。为什么推荐奇数个哨兵节点跟集群奇数个master节点类似。
