Redis 客户端分片模式

0x01：分区的概念

　　分区就是将数据分割到多个Redis实例，所以每一个实例只保存一部分key - value，每个 Redis 实例的 key 的一个子集。

　　若是只使用一个 Redis 实例时，那么这个 Redis 实例保存了服务器中所有的缓存数据，这样会有很大风险，若是单台 Redis 服务宕机了将会影响到整个服务。解决方案能够采用分片 / 分区的技术，将原来一台服务器维护的整个缓存，换为由多台服务器共同维护内存空间。

 

0x02: 分片的实现

　　采用在一台主机上实现分片的方式，因此只须要在该主机上配置启动三台 Redis 的实例。由于 Redis 默认使用的端口号为6379，因此这里分别使用637九、6380以及6381三个端口来实现。

配置：

一、进入到 Redis 的安装目录下，建立一个 shard 文件夹，而后将 Redis 的配置文件 redis.conf 复制一份，取名为redis-6379.conf ( 做为6379这台实例的配置文件 )。而后将该文件移动到shard文件夹下，再将 redis-6379.conf 复制两份。

• redis-6380.conf：做为6380这台实例的配置文件

• redis-6381.conf：做为6381这台实例的配置文件

二、修改6379这台实例的配置文件redis-6379.conf，由于端口6379默认就是 Redis 的端口，因此只须要指定该实例的持久化片区（文件）便可。

三、修改6380实例的配置文件redis-6380.conf

• 修改该实例占用的端口为6380

　

• 修改pid

• 修改dump文件名

四、修改6381实例的配置文件redis-6381.conf

• 修改该实例占用的端口为6381

• 修改pid

• 修改dump文件名

redis-6380.conf 与 redis-6381.conf 配置步骤同样的，只是配置的值不同。

 

0x03：启动与测试：

一、分别启动3台 Redis 实例

二、测试

　　Redis分区有两种方式，对既定的 key 有不一样的方式来选择这个 key 存放到哪一个实例中，也就是说有不一样的算法来映射某个 key 到某个 Redis 的实例中。

• 最简单的分区方式为范围分区，就是映射必定范围的对象到特定的 Redis 实例。好比，ID 从0到10000的用户会保存到实例 R0，ID 从10001到 20000的用户会保存到 R1，以此类推。

• 另外一种方式是 hash 一致算法实现分区，对 key 值进行 hash 一致性计算后获得结果，最终将数据保存到某一台 Redis 实例中。

测试方案一：基于 jedis jar

方法中定义了一个redis分片的链接池，分别添加用于测试的三个节点实例，而后向redis中增长10个记录。

    //定义redis的配置
    PoolConfig poolconfig = new PoolConfig();
    poolconfig.setMaxTotal(1000);  //表示redis的最大链接数——最大1000个线程
    poolconfig.setMinIdle(5);  //表示最小空闲数量
    //定义redis的多个节点机器
    List<JedisShardInfo> list = new ArrayList<>();
    //为集合添加参数
    list.add(new JedisShardInfo("192.168.161.139", 6379));
    list.add(new JedisShardInfo("192.168.161.139", 6380));
    list.add(new JedisShardInfo("192.168.161.139", 6381));
    //定义redis分片链接池
    ShardedJedisPool jedisPool = new ShardedJedisPool(poolconfig, list);
    //获取链接操做redis
    ShardedJedis shardedJedis = jedisPool.getResource();
    //向redis中添加20个记录查看分片结果
    for(int i = 0; i < 10; i++){
        //增长的记录格式为   key=NUM_i   value=i
        shardedJedis.set("NUM_"+i, ""+i);

经过 redis-cli 客户端分别链接到这三台 Redis 实例。结果发现10个记录中有1个分到了6379区，3个分到了6380区，另外6个分到了6381区，由于是采用记录的 key 值来进行 hash 一致性算法来肯定记录的存放区域，因此即便从新分区都不会改变记录的存放地址，因此仍然能够根据 key 值来获取到对应的 value 值。

测试方案一：基于 Spring

• 配置文件redis.properties

# 配置Redis分片实例
redis.nodes = 192.168.161.139:6379,192.168.161.139:6380,192.168.161.139:6381

• RedisConfig配置类

@Configuration   //标识我是一个配置类 通常与@Bean注解联用
@PropertySource("classpath:/properties/redis.properties")
public class RedisConfig {
     @Value("${redis.nodes}")
     private String nodes;   //node,node,node

     @Bean
     public ShardedJedis shardedJedis(){
         List<JedisShardInfo> shards = new ArrayList<JedisShardInfo>();
         String[] nodeArray = nodes.split(",");
         for( String node : nodeArray){   // node=host:port
             String host = node.split(":")[0];
             int port = Integer.parseInt(node.split(":")[1]);
             JedisShardInfo info = new JedisShardInfo(host,port);
             shards.add(info);
         }
         return new ShardedJedis(shards);
     }
}

分区的不足：

• 分区是多台 Redis 共同做用的，若是其中一台出现了宕机现象，则整个分片都将不能使用，虽然是在必定程度上缓减了内存的压力，可是没有实现高可用。

• 涉及多个 key 的操做一般是不被支持的。举例来讲，当两个 set 映射到不一样的Redis 实例上时，就不能对这两个set执行交集操做。

• 涉及多个 key 的 Redis事务不能使用。

• 当使用分区时，数据处理较为复杂，好比须要处理多个 rdb / aof 文件，而且从多个实例和主机备份持久化文件。

　高可用的解决方案

• 哨兵主从复制实现高可用

• 集群模式