目录
一、Redis主从复制
1 Redis主从复制简介
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
Master以写为主，Slave以读为主。
主从复制的作用：
1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是
Redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只是用一台Redis是万万不能的，原因如下：
1. 从结构上，单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2. 从容量上，单个redis服务器内存容量有限，就算一台Redis服务器内容容量为256G，也不能将所有内存用做Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
2 Redis主从复制-一主多从
搭建一主二从的Redis服务器
环境搭建
1. 在同一台虚拟机上配置一主二从Redis服务器，由于单台机器，同一个端口只允许一个进程占用，所以需要修改其他两台Redis的端口。
2. 在/usr/local/myredis文件夹下，新创建三个redis的配置文件，分别为redis6379.conf、
redis6380.conf、redis6381.conf，由文件名可知，redis的端口号分别为6379、6380、6381。
创建出3个空文件，redis.conf是原有的配置文件。
3. 在三个配置文件写入内容
可以通过include /usr/local/myredis/redis.conf将公共基础配置直接引入文件。
将include /usr/local/myredis/redis.conf统一添加到这三个文件中
在各个文件中，添加对应的pidfile、port、dbfilename
如：
redis6379.conf中添加
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
redis6380.conf中添加
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
redis6381.conf中添加
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
4. 通过不同的redis.conf文件，分别启动3个redis服务
./redis-server /usr/local/myredis/redis6379.conf
./redis-server /usr/local/myredis/redis6380.conf
./redis-server /usr/local/myredis/redis6381.conf
通过ps -ef | grep redis命令查看redis服务，3个服务均已启动
5. 在redis客户端中，通过info replication命令可以查看Redis服务器当前状态
可以给redis-cli命令添加-p参数，来指定链接哪个服务器
./redis-cli -p 6379
./redis-cli -p 6380
./redis-cli -p 6381
所有的服务器目前都是master
6. 配从（6380、6381）不配主（6379）
slaveof ip port成为某个实例的从服务器。
在从机6380和6381上执行：slaveof 127.0.0.1 6379在主库（6379）中再次执行info replication
有两个从库，分别为6380和6381。
7. 在主库（6379）中写数据，可以在从库（6380、6381）中读取到。
注意：
- 在从库中进行写操作，会报错。
- 由于该主从复制在同一台虚拟机上搭建，所以需要修改端口号，如果在多台服务器上搭建主从复制，则需要修改相对应的ip。
- 如果在多台服务器上搭建主从复制，一定要开放远程链接。
3 Redis主从复制-复制原理
3.1 主从复制的一些问题
1. 如果Master断开（宕机），Slave依然连接着Master，可以正常使用读操作，但是没有写操作。如果Master恢复正常，Slave依旧可以直接获取Master写的信息。
2. 如果Slave断开（宕机），当该Slave重启成功，则会变为Master，需要通过slaveof 恢复成Slave，只要变为Slave，立刻可以从Master同步所有数据。
3.2 复制原理
- Slave启动成功连接到Master后会主动发送一个同步（sync）命令。
- Master接到Slave的命令，把Master数据进行持久化，把rdb文件发送给Slave，Slave拿到rdb进行读取。
- 每次Master进行写操作之后，会和Slave进行数据同步。
- 全量复制：一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。
- 增量复制：指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
3.3 薪火相传
上一个Slave（从机）是下一个Slave（从机）的Master（主机）。
优点：Slave同样可以接收其他Slave的连接和同步请求，那么该Slave作为了链条中下一个的Master, 可以有效减轻Master的压力，去中心化降低风险。
缺点：一旦某个Slave宕机，后面的Slave都无法备份。
注意：
- 也是通过slaveof ip port命令修改Master。
- 中途变更转向:会清除之前的数据，重新建立拷贝最新的。
- Slave6380本质上仍然是从库，只能读、不能写。
3.4 反客为主
当一个Master宕机后，后面的Slave可以立刻升为Master，其后面的Slave不用做任何修改。
通过slaveof no one 将Slave变为Master。
4 Redis主从复制-哨兵模式（Sentinel）
反客为主的自动版，能够后台监控Master是否故障，如果故障了，根据投票数自动将Slave转换为
Master。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
4.1 哨兵模式的使用
1. 将服务器调整为一主多从（6379带6380、6381）。
2. 在/usr/local/myredis文件夹下创建sentinel.conf文件（名字一定不能错）。
3. 配置哨兵，sentinel.conf添加内容
sentinel monitor myredis 127.0.0.1 6379 1
其中：myredis 为监控对象起的服务器名称（随意），1代表至少有1个哨兵投票同意迁移
如果Master存在密码，需要配置sentinel auth-pass 服务器名 密码
sentinel auth-pass myredis 123456
4. 启动哨兵，在/usr/local/bin/文件夹下执行./redis-sentinel /usr/local/myredis/sentinel.conf命
令。
5. 模拟Master宕机，哨兵会切换Master
- 通过kill命令关闭Master（6379）
- 等待一段时间，哨兵窗口就会输出信息
根据窗口信息可知，Master由6379转换为6381，进入6381客户端执行info replication
6. 重新启动6379服务器后，自动转换为Slave。
4.2 复制延迟
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，Slave机器数量的增加，会使延迟问题会更加严重。
六、Redis集群
1 Redis集群简介
1.1 Redis集群（RedisCluster）
RedisCluster实现了对Redis的水平扩容，即启动N个Redis节点，将整个数据库分布存储在这N个节点当中，每个节点存储总数据的1/N。
RedisCluster通过分区（partition）来提供一定程度的可用性（availability）：即集群有一部分节点失效或者无法进行通讯，集群也可以继续处理命令。
Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接，用来交换彼此的信息。
为了使得集群在一部分节点宕机或者无法与集群的大多数节点进行通讯的情况下， 仍然可以正常运作，Redis 集群对节点使用了主从复制功能。
2 Redis集群搭建
1. 删除持久化数据，aof、dump。
2. 创建6个实例，即在/usr/local/myredis文件夹下分别创建6379、6380、6381、6389、6390、
6391的conf。
3. 在redis.conf中关闭appendonly。
4. 在不同的conf文件中，配置对应的内容
- 可以通过include /usr/local/myredis/redis.conf将公共基础配置直接引入文件。将include /usr/local/myredis/redis.conf统一添加到这三个文件中
- 在各个文件中，添加对应的pidfile、port、dbfilename、cluster-enabled（是否打开集群）、cluster-config-file（设定节点配置文件名）、cluster-node-timeout （设置节点失联时间，超过该时间（毫秒），集群自动进行主从切换）
- 如：
- redis6379.conf中添加
- pidfile /var/run/redis_6379.pid
- port 6379
- dbfilename dump6379.rdb
- cluster-enabled yes
- cluster-config-file nodes-6379.conf
- cluster-node-timeout 15000
将其他文件按照相同规则创建出来。
5. 启动该6个redis，并确保是否全部生成nodes-xxxx.conf文件。（启动之前务必保证redis服务支持远程连接）
6. 进入redis安装目录下的src文件夹
7. 在该文件夹下执行命令
redis-cli --cluster create --cluster-replicas 1 192.168.56.31:6379
192.168.56.31:6380 192.168.56.31:6381 192.168.56.31:6389 192.168.56.31:6390
192.168.56.31:6391此处使用真实ip地址，-replicas 1代表采用最简单的方式配置集群，一台主机，一台从机。
replicas表示每个master需要有几个slave。
执行命令后，redis提供推荐的主从配置建议，执行同意。
集群创建成功。
8. 通过./redis-cli -c -p 6379可连接至集群（由于所有节点相通，任意端口号均可）
在redis客户端中执行cluster nodes查看节点状态。
3 Redis集群操作
3.1 Slot
一个 Redis 集群包含 16384 个哈希槽（hash slot），每个键都属于这 16384 个哈希槽的其中一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key的 CRC16 校验和 。
集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个节点， 其中：
- 节点 1 负责处理 0 号至 5500 号哈希槽。
- 节点 2 负责处理 5501 号至 11000 号哈希槽。
- 节点 3 负责处理 11001 号至 16384 号哈希槽。
3.2 命令执行
set k1 v1
根据k1计算出的槽值进行切换节点，并存入数据。
不在一个slot下的键值，是不能使用mget、mset等多建操作。
可以通过{}来定义组的概念，从而是key中{}内相同内容的键值对放到同一个slot中
mset k1{test} v1 k2{test} v2 k3{test} v3
3.3 故障恢复
1. 关闭6379服务器，进入redis-cli执行cluster nodes
6379服务器fail，6390成为了新的master
2. 重新启动6379服务器，再次查看，6379成为了Slave
