Redis（二十六）：Sentinel——Redis的哨兵模式原理（二）

最新推荐文章于 2025-04-02 14:30:00 发布

原创最新推荐文章于 2025-04-02 14:30:00 发布 · 212 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis

Redis 专栏收录该内容

40 篇文章

订阅专栏

本文详细介绍了Redis Sentinel机制的工作原理，包括如何通过INFO命令获取主从服务器信息，并更新其内部结构。

- 获取主服务器信息
- 获取从服务器信息

上一篇提到了Sentinel的初始化执行的步骤，最后一步为与主服务器建立了两条连接，一条为命令连接，另一条为订阅连接，下面我们就说一下这两条连接的功能，Sentinel怎样与主从服务器进行交流，Sentinel怎样与其他Sentinel进行交流

获取主服务器信息

Sentinel与主服务器建立了命令连接，而为了获取主服务器的信息，还要保持数据是最新的，Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并且通过分析INFO命令的回复来获取主服务器的当前信息（INFO命令可以获取当前服务器的状态，一个哨兵只可以看一个主服务器）
在这里插入图片描述
INFO命令主要有下面这些

服务器状态
客户端状态
内存
持久化信息
网络连接
主从复制
CPU
集群
键空间

# Server（服务器状态）
redis_version:5.0.3
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:1d2d4f865a9683e0
redis_mode:standalone
os:Linux 3.10.0-1160.11.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:15289
run_id:e6f6d7d669687494a5f884c215edf0ab7e2dcb37
tcp_port:6379
uptime_in_seconds:2761007
uptime_in_days:31
hz:10
configured_hz:10
lru_clock:9949349
executable:/usr/local/redis/bin/./redis-server
config_file:/usr/local/redis/bin/redis.conf

# Clients（客户端状态）
connected_clients:6
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# Memory（内存）
used_memory:2070808
used_memory_human:1.97M
used_memory_rss:3977216
used_memory_rss_human:3.79M
used_memory_peak:2111768
used_memory_peak_human:2.01M
used_memory_peak_perc:98.06%
used_memory_overhead:2023990
used_memory_startup:790992
used_memory_dataset:46818
used_memory_dataset_perc:3.66%
allocator_allocated:2111384
allocator_active:2404352
allocator_resident:4792320
total_system_memory:1818816512
total_system_memory_human:1.69G
used_memory_lua:40960
used_memory_lua_human:40.00K
used_memory_scripts:160
used_memory_scripts_human:160B
number_of_cached_scripts:1
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.14
allocator_frag_bytes:292968
allocator_rss_ratio:1.99
allocator_rss_bytes:2387968
rss_overhead_ratio:0.83
rss_overhead_bytes:-815104
mem_fragmentation_ratio:1.92
mem_fragmentation_bytes:1907704
mem_not_counted_for_evict:0
mem_replication_backlog:1048576
mem_clients_slaves:16922
mem_clients_normal:167076
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:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1620546361
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:421888
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:7802
total_commands_processed:1411392
instantaneous_ops_per_sec:3
total_net_input_bytes:64898161
total_net_output_bytes:188209599
instantaneous_input_kbps:0.16
instantaneous_output_kbps:0.27
rejected_connections:0
sync_full:3
sync_partial_ok:0
sync_partial_err:3
expired_keys:2
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:48
keyspace_misses:11
pubsub_channels:1
pubsub_patterns:0
latest_fork_usec:297
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:1
slave0:ip=47.119.112.252,port=8001,state=online,offset=24157802,lag=1
master_replid:176fc18fdbcafe215f5d873b34aeb00970550820
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:24157802
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:23109227
repl_backlog_histlen:1048576

# CPU（硬件CPU的）
used_cpu_sys:1423.376155
used_cpu_user:1888.797539
used_cpu_sys_children:0.058237
used_cpu_user_children:0.043167

# Cluster（集群）
cluster_enabled:0

# Keyspace（键空间，有5个键值对）
db0:keys=5,expires=0,avg_ttl=0

Sentinel通过分析主服务器返回的INFO命令回复，Sentinel可以获取以下两方面的信息

获取主服务器状态，比如run_id、role
另一方面可以看获得服务器的复制信息，从那里可以获取所有从服务器的信息，这样Sentinel就可以根据这些信息去找到从服务器

获取了主服务器信息之后，Sentinel会对自己的master属性里面的主服务器实例结构（SentinelRedisInstance）进行修改（上一篇提到过，Sentinel会维持自己的一个SentinelState状态，里面的master属性是会记录主服务器、其余哨兵或者从服务器的实例结构的），例如主服务器重启（不超过30S重启完成，不会认定为主观下线），runid是会发生变化的，Sentinel会根据INFO返回的信息进行变换。

而至于主服务器返回的从服务器信息，则会被用于更新主服务器实例结构（SentinelRedisInstance）的slaves字典，该字典记录了主服务器属下从服务器的名单

对于该从服务器字典

从服务器字典的键是Sentinel自动设置的从服务器名字，格式为ip:port（从哨兵服务器的日志可以看到）
从服务器字典的值则是从服务器的实例结构

Sentinel在分析INFO返回的信息时，对于从服务器的信息，会去检查该从服务器是否存在于Sentinel的master属性里面的主服务器里面的slave字典。

那么就会发生两种情况，第一种是从服务器实例结构已经存在，第二种是从服务器实例结构不存在

从服务器实例结构已经存在，那么Sentinel对从服务器的状态进行更新
从服务器实例结构不存在，这就说明这个从服务器是新发现的，Sentinel会在slaves字典中新增这个的从服务器的实例结构。

注意：这里也标注了主服务器实例结构和从服务器实力结构之间的区别
主服务器实例结构的flags属性的值为SRI_MASTER，而从服务器实例结构的flags属性的值为SRI_SLAVE
主服务器实例结构的name属性是配置文件里面的主服务器名字，而从服务器实例结构的name属性则是根据主服务器返回的Info信息，ip地址和端口号生成的。
或许这里会觉得奇怪，那怎么判定从服务器挂了？其实判断主从服务器是否挂了，是在后面的主从服务器与哨兵进行互相通信时实现的

获取从服务器信息

当Sentinel连接上了主服务器之后，获取了INFO信息后，也会去监视从服务器，也就是说，Sentinel除了会为该从服务器建立对应的SentinelRedisInstance对象之外，Sentinel还需要去连接从服务器，也就是说，Sentinel也会像对待主服务器一样，与从服务器也会建立命令连接和订阅连接
在这里插入图片描述
创建完连接之后，也是会以每十秒一次的频率通过命令连接向从服务器发送INFO命令，去进行提取信息

slave的info信息跟主服务器是差不多的（因为其实都是一台服务器）

主要的不同其实就是主从复制这块信息不太一样

# Replication
role:slave //主服务器会为master
master_host:47.119.112.252
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:24880164
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:176fc18fdbcafe215f5d873b34aeb00970550820
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:24880164
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:23831589
repl_backlog_histlen:1048576

根据INFO命令的回复，Sentinel会提取出以下的信息