Redis主从与哨兵架构详解

一、Redis主从架构

在这里插入图片描述

1、redis主从架构搭建,配置从节点步骤:

1 1、复制一份redis.conf文件
2
3 2、将相关配置修改为如下值:
4 port 6380
5 pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
6 logfile "6380.log"
7 dir /usr/local/redis‐5.0.3/data/6380 # 指定数据存放目录
8 # 需要注释掉bind
9 # bind 127.0.0.1(bind绑定的是自己机器网卡的ip,如果有多块网卡可以配多个ip,代表允许客户端通
过机器的哪些网卡ip去访问,内网一般可以不配置bind,注释掉即可)
10
11 3、配置主从复制
12 replicaof 192.168.0.60 6379 # 从本机6379的redis实例复制数据,Redis 5.0之前使用slaveof
13 replica‐read‐only yes # 配置从节点只读
14
15 4、启动从节点
16 redis‐server redis.conf
17
18 5、连接从节点
19 redis‐cli ‐p 6380
20
21 6、测试在6379实例上写数据,6380实例是否能及时同步新修改数据
22
23 7、可以自己再配置一个6381的从节点

2、Redis主从工作原理

如果你为master配置了一个slave,不管这个slave是否是第一次连接上Master,它都会发送一个PSYNC命令给master请求复制数据。

master收到PSYNC命令后,会在后台进行数据持久化通过bgsave生成最新的rdb快照文件,持久化期间,master会继续接收客户端的请求,它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后,master会把这份rdb文件数据集发送给slave,slave会把接收到的数据进行持久化生成rdb,然后再加载到内存中。然后,master再将之前缓存在内存中的命令发送给slave。

当master与slave之间的连接由于某些原因而断开时,slave能够自动重连Master,如果master收到了多个slave并发连接请求,它只会进行一次持久化,而不是一个连接一次,然后再把这一份持久化的数据发送
给多个并发连接的slave。

1、主从复制(全量复制)流程图
在这里插入图片描述
2、数据部分复制

当master和slave断开重连后,一般都会对整份数据进行复制。但从redis2.8版本开始,redis改用可以支持部分数据复制的命令PSYNC去master同步数据,slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。

master会在其内存中创建一个复制数据用的缓存队列,缓存最近一段时间的数据,master和它所有的slave都维护了复制的数据下标offset和master的进程id,因此,当网络连接断开后,slave会请求master继续进行未完成的复制,从所记录的数据下标开始。如果master进程id变化了,或者从节点数据下标offset太旧,已经不在master的缓存队列里了,那么将会进行一次全量数据的复制。

主从复制(部分复制,断点续传)流程图:
在这里插入图片描述
如果有很多从节点,为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大),可以做如下架构,让部分从节点与从节点(与主节点同步)同步数据
在这里插入图片描述

3、Jedis连接代码示例:

1、引入相关依赖:

 <dependency>
 <groupId>redis.clients</groupId>
 <artifactId>jedis</artifactId>
 <version>2.9.0</version>
 </dependency>

访问代码:

 public class JedisSingleTest {
 public static void main(String[] args) throws IOException {

 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
 jedisPoolConfig.setMaxTotal(20);
 jedisPoolConfig.setMaxIdle(10);
 jedisPoolConfig.setMinIdle(5);

 // timeout,这里既是连接超时又是读写超时,从Jedis 2.8开始有区分connectionTimeout和soTimeout的构造函数
 JedisPool jedisPool = new JedisPool(jedisPoolConfig,"192.168.0.60", 6379, 3000,null);

 Jedis jedis = null;
 try {
 //从redis连接池里拿出一个连接执行命令
 jedis = jedisPool.getResource();

 System.out.println(jedis.set("single", "java"));
 System.out.println(jedis.get("single"));

 //管道示例
 //管道的命令执行方式:cat redis.txt | redis‐cli ‐h 127.0.0.1 ‐a password ‐ p 6379 ‐‐pipe
 /*Pipeline pl = jedis.pipelined();
 for (int i = 0; i < 10; i++) {
 pl.incr("pipelineKey");
 pl.set("java" + i, "java");
 }
 List<Object> results = pl.syncAndReturnAll();
 System.out.println(results);*/

 //lua脚本模拟一个商品减库存的原子操作
 //lua脚本命令执行方式:redis‐cli ‐‐eval /tmp/test.lua , 10
 /*jedis.set("product_count_10016", "15"); //初始化商品10016的库存
 String script = " local count = redis.call('get', KEYS[1]) " +
 " local a = tonumber(count) " +
 " local b = tonumber(ARGV[1]) " +
 " if a >= b then " +
 " redis.call('set', KEYS[1], a‐b) " +
 " return 1 " +
 " end " +
 " return 0 ";
 Object obj = jedis.eval(script, Arrays.asList("product_count_10016"),
Arrays.asList("10"));
 System.out.println(obj);*/

 } catch (Exception e) {
 e.printStackTrace();
 } finally {
 //注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
 if (jedis != null)
 jedis.close();
 }
 }
 }

