Redis专题(持续更新)
02-VIP-Redis持久化、主从与哨兵架构详解
文章目录
- 02-VIP-Redis持久化、主从与哨兵架构详解
- 正文
- Redis主从架构
-
- redis主从架构搭建，配置从节点步骤：
- Redis主从工作原理
- 主从复制(全量复制)流程图：
-
- 数据部分复制
- 主从复制(部分复制，断点续传)流程图：
- Jedis连接代码示例：
-
- 1、引入相关依赖：
- 顺带讲下redis管道与调用lua脚本，代码示例上面已经给出：
-
- 管道（Pipeline）
- Redis Lua脚本
正文
Redis主从架构
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的从节点
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。
主从复制(全量复制)流程图：
数据部分复制
当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支
持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分
数据复制(断点续传)。
master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的
slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master
继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标
offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。
主从复制(部分复制，断点续传)流程图：
如果有很多从节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以做如
下架构，让部分从节点与从节点(与主节点同步)同步数据
Jedis连接代码示例：
1、引入相关依赖：
1 <dependency>
2 <groupId>redis.clients</groupId>
3 <artifactId>jedis</artifactId>
4 <version>2.9.0</version>
5 </dependency>
访问代码：
1 public class JedisSingleTest {
2 public static void main(String[] args) throws IOException {
3
4 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
5 jedisPoolConfig.setMaxTotal(20);
6 jedisPoolConfig.setMaxIdle(10);
7 jedisPoolConfig.setMinIdle(5);
8
9 // timeout，这里既是连接超时又是读写超时，从Jedis 2.8开始有区分connectionTimeout和soTimeou
t的构造函数
10 JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.0.60", 6379, 3000,
null);
11
12 Jedis jedis = null;
13 try {
14 //从redis连接池里拿出一个连接执行命令
15 jedis = jedisPool.getResource();
16
17 System.out.println(jedis.set("single", "zhuge"));
18 System.out.println(jedis.get("single"));
19
20 //管道示例
21 //管道的命令执行方式：cat redis.txt | redis‐cli ‐h 127.0.0.1 ‐a password ‐ p 6379 ‐‐pi
pe
22 /*Pipeline pl = jedis.pipelined();
23 for (int i = 0; i < 10; i++) {
24 pl.incr("pipelineKey");
25 pl.set("zhuge" + i, "zhuge");
26 }
27 List
29
30 //lua脚本模拟一个商品减库存的原子操作
31 //lua脚本命令执行方式：redis‐cli ‐‐eval /tmp/test.lua , 10
32 /*jedis.set("product_count_10016", "15"); //初始化商品10016的库存
33 String script = " local count = redis.call('get', KEYS[1]) " +
34 " local a = tonumber(count) " +
35 " local b = tonumber(ARGV[1]) " +
36 " if a >= b then " +
37 " redis.call('set', KEYS[1], a‐b) " +
38 " return 1 " +
39 " end " +
40 " return 0 ";
41 Object obj = jedis.eval(script, Arrays.asList("product_count_10016"),
Arrays.asList("10"));
42 System.out.println(obj);*/
43
44 } catch (Exception e) {
45 e.printStackTrace();
46 } finally {
47 //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
48 if (jedis != null)
49 jedis.close();
50 }
51 }
52 }
顺带讲下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("zhuge" + i, "zhuge");
5 //模拟管道报错
6 // pl.setbit("zhuge", ‐1, true);
7 }
8 List<Object> results = pl.syncAndReturnAll();
9 System.out.println(results);
Redis Lua脚本
Redis在2.6推出了脚本功能，允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下:
1、减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器
上完成。使用脚本，减少了网络往返时延。这点跟管道类似。
2、原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过
redis的批量操作命令(类似mset)是原子的。
3、替代redis的事务功能：redis自带的事务功能很鸡肋，而redis的lua脚本几乎实现了常规的事务功能，
官方推荐如果要使用redis的事务功能可以用redis lua替代。
官网文档上有这样一段话：
1 A Redis script is transactional by definition, so everything you can do with a Redis t
ransaction, you can also do with a script,
2 and usually the script will be both simpler and faster.
从Redis2.6.0版本开始，通过内置的Lua解释器，可以使用EVAL命令对Lua脚本进行求值。EVAL命令的格
式如下：
1 EVAL script numkeys key [key ...] arg [arg ...]
script参数是一段Lua脚本程序，它会被运行在Redis服务器上下文中，这段脚本不必(也不应该)定义为一
个Lua函数。numkeys参数用于指定键名参数的个数。键名参数 key [key …] 从EVAL的第三个参数开始算
起，表示在脚本中所用到的那些Redis键(key)，这些键名参数可以在 Lua中通过全局变量KEYS数组，用1
为基址的形式访问( KEYS[1] ， KEYS[2] ，以此类推)。
在命令的最后，那些不是键名参数的附加参数 arg [arg …] ，可以在Lua中通过全局变量ARGV数组访问，
访问的形式和KEYS变量类似( ARGV[1] 、 ARGV[2] ，诸如此类)。例如
1 127.0.0.1:6379> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first seco
nd
2 1) "key1"
3 2) "key2"
4 3) "first"
5 4) "second"
其中 “return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}” 是被求值的Lua脚本，数字2指定了键名参数的数
量， key1和key2是键名参数，分别使用 KEYS[1] 和 KEYS[2] 访问，而最后的 first 和 second 则是附加
参数，可以通过 ARGV[1] 和 ARGV[2] 访问它们。
在 Lua 脚本中，可以使用redis.call()函数来执行Redis命令
Jedis调用示例详见上面jedis连接示例：
1
2 jedis.set("product_stock_10016", "15"); //初始化商品10016的库存
3 String script = " local count = redis.call('get', KEYS[1]) " +
4 " local a = tonumber(count) " +
5 " local b = tonumber(ARGV[1]) " +
6 " if a >= b then " +
7 " redis.call('set', KEYS[1], a‐b) " +
8 " return 1 " +
9 " end " +
10 " return 0 ";
11 Object obj = jedis.eval(script, Arrays.asList("product_stock_10016"), Arrays.asList("1
0"));
12 System.out.println(obj)
注意，不要在Lua脚本中出现死循环和耗时的运算，否则redis会阻塞，将不接受其他的命令， 所以使用
时要注意不能出现死循环、耗时的运算。redis是单进程、单线程执行脚本。管道不会阻塞redis。
明天说Redis哨兵高可用架构!