Redis6总纲
一、主从复制
1、是什么
主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
2、能干嘛
1、读写分离，性能扩展
2、容灾快速恢复
image.png
3、怎么做
3.1 启动三台
1、创建 /myredis 文件夹
mkdir /myredis
2、复制配置文件到 /myredis 文件夹下
cp /etc/redis.conf /myredis.conf
3、编辑配置文件
（1）新建redis6379.conf，填写以下内容
include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
（2）新建redis6380.conf，填写以下内容
include /myredis/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
（3）新建redis6381.conf，填写以下内容
include /myredis/redis.conf
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
（4）被引入的 /myredis/redis.conf中
此处 appendonly no修改为 no
（5）启动三台
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
image.png
3.2 配置主从
声明：6379为主，6380 和 6381 为从机
（1）进入客户端：redis-cli -p 6379
（2）查看运行情况：info replication
image.png
image.png
image.png
可见在默认情况下，都是主机（主）
（3）在 两台从机上面运行命令
# slaveof 主机IP + 主机端口
slaveof 127.0.0.1 6379
（4）再 主机上面查看情况
image.png
（5）测试效果（主读写，从读）
image.png
image.png
3.3 问题一：某台从机挂掉了
（1）6381挂掉：6381 关闭，查看主机 6379只剩一台从机
image.png
（2）6381挂掉的时候，主机插入了新数据，没挂掉的6380有数据
image.png
（3）此时 6381 重启，发现变成了主机
image.png
（4）此时 6381 在此配置为 6379的从机，数据依次从主机复制过来
image.png
3.4 问题二：主机挂掉了
（1）大哥(6379)病入膏肓，小弟记得大哥，没有谋权篡位
image.png
（2）大哥病好了（6379重启），重启还是主机，数据还在从小弟那里拿
image.png
4、主从复制的原理
（1）Slave启动成功连接到master后会发送一个sync命令
（2）Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
（3）全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
（4）增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
（5）但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
二、薪火相传
1、是什么
比如一个 pm（项目经理）要管理20个人，那么管理的压力就比较大，此时可以分小组，分为两个小组。pm 只需要管理两个小组长，而小组长也可以再分小小组长。
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
image.png
2、做法
6380 为 6381的从机，为6379的从机
image.png
三、反客为主（大哥生病小弟上位）
（1）概述
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
用 slaveof no one 将从机变为主机
（2）主机 6370 挂掉，6381 上位为大哥
image.png
（3）缺点：手动
四、哨兵模式
1、是什么
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
image.png
2、怎么玩
（1）调整为一主二仆模式，6379带着6380、6381
image.png
（2）自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
（3）配置哨兵,填写内容
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量
image.png
（4）启动哨兵
执行 redis-sentinel /myredis/sentinel.conf
（5）当主机挂掉，从机选举中产生新的主机
(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)
哪个从机会被选举为主机呢？根据优先级别：slave-priority
原主机重启后会变为从机。
image.png
image.png
（6）复制延迟
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重
3、哨兵的故障恢复
image.png
（1）优先级在redis.conf中默认：slave-priority 100，值越小优先级越高
image.png
（2）偏移量是指获得原主机数据最全的
（3）每个redis实例启动后都会随机生成一个40位的runid
4、主从复制
private static JedisSentinelPool jedisSentinelPool = null;
public static Jedis getJedisFromSentinel() {
if (jedisSentinelPool == null) {
Set<String> sentinelSet = new HashSet<> ( );
sentinelSet.add ("192.168.11.103:26379");
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig ( );
jedisPoolConfig.setMaxTotal (10); //最大可用连接数
jedisPoolConfig.setMaxIdle (5); //最大闲置连接数
jedisPoolConfig.setMinIdle (5); //最小闲置连接数
jedisPoolConfig.setBlockWhenExhausted (true); //连接耗尽是否等待
jedisPoolConfig.setMaxWaitMillis (2000); //等待时间
jedisPoolConfig.setTestOnBorrow (true); //取连接的时候进行一下测试 ping pong
jedisSentinelPool = new JedisSentinelPool ("mymaster", sentinelSet, jedisPoolConfig);
return jedisSentinelPool.getResource ( );
} else {
return jedisSentinelPool.getResource ( );
}
}
网友评论