1. 主从部署
主从复制主要⽤于实现数据的冗余备份和读分担，并不是真正的高可用。
一个主节点，一个或者多个从节点。
同步数据的方向：单向 ，只能主节点到从节点。
作用：
- 数据冗余：除了数据持久化之外的一种数据冗余方式。
- 故障恢复：主节点出现问题，从节点提供服务。可以手动切换。
- 负载均衡：主节点写，从节点读。非常适合写少读多的场景。
- 高可用的基石：主从复制是哨兵模式和集群能使用的基础。
缺点：
- 主节点同步数据到从节点，存在延时，特别是从节点越来越多，延时会越严重。
- 主节点宕机，从节点要手动切换到主节点，不能自动切换。
2.哨兵部署（Sentinel）
原理：哨兵模式是通过独立的哨兵节点上的哨兵进程来实现的。哨兵进程会监控主节点和从节点的状态。当哨兵领导者通过心跳监控主观的判断主节点是否可用，并且当超过选举个数的哨兵节点也判断认为该主节点存在问题，大部分哨兵节点都同意下线，该主节点就客观下线了。哨兵领导者会执行故障转移，从当前的从节点中选出一个新的主节点，并将其他节点切换到新的主节点，为系统提供服务。哨兵节点会通知客户端新的主节点位置，使其能与新的主节点建立连接。如果是从节点出现故障，哨兵节点会让他先下线，等恢复正常了，再重新加入集群。
确认主节点：
- 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应 的从节点
- 选择从节点优先级最⾼的
- 选择复制偏移量最⼤，此指复制最完整的从节点
- 当主节点出现故障， 由领导者负责处理主节点的故障转移。
建议：
- 哨兵节点应该是多个，奇数个，构成哨兵集群，保证高可用
- 哨兵节点的配置是一致的
哨兵模式必不能保证数据完全不丢失，主要有以下几点原因：
- 主节点的故障转移时需要时间的。
- 从节点全部故障或者在故障转移之前都失联，将没有从节点升到主节点。
3. 集群部署
Redis集群部署的最小架构是3个主节点+3个从节点，每个主节点至少一个从节点。整个数据集会被自动分割到多个节点，每个主节点都可以对外提供读服务和写服务。每个键通过CRC16算法对16384个哈希槽取模------CRC16(KEY)%16384 来确定其所属槽。
客户端访问任意节点，如果计算出是属于本节点的就直接处理，不是的话，返回MOVED 重定向，客户端再去连接正确的节点。当然客户端也可以缓存槽位分布表，减少定向次数。
节点A向节点B发送心跳检测，超时没有收到响应，就会标记节点B疑似下线（PFAIL），多数的主节点确认后，就可以标记为已下线（FAIL）。
主节点故障，从节点等待延时时间，发起选举，获取多数投票就可以成为新的主节点，接管原来主节点的槽，更新集群的配置。
4. Redis的核心数据结构
1）String------底层是动态字符串
常用的场景：计数（自增 INCR 、自减DECR）
分布式锁： SET product:10001 true ex 10 nx //nx保证互斥，只有一个客户端能设置成功，PX设置超时防止死锁。释放锁之前（DEL product:10001），要先检查是否是当前锁，避免误删其他客户端的锁。
2）list------压缩链表、双向链表
常用的数据结构：
- Stack(栈) = LPUSH + LPOP
- Queue(队列）= LPUSH + RPOP
- Blocking MQ(阻塞队列）= LPUSH + BRPOP
常见应用场景：
签到列表、简化版的MQ
注意点：
- 大KEY
- 因为底层是双向链表，所以头尾操作方便，中间通过索引获取值性能差。
3）Hash------哈希表、压缩列表
常用2种：一个是放JSON 二是HASH分字段存储
比如余额表操作，因为变化的是余额，用第二种方式就会更方便。
注意点：过期的功能只能用在key上。
4）set------哈希表、整数数组
存放不重复的集合。适合全局去重的操作以及抽奖的场景。
5）zset------压缩列表、跳表
有序集合，适合排行榜的场景。
跳表：将有序链表改造为支持"折半查找"算法，可以进行快速的增删查找操作。