Redis集群

1.集群:多个服务器集中在一起,实现同一个业务,当一台服务器不能满足开发需求的时候,需要多台服务器的支持,这时就需要做集群,但是集群往往伴随着分布式.

分布式服务之间的相互通信:RPC方案,远程调用框架
分布式的缺点:事务和缓存的处理问题
2.集群和分布式概述

a)  分布式:将不同的业务分布在不同的服务器,web应用和 数据库服务分开

1. 集群分类

a)  数据库集群,应用集群,功能集群,Tomcat集群

1. 集群的两大特性

a)  可扩展性

            i.     可以动态的添加新的服务器,增强集群的性能

b)  高可用性

            i.     集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出错的服务实体恢复到另一个服务实体的功能增强了应用的可用性,当访问的服务器挂了时，集群要有能力找可以正常使用额服务器继续提供服务器。

1. 集群的两大能力

a)  负载均衡

            i.     负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。

           ii.     负载均衡的策略:轮询,权重,随机

b)  错误恢复

            i.     由于某种原因，执行某个任务的资源出现故障，另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。当访问的服务器挂了时，集群要有能力找可以正常使用额服务器继续提供服务器.

           ii.     注意: 负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图（信息上下文）必须是一样的

         iii.     集群和分布式的相同点和不同点

1. 相同点:都是用来处理高并发的,需要多台服务器的支持,( 一般在一个系统中同时存在分布式和集群.)
2. 不同点:分布式中不同的服务器处理不同的业务,而集群是多个服务器处理同一个业务.
   
   
   
   
3. Redis集群方案的选择

a)  为什么选择使用Redis做集群

            i.     Redis集群可防止单点故障

           ii.     处理高并发问题

         iii.     处理大量数据,数据太多,一台服务器的内存搞不定

b)  Redis集群方案一:主从复制,主机或者从挂了就会有数据的丢失

            i.     原理：

从服务器连接主服务器，发送SYNC命令；

主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；

主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

                  ii.      主从同步,读写分离

好处:主服务器向从服务器复制数据,从服务器用来进行读的操作,主服务器用来进行写的操作,这样可减小对主服务器的读的操作的压力

坏处: Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。只解决高并发.

a)  Redis集群方案二:Redis-Cluster集群

a)  从redis 3.0之后版本支持redis-cluster集群，它是Redis官方提出的解决方案，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。其redis-cluster架构图如下：

 

客户端与 redis 节点直连,不需要中间 proxy 层.客户端不需要连接集群所有节点连接集群中任何一个可用节点即可。

b)  所有的 redis 节点彼此互联(PING-PONG 机制),内部使用二进制协议优化传输速度和带宽.

c)  每个Redis服务的节点上都存储不同的内容,也包含主节点和从节点,主节点挂了,从节点填充上去,解决单点故障

                 i.     每个节点里面都有一个插槽,通过一种算法来存储数据,还有一个cluster插件, 当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

b)  集群方案三:哨兵模式

a)  当主服务器挂掉之后,我们可以进行手动配置将从服务器自动设置升级为主服务器.

b)       优点：

哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

主从可以自动切换，系统更健壮，可用性更高。

c)        缺点：

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂

d)   

7.集群环境的搭建(这里对方案二集群环境搭建的介绍)

   a) 需求:六台Redis的服务器,伪集群

   b)  六个Redis的服务器实例和六个Redis的端口

   c) ruby语言运行环境的搭建,ruby脚本来实现集群搭建,先安装ruby脚本运行环境,再安装(rubyGems)的驱动rubygems,

   d) rubyGems安装完毕之后,cmd运行setup.rb

   e) 再用rubyGems安装Redis(命令: gem install redis)

f)      启动每个Redis服务,将redis-trib.rb文件拷贝到其中一个Redis节点里面
                  执行命令

 redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384

输入yes回车命令

看集群是否配置成功.

8.Redis集群环境的测试

         a)命令行测试Redis-cli

使用Redis客户端Redis-cli.exe来查看数据记录数，以及集群相关信息

命令 redis-cli –c –h ”地址” –p "端口号" ;  c 表示集群

         b) 查看集群的信息，命令：cluster info

         c)  查看主从服务器命令

                  先用命令 redis-cli –c –h ”地址” –p "端口号" 找到集群

                  然后运行info replication查看是主服务器还是从服务器.

         d)     存值测试

9.Jedis代码测试Redis集群是否集成完毕

@Test

    public void testCluster() throws IOException, InterruptedException {

        Set<HostAndPort> nodes = new HashSet<>();

        nodes.add(new HostAndPort("127.0.0.1", 6379));

        nodes.add(new HostAndPort("127.0.0.1", 6380));

        nodes.add(new HostAndPort("127.0.0.1", 6381));

        nodes.add(new HostAndPort("127.0.0.1", 6382));

        nodes.add(new HostAndPort("127.0.0.1", 6383));

        nodes.add(new HostAndPort("127.0.0.1", 6384));

        JedisCluster cluster = new JedisCluster(nodes);

        try {

            String res = cluster.get("key值");

            System.out.println(res);

//            cluster.quit();

        } catch (Exception e) {

            e.printStackTrace();

//            cluster.quit();

        }

    }

}