目录
前言
本文是我借鉴网上很多大神的总结，并结合自己在项目中的使用归纳出的。如果发现有的地方与其他大神的文章有类似的地方，绝不是偶然。。。。
下面放上一些借鉴的文章链接：
https://new.qq.com/omn/20180126/20180126G00THE.html
http://www.cnblogs.com/yu421/p/8081544.html
一、Redis使用准备工作
1.1、下载redis
据了解，redis官方只有linux版，没有windows版的。
下面是微软的windows版的redis，linux版的请自行去官网下载：
https://github.com/MSOpenTech/redis/releases
关于redis版本，一般情况下不会有问题，但是以后项目的依赖更新，有可能不兼容老版本的redis。
1.2、安装redis
windows的版本直接解压就可以了
Linux需要先通过解压命令解压：tar zxvf redis-4.0.11.tar.gz
之后会出现一个解压后的文件夹，然后进入里面的src目录下：cd redis-4.0.11/src
然后进行安装命令：make install PREFIX=../
PREFIX后面跟的是想要安装到的路径，可以自定义，这里安装到了src文件的上一级目录
然后看到以下字样证明安装成功了
到这里安装完成
二、Redis部署
2.1、单节点模式部署
单节点模式其实就是直接启动一个redis，一般小项目或者数据量不大的项目才有可能会用到。
直接进入bin文件夹输入命令启动即可：./redis-server
出现下面这张图证明启动成功了
2.2、主从模式部署
2.2.1 主从模式的感念：
主从模式就是N个redis实例，可以是1主N从，也可以N主N从（N主N从则不是严格意义上的主从模式了，后续的集群模式会说到，N主N从就是N+N个redis实例。）
主从模式的一个作用是备份数据，这样当一个节点损坏（指不可恢复的硬件损坏）时，数据因为有备份，可以方便恢复。
另一个作用是负载均衡，所有客户端都访问一个节点肯定会影响Redis工作效率，有了主从以后，查询操作就可以通过查询从节点来完成。
2.2.2 主从模式的理解：
这里引用网上大神总结的内容，大神总结的非常到位
1.一个Master可以有多个Slaves，可以是1主N从。
2.默认配置下，master节点可以进行读和写，slave节点只能进行读操作，写操作被禁止（readonly）。
3.不要修改配置让slave节点支持写操作，没有意义，原因一，写入的数据不会被同步到其他节点；原因二，当master节点修改同一条数据后，slave节点的数据会被覆盖掉。
4.slave节点挂了不影响其他slave节点的读和master节点的读和写，重新启动后会将数据从master节点同步过来。
5.master节点挂了以后，不影响slave节点的读，Redis将不再提供写服务，master节点启动后Redis将重新对外提供写服务。
6.特别说明：该种模式下，master节点挂了以后，slave不会竞选成为master。
对有密码的情况说明一下，当master节点设置密码时：
客户端访问master需要密码，启动slave需要密码，在配置中进行配置即可。客户端访问slave不需要密码
综上，客户端只需要配置一个密码参数，而redis配置文件中需要配置两个参数。
分别是：
Redis服务端配置文件：
masterauth "chrdw,hdhxt!"
requirepass "chrdw,hdhxt!"
客户端配置文件：
jedis-cluster.password=chrdw,hdhxt!
注意没有引号。
2.2.3 主从模式的缺点：
主从模式的缺点其实从上面的描述中可以得出：
master节点挂了以后，redis就不能对外提供写服务了，因为剩下的slave不能成为master
这个缺点影响是很大的，尤其是对生产环境来说，是一刻都不能停止服务的，所以一般的生产坏境是不会单单只有主从模式的。所以有了下面的sentinel模式。
2.2.4 配置主从模式：
首先复制3份redis目录下的redis.conf文件，分别命名：
redis6379.conf
redis6380.conf
redis6381.conf
其中6379为master，剩下两个为slave,并对3个文件进行配置:
bind 127.0.0.1
port=6380
daemonize yes
slaveof 127.0.0.1 6379
master的话只需要添加前三条即可
daemonize yes表示后台启动，原值为no
然后启动：
redis-server.exe redis6379.conf
redis-server.exe redis6380.conf
redis-server.exe redis6381.conf
打开master客户端界面查看状态
redis-cli.exe -h 127.0.0.1 -p 6379
info replication
可以看到master下有两个slave，证明启动成功
关闭redis
可以通过命令：ps -ef|grep redis 来查看后台运行的redis进程
可以通过：./redis-cli -h 127.0.0.1 -p 6380 shutdown 来指定要关闭的redis
2.3、哨兵模式部署
sentinel的中文含义是哨兵、守卫。也就是说既然主从模式中，当master节点挂了以后，slave节点不能主动选举一个master节点出来，那么我就安排一个或多个sentinel来做这件事，当sentinel发现master节点挂了以后，sentinel就会从slave中重新选举一个master。
2.3.1 对哨兵模式(Sentinel)的理解：
1.sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义。
2.当master节点挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master。
3.当master节点重新启动后，它将不再是master，而是作为slave接收新的master节点的同步数据
4.sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群。
5.当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心。
6.一个sentinel或sentinel集群可以管理多个主从Redis。
7.sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了。
8.sentinel监控的Redis集群都会定义一个master名字，这个名字代表Redis集群的master Redis。
当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。
2.3.2 Sentinel模式的好处:
1.如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）。
2.如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。
3.sentinel集群自身也需要多数机制，也就是2个sentinel进程时，挂掉一个另一个就不可用了。
2.3.3 Sentinel集群：
和其他集群不同，你无须设置其他Sentinel的地址，Sentinel进程可以通过发布与订阅来自动发现正在监视相同主实例的其他Sentinel。当一个 Sentinel 发现一个新的 Sentinel 时，它会将新的 Sentinel 添加到一个列表中，这个列表保存了 Sentinel 已知的，监视同一个主服务器的所有其他Sentinel。
Sentinel集群中的Sentinel不会再同一时刻并发去failover（故障切换or故障转移）同一个master，第一个进行failover的Sentinel如果失败了（上文配置的failover-timeout），另外一个才会重新进行failover，以此类推。
当Sentinel将一个slave选举为master并发送SLAVE OF NO ONE后，即使其它的slave还没针对新master重新配置自己，failover也被认为是成功了。
上述过度过程中，若此时重启old master，则redis集群将处于无master状态，此时只能手动修改配置文件，然后重新启动集群.（生产情况下千万不要做如此愚蠢的操作，否则你会导致整个应用集群都启动失败。）
Master-Slave切换后，Sentinel会改写master，slave和sentinel的conf配置文件。
一旦一个Sentinel成功地对一个master进行了failover，它将会把关于master的最新配置通过广播形式通知其它sentinel，其它的Sentinel则更新对应master的配置。
Sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况（这个一般是内存瓶颈，本人进行过Redis的压力测试，Redis在高并发、大数据量的情况下CPU等资源的消耗不高，主要压力是内存。）时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中，就是下面要讲的。
2.3.4 配置Sentinel模式
首先依然是先复制3个哨兵的配置文件
sentinel26379.conf
sentinel26380.conf
sentinel26381.conf
修改其中的配置
port 26379 // 当前Sentinel服务运行的端口
sentinel monitor mymaster 127.0.0.1 6379 2 // 去监视一个名为mymaster的主redis实例，这个主实例的IP地址为本机地址127.0.0.1，端口号为6379，而将这个主实例判断为失效至少需要2个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
sentinel down-after-milliseconds mymaster 5000 // 指定了Sentinel认为Redis实例已经失效所需的毫秒数。当 实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
sentinel parallel-syncs mymaster 1 // 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel failover-timeout mymaster 15000 // 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
daemonize yes //添加此条可以后台启动
然后启动即可：
./redis-server ./config/sentinel26379.conf --sentinel
./redis-server ./config/sentinel26380.conf --sentinel
./redis-server ./config/sentinel26381.conf --sentinel
可以利用redis客户端查看
如图，证明启动成功
2.4、集群模式
2.4.1 对集群模式的理解
cluster的出现是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。对cluster的一些理解：
一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个键都属于这 16384 个哈希槽的其中一个，集群中的每个节点负责处理一部分哈希槽。
例如一个集群有三个主节点，其中：
节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。
这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。例如：如果用户将新节点 D 添加到集群中， 那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。
如果用户要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。
这里需要注意的是，集群如果是5主5从，主节点也是16384个hash slot，而不会因为主节点的增多slot也增多。我们在分槽的时候，尽量把槽平均分给主节点。因为一个key落在哪个槽里面，是根据key的CRC16值模上16384得出的值来计算的。
2.Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有 1 个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1 个复制品为从节点（slave）。
我们知道集群模式下，1主N从时，当主节点挂掉时，从节点通过心跳监听机制，会竞选成为主节点（这时设置的readonly会失效），所以在部署的时候，主从节点应该部署在不同的机器上，这个时候如果主节点的服务器宕机，从节点竞选成功后会继续承担读写的任务。
3.Redis 集群的节点间通过Gossip协议通信。
4.当前Redis集群不支持NAT环境或者IP，端口重新映射的环境。
cluster这种模式适合数据量巨大的缓存要求，当数据量不是很大使用sentinel即可。
5.以上四条全是网上大神总结的，所以我自己再加一条哈哈哈
2.4.2 集群模式配置
安装ruby环境：
普通Linux下：
yum install ruby
yum install rubygems
gem install redis
Ubuntu下：
Ubuntu的话安装东西都需要获得管理员权限，所以跟Linux下不太一样
sudo apt-get install ruby
sudo apt-get install rubygems
sudo gem install redis
创建6个集群文件：
redis6379.conf
redis6380.conf
redis6381.conf
redis6382.conf
redis6383.conf
redis6384.conf
修改配置：
cluster-enabled yes --开启集群
cluster-config-file nodes-6382.conf --集群配置文件名，每个实例配置的要不同，redis会根据文件名自动新建
这里要注意：
如果你沿用了上面的6379,6380和6391的话，需要注释掉之前的slaveof 127.0.0.1 6379。因为两个模式无法兼容。
启动集群：
进入redis文件夹下的src目录，执行命令：
./redis-trib.rb create --replicas 1 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 127.0.0.1:6379
这里的节点，前三个表示master，后三个表示对应的slave。
如图：
出现以上内容，输入yes，集群就搭建完毕了。
登录任一台redis，执行 info cluster，提示cluster_enabled:1
2.4.3 集群过程
首先redis-trib.rb会以客户端的形式尝试连接所有的节点，并发送PING命令以确定节点能够正常服务。如果有任何节点无法连接，则创建失败。同时发送 INFO 命令获取每个节点的运行ID以及是否开启了集群功能（即cluster_enabled为1）。 准备就绪后集群会向每个节点发送 CLUSTER MEET命令，格式为 CLUSTER MEET ip port，这个命令用来告诉当前节点指定ip和port上在运行的节点也是集群的一部分，从而使得6个节点最终可以归入一个集群。
然后redis-trib.rb会分配主从数据库节点，分配的原则是尽量保证每个主数据库运行在不同的IP地址上，同时每个从数据库和主数据库均不运行在同一IP地址上，以保证系统的容灾能力
3主3从，当1个主故障，大家会给对应的从投票，把从立为主，若没有从数据库可以恢复则redis集群就down了。
总结：
以上就是本文的全部内容，再次感谢网上大神们的总结。欢迎各位留言评论指出本文的不足。谢谢！