京淘项目014

1. Redis分片机制

1.1 分片机制说明

前提说明: redis可以通过修改内存的大小 实现数据的保存.但是内存的资源不易设置的过大,因为很多的时间都浪费在内存的寻址中.
需求: 如果有海量的数据,需要redis存储 问:应该如何处理?
解决方案: 可以采用Redis分片机制 实现内存数据的扩容.
知识点: 采用redis分片 只要的目的就是为了实现内存扩容.从而解决海量数据存储的问题

1.2 Redis分片搭建步骤

1.2.1 分片节点说明

说明: 端口号分别为  6379/6380/6381  

1.2.2 关闭原有的Redis

1.2.3 准备多个配置文件

分别修改6380/6381 改为各自对应的端口号.
启动3台redis

[root@localhost shards]# redis-server 6379.conf
[root@localhost shards]# redis-server 6380.conf
[root@localhost shards]# redis-server 6381.conf

1.2.4 Redis分片入门案例

public class TestShards { //改类表示测试redis分片机制

    /**
     * 说明:在Linux中有3台redis.需要通过程序进行动态链接.
     * 实现数据的存储.
     * 思考: 数据保存到了哪台redis中???
     */
    @Test
    public void test01(){
        List<JedisShardInfo> shards = new ArrayList<>();
        shards.add(new JedisShardInfo("192.168.126.129", 6379));
        shards.add(new JedisShardInfo("192.168.126.129", 6380));
        shards.add(new JedisShardInfo("192.168.126.129", 6381));
        //分片的API
        ShardedJedis shardedJedis = new ShardedJedis(shards);
        shardedJedis.set("王者荣耀", "你好我是小菜鸡,坑死你");
        System.out.println(shardedJedis.get("王者荣耀"));
    }
}

1.3 一致性hash算法

1.3.1 一致性hash说明

一致性哈希算法在1997年由麻省理工学院提出，是一种特殊的哈希算法，目的是解决分布式缓存的问题。 [1] 在移除或者添加一个服务器时，能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table，DHT) 中存在的动态伸缩等问题 [2] 。

1.3.2 一致性hash原理

常识:

1. 一般的hash由8位16进制数组成的. 共有2^32种可能性!!!
2. hash算法对相同的数据进行hash运算时 结果必然相同.

00000000-FFFFFFFF 0-F=(24)8 = 2^32
进制:
1).二进制 取值 : 0-1 规则满2进1
2).八进制 取值 : 0-7 规则满8进1 2^3=8 每三位二进制数就是一个8进制数
3).十六进制 取值 : 0-9 A-F 规则满16进一 2^4=16 每四位二进制数就是一个16进制数

1.3.2 一致性hash 特性

1.3.2.1平衡性

①平衡性是指hash的结果应该平均分配到各个节点，这样从算法上解决了负载均衡问题
说明:引入虚拟节点 实现数据的平衡 但是平衡是相对的.不是绝对的.

1.3.2.2 单调性

②单调性是指在新增或者删减节点时，不影响系统正常运行 [4] 。

1.3.2.2 分散性

③分散性是指数据应该分散地存放在分布式集群中的各个节点(节点自己可以有备份)，不必每个节点都存储所有的数据 [4] 。
鸡蛋不要放到一个篮子里.

1.4 Spring整合redis分片机制

1.4.1 准备Redis.pro文件

# 配置单台redis
#redis.host=192.168.126.129
#redis.port=6379

# 配置多台redis
redis.nodes=192.168.126.129:6379,192.168.126.129:6380,192.168.126.129:6381

1.4.2 编辑配置类

@Configuration  //标识我是配置类
@PropertySource("classpath:/properties/redis.properties")
public class RedisConfig {

    @Value("${redis.nodes}")
    private String nodes;   //node,node,node

    /**
     * spring整合redis分片机制
     */
    @Bean
    public ShardedJedis shardedJedis(){
        //1.获取每个节点的信息
        String[] strNodes = nodes.split(",");
        List<JedisShardInfo> shards = new ArrayList<>();
        //2.遍历所有node.为list集合赋值
        for(String node :strNodes){ //node=ip:port
            String host = node.split(":")[0];
            int port = Integer.parseInt(node.split(":")[1]);
            JedisShardInfo info = new JedisShardInfo(host,port);
            shards.add(info);
        }

        ShardedJedis shardedJedis = new ShardedJedis(shards);
        return shardedJedis;
    }





