持久化
- 什么是持久化：redis所有的数据保持在内存中，对数据的更新将异步的保存在磁盘上
- 持久化方式：快照（MySQL Dump，Redis RDB），写日志（MySQL Binlog,Hbase HLog，Redis AOF）
RDB
-
触发机制：
-
save（同步）
文件策略：若存在旧RDB文件，新替换旧
复杂度：O(N)
-
bgsave（异步）
-
自动
-
-
save命令
- bgsave命令
- save比较bgsave
-
触发机制：
全量复制
debug reload
shutdown
-
总结：
RDB是Redis内存到硬盘的快照，用于持久化
save通常会阻塞Redis
bgsave不会阻塞Redis，但是会fork新进程
save自动配置满足任一就会被执行
有些触发机制不容忽视
AOF
- RDB存在哪些问题？
- 耗时，耗性能
- 不可控，丢失数据
- AOF运行原理
- 三种策略：
- always
- everysec
- no
- always策略
- everysec策略（默认值）
- no策略
- 比较
- AOF重写：减少硬盘占用量，加速恢复速度
-
AOF重写两种方式：
- bgrewriteaof命令
- 重写配置
-
AOF重写流程
比较
主从复制
-
主从复制的作用：作为数据副本（如果一个Redis节点宕机了，另一个Redis节点可以继续工作，相当于一个备份），扩展读性能
-
说明：
一个master可以有多个slave
一个slave只能有一个master
数据流向是单向的，master到slave
实现方式
- 命令方式
- 取消复制后再次复制一个节点，这时从节点的数据会被清除
- 修改配置
- 比较
- 全量复制：从节点复制主节点已有的数据并且开始同步主节点的数据
-
全量复制的开销：
bgsave的时间
RDB文件网络传输时间
从节点清空数据时间
从节点加载RDB的时间
可能的AOF重写时间
-
部分复制
主从结构故障转移
- slave宕机：
- master宕机：
读写分离
- 读流量分摊到从节点
- 可能发生的问题：复制数据延迟，读到过期数据，从节点故障
哨兵与高可用
- 什么是主从复制高可用：主从复制，master挂掉后需要收工操作，写能力和存储能力受限（主从复制只是备份，单节点存储能力）
- 哨兵架构
-
Redis sentinel故障转移：
多个sentinel发现并确认master有问题
选举出一个sentinel作为领导
选出一个slave作为master
通知其余slave成为新master的slave
通知客户端主从变化
等待老的master复活成为新的master的slave
-
在jedis中的使用
JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName,sentinelSet,poolConfig,timeout);
Jedis jedis = null;
try{
jedis = sentinelPool.getResource();
//jedis command
}catch(Exception e){
logger.error(e.getMessage(),e);
}finally{
if(jedis != null){
jedis.close();
}
}
- 安装配置：
- 配置开启主从节点
- 配置开启sentinel监控主节点，sentinel是特殊的redis
- 实际应该多台机器
- 详细配置节点
- sentinel默认端口是26379，形成如下的安装配置（其实就是单机多实例）
- 客户端连接
- sentinel地址集合
- masterName
- 不是代理模式
- 实现原理
总结
集群
数据分区
- 顺序分布
- 哈希分布
- 比较
分布式架构
- 分布式情况下，节点之间是可以互相通信的，每个节点都负责读写