顺带说下redis管道与调用lua脚本,代码示例上面已经给出:

管道(Pipeline)
客户端可以一次性发送多个请求而不用等待服务器的响应,待所有命令都发送完后再一次性读取服务的响应,这样可以极大的降低多条命令执行的网络传输开销,管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送,redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多,缓存消耗内存也越多。所以并不是打包的命令越多越好。

pipeline中发送的每个command都会被server立即执行,如果执行失败,将会在此后的响应中得到信息;也就是pipeline并不是表达“所有command都一起成功”的语义,管道中前面命令失败,后面命令不会有影响,继续执行。
详细代码示例见上面jedis连接示例:

1 Pipeline pl = jedis.pipelined();
2 for (int i = 0; i < 10; i++) {
3 pl.incr("pipelineKey");
4 pl.set("java" + i, "java");
5 //模拟管道报错
6 // pl.setbit("java", ‐1, true);
7 }
8 List<Object> results = pl.syncAndReturnAll();
9 System.out.println(results);

Redis Lua脚本(放在后面Redis高并发分布式锁实战课里详细讲)
Redis在2.6推出了脚本功能,允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下:
1、减少网络开销:本来5次网络请求的操作,可以用一个请求完成,原先5次请求的逻辑放在redis服务器上完成。使用脚本,减少了网络往返时延。这点跟管道类似。
2、原子操作:Redis会将整个脚本作为一个整体执行,中间不会被其他命令插入。管道不是原子的,不过redis的批量操作命令(类似mset)是原子的。
3、替代redis的事务功能:redis自带的事务功能很鸡肋,而redis的lua脚本几乎实现了常规的事务功能,官方推荐如果要使用redis的事务功能可以用redis lua替代。

官网文档上有这样一段话:

 A Redis script is transactional by definition, so everything you can do with a Redis transaction, you can also do with a script, and usually the script will be both simpler and faster.

从Redis2.6.0版本开始,通过内置的Lua解释器,可以使用EVAL命令对Lua脚本进行求值。

二、Redis哨兵高可用架构

在这里插入图片描述
sentinel哨兵是特殊的redis服务,不提供读写服务,主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点,后续就直接访问redis的主节点,不会每次都通过sentinel代理访问redis的主节点,当redis的主节点发生变化,哨兵会第一时间感知到,并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能,订阅sentinel发布的节点变动消息)

1、redis哨兵架构搭建步骤

1、复制一份sentinel.conf文件

 cp sentinel.conf sentinel‐26379.conf

2、将相关配置修改为如下值:

 port 26379
 daemonize yes
 pidfile "/var/run/redis‐sentinel‐26379.pid"
 logfile "26379.log"
 dir "/usr/local/redis‐5.0.3/data"
 # sentinel monitor <master‐redis‐name> <master‐redis‐ip><master‐redis‐port> <quorum>
 # quorum是一个数字,指明当有多少个sentinel认为一个master失效时(值一般为:sentinel总数/2 +1),master才算真正失效
 sentinel monitor mymaster 192.168.0.60 6379 2 # mymaster这个名字随便取,客户端访问时会用到

3、启动sentinel哨兵实例

 src/redis‐sentinel sentinel‐26379.conf

4、查看sentinel的info信息

 src/redis‐cli ‐p 26379
 127.0.0.1:26379>info
 可以看到Sentinel的info里已经识别出了redis的主从

5、可以自己再配置两个sentinel,端口26380和26381,注意上述配置文件里的对应数字都要修改

sentinel集群都启动完毕后,会将哨兵集群的元数据信息写入所有sentinel的配置文件里去(追加在文件的最下面),我们查看下如下配置文件sentinel-26379.conf,如下所示:

sentinel known‐replica mymaster 192.168.0.60 6380 #代表redis主节点的从节点信息
sentinel known‐replica mymaster 192.168.0.60 6381 #代表redis主节点的从节点信息
sentinel known‐sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵节点
sentinel known‐sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵节点

当redis主节点如果挂了,哨兵集群会重新选举出新的redis主节点,同时会修改所有sentinel节点配置文件的集群元数据信息,比如6379的redis如果挂了,假设选举出的新主节点是6380,则sentinel文件里的集群元数据信息会变成如下所示:

