1. 数据类型支持:
1.1 String: key-value
二进制安全(binary safe),可存储json、JPEG格式字符串
1.2 List:双向链表
实现消息队列最经济方式
1.3 Set:key-(value1,value2,value3)
共同好友列表
1.4 Hash: key-field-value
灵活性、内存开销小
1.5 Sorted Set:基于Set排序存储
亲密度排序
2. 通信协议(https://blog.csdn.net/u014608280/article/details/84586042):
2.1 客户端服务端通信:RESP
2.2 传输层:TCP
3. 高可用架构(https://www.cnblogs.com/bigben0123/p/9564264.html):
3.1 Redis Sentinel:
原理:
Sentinel通过给定配置文件发现Master,从而向Master发送info信息(10s一次)获取其信息及隶属的Slave节点信息;
Sentinel间隔指定周期向所监控Master发送hello信息(包括自身IP 端口 ID等内容)向其它订阅同一个Master的Sentinel交换主节点和Sentinel信息;
Sentinel集群使用Ping(1s一次)来检测实例状态,未在指定时间内回复或回复错误则判定实例失效触发failover机制;
Sentinel集群通过选举产生leader来完成后续主节点选举工作;
触发failover主备切换机制后,需要Sentinel集群中指定个数(quorum)节点授权后才可进行切换;
Sentinel向选定晋级对象Slave发送SLAVEOF NO ONE命令(选择机制为健康状态>优先级>复制偏移量>进程ID);
晋级对象Slave获取授权后得到宕机Master最新配置版本号(config-epoch),failover机制结束后,该版本号用于最新配置,通过广播形式通知Sentinel,其他Sentinel更新对应配置;
原Master节点隶属Slave接入新Master,原Master降级为Slave,当其恢复后复制Master节点数据;
特点:
高可用
节点监控
自动故障迁移
缺点:
主从模式切换需要时间,数据会发生丢失
Master写入请求压力没有得到分摊
3.2 Redis Cluster:
特点:
去中心化
节点数据共享,动态调整数据分布(各节点保存数据和集群状态)
可扩展性(动态添加或删除节点)
高可用
自动故障切换(通过Gossip协议交换状态信息,从而利用投票机制完成Slave晋级)
缺点:
资源隔离性差
数据异步复制,一致性无法保证
4. 持久化方案:
4.1 RDB:进程数据生成快照写入硬盘
优点:
恢复数据速度快
数据完整性可以得到保证
缺点:
执行成本高导致无法实时持久化(每次RDB都要fork子进程)
版本兼容性较低
触发方式:
手动:
save:阻塞Redis服务器,直到RDB过程完成,服务器内存过大会导致时间过长
bgsave:Redis会fork子进程负责RDB,RDB完成后自动结束子进程,子进程被fork阶段阻塞服务器
自动:
save m n为m秒内数据发生n次修改自动触发bgsave
shutdown被执行时如AOF功能未开启则自动触发bgsave
Slave请求全量复制时Master自动bgsave生成RDB文件发送至Slave
4.2 AOF:独立日志格式记录写入命令
流程:命令写入>命令同步>文件重写>重启加载
重写方式:
手动:
bgrewriteaof
自动:
调整auto-aof-rewrite-min-size,auto-aof-rewrite-percentage等参数
5. 缓存雪崩:
5.1 原因:
Key同时大面积失效,导致QPS越过Redis直达后端数据库,后端数据库如无熔断等策略会导致该数据库及其依赖库无法承受负载瞬间宕机
5.2 解决方案:
1.为每个Key失效时间增加一个随机值,从而保证数据不会同时大面积失效
2.缓存数据均匀分布Redis集群
3.热点数据永不老化(需更新数据时更新缓存)
6. 缓存穿透:
6.1 原因:
请求数据不存在Redis与后端数据库中,如请求ID为负数或极值的数据会导致请求直接抵达后端数据库,数据库无法查询到该数据,类似并发请求过多会导致数据库崩溃
6.2 解决方案:
1.用户接口层增加校验(用户鉴权校验 参数校验)
2.减少缓存有效时间,将请求为空的Key其Value重写为指定内容
3.负载均衡层对QPS过高IP做封禁处理
4.布隆过滤器(Bloom Filter)对后端数据库不存在数据直接Return
7. 缓存击穿:
7.1 原因:
客户端持续对同一个Key进行请求,导致该Key失效,请求抵达后端数据库
7.2 解决方案:
1.热点数据永不过期
2.互斥锁
8. 部署Redis(redis-5.0.8.tar.gz):
8.1 yum install -y gcc gcc-c++ && tar xfz redis-5.0.8.tar.gz && cd redis-5.0.8 && make && make install
8.2 可执行文件(./src/):
redis-server:Redis服务端
redis-cli:Redis客户端
redis-benchmark:Redis性能测试工具
redis-check-rdb:RDB文件修复工具
redis-check-aof:AOF文件修复工具
redis-sentinel:Redis哨兵客户端
redis-trib.rb:Redis集群操作工具
8.3 配置文件参数详解(./redis.conf):
daemon [yes/no]:是否后台运行
pidfile [path]:pid文件路径
port [1-65535]:监听端口
timeout [number]:超时时间
loglevel [debug/verbose/notice/warning]:日志级别
logfile [path]:日志路径
bind [***.***.***.***]:绑定地址
databases [number]:数据库数量
maxclients [number]:最大连接数(0为不限制)
hash-max-zipmap-entries [number]:HashMap内元素数量低于number时采用线性紧凑格式存储,超过时再转换为HashMap
hash-max-zipmap-value [size]:HashMap内元素长度低于size时采用线性紧凑格式存储,超过时再转换为HashMap
list-max-ziplist-entries [number]:List中节点数低于number时采用线性紧凑格式存储
list-max-ziplist-value [size]:List中节点长度低于size时采用线性紧凑格式存储
set-max-intset-entries [number]:Set中节点数低于number且类型都为数值型时采用线性紧凑格式存储
activerehashing [yes/no]:是否激活重置哈希
vm-enabled [yes/no]:是否启用虚拟内存(内存占用较多)
maxmemory-samples [number]:随机选择number个Key,删除使用频率最低的
maxmemory [size]:内存清理阈值
maxmemory-policy [method]:内存清理策略
volatile-lru:从过期时间已指定数据集中删除最近使用频率较低的数据
volatile-random:从过期时间已指定数据集中随机删除数据
volatile-lfu:从过期时间已指定数据集中删除总体使用频率最低的数据
volatile-ttl:从过期时间已指定数据集中删除即将过期的数据
allkeys-lru:从数据集中删除最近使用频率较低的数据
allkeys-lfu:从数据集中删除总体使用频率较低的数据
allkeys-random:从数据集中随机删除数据
noeviction:默认策略,数据永不过期(内存不足时进行写入操作报错)
save [m n]:在m秒内发生n次修改则写入RDB快照(可设置多个条件)
rdbcompression [yes/no]:RDB时是否压缩数据
dbfilename [name]:RDB文件名
dir [path]:RDB文件存放目录
appendonly [yes/no]:是否开启AOF持久化(提高数据抗风险能力,会影响效率)
appendfilename [name]:AOF文件名
appendfsync [always/everysec/no]:AOF同步机制
no-appendfsync-on-rewrite [yes/no]:AOF文件达到指定值时是否调用bgrewriteaof重写
slaveof [MasterIP MasterPort]:Slave连接Master指定地址
masterauth [password]:Master验证密码
requirepass [password]:连接Redis验证密码
8.4 Redis启动方式:
./src/redis-server & [parameter]
./src/redis-server 配置文件路径
设置开机自启