1.前期回顾
前面说了redis的主从复制可以保证数据容灾，就是主节点坏了，从节点中也保存着完整数据，不会造成数据丢失的情况；
然后又说了哨兵模式(sentinel)，这个是在主从复制的基础上增强了一下，当主节点坏了，从节点中就会选举出来一个当作主节点，继续对外提供服务，而不需要人为的去操作，这叫做保证自动故障转移；
注意，哨兵的个数之前只配置了一个，其实可以配置多个，防止一个哨兵由于网络延迟等原因误判了；多个哨兵的时候超过半数的哨兵觉得主节点挂了那么就是主节点挂了，才会选举新的主节点；
哨兵模式下，使用springboot去连接redis的时候，连接的哨兵节点哦！因为此时主节点的ip是不确定的，有兴趣的可以自己测试；
2. redis单机版的缺陷
哨兵模式下，其实就可以适用于绝大多数公司的场景了，毕竟也没有那么多的用户
但是对于比较大的公司，用户数量贼多，然后并发量贼高，然后redis主节点只有一个，一下子就能将redis主节点打趴下了，然后哨兵重新推选新的主节点刚刚站起来，然后又一下子被打趴下了，不断的重复直至所有的redis节点都被打趴下了，最终所有请求都来到数据库，数据库也挂了....这也就是单节点并发压力的问题
而且只有单节点的话，redis持久化数据越来越多，直至最后持久化了TB级别的数据，其实是比较夸张的
所以我们更希望能有多个redis主节点服务器可以提供服务，每个主节点有从节点，而且还有有类似之前说的哨兵机制，那么持久化的数据能大概均分到各个服务器，而且可用性也有，单节点并发和磁盘压力也会大大的缓解
3 redis集群（cluster）说明
集群就类似下面这个图，集群中三个节点提供服务，三个节点都是主节点，同时三个节点都有从节点；
在集群模式下，主从节点自动的会有哨兵功能，即主节点挂了，从节点就会顶上；
下面的这种，redis持久化的数据可以大概的平均分成三份，分别存到每个节点中，所以，每个节点中存的数据是不一样的！！！
那么问题来了，一个集群中有那么多节点，我们如果要向里面存数据，那么怎么选择节点呢？ 只有先选择了节点然后才能往这个节点中存入数据
例如set a 1，那么应该怎么向集群中存呢？
原理：类似于java中的hashmap，如果我有一个容量为16383的数组，分成三份，上面节点node-1 中管理的是0-5461的位置，node-2管理的是5462-10922的位置，然后node-3管理的是10923-16383的位置
然后a首先经过hash再对16383取余，得到的结果肯定是在0-16383之间的某个数字（在redis中就叫做CRC16算法），然后根据这个结果所在的位置就能确定放在哪个节点了
比如上面的set a 1 ，假设a经过CRC16算法得到的结果是7000，那就肯定丢到node-2里面去了，还是比较容易的，并且相同的键，经过CRC16算法，每次都是一样的，所以当使用get a 的时候，a经过CRC16之后，结果也是7000，也就到node-2中去取数据了
这实现了存的时候在哪个节点存，取得时候肯定就在那个节点去取；
4 redis在linux中简单使用
之前单机版都是windows中配置的，现在我们在linux中玩一下
4.1 安装redis源码
redis中文网 根据提示下载redis源码，我把安装命令放在下面，注意下载你想要的版本；
#下载，解压，编译: wget .tar.gz tar xzf redis-5.0.4.tar.gz cd redis-5.0.4 make #二进制文件是编译完成后在src目录下. 运行如下: src/redis-server #你能使用Redis的内置客户端进行进行redis代码的编写: $ src/redis-cli redis> set foo bar OK redis> get foo "bar"