单机的 redis,能够承载的 QPS 大概就在上万到几万不等。对于缓存来说,一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容,支撑读高并发。
1.Redis 主从工作原理
1.1 全量复制(启动)
1)如果你为 master 配置了一个 slave,不管这个 slave 是否是第一次连接上 Master,它都会发送一个 SYNC 命令(redis2.8版本之前的命令)给master请求复制数据。
2)master 收到 SYNC 命令后,会在后台进行数据持久化通过 bgsave 生成新的 rdb 快照文件。
两点注意:
- 持久化期间, master 会继续接收客户端的请求,它会把这些可能修改数据集的请求缓存在内存中。
- 当 master 与 slave 之间的连接由于某些原因而断开时,slave 能够自动重连 Master,如果 master 收到了多个 slave 并发连接请求,它只会进行一次持久化,而不是一个连接一次,然后再把这一份持久化的数据发送给多个并发连接的 slave。
3)当持久化进行完毕以后,master 会把这份 rdb 文件数据集发送给 slave
4)然后,master 再将之前缓存在内存中的命令发送给 slave
5)slave 会把接收到的数据进行持久化生成 rdb,然后再加载到内存中
主从复制(全量复制)流程图:
1.2 部分复制(重启)
当 master 和 slave 断开重连后,一般都会对整份数据进行复制。但从 redis2.8 版本开始,master 和 slave 断开重连后支持部分复制。
从2.8版本开始,slave 与 master 能够在网络连接断开重连后只进行部分数据复制。 master 会在其内存中创建一个复制数据用的缓存队列,缓存近一段时间的数据,master 和它所有的 slave 都维护了复制的数据下标 offset 和 master 的进程id。
因此,当网络连接断开后,slave 会请求master 继续进行未完成的复制,从所记录的数据下标开始。如果 master 进程 id 变化了,或者从节点数据下标 offset太旧,已经不在 master 的缓存队列里了,那么将会进行一次全量数据的复制。从2.8版本开始,redis 改用可以支持部分数据复制的命令PSYNC去master同步数据。
主从复制(部分复制)流程图:
2.优缺点
优点:
- 主从模式下,当某一节点损坏时,因为其会将数据备份到其它 Redis 实例上,这样做在很大程度上可以恢复丢失的数据。
- 主从模式下,主节点和从节点是读写分离的。使用者不仅可以从主节点上读取数据,还可以很方便的从从节点上读取到数据,这在一定程度上缓解了主机的压力。
- 主从模式下,可以保证负载均衡(多个redis读),这里不再叙说了
- 从节点也是能够支持写入数据的,只不过从从节点写入的数据不会同步到主节点以及其它的从节点下。
缺点:Redis 在主从模式下,只有主节点提供服务必须保证主节点不会宕机——一旦主节点宕机,其它节点不会竞争称为主节点,此时,Redis将丧失写的能力。这点在生产环境中,是致命的
3.主从架构搭建
1、复制一份redis.conf文件
2、将相关配置修改为如下值:
port 6380
pidfile /var/run/redis_6380.pid
logfile "6380.log"
dir /usr/local/redis‐5.0.3/data/6380
3、配置主从复制
replicaof 192.168.0.60 6379 # 从本机6379的redis实例复制数据
replica‐read‐only yes
4、启动从节点
redis‐server redis.conf
5、连接从节点
redis‐cli ‐p 6380
6、测试在6379实例上写数据,6380实例是否能及时同步新修改数据
7、可以自己再配置一个6381的从节点
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
public class JedisSingleTest {
public static void main(String[] args) {
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(20);
jedisPoolConfig.setMaxIdle(10);
jedisPoolConfig.setMaxIdle(5);
// timeout,这里既是连接超时又是读写超时,从Jedis 2.8开始区分connectionTimeout和soTimeout的构造函数
JedisPool jedisPool = new JedisPool(jedisPoolConfig, "43.107.136.120", 6379, 3000, null);
// 从redis连接池里拿出一个连接执行命令
Jedis jedis = jedisPool.getResource();
System.out.println(jedis.set("single", "zhangsan"));
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("zhangsan" + i, "zhangsan");
}
List<Object> results = pl.syncAndReturnAll();
System.out.println(results);
*/
// lua脚本模拟一个商品减库存的原子操作
// lua脚本执行命令方式:redis-cli --eval /tmp/test.lua, 10
/*
jedis.set("product_count_1001", "15")
String script = " local count = redis.call('get', KEYS[1]) " +
" local a = tonumber(count) " +
" local a = tonumber(ARGV[i]) " +
" if a >= b then " +
" redis.call('set', KEYS[1], count-b) " +
" return 1 " +
" end " +
"return 0 ";
Object obj = jedis.eval(script, Arrays.asList("product_count_1001"), Arrays.asList("10"));
System.out.println(obj);
*/
// 这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池
jedis.close();
}
}