为什么说Redis是单线程的以及Redis为什么这么快!Redis、面试、缓存、雪崩、分布式锁实现一篇文章搞定(1)

最后

俗话说,好学者临池学书,不过网络时代,对于大多数的我们来说,我倒是觉得学习意识的觉醒很重要,这是开始学习的转折点,比如看到对自己方向发展有用的信息,先收藏一波是一波,比如如果你觉得我这篇文章ok,先点赞收藏一波。这样,等真的沉下心来学习,不至于被找资料分散了心神。慢慢来,先从点赞收藏做起,加油吧!

另外,给大家安排了一波学习面试资料:

image

image

以上就是本文的全部内容,希望对大家的面试有所帮助,祝大家早日升职加薪迎娶白富美走上人生巅峰!

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

(2)多进程启动:此时系统有且仅有一个Master进程,至少有一个Worker进程工作。

(3)Master进程主要进行一些全局性的初始化工作和管理Worker的工作;事件处理是在Worker中进行的。

1、Redis的的用途和场景

高性能与高并发 各种业务场景如何利用Redis秀操作,可以参考《Redis数据说明》

2、使用不当的后果

缓存与数据库的数据一致性

缓存雪崩

缓存穿透

缓存并发竞争

3、redis为啥高性能

绝大部分请求是纯粹的内存操作(非常快速),数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1);

数据结构简单,对数据操作也简单

采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗;

非阻塞IO - IO多路复用,“多路”指的是多个网络连接,“复用”指的是复用同一个线程。

4、redis的数据类型

string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。

5、redis的过期策略

两种策略组合,保证过期的key一定能删掉。

定期删除,每隔100ms随机抽取设置过期时间的key,检查是否过期。(避免过多数据的轮询耗时)

惰性删除,key查询时再判断是否过期,过期了再进行确认,过期则删除。

LRU内存淘汰策略,进行过期key(最近最少使用)的内存释放。可以用LinkedHashMap自己手写一个.

6.redis如何支持高并发

单机redis的并发在几万(高性能的主机可以支撑到10w+),一般会采用主从架构+读写分离,一般是一主多从,主负责写并将数据同步复制到其他的slave节点上去,从节点负责读,所有的读请求都要走从节点,这样可以支撑起一个水平扩展的读高并发架构。

7、redis replication主从复制的核心原理

当启动一个salve节点时,它首先会发送一个psync的命令给master节点,如果是第一次连接,就会触发全量同步,master会异步的生成一份rdb快照文件(无磁盘化复制,内存中创建不会落盘),同时还会将这段时间从客户端收到的所有写命令缓存在内存中。rdb生辰后,发送给slave节点,slave写入磁盘再加载到内存中,然后master会讲内存中缓存的写命令也同步给slave,slave也会去同步这部分增量数据。

master和slave都会维护一个offset,不仅仅用于全量复制,让master和slave都知道相互之间一个数据一致性情况。

8、断点续传

全量主从复制支持断点续传,master节点在内存中维护了backlog,记录了一个同步的偏移量,如果断线重连以后,会从backlog中记录的偏移量位置开始进行同步,如果没有找到offset就会触发全量同步。

9、redis的高可用机制

redis的高可用是通过哨兵机制来保障的。类似zk,可以实现集群监控、消息通知、故障转移和配置中心的作用。哨兵本身也是分布式的:

故障转移,判断一个master挂了,需要多数哨兵同意才行,需要重新选举。

哨兵本身也是集群模式,部分节点挂了,还是能工作,同时为了方便选举哨兵的节点数最好设置成奇数个。

a.社区版本推出的原生高可用解决方案

Redis哨兵架构

故障转移的工作流程就是,当Master宕机的时候,Sentinel会选举出新的Master,并根据Sentinel中client-reconfig-script脚本配置的内容,去动态修改VIP(虚拟IP),将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可!

缺陷: (1)主从切换的过程中会丢数据 (2)Redis只能单点写,不能水平扩容

b.开源Proxy+Replication+Sentinel

前端使用Twemproxy+KeepAlived做代理,将其后端的多台Redis实例分片进行统一管理与分配

HA proxy+KeepLive

