Redis知识整理
一、Redis 数据类型
1. string 字符型。
2.hash hash 结构化的对象。 key不可重复
3.list 队列 lpush rpop lpop rpush
4. set 集合 value不可重复
5. zset 有序集合 set的基础上加了分数(排序)。
二、Redis事务
1.multi (事务启动) 、 exec (事务执行) 、 watch(监视某几个键有没有被别的客户端进行修改,一旦有任何的键被修改过,exec的时候都会直接返回一个nil,不执行事务)、discard(立刻取消事务,清空事务队列中所有命令)。
2.redis数据库里会存在一个watched_keys字典,这个字典里 key为被监视的key,值为一个链表,链表里记录着监视该key的客户端,一旦被监视的key发生了修改,该key对应的客户端会打开REDIS_DIRTY_CAS标识,代表该客户端的事务安全性被破坏了。这就是watch命令的实现。
3.为什么redis的事务不支持回滚?
因为这种复杂的功能和redis的设计理念不符。并且redis事务中出错原因通常是编程错误,只在开发环境出现,生产环境可避免。
4.redis事务中命令执行出错的结果?
redis并不会中断事务的执行,会继续执行后续的操作命令。exec的时候,出错的命令会被标识出来,并给出原因。
5. redis的事务持久性,受到持久化方式的影响,只要采用了aof快照模式,并且appendfsync选项的值为always时,程序总会在执行命令之后调用同步(sync)函数,将命令数据真正地保存到硬盘里。
ps: 因为如果只采用了rdb方式的话,redis服务器只会在特定的保存条件下才会执行BGSAVE命令,并且异步执行的BGSAVE命令不能保证事务的数据第一时间被保存到硬盘上。
三、Redis缓存穿透和缓存雪崩
缓存穿透:
一些恶意的请求,会故意查询大量不存在的key。
如何避免:
1.对key查询结果为空的情况也进行缓存,缓存有效期设置的短一些,或者当该key插入之后,对缓存进行清理,更新。
2.提前过滤一遍一定不存在的key,将所有可能的key放到一个大的bitmap中进行过滤,或者使用布隆过滤器。
缓存雪崩:
同一时间点,大量缓存集体失效。
如何避免:
1.对大量缓存失效的db加锁或者进行入队控制,控制并发数量。
2.做二级缓存。A1为短期拷贝缓存。A2为长期原始缓存。A1失效时,访问A2.
3.不同的key尽量设置不同的有效期,让缓存的时效节点均匀一些。
四、Redis的线程模型
单线程,基于文件事件管理器(file event handler),I/O多路复用,同时监听多个socket,根据socket上的事件类型,分派给对应的事件处理器进行处理。
五、Redis过期策略
1.定期删除:
每个100ms 随机抽取key是否过期,过期则删除。(ps:如果每次都检查所有的key会卡死的。)
2.惰性删除:
获取某个key的时候,检查该key是否过期,过期则删除。
如果定期删除没有删除到,又没有请求来获取 某些key,那这些key则会一直占着内存。内存越来越高,触发内存淘汰机制。
六、Redis的内存淘汰机制
1.noeviction : 不淘汰数据,写入报错。
2.allkeys-random : 从所有数据中选择任意数据进行淘汰。
3.allkeys-lru : 从所有数据中挑选最近最少使用的key进行淘汰。
4.volatile-random :从设置有效期的数据中选择任意数据进行淘汰。
5.volatile-lru : 从设置有效期的数据中选择最近最少使用的key进行淘汰。
6.volatile-ttl : 从设置有效期的数据中挑选存活时间最短的key进行淘汰。
七、Redis 和 Memcached 区别
1.memcached 只支持存储字符串。 redis支持多样化的5种类型。
2.memcached 不支持持久化。 redis支持RDB和AOF快照。
3.总体来说redis内存使用更少一些。
八、Redis集群在什么时候下不可用
1.任意master挂掉,且当前master没有slave从库,导致哈希槽不完整。
2.超过半数的master挂掉。
九、Redis的哈希槽
没有像一致性哈希的环状概念, Redis集群共有16384个哈希槽,每个key通过CRC16校验后,对16384取模来决定放在哪个槽。集群的每个节点负责一部分槽,可以方便的添加和移除节点。
十、Redis持久化方式
1.RBD : fork子进程,使用copy-on-write写时复制技术,将内存数据记录到RDB文件中。
2.AOF : 将Redis的操作日志以追加 的方式写入文件。
ps: redis 4.0支持混合持久化。 redis实例重启时,使用RDB重建大部分内存。再使用AOF快照重放,回复到重启之前的状态。
十一、AOF如何缩减自身 文件大小
bgrewriteaof 重写aof,重写成功才会替换。
十二、Redis的主从同步
1.同步前,主节点先来一次bgsave,并同时将后续的修改操作记录到内存buffer。 后续将rdb文件完全同步到从节点,构建内存。再通知主节点将内存buffer里的修改操作同步到从节点进行重放,完成。
十三、Redis队列
pub/sub模式 如果消费者下线,生产者的数据积压,如果这时候没有实时aof,数据就会丢失。
十四、数据库、缓存双写一致性
先更新数据库,再删缓存。后续如果有对该key做查询,查缓存不存在,再去查数据库后,往缓存里再写一份。