  /*  @Value("${redis.host}")
    private String  host;
    @Value("${redis.port}")
    private Integer port;

    //SpringBoot管理  Spring框架的优化的API
    @Bean
    public Jedis jedis(){

        return new Jedis(host,port);
    }*/
}

1.4.3 分片机制AOP使用

2.Redis哨兵机制

2.1 redis分片机制存在的问题

2.2 Redis主从搭建

前提条件: 如果要实现redis高可用机制,则必须首先实现主从搭建.
主从关系设定: 6379当做主机-M 6380/6381 从机-S

2.2.1 准备哨兵工作目录

2.2.2 Redis主从配置

1).检查Redis默认条件下的主从关系

2).实现主从配置
命令:slave of 主机IP 主机端口

3).用户操作Redis主机,之后检查从机是否实现数据同步即可.
数据同步正常.

2.2.3 主从配置问题说明

说明:当redis服务器已经配置了主从结构之后.如果将服务器宕机.之后再次重启.则发现从服务器又会变为主机!!!
问题说明: 执行了主从挂载命令 该命令一直保存在内存中.当redis服务器重启之后,该命令失效.如果想要一直保持主从的关系.则必须将主从的结构写入Redis.conf的配置文件中.

2.3 哨兵机制原理说明

1.首先启动Redis哨兵.由哨兵监控整个Redis主从状态. 主要监控M主机. 同时获取其从机的信息.
2.哨兵利用心跳检测机制(PING-PONG)的方式监控主机是否宕机. 如果连续3次主机没有响应.则哨兵判断主机宕机.
之后开始进行选举.
3.根据从主机中获取的从机信息.之后利用 选举机制算法.挑选新的主机.
4.之后将剩余的redis修改为当前主机的的从.并且修改配置文件.

2.4 Redis实现哨兵机制

2.4.1 复制Redis哨兵配置文件

2.4.2修改配置文件
命令: 在sentinel目录下 vim sentinel.conf

2.修改哨兵监控配置

3.修改哨兵选举的时间
当redis主机宕机之后,哨兵多久开始选举.

4.选举超时时间设定
说明:如果当选主机的服务器在规定的时间之内,没有完成切换.则哨兵重新选举.

2.4.3 启动哨兵检查高可用性
命令: redis-sentinel sentinel.conf

测试步骤:
1.将6379主机宕机.

2.等待10秒之后.检查从机是否当选主机.

3.重启6379服务器.检查是否为当前主机的从.

重启服务之后,检查是否为从.!

2.5 Spring整合Redis哨兵

2.5.1 入门案例

package com.jt.test;

import org.junit.jupiter.api.Test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;

import java.util.HashSet;
import java.util.Set;

public class TestSentinel { //主要完成哨兵测试

    /**
     * 参数说明:
     *   masterName: 主机名称
     *   sentinels:  哨兵节点信息.
     */
    @Test
    public void test01(){
        Set<String> sentinels = new HashSet<>();
        String node = "192.168.126.129:26379";
        sentinels.add(node);
        JedisSentinelPool sentinelPool =
                new JedisSentinelPool("mymaster", sentinels);

        Jedis jedis = sentinelPool.getResource(); //获取资源
        jedis.set("sentinel", "redis哨兵机制配置成功!!!!");
        System.out.println(jedis.get("sentinel"));
    }

}

3 搭建Redis集群

3.1 Redis分片/Redis哨兵总结

说明:
1).分片可以实现Redis内存数据的扩容.可以存储海量的内存数据. Redis分片机制没有实现高可用.如果分片中一个节点宕机,则直接影响整个服务的运行.
2).哨兵可以实现Redis节点的高可用.但是Redis中的数据不能实现内存的扩容.
哨兵服务本身没有实现高可用.如果哨兵发生了异常则直接影响用户使用.

想法:  能否有一种机制既可用满足海量数据的存储要求(扩容),同时可以实现redis高可用,并且还不会依赖第三方.