每一个分片节点的Slave都是Master的副本且只读;Sentinel持续不断的监控每个分片节点的Master,当Master出现故障且不可用状态时,Sentinel会通知/启动自动故障转移等动作;Sentinel 可以在发生故障转移动作后触发相应脚本(通过 client-reconfig-script 参数配置 ),脚本获取到最新的Master来修改Twemproxy配置。

缺陷: (1)部署结构超级复杂 (2)可扩展性差,进行扩缩容需要手动干预 (3)运维不方便

10、redis哨兵的选举算法

判断master失败的两种状态:

sdown,主观宕机,一个哨兵ping不同一个master,超过一定时刻就主观认为sdown了。

odown,客观宕机,如果有quorum数量的哨兵都认为master宕机了,就客观认为master宕机了。

如果一个master被认为odown,且majority哨兵都允许了准备切换,选举一个slave为一个master。

slave priority越低,选举为master的优先级越高

slave priority相同,replica offset越靠后,优先级越高(从master同步数据越多)

上面都相同,就选择一个run id较小的slave。

source: 史上最全 Redis 高可用解决方案总结

11、redis挂掉以后的数据恢复(持久化机制)

redis持久化主要功能就是为了保证灾难恢复,数据恢复。可以归类于高可用。关于持久化的AOF和RDB,二者区别介绍如下:

RDB持久化是通过将某个时间点Redis服务器存储的数据保存到RDB文件中来实现持久化的。AOF持久化是通过将Redis服务器执行的所有写命令保存到AOF文件中来实现持久化的。

RDB持久化记录的是结果,AOF持久化记录的是过程,所以AOF持久化生成的AOF文件会有体积越来越大的问题,Redis提供了AOF重写功能来减小AOF文件体积

AOF持久化的安全性要比RDB持久化的安全性高,即如果发生机器故障,AOF持久化要比RDB持久化丢失的数据要少

如果Redis服务器开启了AOF持久化功能(默认是关闭的),Redis服务器在启动时会使用AOF文件来还原数据,如果Redis服务器没有开启AOF持久化功能,Redis服务器在启动时会使用RDB文件来还原数据,所以AOF文件的优先级比RDB文件的优先级高

12、RDB中save和Bgsave的区别?

Redis提供了2个命令来创建RDB文件,一个是SAVE,另一个是BGSAVE。

SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理任何命令请求。

BGSAVE命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程(父进程)继续处理命令请求

BGSAVE命令可以在不阻塞服务器进程的情况下执行,所以推荐使用BGSAVE命令。

13、RDB和AOF如何选择?

可以综合使用,用AOF来保证数据不丢失,作为恢复数据的第一选择;用RDB来做冷备,在AOF或者磁盘损坏不可用的情况下,还有RDB作为快速恢复的手段。

source: 阿里二面:熟悉Redis?讲讲你理解的Redis的持久化机制(RDB、AOF)

14、Redis的架构选择

如果数据量很少,主要是承载高并发高性能的场景,比如你的缓存一般就几个G,单机足够了

主从+replication,数据量一般,满足高并发,一个mater,多个slave,要几个slave跟你的要求的读吞吐量有关系,然后自己搭建一个sentinal集群,去保证redis主从架构的高可用性,就可以了

redis cluster,主要是针对海量数据+高并发+高可用的场景,海量数据,如果你的数据量很大,那么建议就用redis cluster

15、Redis Cluster

客户端与Redis节点直连,不需要中间Proxy层,直接连接任意一个Master节点;根据公式HASH_SLOT=CRC16(key) mod 16384,计算出映射到哪个分片上,然后Redis会去相应的节点进行操作

Redis cluster架构

具有如下优点: (1)无需Sentinel哨兵监控,如果Master挂了,Redis Cluster内部自动将Slave切换Master (2)可以进行水平扩容 (3)支持自动化迁移,当出现某个Slave宕机了,那么就只有Master了,这时候的高可用性就无法很好的保证了,万一Master也宕机了,咋办呢? 针对这种情况,如果说其他Master有多余的Slave ,集群自动把多余的Slave迁移到没有Slave的Master 中。

