Redis集群（理论+案例）详细步骤

案例概述

单节点Redis服务器带来的问题

• 单点故障，服务不可用
• 无法处理大量的并发数据请求
• 数据丢失一大灾难

解决方法

• 搭建Redis集群

Redis集群知识点

Redis集群介绍

• Redis集群是一个提供在多个Redis间节点间共享数据的程序集
• Redis集群并不支持处理多个keys的命令，因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误。
• Redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

Redis集群的优势

• 自动分割数据到不同的节点上
• 整个集群的部分节点失败或者不可达的情况下能够继续处理命令

Redis集群的实现方法

• 有客户端分片
• 代理分片
• 服务器端分片

Redis-Cluster数据分片

• Redis集群没有使用一致性hash，而是引入了 哈希槽概念
• Redis集群有16384个哈希槽
• 每个key通过CRC16校验后对16384取模来决定放置槽
• 集群的每个节点负责一部分哈希槽
• 以3个节点组成的集群为例
  • 节点A包含0到5500号哈希槽
  • 节点B包含5501到11000号哈希槽
  • 节点C包含11001到16384号哈希槽
• 支持添加或者删除节点
  • 添加删除节点无需停止服务
  • 例如
    • 如果想新添加个节点D，需要移动节点A，B，C中的部分槽到D上
    • 如果想移除节点A，需要将A中的槽移到B和C节点上，再将没有任何槽的A节点从集群中移除

Redis-Cluster的主从复制模型

• 集群中具有A，B，C三个节点，如果节点B失败了，整个集群就会缺失5501-11000这个范围的槽而不可用
• 为每个节点添加一个从节点A1，B1，C1，整个集群便有三个master节点和三个salve节点组成，在节点B失败后，集群便会选举B1为新的主节点继续服务
• 当B和B1都失败后，集群将不可用

案例拓扑图

部署环境

[root@localhost ~]# systemctl stop firewalld.service 
[root@localhost ~]# setenforce 0
[root@localhost ~]# yum install gcc gcc-c++ y

编译安装Redis

编译安装Redis详细步骤

redis 集群（所有节点操作）

[root@localhost utils]# vim /etc/redis/6379.conf 
  70/ # bind 127.0.0.1  #bind 选项默认监听所有网卡
  89/ protected-mode no  #关闭保护模式
  93/ port 6379
 137/ daemonize yes  #以独立进程启动
 833/  cluster-enabled yes  #开启群集功能
 841/  cluster-config-file nodes-6379.conf #群集名称文件设置
 847/  cluster-node-timeout 15000  #群集超时时间设置
 700/ appendonly yes   #开启aof持久化

[root@localhost utils]# /etc/init.d/redis_6379 restart		#启动

正常启动后，/var/lib/redis/6379/目录下会多出两个文件，
一个是持久化appendonly.aof文件，另外一个是节点首次启动生成的 nodes-6379.conf 配置文件。

仅限master操作

导入key文件

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

安装rvm

tar zvxf rvm-master.tar\(1\).gz 
./install 

执行环境变量

source /etc/profile.d/rvm.sh 

安装Ruby可安装的版本

rvm list known

安装Ruby2.4.1版本

rvm install 2.4.1

使用Ruby2.4.1版本

rvm use 2.4.1

查看当前Ruby2.4.1版本

ruby -v

再次安装Redis

gem install redis

创建集群（单个master操作即可）

redis-cli --cluster create 20.0.0.11:6379 20.0.0.12:6379 20.0.0.21:6379 20.0.0.22:6379 20.0.0.31:6379 20.0.0.32:6379 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 20.0.0.31:6379 to 20.0.0.11:6379
Adding replica 20.0.0.32:6379 to 20.0.0.12:6379
Adding replica 20.0.0.22:6379 to 20.0.0.21:6379
M: 50e82e988dd0964efaf7f4ee4d740e22e7ace531 20.0.0.11:6379
   slots:[0-5460] (5461 slots) master
M: 6350e472daf3bfec2e249007c3d8d5d9d13e550b 20.0.0.12:6379
   slots:[5461-10922] (5462 slots) master
M: 2a0e7ff42a53b44eb6c83b7db018ff1ddecece91 20.0.0.21:6379
   slots:[10923-16383] (5461 slots) master
S: 2a4a67630db894f9e037af9196e14d49b3e2a462 20.0.0.22:6379
   replicates 2a0e7ff42a53b44eb6c83b7db018ff1ddecece91
S: 887059d9e99ad25980eca8183090b61d7ae18fd4 20.0.0.31:6379
   replicates 50e82e988dd0964efaf7f4ee4d740e22e7ace531
S: d12b26294f09c11a004380f4d12fbc03ad19e5f6 20.0.0.32:6379
   replicates 6350e472daf3bfec2e249007c3d8d5d9d13e550b
Can I set the above configuration? (type 'yes' to accept): yes

[root@master1 ~]# redis-cli -c -h 20.0.0.11 		#进入节点