个人记录，谨慎参考，欢迎指正，谢谢
针对redis的使用过程中，不断地遇到问题，redis也在不断发展
目前接触到的主要策略有：主从备份、哨兵机制、搭建集群。
一、 配置多个redis服务
Redis安装后，默认安装到
/usr/local/bin目录下，端口默认6379
安装多个redis服务最简单粗暴的就是复制这个bin。
步骤：
- 找一个自己喜欢的路径(理论上凭喜好，注意避开具有特殊功能的目录)，新建一个redis文件夹
mkdir redis - 为了方便管理，可以另外新建若干个文件夹，以端口号命名，用来区分不同的redis，
- 例如
mkdir 6380 - 将bin复制进去
cp /usr/local/bin/* redis/6380, - 修改端口号：
vi redis.conf替换:%s/6379/6380/g - 保存退出
配置集体启动/关闭
当服务多了起来后，包括后期搭建集群，为了方便统一开关服务，我们可以配置集群启动：
- 在保存不同端口服务的redis目录下，新建一个文件
vi startRedis.sh -
将所有redis开启步骤编写进去： 开启关闭
- 关闭同上，注意端口
- 保存并退出文档，文件名没有加粗 ，此时还只是个文件，并不能起到服务的作用
- 提高开启和关闭的权限，使它成为服务
chmod +x start.sh(文件全名) - 成为服务后，文件名就成粗体 ，就可以通过
./start.sh统一开启服务了，如图：
打印日志 - 使用命令查看是否开启成功
ps aux|grep redis
三个服务都已经启动
二、 主从备份
Redis的持久化保证了即使redis服务重启也会丢失数据 ，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但当redis服务器的硬盘损坏了可能会导致数据丢失 ，如果通过redis的主从复制机制可以避免这种单点故障。
相较于普通的单节点使用，主从配置最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。
1. 配置
进入要作为从节点redis的bin目录，打开redis.conf文件，
找到#slaveof <masterip> <masterport> 修改为slaveof 主节点IP 主节点端口。
配置完毕后重启所有redis服务，查询节点状态后如图：
2. 测试
存入字段，显示存入成功接下来打开rdm，查看从节点是否成功备份
主从配置成功
3. 优点
- 高可靠性，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题。
- 读写分离策略，从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。
4. 缺点
故障恢复复杂，当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其他从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐。
三、 哨兵机制
由若干Sentinel 节点组成的分布式集群，可以实现故障发现，故障自动转移，配置中心和客户端通知。Redis Sentinel 的节点数量要满足
2n + 1（n>=1）的奇数个。
redis的哨兵机制是从redis2.8开始支持。
redis的sentinel系统用于管理多个redis服务器，该系统主要执行三个任务：监控、提醒、自动故障转移。
1、监控（Monitoring）：Redis Sentinel实时监控主服务器和从服务器运行状态，并且实现自动切换。
2、提醒（Notification）：当被监控的某个Redis服务器出现问题时，Redis Sentinel可以向系统管理员发送通知，也可以通过API向其他程序发送通知。
3、自动故障转移（Automatic failover）：当一个主服务器不能正常工作时，Redis Sentinel可以将一个从服务器升级为主服务器，并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接Redis服务器时，Redis Sentinel会告之新的主服务器地址和端口。
1. 配置
哨兵模式需要配置的仅仅是哨兵系统
在主从备份服务文件夹（redis）的目录下新建一个目录
mkdir redis-sentinel（方便管理）将redis（主从服务）三个服务分别复制过来
例如：cp –rf redis/6379 redis-sentinel/26379进入redis-sentinel目录删除每一个的redis.conf
rm -rf 26379/redis.conf从redis-4.0.11目录中把sentinel.conf文件复制到每一个哨兵服务
修改每一个sentinel.conf：
a)# protected-mode no取消注释，改为protected-mode no
b)sentinel monitor mymaster 192.168.11.128 6379 2其中地址改为主redis节点地址，2表示的是当两个或两个以上的哨兵认为主节点挂掉，进行failover操作
c) 加入daemonize yes用来后台启动哨兵服务，避免服务阻塞启动哨兵服务（单个） 进入26379目录，执行命令
./redis-sentinel sentinel.conf
这里我们也可以把哨兵服务的启动集合到一个文件里面注册成服务，同多个redis服务
2. 启动测试
3. 模拟错误
通过命令杀掉主节点进程
随便进入一个从节点，查看信息
此时，6380身份还是从节点，但是主节点变成了6381，哨兵机制配置成功
4. 优点
部署简单
能够解决 Redis 主从模式下的高可用切换问题
可以实现一套 Sentinel 监控一组 Redis 数据节点或多组数据节点
5. 缺点
部署相对 Redis 主从模式要复杂一些，原理理解更繁琐
资源浪费，Redis 数据节点中 slave 节点作为备份节点不提供服务
不能解决读写分离问题，实现起来相对复杂
Redis Sentinel 主要是针对 Redis 数据节点中的主节点的高可用切换，对 Redis 的数据节点做失败判定分为主观下线和客观下线两种，对于 Redis 的从节点有对节点做主观下线操作，并不执行故障转移。
四、 集群模式 redis-cluster
Redis Cluster 是社区版推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。
Redis集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
1. 搭建集群前的准备
在local目录下创建文件夹 redis-cluster
把端口为6379的bin实例拷贝到redis-cluster文件夹下，并改名（随意）1-7001
切换到redis-cluster/1-7001目录下，删除dump.rdb，一个干净的redis是没有它的
修改端口号，
vi redis.conf快捷方式:%s/6379/7001/g搭建集群需要开启集群设置 把
cluster-enabled yes的注释打开打开
bind 127.0.0.1的注释并修改为虚拟机ip退出目录到redis-cluster目录下，拷贝5次这个实例并命名，可以配置集群启动
修改每一个实例的端口 快捷方式
:%s/6379/7001/g-
启动redis，查看进程如下图
启动成功
现在的集群只是空有其表，还需要将他们连接起来
2. 搭建集群所需环境
安装ruby
ruby是一种面向对象程序设计的脚本语言，redis-cluster的搭建需要使用到官方提供的ruby脚本，所以搭建前需要安装ruby环境
执行命令
`yum –y install ruby`
`yum –y install rubygems`
安装ruby脚本---redis-4.1.1.gem 并将其上传到Linux。
注意：这里的版本要求不低于redis版本。Redis5.0以后就不再需要ruby。
安装redis-4.1.1.gem，执行命令 gem install redis-4.1.1.gem
这时候，可能就会报错了
如果有，请跳往 --> 解决办法
3. 正式操作集群配置
进入redis-4.0.11解压目录下，打开src文件夹，有一个redis-trib.rb 是个粗体脚本文件，后缀是.rb就是ruby的缩写
拷贝redis-trib.rb到集群目录下
-
运行脚本
./redis-trib.rb create --replicas 1 192.168.5.230:7001 192.168.5.230:7002 192.168.5.230:7003 192.168.5.230:7004 192.168.5.230:7005 192.168.5.230:7006 'replicas 1' 表示每个redis服务只有1台备份机
第三步注意参数，如果多写、少写或者写错ip和端口，那么集群基本需要重新搭建
- 连接集群
集群的特点就是每一个节点都可以作为入口，备份节点也可以作为主机。Redis提供了客户端，那么连接集群命令参照 ./1-7001/redis-cli –h “192.168.5.230” –p 7001 -c
至此，集群搭建并连接成功。
4. 模拟错误
-
进入集群，查看数据存储的节点，强制杀死该节点
模拟错误 - 再次进入集群，尝试查询数据
再次查询
查询结果成功，发现数据的存储分布被动态调整。
5. 优点
无中心架构。
数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除。
高可用性：部分节点不可用时，能够实现故障自动 failover，集群仍可用。
6. 缺点
实现复杂。
节点会因为某些原因发生阻塞（阻塞时间大于 clutser-node-timeout），被判断下线，这种 failover 是没有必要的。
数据通过异步复制，不保证数据的强一致性。
