哨兵模式：sentinel，哨兵是redis集群中非常重要的一个组件，主要有以下功能：
集群监控：负责监控redis master 和 slave进程是否正常工作。
消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为警报通知给管理员。
故障转移：如果master node 挂掉了，会自动转移到slave node上。
配置中心：如果故障转移发生了，通知client客户端新的master地址。
哨兵用于实现redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。故障转移时，判断一个master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到分布式选举即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的哨兵通常需要3个实例，来保证自己的健壮性。哨兵+redis主从的部署架构，是不保证数据零丢失的，只能保证redis集群的高可用性。对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
服务端分片
Redis Cluster 是一种服务端Sharding 技术，3.0 版本开始正式提供。采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点将会查询请求发送到正确的节点上执行
方案说明
- 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽（哈希值）区间的数据，默认分配了16384个槽位
- 每份数据分片会存储在多个互为主从的多节点上
- 数据写入先写主节点，再同步到从节点（支持配置为阻塞同步）
- 同一分片多个节点间的数据不保持强一致性
- 读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
- 扩容时需要把旧节点的数据迁移一部分到新节点
在redis cluster 架构下，每个redis要放开两个端口号，比如一个是6379，另外一个就是加1w的端口号，比如16379。
16379 端口号是用来进行节点间通信的，也就是cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。
优点
- 无中心架构，支持动态扩容，对业务透明
- 具备Sentinel的监控和自动Failover(故障转移) 能力
- 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
- 高性能，客户端直连redis服务，免去了proxy代理的损耗
缺点
- 运维也很复杂，数据迁移需要人工干预
- 只能使用0号数据库
- 不支持批量操作（pipeline管道操作）
- 分布式逻辑和存储模块耦合等
客户端分片
Redis Sharding 是redis Cluster 出来之前，业界普遍使用的多Redis 实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。Java redis客户端驱动jedis，支持Redis Sharding功能，即ShardedJedis 以及结合缓存池的ShardedJedisPool
优点
优势在于非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强
缺点
由于sharding 处理放到客户端，规模进一步扩大时给运维带来挑战。
客户端sharding不支持动态增删节点。服务端Redis 实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化
