redis的部署方式主要分4种：
- 单机模式
- 主从模式
- 哨兵模式 Sentinel
- 集群模式 Cluster
1、单机模式
单机模式的缺点比较明显，高性能受限于CPU的处理能力；可靠性不强，如果出现宕机，则造成服务不可用，一般情况下不建议使用。
2、主从模式
优点
读写分离：分担服务器压力，从节点可以拓展主库节点的读能力。
高可靠性：主库发生故障，可以进行主备切换，保证服务平稳运行；合理备份，可以解决数据丢失。
缺点
故障恢复复杂：如果没有HA系统，主库故障，先需要手动将一个节点晋升为主节点，再需要通知业务方变更配置，其次让其他从节点复制新主库节点。
主库的写与存储受单机限制。
3、哨兵模式 Sentinel
redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行切换。哨兵集群节点数为奇数个，最少3个。
补充个知识点：HA:High-Availability (高可用性)，是一系列的技术总和，用来减少宕机时间和增加对业务数据的保护。通常用以下公式进行计算，值越大则表明系统宕机时间越少。
MTBF：平均无故障时间
MTTR：平均故障修复时间
缺点：当一台主节点的机子因为某些原因无法进行连接了，哨兵以为它挂了，就重新选举出一台新的机子作为主节点，但后续之前那台机子又恢复过来了，这样整个集群就有了两个主节点了，需要将之前的节点降级为从节点。
以上单实例存redis会存在几个问题：
1）写并发： Redis单实例读写分离可以解决读操作的负载均衡，但对于写操作，仍然是全部落在了master节点上面，在海量数据高并发场景，一个节点写数据容易出现瓶颈，造成master节点的压力上升。
2）海量数据的存储压力： 单实例Redis本质上只有一台Master作为存储，如果面对海量数据的存储，一台Redis的服务器就应付不过来了，而且数据量太大意味着持久化成本高，严重时可能会阻塞服务器，造成服务请求成功率下降，降低服务的稳定性。
针对以上的问题， 提供了较为完善的方案，解决了存储能力受到单机限制，写操作无法负载均衡的问题。
4、集群模式 Cluster
RedisCluster是Redis的分布式解决方案，在3.0版本后推出的方案，有效地解决了Redis分布式的需求。说白了就是把数据分布在不同的节点上，实现了数据的分布式存储，对数据进行分片，采用去中心化的思想，从而解决了海量数据的存储问题。
4.1 数据分区方式：顺序分布
假如现在有100条缓存数据需要缓存到3台服务器上，我们可以将100/3的结果分别存储，
特点：键值业务相关；数据分散，但是容易造成访问倾斜；支持顺序访问；支持批量操作
4.2 数据分区方式：哈希分布
同样是100条数据,有3台服务器,通过自定义一个哈希函数,比如节点取余的方法,余数为0的存在第一台服务器,余数为1的存在第二台服务器,余数为2的存储在第三台服务器.如下所示:
特点：数据分散度高；键值分布与业务无关；不支持顺序访问；支持批量操作。
4.2.1增加节点
集群支持根据实际的硬件资源使用率来进行扩缩容(或者说增减节点node)，上面4.1和4.2的分区方式会带来下面问题。在宕机、增加节点、删除节点场景中，都会出现大批量的数据迁移，而且迁移量都会超过50%。可能会给服务器带来严重的性能问题，如下图展示：
上图分析，总共10个数据通过节点取余hash(key)%/N 的方式分布到3个节点，这时候由于访问量变大，要进行扩容，由 3 个节点变为 4 个节点。我们发现，数据除了标橙色的1和2 没有进行迁移，别的数据都要进行变动，达到了80%，如果这时候并发很高，80%的数据都要从下层节点（比如数据库）获取，会给下层节点造成很大的访问压力，这是不能接受的。即使我们进行翻倍扩容，从3个节点增加到6个节点，其数据迁移也在50%左右。
宕机和删除节点的不在讲述，即等同上图反转过来，右4个节点变为3个节点。
那么如何使得集群中新增节点或者删除节点时，数据迁移量最少？——一致性哈希算法 可以实现。
4.3、一致性哈希算法
假设有一个哈希环，从0到2的32次方，均匀的分成三份，中间存放三个节点，沿着顺时针旋转，从Node1到Node2之间的数据，存放在Node2节点上；从Node2到Node3之间的数据，存放在Node3节点上，依次类推。
假设Node1节点宕机，那么原来Node3到Node1之间的数据这时候改为存放到Node2节点上，Node2到Node3之间数据保持不变，原来Node1到Node2之间的数据还是存放在Node2上，也就是只影响三分之一的数据，节点越多，影响数据越少。
同理，假设增加一个节点，影响的数据甚至更少。当然，实际业务中并不是你节点均匀分布，访问就会很平均，这时候容易造成访问倾斜的问题，这里就会引出虚拟节点的定义。我这里就不做详解了。
4.4、Redis Cluster虚拟槽分区
Redis内部内置了序号 0-16383 个槽位，每个槽位可以用来存储一个数据集合，将这些槽位按顺序分配到集群中的各个节点。每次新的数据到来，会通过哈希函数 CRC16(key) 算出将要存储的槽位下标，然后通过该下标找到前面分配的Redis节点，最后将数据存储到该节点中。
具体情况如下图：（以集群有3个节点为例）
至于为什么Redis不使用一致性哈希分布，而是虚拟槽分区。因为虚拟槽分区虽然没有一致性哈希那么灵活，但是CRC16(key)%16384 已经分布很均匀了，并且对于后面节点增删（按照序号）操作起来也很方便。
集群的搭建一般以 三主三从的模式来搭建。