1. Redis
1.1 基础
优点
- 性能高
- 数据结构丰富
为什么快?
- 基于内存进行数据处理的
- 单线程模型,不存在线程竞争以及上下文切换
- 基于k-v的数据结构,结构简单
- IO 模型采用多路复用技术,尽可能充分使用单线程去完成连接处理以及读写IO(尽可能压榨单线程的IO模型)
存在什么问题
- 基于内存操作,数据稳定性、安全性不高,容易丢失
- k-v的结构导致数据检索能力较差
- 事务支持不友好
1.2 数据结构
基础
- string
- hash
- list
- set
- zset
扩展
- bitmap,位图,利用二进制数组的特性,可以实现占用非常小的内存,存储大量的数据。场景:基于其实现布隆过滤器解决缓存穿透问题
- geo,针对地理位置经纬度实现地理位置的相关操作。场景:查询指定范围内的地点。
- hyperloglog,数学上集合的元素个数,不能重复。场景:统计网站的UV。
1.3 常用命令
通用命令
- del
- keys(禁用)
- ttl
- expire
string
- get/set
- incr/decr
- setnx
- setex
hash
- hget/hset
- hsetnx
list
- lpush/rpush
- lpop/rpop
- llen
- lindex
set
- sadd
- sdiff
- srem
- spop
zset(sorted set)
- zadd
- zcard
- zcount
- zdiff
- zincrby
- zrange
1.4 持久化
RDB
快照类型的持久化,通过配置指定时间内多少key发生变动,进行一次持久化操作。
该持久化操作时将当前redis的内存dump下来保存到持久化文件中,在redis重新启动时再加载该文件恢复到内存中。
优点:恢复数据效率高
缺点:可能丢失较多数据
AOF
日志类型的持久化,根据配置的AOF规则,可以分为按cpu情况、每秒一次、每个key持久化一次三种不同策略。
每次持久化时,是将当前这一批需要持久化的key以日志形式存储到持久化文件,在恢复数据时,在重新读取该文件,并重新读取命令。
优点:数据安全性相对更高
缺点:恢复数据效率很慢
混合持久化
在redis4.0以后,推出了混合持久化功能,分别结合RDB二进制恢复数据快的特性,以及AOP持久化效果好的特性
首先需要开启AOF持久化,再去开启混合持久化,开启之后会将数据都持久化在aof文件中,并且一段时间会将大部分的日志数据转换为二进制数据,新增加的数据继续作为日志文件追加。
也就形成了一半二进制数据一般日志形式。
1.5 内存淘汰
当redis中内存不足时,采用什么策略去清除不需要的数据,以满足可以继续往redis存数据。
有过期时间
- LRU:最近最少使用,淘汰最久未被使用的key
- LFU:最少频率使用,淘汰最少被访问的key,即使用次数最少的key。
- RANDOM:随机淘汰
- TTL:淘汰距离过期时间最近的key
无过期时间
- LRU
- LFU
- RANDOM
默认
不淘汰,抛出异常
1.6 key删除策略
惰性删除
过期后,不会做任何处理,等待下一次访问该key的时候,发现已经过期,才会将其删除。
优点:性能影响较少
缺点:如果一直不访问,可能导致内存泄露
定时删除
设置过期时间的同时,设置一个定时器,让定时器在键的过期时间到达后,自动删除。
优点:删除及时,对内存友好
缺点:对cpu不友好
定期删除
每隔一段时间,程序对数据库进行一次检查,删除里面的过期键。折中方案。
优点:删除频率、时长、数量可控
缺点:删除不够实时
1.7 集群
主从模式
直接使用redis自带的主从方案,配置主节点从节点即可
优点:部署简单
缺点:如果主节点挂掉,无法恢复
哨兵模式
通过额外引入哨兵进程,去监控整个redis集群的状态,如果一旦发现主节点出现问题,会对剩余的从节点进行选举,选出新的主节点。
一般在有选举的情况下,都采用奇数形式部署服务。如果是用偶数部署,可能产生脑裂问题。
选举投票:半数机制,只有超过一半以上的投票,才成立
优点:有主从选举机制,主节点挂掉可以产生新的主节点
缺点:还是集群,没有数据分片
Redis Cluster
Redis3.0以后推出的集群方案,支持集群+分片方案,可以实现每个分片即是一个集群。
1.8 常见问题
并发问题
- 缓存击穿
- 缓存穿透
- 缓存雪崩
一致性问题
- 缓存同步
- 双写一致性