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 < Object > results = pl . syncAndReturnAll ();

28 System . out . println ( results ); */

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。