缺点: (1)批量操作是个坑(mget) (2)资源隔离性较差,容易出现相互影响的情况。

source: 那些年用过的Redis集群架构(含面试解析)

16、Redis cluster的高可用性

整个流程跟哨兵相比,非常类似,所以说,redis cluster功能强大,直接集成了replication和sentinal的功能。不过在通信协议上整个采用了gossip协议,跟集中式的哨兵协议不同,不是将集群元数据(节点信息,故障,等等)集中存储在某个节点上,而是互相之间不断通信,保持整个集群所有节点的数据是完整的。其他在判断节点是否当季、节点过滤和选举上的思路都是少数服从多少的思路,基本一致。

集中式:好处在于,元数据的更新和读取,时效性非常好,一旦元数据出现了变更,立即就更新到集中式的存储中,其他节点读取的时候立即就可以感知到; 不好在于,所有的元数据的跟新压力全部集中在一个地方,可能会导致元数据的节点有压力。

gossip:好处在于,元数据的更新比较分散,不是集中在一个地方,更新请求会陆陆续续,打到所有节点上去更新,有一定的延时,降低了压力; 缺点,元数据更新有延时,可能导致集群的一些操作会有一些滞后。

17、数据分区的选择

a.哈希取余分区

哈希取余分区思路非常简单:计算 key 的 hash 值,然后对节点数量进行取余,从而决定数据映射到哪个节点上。 该方案最大的问题是,当新增或删减节点时,节点数量发生变化,系统中所有的数据都需要重新计算映射关系,引发大规模数据迁移。

b.一致性哈希分区

一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环,如下图所示,范围为 0-2^32-1。对于每个数据,根据 key 计算 hash 值,确定数据在环上的位置,然后从此位置沿环顺时针行走,找到的第一台服务器就是其应该映射到的服务器。

**与哈希取余分区相比,一致性哈希分区将增减节点的影响限制在相邻节点。**一致性哈希分区的主要问题在于,当节点数量较少时,增加或删减节点,对单个节点的影响可能很大,造成数据的严重不平衡;同时也需要保证节点能够均匀分布在哈希环,使得缓存数据能够均匀分布。

c.带虚拟节点的一致性哈希分区(哈希槽)

该方案在一致性哈希分区的基础上,引入了虚拟节点的概念。Redis 集群使用的便是该方案,其中的虚拟节点称为槽(slot)。槽是介于数据和实际节点之间的虚拟概念;每个实际节点包含一定数量的槽,每个槽包含哈希值在一定范围内的数据。引入槽以后,数据的映射关系由数据 hash->实际节点,变成了数据 hash->槽->实际节点。在使用了槽的一致性哈希分区中,槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系,增加或删除节点对系统的影响很小。槽的数量一般远小于 2^32,远大于实际节点的数量;在 Redis 集群中,槽的数量为 16384

数据映射

Redis 集群将数据映射到实际节点的过程:

Redis 对数据的特征值(一般是key)计算哈希值,使用的算法是 CRC16。

根据哈希值,计算数据属于哪个槽。

根据槽与节点的映射关系,计算数据属于哪个节点。

source: 深入学习 Redis 集群搭建方案及实现原理

18、缓存雪崩

故障原因:redis挂了 事前:redis高可用,主从+哨兵,redis cluster,避免全盘崩溃 事中:本地cache缓存 + hystrix限流&降级,避免MySQL被打死 事后:redis持久化,快速恢复缓存数据

故障原因2:缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效 将缓存失效时间分散开,比如我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。

19、缓存穿透

缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。解决办法有两个:

查询数据库不存在,则在redis中存一份Null值,避免访问Mysql

最后

金三银四到了,送上一个小福利!

image.png

image.png

专题+大厂.jpg

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

大。解决办法有两个:

查询数据库不存在,则在redis中存一份Null值,避免访问Mysql

最后

金三银四到了,送上一个小福利!

[外链图片转存中…(img-cPNvMpJc-1715495583430)]

[外链图片转存中…(img-3AFnRDBM-1715495583431)]

[外链图片转存中…(img-KJD0UBfl-1715495583431)]

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友,可以点击这里获取

  • 27
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值