Redis入门8--Redis主从复制与分布式

问题导读：




1.什么是主从复制？
2.什么是Redis的分布式模式？
3.集群模式存在的问题有哪些？








一、主从复制

redis主从复制配置和使用都非常简单。通过主从复制可以允许多个slave server拥有和master server相同的数据库副本。下面是关于redis主从复制的一些特点：

       1.master可以有多个slave

       2.除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构

       3.主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。

       4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余

       5.可以在master禁用数据持久化，只需要注释掉master配置文件中的所有save配置，然后只在slave上配置数据持久化。

主从复制的过程：

       当设置好slave服务器后，slave会建立和master的连接，然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连接，master都会启动(fork)一个后台进程，将数据库快照保存到文件中（fork一个进程入内在也被复制了，即内存会是原来的两倍），同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件后，master就发送文件给slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到slave上。接着master就会把缓存的命令转发给slave。而且后续master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从client发送的命令使用相同的协议格式。当master和slave的连接断开时slave可以自动重新建立连接。如果master同时收到多个 slave发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有slave。

       配置slave服务器只需要在配置文件中加入如下配置：

slaveof 192.168.1.1 6379  #指定master的ip和端口

二、分布式

Redis-2.4.15目前没有提供集群的功能，Redis作者在博客中说将在3.0中实现集群机制。目前Redis实现集群的方法主要是采用一致性哈稀分片（Shard），将不同的key分配到不同的redis server上，达到横向扩展的目的。下面来介绍一种比较常用的分布式场景：在读写操作比较均匀且实时性要求较高，可以用下图的分布式模式：

在读操作远远多于写操作时，可以用下图的分布式模式：


       对于一致性哈稀分片的算法，Jedis-2.0.0已经提供了，下面是使用示例代码（以ShardedJedisPool为例）：

[mw_shl_code=applescript,true]package com.jd.redis.client;

import java.util.ArrayList;
import java.util.List;

import redis.clients.jedis.JedisPoolConfig;
import redis.clients.jedis.JedisShardInfo;
import redis.clients.jedis.ShardedJedis;
import redis.clients.jedis.ShardedJedisPool;
import redis.clients.util.Hashing;
import redis.clients.util.Sharded;

publicclass RedisShardPoolTest {
    static ShardedJedisPoolpool;
    static{
        JedisPoolConfig config =new JedisPoolConfig();//Jedis池配置
        config.setMaxActive(500);//最大活动的对象个数
          config.setMaxIdle(1000 * 60);//对象最大空闲时间
          config.setMaxWait(1000 * 10);//获取对象时最大等待时间
          config.setTestOnBorrow(true);
        String hostA = "10.10.224.44";
          int portA = 6379;
          String hostB = "10.10.224.48";
          int portB = 6379;
        List<JedisShardInfo> jdsInfoList =new ArrayList<JedisShardInfo>(2);
        JedisShardInfo infoA = new JedisShardInfo(hostA, portA);
        infoA.setPassword("redis.360buy");
        JedisShardInfo infoB = new JedisShardInfo(hostB, portB);
        infoB.setPassword("redis.360buy");
        jdsInfoList.add(infoA);
        jdsInfoList.add(infoB);
      
        pool =new ShardedJedisPool(config, jdsInfoList, Hashing.MURMUR_HASH,
Sharded.DEFAULT_KEY_TAG_PATTERN);
    }
   
    /**
     * @param args
     */
    publicstaticvoid main(String[] args) {
        for(int i=0; i<100; i++){
            String key = generateKey();
            //key += "{aaa}";
            ShardedJedis jds = null;
            try {
                jds = pool.getResource();
                System.out.println(key+":"+jds.getShard(key).getClient().getHost());
                System.out.println(jds.set(key,"1111111111111111111111111111111"));
            } catch (Exception e) {
                e.printStackTrace();
            }
            finally{
                pool.returnResource(jds);
            }
        }
    }

    privatestaticintindex = 1;
    publicstatic String generateKey(){
        return String.valueOf(Thread.currentThread().getId())+"_"+(index++);
    }
}[/mw_shl_code]
从运行结果中可以看到，不同的key被分配到不同的Redis-Server上去了。

实际上，上面的集群模式还存在两个问题：

1. 扩容问题：

因为使用了一致性哈稀进行分片，那么不同的key分布到不同的Redis-Server上，当我们需要扩容时，需要增加机器到分片列表中，这时候会使得同样的key算出来落到跟原来不同的机器上，这样如果要取某一个值，会出现取不到的情况，对于这种情况，Redis的作者提出了一种名为Pre-Sharding的方式：

Pre-Sharding方法是将每一个台物理机上，运行多个不同断口的Redis实例，假如有三个物理机，每个物理机运行三个Redis实际，那么我们的分片列表中实际有9个Redis实例，当我们需要扩容时，增加一台物理机，步骤如下：

A.     在新的物理机上运行Redis-Server；

B.      该Redis-Server从属于(slaveof)分片列表中的某一Redis-Server（假设叫RedisA）；

C.      等主从复制(Replication)完成后，将客户端分片列表中RedisA的IP和端口改为新物理机上Redis-Server的IP和端口；

D.     停止RedisA。

这样相当于将某一Redis-Server转移到了一台新机器上。Prd-Sharding实际上是一种在线扩容的办法，但还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。

2. 单点故障问题：

还是用到Redis主从复制的功能，两台物理主机上分别都运行有Redis-Server，其中一个Redis-Server是另一个的从库，采用双机热备技术，客户端通过虚拟IP访问主库的物理IP，当主库宕机时，切换到从库的物理IP。只是事后修复主库时，应该将之前的从库改为主库（使用命令slaveof no one），主库变为其从库（使命令slaveof IP PORT），这样才能保证修复期间新增数据的一致性。




相关文章




Redis入门1--入门篇
http://www.aboutyun.com/thread-17346-1-1.html


Redis入门2--Redis数据类型及相关命令
http://www.aboutyun.com/thread-17347-1-1.html



Redis入门3--Redis键值设计和Redis数据存储优化机制
http://www.aboutyun.com/thread-17361-1-1.html



Redis入门4--Redis排序
http://www.aboutyun.com/thread-17377-1-1.html


Redis入门5--Redis事务与Redis管道（pipeline）
http://www.aboutyun.com/thread-17378-1-1.html


Redis入门6--Redis发布/订阅
http://www.aboutyun.com/thread-17384-1-1.html



Redis入门7--Redis持久化
http://www.aboutyun.com/thread-17388-1-1.html


Redis入门8--Redis主从复制与分布式
http://www.aboutyun.com/thread-17401-1-1.html