主从复制
主节点负责写数据、从节点负责读数据。主节点定期将数据同步到从节点，从而保证数据的一致性。
-
一主一从
-
一主多从
针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定 -
树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。
缺点：
- 主节点出现问题，需手动配置将从节点变为主节点
- 主从复制的主节点写能力单机，能力有限
发布与订阅
redis提供了“发布、订阅”模式的消息机制，其中消息订阅者与发布者不直接通信，发布者向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以接收到消息
Redis哨兵机制（Sentinel）
哨兵机制正式为了解决主从复制的缺点
原理：当主节点出现故障时，由Redis Sentinel自动监控完成故障发现和转移，并通知应用方，实现高可用性
Redis 持久化
支持RDB、AOF。两种持久化机制。持久化可避免进程丢失而造成数据丢失。
- RDB持久化
RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发
手动触发有save和bgsave两命令
save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它
bgsave命令：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;
显然bgsave是对save的优化
优点：1，压缩后的二进制文文件适用于备份、全量复制，用于灾难恢复
2，加载RDB恢复数据远快于AOF方式
缺点：1，无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2，保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题
- AOF持久化
Redis的过期策略
Redis的分布式锁实现
redis常见集群技术
- 客户端分片
- 代理分片
- Redis Cluster
codis
Twemproxy代理分片
应用场景
-
缓存
-
排行榜：redis的有序列表数据结构非常方便。
-
计数器：点赞、访问数。
-
限速器：抢购秒杀，防止用户疯狂点击带来不必要的压力；
-
session共享：session默认保存在服务器中，即当前服务器。如果是集群服务，用户的信息可能在不同机器，所以会造成用户频繁登录。利用redis保存session，无论哪台机器都可以获取session信息。
-
简单的消息队列：除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，比如：到货通知、邮件发送之类的需求