redis哨兵架构

系列文章目录

redis主从架构
redis哨兵架构
redis的集群架构
Redis的单线程和高性能
redis管道操作(节省网络IO开销)
redis的lua脚本
redis分布式锁
redis分布式锁redisson
redis缓存优化
redis的过期淘汰策略
redis连接池参数

文章目录

  • 系列文章目录
    • redis的哨兵高可用架构(中小型公司大部分在使用)
      • 哨兵集群搭建
      • info命令打印信息
      • jedis连接sentinel集群
      • 哨兵leader选举流程

redis的哨兵高可用架构(中小型公司大部分在使用)

redis哨兵架构_第1张图片

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 
# 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节点类似。

你可能感兴趣的:(redis,架构,bootstrap)