redis主要有几种模式：
- 主从模式
- 哨兵模式
- 集群模式
1、 主从模式
基于主从复制的特性，一般有一个主节点，多个从节点，默认是我们可以从主节点写，写入的数据会自动备份到从节点，可以从从节点读取数据。
这样做的好处是，解决单台redis的读请求的瓶颈，可以横向扩容读请求，相当于做到了读请求的负载均衡。
从节点也是可以支持写的，但是不会复制到其他节点，所以我们基本不这么干。
这样做的缺陷是什么：
1.redis的主节点很重要，挂了就没有了，一挂整个集群都有问题。
2.redis写请求很多怎么办？我还不想用消息队列，就想在redis上实现（实际上写请求很多的时候可以适当用消息队列）
2、 哨兵模式
哨兵模式，和主从模式不是互斥的，反而他们一般是同时存在的，为了提高redis的高可用性存在的。如果是单独的主从架构，那么主节点挂了，问题就很大了。一般服务器宕机，停电或者硬件有问题，主节点可能会有问题。有问题的时候，哨兵模式能够帮我们快速地纠正。
哨兵一般是依靠主从模式的，也就是在主从结构上，加上了哨兵模式，一旦主节点宕机，就可以通过几个哨兵选举，产生新的主节点，自动调整过来。哨兵本质上也是redis，但是它不做数据存储，只负责监控，通知，故障转移等工作，一般部署的端口和redis是不一样的，可以选择部署在同一个机器上。
哨兵主要有以下功能：
- 监控：不断检测主从服务器是否正常在工作中
- 通知：可以通过api来通知管理员或者其他应用程序，告知我们redis出现了问题。
- 自动故障转移：如果sentinel系统判断出master down掉了，就是不可用了，就会执行故障转移过程，通过投票选举把slave节点提升成为master节点，其他slave节点成为新master节点的从节点。
- 提供配置：客户端连接sentinels，查询主节点的时候，提供最新的master的地址。
这样一来算是很大程度上解决了单机的高可用问题。
3、 Redis集群（cluster）模式
哨兵只是解决了高可用的问题，但是上面的主从结构还有一个问题，就是写请求只能一台机器，那么如果写请求的并发很大呢？这样的结构明显是不能满足需求的，所以就有了redis cluster结构。
redis cluster可以有很多个mster node，而且每一个master都可以多个slave node。这样的结构可以做读写分离，但是一般不这么干，一般只在master上读，在master上写，slave只是作为数据备份。可以做读写分离，但是一般不这么做而已。，Jedis对cluster的读写分离支持不是很好。
这样也可以满足高可用，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master。
我们只要基于redis cluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用。cluster已经集成了这些能力。
至于能不能读写都在同一个机器上呢？如何保障呢？
其实这就是redis的hash算法啦，可以做到的，这就是redis的hash槽。Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽。每个master节点会负责一部分hash槽，比如三个节点A,B,C。
- A持有0 到 5500号哈希槽
- B持有5501 到 11000 号哈希槽
- C持有11001 到 16384号哈希槽
每个key就会hash后，根据hash值打到对应的机器上，如果删除节点A，那么A的槽就会移动到B，C上，如果添加一个D的话，那么会把A,B，C的部分槽移动到D上面，这样拓展就比较方便了。
4、选择redis cluster 还是 replication + sentinal？
1.如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了。
-
replication，一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了，业务类型主要是读请求比较大，但是写请求比较少。
-
redis cluster，主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，或者读写请求都较大，那么建议就用redis cluster。