【Redis】集群模式（一）：主从架构原理分析及代码示例

单机的 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.主从架构搭建

3.1 配置从节点

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的从节点

3.2 Jedis连接代码示例

 <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();
    }
}