哨兵(sentinel)是Redis的高可用性(High Availability)的解决方案: 由一个或多个sentinel实例组成sentinel集群,可以监视一个或多个主服务器和多个从服务器。当主服务器进入下线状态时,sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务,从而保证redis的高可用性。
本次示例在一台机器上采用伪分布式的方式部署
参考地址:https://blog.csdn.net/rzpy_qifengxiaoyue/article/details/107585283
Redis-Master :127.0.0.1 6380
#进入redis安装目录 [root@rpp ~]# cd /usr/local/redis make install PREFIX=/usr/local/redis-ms/redis-master cp /usr/local/redis/redis.conf /usr/local/redis-ms/redis-master #修改redis.conf port 6380 # 将`daemonize`由`no`改为`yes` daemonize yes # 默认绑定的是回环地址,默认不能被其他机器访问 # bind 127.0.0.1 # 是否开启保护模式,由yes该为no protected-mode noRedis-Slaver1:127.0.0.1 6381
cp -r /usr/local/redis-ms/redis-master/* /usr/local/redis-ms/redis-slaver1 #修改配置文件 vim /usr/local/redis-ms/redis-slaver1/redis.conf port 6381 replicaof 127.0.0.1 6380Redis-Slaver2:127.0.0.1 6382
cp -r /usr/local/redis-ms/redis-master/* /usr/local/redis-ms/redis-slaver2 #修改配置文件 vim /usr/local/redis-ms/redis-slaver2/redis.conf port 6382 replicaof 127.0.0.1 6380Redis-Sentinel1:127.0.0.1 26379
cp -r /usr/local/redis-ms/redis-master/* /usr/local/redis-ms/redis-sentinel1 #拷贝sentinel.conf 配置文件并修改 cp /usr/local/redis/sentinel.conf /usr/local/redis-ms/redis-sentinel1 # 哨兵sentinel实例运行的端口 默认26379 port 26379 # 将`daemonize`由`no`改为`yes` daemonize yes # 哨兵sentinel监控的redis主节点的 ip port # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。 # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2 # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提 供密码 # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒,改成3秒 # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 3000 # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步, 这个数字越小,完成failover所需的时间就越长, 但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 # sentinel parallel-syncs <master-name> <numslaves> sentinel parallel-syncs mymaster 1 # 故障转移的超时时间 failover-timeout 可以用在以下这些方面: #1. 同一个sentinel对同一个master两次failover之间的间隔时间。 #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master 那里同步数据时。 #3.当想要取消一个正在进行的failover所需要的时间。 #4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时, slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了 # 默认三分钟 # sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000Redis-Sentinel2:127.0.0.1 26380
cp -r /usr/local/redis-ms/redis-sentinel1/* /usr/local/redis-ms/redis-sentinel2 #修改sentinel.conf vim /usr/local/redis-ms/redis-sentinel2/sentinel.conf port 26380Redis-Sentinel3:127.0.0.1 26381
cp -r /usr/local/redis-ms/redis-sentinel1/* /usr/local/redis-ms/redis-sentinel3 #修改sentinel.conf vim /usr/local/redis-ms/redis-sentinel3/sentinel.conf port 26381redis-master、redis-slaver1、redis-slaver2、redis-sentinel1、redis-sentinel2、redis-sentinel3
#启动redis-master和redis-slaver 在redis-master目录下 ./bin/redis-server redis.conf 在redis-slaver1目录下 ./bin/redis-server redis.conf 在redis-slaver2目录下 ./bin/redis-server redis.conf #启动redis-sentinel 在redis-sentinel1目录下 ./bin/redis-sentinel sentinel.conf 在redis-sentinel2目录下 ./bin/redis-sentinel sentinel.conf 在redis-sentinel3目录下./bin/redis-sentinel sentinel.conf查看启动状态
[root@rpp redis-sentinel3]# ps -ef |grep redis root 29529 1 0 23:39 ? 00:00:00 ./bin/redis-server 0.0.0.0:6380 root 29559 1 0 23:39 ? 00:00:00 ./bin/redis-server 0.0.0.0:6381 root 29575 1 0 23:39 ? 00:00:00 ./bin/redis-server 0.0.0.0:6382 root 29644 1 0 23:40 ? 00:00:00 ./bin/redis-sentinel *:26379 [sentinel] root 29674 1 0 23:40 ? 00:00:00 ./bin/redis-sentinel *:26380 [sentinel] root 29720 1 0 23:40 ? 00:00:00 ./bin/redis-sentinel *:26381 [sentinel] root 29743 26484 0 23:41 pts/3 00:00:00 grep --color=auto redis在主节点客户端执行info命令查看集群信息,如下
127.0.0.1:6380> info # Server redis_version:5.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:d828c6186d2762b0 redis_mode:standalone os:Linux 3.10.0-957.21.3.el7.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:29529 run_id:9be5ec63623c7f5a106c8a3e93fc20c52d43eaab tcp_port:6380 uptime_in_seconds:777 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:9460014 executable:/usr/local/redis-ms/redis-master/./bin/redis-server config_file:/usr/local/redis-ms/redis-master/redis.conf # Clients connected_clients:7 client_recent_max_input_buffer:2 client_recent_max_output_buffer:0 blocked_clients:0 # Memory used_memory:2113576 used_memory_human:2.02M used_memory_rss:2994176 used_memory_rss_human:2.86M used_memory_peak:2194216 used_memory_peak_human:2.09M used_memory_peak_perc:96.32% used_memory_overhead:2059522 used_memory_startup:792504 used_memory_dataset:54054 used_memory_dataset_perc:4.09% allocator_allocated:2133856 allocator_active:2441216 allocator_resident:7122944 total_system_memory:3777241088 total_system_memory_human:3.52G used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.14 allocator_frag_bytes:307360 allocator_rss_ratio:2.92 allocator_rss_bytes:4681728 rss_overhead_ratio:0.42 rss_overhead_bytes:-4128768 mem_fragmentation_ratio:1.45 mem_fragmentation_bytes:922848 mem_not_counted_for_evict:0 mem_replication_backlog:1048576 mem_clients_slaves:33844 mem_clients_normal:183998 mem_aof_buffer:0 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0 # Persistence loading:0 rdb_changes_since_last_save:1 rdb_bgsave_in_progress:0 rdb_last_save_time:1603294781 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:1 rdb_current_bgsave_time_sec:-1 rdb_last_cow_size:417792 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok aof_last_cow_size:0 # Stats total_connections_received:9 total_commands_processed:4746 instantaneous_ops_per_sec:7 total_net_input_bytes:224073 total_net_output_bytes:1439214 instantaneous_input_kbps:0.37 instantaneous_output_kbps:3.37 rejected_connections:0 sync_full:1 sync_partial_ok:1 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 evicted_keys:0 keyspace_hits:2 keyspace_misses:1 pubsub_channels:1 pubsub_patterns:0 latest_fork_usec:156 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 # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6381,state=online,offset=136498,lag=1 slave1:ip=127.0.0.1,port=6382,state=online,offset=136498,lag=1 master_replid:8dc1f397d723387b6328ba37c6abded94370d635 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:136498 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:136498 # CPU used_cpu_sys:0.260864 used_cpu_user:0.315793 used_cpu_sys_children:0.001172 used_cpu_user_children:0.000000 # Cluster cluster_enabled:0 # Keyspace db0:keys=11,expires=0,avg_ttl=0 127.0.0.1:6380> 127.0.0.1:26379> info # Server redis_version:5.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:d828c6186d2762b0 redis_mode:sentinel os:Linux 3.10.0-957.21.3.el7.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:29644 run_id:f23e1f9b157ef080bf8855d9deefb4a1b070bfa8 tcp_port:26379 uptime_in_seconds:1318 uptime_in_days:0 hz:11 configured_hz:10 lru_clock:9460618 executable:/usr/local/redis-ms/redis-sentinel1/./bin/redis-sentinel config_file:/usr/local/redis-ms/redis-sentinel1/sentinel.conf # Clients connected_clients:3 client_recent_max_input_buffer:2 client_recent_max_output_buffer:0 blocked_clients:0 # CPU used_cpu_sys:0.555261 used_cpu_user:0.682642 used_cpu_sys_children:0.000000 used_cpu_user_children:0.000000 # Stats total_connections_received:3 total_commands_processed:3741 instantaneous_ops_per_sec:2 total_net_input_bytes:202550 total_net_output_bytes:22460 instantaneous_input_kbps:0.11 instantaneous_output_kbps:0.01 rejected_connections:0 sync_full:0 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count: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:6380,slaves=2,sentinels=3主从依次查询key ,master 6380 slaver1 6381
127.0.0.1:6380> get name1 (nil) 127.0.0.1:6381> get name1 (nil)主服务器写入数据,从服务器查看
127.0.0.1:6380> set name1 a OK 127.0.0.1:6380> get name1 "a" 127.0.0.1:6381> get name1 "a"测试结果 主从复制成功
把主服务master关闭
[root@rpp redis]# ps -ef|grep redis root 29529 1 0 Oct21 ? 00:00:01 ./bin/redis-server 0.0.0.0:6380 root 29559 1 0 Oct21 ? 00:00:00 ./bin/redis-server 0.0.0.0:6381 root 29575 1 0 Oct21 ? 00:00:00 ./bin/redis-server 0.0.0.0:6382 root 29644 1 0 Oct21 ? 00:00:01 ./bin/redis-sentinel *:26379 [sentinel] root 29674 1 0 Oct21 ? 00:00:01 ./bin/redis-sentinel *:26380 [sentinel] root 29720 1 0 Oct21 ? 00:00:01 ./bin/redis-sentinel *:26381 [sentinel] root 30213 25644 0 Oct21 pts/1 00:00:00 ./redis-cli -p 6380 root 31892 26484 0 00:03 pts/3 00:00:00 ./redis-cli -p 26380 root 31968 31535 0 00:04 pts/4 00:00:00 grep --color=auto redis [root@rpp redis]# kill -9 29529 [root@rpp redis]# ps -ef|grep redis root 29559 1 0 Oct21 ? 00:00:00 ./bin/redis-server 0.0.0.0:6381 root 29575 1 0 Oct21 ? 00:00:00 ./bin/redis-server 0.0.0.0:6382 root 29644 1 0 Oct21 ? 00:00:01 ./bin/redis-sentinel *:26379 [sentinel] root 29674 1 0 Oct21 ? 00:00:01 ./bin/redis-sentinel *:26380 [sentinel] root 29720 1 0 Oct21 ? 00:00:01 ./bin/redis-sentinel *:26381 [sentinel] root 30213 25644 0 Oct21 pts/1 00:00:00 ./redis-cli -p 6380 root 31892 26484 0 00:03 pts/3 00:00:00 ./redis-cli -p 26380 root 32059 31535 0 00:05 pts/4 00:00:00 grep --color=auto redis登录客户端6381查看信息
127.0.0.1:6381> info # Replication role:slave master_host:127.0.0.1 master_port:6382 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_repl_offset:303828 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:5234efe2b80aa660993474dc26d7505b4689d458 master_replid2:8dc1f397d723387b6328ba37c6abded94370d635 master_repl_offset:303828 second_repl_offset:290940 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:303828 # CPU used_cpu_sys:0.467161 used_cpu_user:0.559959 used_cpu_sys_children:0.001200 used_cpu_user_children:0.000000 # Cluster cluster_enabled:0 # Keyspace db0:keys=11,expires=0,avg_ttl=0 127.0.0.1:6381>从 master_host:127.0.0.1 master_port:6382 可以看出主服务自动切换到6382
Sentinel是一个特殊的Redis服务器,不会进行持久化,Sentinel实例启动后每个Sentinel会创建2个连向主服务器的网络连接
命令连接:用于向主服务器发送命令,并接收响应;订阅连接:用于订阅主服务器的—sentinel—:hello频道。Sentinel默认每10s一次,向被监控的主服务器发送info命令,获取主服务器和其下属从服务器的信息。
当Sentinel发现主服务器有新的从服务器出现时,Sentinel还会向从服务器建立命令连接和订阅连接。 在命令连接建立之后,Sentinel还是默认10s一次,向从服务器发送info命令,并记录从服务器的信息。
默认情况下,Sentinel每2s一次,向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息,消息中会携带Sentinel自身的信息和主服务器的信息。
PUBLISH _sentinel_:hello "< s_ip > < s_port >< s_runid >< s_epoch > < m_name > <m_ip >< m_port ><m_epoch>"当Sentinel与主服务器或者从服务器建立起订阅连接之后,Sentinel就会通过订阅连接,向服务器发送以下命令:
subscribe —sentinel—:helloSentinel彼此之间只创建命令连接,而不创建订阅连接,因为Sentinel通过订阅主服务器或从服务器,因为订阅的是同一个频道,一个Sentinel发送消息后,其他的Sentinel就可以接受到消息,这样就可以感知到新的Sentinel的加入,而一旦新Sentinel加入后,相互感知的Sentinel通过命令连接来通信就可以了。
Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命 令 实例在down-after-milliseconds毫秒内返回无效回复(除了+PONG、-LOADING、-MASTERDOWN外) 实例在down-after-milliseconds毫秒内无回复(超时) Sentinel就会认为该实例主观下线(SDown)
当一个Sentinel将一个主服务器判断为主观下线后,Sentinel会向同时监控这个主服务器的所有其他Sentinel发送查询命令,如下
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>其他Sentinel回复
<down_state>< leader_runid >< leader_epoch >Sentinel通过判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线,则该主服务器就会被判定为客观下线(ODown)。
当一个主服务器被判定为客观下线后,监视这个主服务器的所有Sentinel会通过选举算法(raft),选出一个Leader Sentinel去执行failover(故障转移)操作。
RaftRaft协议是用来解决分布式系统一致性问题的协议。 Raft协议描述的节点共有三种状态:Leader, Follower, Candidate。 term:Raft协议将时间切分为一个个的Term(任期),可以认为是一种“逻辑时间”。
选举流程:
Raft采用心跳机制触发Leader选举 ,系统启动后,全部节点初始化为Follower,term为0。 节点如果收到了RequestVote或者AppendEntries,就会保持自己的Follower身份,节点如果一段时间内没收到AppendEntries消息,在该节点的超时时间内还没发现Leader,Follower就会转换成Candidate,自己开始竞选Leader。 一旦转化为Candidate,该节点立即开始下面几件事情:
增加自己的term。启动一个新的定时器。给自己投一票。向所有其他节点发送RequestVote,并等待其他节点的回复。如果在计时器超时前,节点收到多数节点的同意投票,就转换成Leader。同时向所有其他节点发送 AppendEntries,告知自己成为了Leader。
每个节点在一个term内只能投一票,采取先到先得的策略,Candidate前面说到已经投给了自己, Follower会投给第一个收到RequestVote的节点。
Raft协议的定时器采取随机超时时间,这是选举Leader的关键。 在同一个term内,先转为Candidate的节点会先发起投票,从而获得多数票。
Sentinel的leader选举流程 某Sentinel认定master客观下线后,该Sentinel会先看看自己有没有投过票,如果自己已经投过票给其他Sentinel了,在一定时间内自己就不会成为Leader。如果该Sentinel还没投过票,那么它就成为Candidate。Sentinel需要完成几件事情: 更新故障转移状态为start当前epoch加1,相当于进入一个新term,在Sentinel中epoch就是Raft协议中的term。向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch。给自己投一票(leader、leader_epoch) 当其它哨兵收到此命令时,可以同意或者拒绝它成为领导者;(通过判断epoch)Candidate会不断的统计自己的票数,直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum,这时它就成为了Leader。其他Sentinel等待Leader从slave选出master后,检测到新的master正常工作后,就会去掉客观下线的标识。当选举出Leader Sentinel后,Leader Sentinel会对下线的主服务器执行故障转移操作,主要有三个步 骤:
它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复 制新的 Master ;当客户端试图连接失效的 Master 时,集群也会向客户端返回新 Master 的地址,使得集群可以使 用现在的 Master 替换失效 Master 。Master 和 Slave 服务器切换后, Master 的 redis.conf 、 Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变,即, Master 主服务器的 redis.conf 配置文件中会多一行 replicaof 的配置, sentinel.conf 的监控目标会随之调换。 如何选择新的主服务器哨兵leader根据以下规则从客观下线的主服务器的从服务器中选择出新的主服务器。
过滤掉主观下线的节点选择slave-priority最高的节点,如果有则返回没有就继续选择选择出复制偏移量最大的系节点,因为复制偏移量越大则数据复制的越完整,如果有就返回了,没有就继续选择run_id最小的节点,因为run_id越小说明重启次数越少