1、redis介绍
redis是高性能的key-value数据库。特点有:redis支持数据持久化;支持多个数据结构类型的数据存储(string,list,set,zset,hash);支持数据的备份(master-slave模式);redis操作是原子性,单个操作是原子性的,多个操作也可以使用事务,通过MULTI和EXEC指令包起来;支持publish-subscribe等模式。
2、redis的数据类型及使用场景
3、redis使用的优点
- 操作速度快,因为数据都是存放在内存中。
- 支持多个数据类型,string list set zset hash等
- 支持事务,操作都是原子性
- 丰富的特性:可用于缓存,消息,按key设置过期时间
3、redis是单进程单线程的,redis利用队列技术并发访问变为串行访问。
4、redis的持久化机制是什么?各自的优缺点?
目前有两种持久化机制:RDB和AOF机制。
- RDB持久化机制:用数据集快照的方式半持久化模式,记录redis数据库的所有键值对,在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。
优点:只有一个文件dump.rdb,方便持久化;容灾性好,一个文件可以保存到安全的磁盘;性能最大化,fork子进程来完成写操作,让主进程继续处理命令,所以是IO最大化。相对于数据集发时,比AOF的启动效率更高。
缺点:数据安全性低,RDB是间隔一段时间进行持久化,如果持久化期间发生redis故障,会导致数据丢失,所以这种方式更适合数据要求不严谨的。
- AOF持久化:是指所有的命令行记录以redis命令请求协议的格式完全持久化存储保存为aof文件。
- 优点:数据安全,aof持久化可以配置appendfsync属性,有always,每次操作都记录到aof文件中;通过append模式写文件,即使中途服务器宕机,也可以通过redis-check-aof工具解决数据一致性问题;aof机制的rewrite模式,AOF 文件没被 rewrite 之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的 flushall))
缺点:AOF文件比RDB文件大,所以恢复速度慢;数据集大的时候,比 rdb 启动效率低。
5、redis常见的性能问题及解决方法:
- master最好不要做任何持久化的工作,包括内存快照(RDB)和AOF日志文件,特别不要启动内存快照持久化
- 为了主从复制的速度和连接的稳定性,slave和master最好在同一个局域网
- 避免在压力大的主库上添加从库
- 为了master稳定性,主从复制不要用图状结构,单向链表更稳定,即master->slave1->slave2,这个结构方便解决单点故障问题,意思是master挂了,可以立马启用slave1作为master,其他不变。
6、redis过期键的删除策略
- 定时删除:在设置键的过期时间的同时,创建一个定时器,定时检查key是否过期;优点是可以及时清除过期key,释放内存;缺点是如果过期key比较多,也会占用较多的cpu资源
- 惰性删除:当获取某个key再去判断该key是否过期,过去则删除,返回null。优点是不需要单独占用cpu资源,缺点是可能长时间不释放内存空间。
- 定期删除:上述方式的综合,每隔一段时间(server.hz参数可以配置每秒执行的次数)抽查一些key,并计算过期的key与该次抽查key总数比值,大于25%,继续抽查该库的数据。优点是平衡了cpu和内存的资源问题,缺点是定时时间设置不是很好把握。
redis采用的方式是惰性+定时。
7、Redis 的回收策略(淘汰策略)
- volatile-lru:从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
- volatile-ttl:从已设置过期时间的数据集中挑选将要过期的数据淘汰
- allkeys-lru:从数据集中挑选最近最少使用的数据淘汰
- allkeys-random:从数据集中任意选择数据淘汰
- no-enviction(驱逐):禁止驱逐数据
- 使用的策略:第一如果数据呈现幂律分布,即一部分数据访问频率高,一部分访问频率低,使用allkeys-lru;第二如果数据访问的频率相同或者差不多,则使用allkeys-random
8、redis同步机制:redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
9、说说 Redis 哈希槽的概念:redis集群没有使用一致性hash,而是引入了哈希槽的概念,Redis集群中有16384个哈希槽,每个key通过crc16校验后对16384取模来决定放在哪个槽,集群的每个节点负责一部分哈希槽。