【java八股文】之JVM基础篇-CSDN博客
【java八股文】之MYSQL基础篇-CSDN博客
【java八股文】之Redis基础篇-CSDN博客
【java八股文】之Spring系列篇-CSDN博客
【java八股文】之分布式系列篇-CSDN博客
【java八股文】之多线程篇-CSDN博客
【java八股文】之JVM基础篇-CSDN博客
【java八股文】之计算机网络系列篇-CSDN博客
1、Redis有哪几种基本的数据类型
- 字符串类型:用于存储文章的访问量
- Hash:用来存储key-value的数据结构,当单个元素比较小和元素数量比较少的时候 ,底层是用ziplist存储。通常可以用来存储一些对象之类的
- List: 底层采用的quicklist 和 ziplist进行存储的,quicklist就是类似于双端的链表,这样做的好处就是提高存取的效率。通常用作微信公众号的推送消息队列
- Set:底层就是hashtable的value为空的数据结构,通常用作点赞 + 收藏 之类
- ZSet: 底层使用的跳表和字典,调表方便于对排好序的数据查询 , 通常用作类似于微博的热搜
- bitmap:一般用于签到功能或者是统计是否登录的功能上
2、Redis持久化机制
- 快照持久化RDB
在默认情况下, Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
redis的默认持久化机制,通过父进程fork一个子进程,子进程可以共享主线程的所有内存数据。bgsave 子进程 运行后,开始读取主线程的内存数据,并把它们写入 RDB 文件。此时,如果主线程对这些数据也都是读操作, 那么,主线程和 bgsave 子进程相互不影响。但是,如果主线程要修改一块数据,那么,这块数据就会被复制 一份,生成该数据的副本。然后,bgsave 子进程会把这个副本数据写入 RDB 文件,而在这个过程中,主线程 仍然 可以直接修改原来的数据。
- 追加持久化AOF
以日志形式记录每一次的写入和删除操作,策略有每秒同步、每次操作同步、不同步,优点是数据完整性高, 缺点是运行效率低,恢复时间长
3、Redis是单线程吗
redis单线程仅局限于他的网络IO流,和他的键值对读写操作。但是redis对于其他的功能,比如持久化、异步的删除、集群同步等操作,都是额外的线程操作的。
4、为什么Redis单线程还这么快
因为redis所有数据都是在内存中,所有的运算都是内存级别的,而且单线程避免了多线程切换的性能损耗问题。正因为 Redis 是单线程,所以要小心使用 Redis 指令,对于那些耗时的指令(比如keys),一定要谨慎使用,一不小心就可能会导致 Redis 卡顿。
5、Redis单线程还能处理那么多的并发客户端连接
Redis的IO多路复用:redis利用epoll来实现IO多路复用,将连接信息和事件放到队列中,依次放到文件事件分派器,事件分派器将事件分发给事件处理器。
6、什么是缓存穿透
缓存穿透就是查询到一些不存在的数据,本来缓存层就是为了保护存储层的,而这样直接穿透到存储层就起不到保护的作用。
如何解决:在缓存存这是访问的key 为 一个null的值,并设置一个过期时间。或者提前在接口层做好校验工作
7、什么是缓存击穿
由于大批量的缓存在同一时刻失效,大量请求过来就穿透缓存到达存储层,可能造成存储层压力过大甚至挂掉。
如何解决:设置一个随机的过期时间,而不是同一时刻都过期。或者加上互斥锁。
8、什么是缓存雪崩
缓存雪崩指的是缓存层支撑不住或宕掉后,流量会像奔逃的野牛一样, 打向后端存储层。由于缓存层承载着大量请求, 有效地保护了存储层, 但是如果缓存层由于某些原因不能提供服务(比如超大并发过来,缓存层支撑不住,或者由于缓存设计不好,类似大量请求访问bigkey,导致缓存能支撑的并发急剧下降), 于是大量请求都会打到存储层, 存储层的调用量会暴增, 造成存储层也会级联宕机的情况。
预防和解决缓存雪崩问题:
- 保证缓存层服务高可用性,比如使用Redis Sentinel或Redis Cluster。
- 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。比如服务降级,我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据(例如电商商品属性,用户信息等)时,暂时停止从缓存中查询这些数据,而是直接返回预定义的默认降级信息、空值或是错误提示信息;当业务应用访问的是核心数据(例如电商商品库存)时,仍然允许查询缓存,如果缓存缺失,也可以继续通过数据库读取。
- 提前演练。 在项目上线前, 演练缓存层宕掉后, 应用以及后端的负载情况以及可能出现的问题, 在此基础上做一些预案设定。
9、Redis如何实现key的过期删除?
采用的定期过期 + 惰性过期
- 定期删除 :Redis 每隔一段时间从设置过期时间的 key 集合中,随机抽取一些 key ,检查是否过期,如果已经过期做删除处理。
- 惰性删除 :Redis 在 key 被访问的时候检查 key 是否过期,如果过期则删除。
10、缓存与数据库双写不一致
在大并发下,同时操作数据库与缓存会存在数据不一致性问题
1)双写不一致情况
2)读写并发不一致
3)解决方案
- 对于并发几率很小的数据(如个人维度的订单数据、用户数据等),这种几乎不用考虑这个问题,很少会发生缓存不一致,可以给缓存数据加上过期时间,每隔一段时间触发读的主动更新即可。
- 就算并发很高,如果业务上能容忍短时间的缓存数据不一致(如商品名称,商品分类菜单等),缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
- 如果不能容忍缓存数据不一致,可以通过加读写锁保证并发读写或写写的时候按顺序排好队,读读的时候相当于无锁。
- 也可以用阿里开源的canal通过监听数据库的binlog日志及时的去修改缓存,但是引入了新的中间件,增加了系统的复杂度。
11、Redis集群方案
(1)主从模式:多个master节点,多个slave节点,master节点宕机slave自动变成主节点
(2)哨兵模式:在主从集群基础上添加哨兵节点或哨兵集群,用于监控master节点健康状态,通过投票机制选择slave成为主节点
(3)分片集群:主从模式和哨兵模式解决了并发读的问题,但没有解决并发写的问题,因此有了分片集群。分片集群有多个master节点并且不同master保存不同的数据,master之间通过ping相互监测健康状态。客户端请求任意一个节点都会转发到正确节点,因为每个master都被映射到0-16384个插槽上,集群的key是根据key的hash值与插槽绑定
12、Redis集群主从同步原理
主从同步第一次是全量同步:slave第一次请求master节点会根据replid判断是否是第一次同步,是的话master会生成RDB发送给slave。
主从复制(全量复制)流程图:
后续为增量同步:在发送RDB期间,会产生一个缓存区间记录发送RDB期间产生的新的命令,slave节点在加载完后,会持续读取缓存区间中的数据。
主从复制(部分复制,断点续传)流程图:
13、Redis集群为什么至少需要三个master节点,并且推荐节点数为奇数?
新master的选举需要大于半数的集群master节点同意才能选举成功,如果只有两个master节点,当其中一个挂了,是达不到选举新master的条件的。
奇数个master节点可以在满足选举该条件的基础上节省一个节点,比如三个master节点和四个master节点的集群相比,大家如果都挂了一个master节点都能选举新master节点,如果都挂了两个master节点都没法选举新master节点了,所以奇数的master节点更多的是从节省机器资源角度出发说的。
14、Redis集群选举原理分析
当slave发现自己的master变为FAIL状态时,便尝试进行Failover,以期成为新的master。由于挂掉的master可能会有多个slave,从而存在多个slave竞争成为master节点的过程, 其过程如下:
- slave发现自己的master变为FAIL
- 将自己记录的集群currentEpoch加1,并广播FAILOVER_AUTH_REQUEST 信息
- 其他节点收到该信息,只有master响应,判断请求者的合法性,并发送FAILOVER_AUTH_ACK,对每一个epoch只发送一次ack
- 尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
- slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点,如果只有两个,当其中一个挂了,只剩一个主节点是不能选举成功的)
- slave广播Pong消息通知其他集群节点。
可以查看学习以下关于Redis的博文,希望对您有用。
Redis入门学习笔记【一】-CSDN博客
Redis入门学习笔记【二】Redis缓存-CSDN博客
Redis入门学习笔记【三】Redis淘汰策略-CSDN博客
Redis入门学习笔记【四】Redis持久化-CSDN博客
Redis入门学习笔记【五】Redis在分布式环境下常见的应用场景_redis与分布式id的运用场景-CSDN博客
Redis入门学习笔记【六】如何解决 Redis 的并发竞争Key问题_redis中的key并发获取-CSDN博客
Redis入门学习笔记【七】Redis如何保证缓存与数据库双写时的数据一致性-CSDN博客
【Redis读书笔记】Redis集群的三大模式_redis master挂了,启动如何成为 salve-CSDN博客