sentinel known‐replica mymaster 192.168.0.60 6379 #代表主节点的从节点信息
sentinel known‐replica mymaster 192.168.0.60 6381 #代表主节点的从节点信息
sentinel known‐sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵节点
sentinel known‐sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵节点
同时还会修改sentinel文件里之前配置的mymaster对应的6379端口,改为6380
sentinel monitor mymaster 192.168.0.60 6380 2
当6379的redis实例再次启动时,哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点加入集群

2、哨兵的Jedis连接代码:

 public class JedisSentinelTest {
 public static void main(String[] args) throws IOException {

 JedisPoolConfig config = new JedisPoolConfig();
 config.setMaxTotal(20);
 config.setMaxIdle(10);
 config.setMinIdle(5);

 String masterName = "mymaster";
 Set<String> sentinels = new HashSet<String>();
 sentinels.add(new HostAndPort("192.168.0.60",26379).toString());
 sentinels.add(new HostAndPort("192.168.0.60",26380).toString());
 sentinels.add(new HostAndPort("192.168.0.60",26381).toString());
 //JedisSentinelPool其实本质跟JedisPool类似,都是与redis主节点建立的连接池
 //JedisSentinelPool并不是说与sentinel建立的连接池,而是通过sentinel发现redis主节点并与其建立连接
JedisSentinelPool jedisSentinelPool = new JedisSentinelPool(masterName, sentinels, config, 3000, null);
Jedis jedis = null;
try {
jedis = jedisSentinelPool.getResource();
System.out.println(jedis.set("sentinel", "java"));
System.out.println(jedis.get("sentinel"));
} catch (Exception e) {
 e.printStackTrace();
 } finally {
//注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
 if (jedis != null)
 jedis.close();
 }
 }
 }

3、哨兵的Spring Boot整合Redis连接代码

见示例项目:redis-sentinel-cluster
1、引入相关依赖:

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring‐boot‐starter‐data‐redis</artifactId>
 </dependency>

 <dependency>
 <groupId>org.apache.commons</groupId>
 <artifactId>commons‐pool2</artifactId>
 </dependency>

2、springboot项目核心配置:

 server:
 port: 8080

 spring:
 redis:
 database: 0
 timeout: 3000
 sentinel: #哨兵模式
 master: mymaster #主服务器所在集群名称
 nodes: 192.168.0.60:26379,192.168.0.60:26380,192.168.0.60:26381
 lettuce:
 pool:
 max‐idle: 50
 min‐idle: 10
 max‐active: 100
 max‐wait: 1000

3、访问代码:

 @RestController
 public class IndexController {

 private static final Logger logger = LoggerFactory.getLogger(IndexController.class);

 @Autowired
 private StringRedisTemplate stringRedisTemplate;

 /**
 * 测试节点挂了哨兵重新选举新的master节点,客户端是否能动态感知到
 * 新的master选举出来后,哨兵会把消息发布出去,客户端实际上是实现了一个消息监听机制,
 * 当哨兵把新master的消息发布出去,客户端会立马感知到新master的信息,从而动态切换访问的masterip
 * 
 * @throws InterruptedException
 */
@RequestMapping("/test_sentinel")
public void testSentinel() throws InterruptedException {
int i = 1;
 while (true){
 try {
 stringRedisTemplate.opsForValue().set("java"+i, i+"");
 System.out.println("设置key:"+ "java" + i);
 i++;
 Thread.sleep(1000);
 }catch (Exception e){
 logger.error("错误:", e);
 }
 }
 }
 }

4、StringRedisTemplate与RedisTemplate详解

spring 封装了 RedisTemplate 对象来进行对redis的各种操作,它支持所有的 redis 原生的 api。在RedisTemplate中提供了几个常用的接口方法的使用,分别是:

 private ValueOperations<K, V> valueOps;
 private HashOperations<K, V> hashOps;
 private ListOperations<K, V> listOps;
 private SetOperations<K, V> setOps;
 private ZSetOperations<K, V> zSetOps;

RedisTemplate中定义了对5种数据结构操作

 redisTemplate.opsForValue();//操作字符串
 redisTemplate.opsForHash();//操作hash
 redisTemplate.opsForList();//操作list
 redisTemplate.opsForSet();//操作set
 redisTemplate.opsForZSet();//操作有序set

StringRedisTemplate继承自RedisTemplate,也一样拥有上面这些操作。
StringRedisTemplate默认采用的是String的序列化策略,保存的key和value都是采用此策略序列化保存的。
RedisTemplate默认采用的是JDK的序列化策略,保存的key和value都是采用此策略序列化保存的。

下一节继续详解Redis集群之高可用可水平扩展,关注我,不迷路~

  • 27
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一只IT攻城狮

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值