小言_互联网的博客

Redis&Nginx常见面试题

404人阅读  评论(0)

1.Redis常见面试题

1.1 为什么使用redis

  1. 性能: 我们在碰到需要执行耗时特别久,且结果不频繁变动的SQL,就特别适合将运行结果放入缓存。这样,后面的请求就去缓存中读取,使得请求能够迅速响应。

  2. 并发: 在大并发的情况下,所有的请求直接访问数据库,数据库会出现连接异常。这个时候,就需要使用redis做一个缓冲操作,让请求先访问到redis,而不是直接访问数据库。

1.2 使用redis有什么缺点

  1. 缓存和数据库双写一致性问题
  2. 缓存雪崩问题
  3. 缓存击穿问题
  4. 缓存的并发竞争问题

1.3 单线程的redis为什么这么快

  1. 纯内存操作
  2. 单线程操作,避免了频繁的上下文切换
  3. 采用了非阻塞I/O多路复用机制

​ redis-client在操作的时候,会产生具有不同事件类型的socket。在服务端,有一段I/0多路复用程序,将其置入队列之中。然后,文件事件分派器,依次去队列中取,转发到不同的事件处理器中。

1.4 redis的数据类型,以及每种数据类型的使用场景

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vqvZfZf1-1570090856959)(…/…/…/…/assets/img/2205963.png)]

  1. String

  2. hash

    ​ 这里value存放的是结构化的对象,比较方便的就是操作其中的某个字段。单点登录的时候,用这种数据结构存储用户信息,以cookieId作为key,设置30分钟为缓存过期时间,能很好的模拟出类似session的效果。

  3. list

    ​ 使用List的数据结构,可以做简单的消息队列的功能。另外还有一个就是,可以利用lrange命令,做基于redis的分页功能,性能极佳,用户体验好。

  4. set

    因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。

  5. sorted set

    sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用,取TOP N操作。

1.5 redis的过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略。

1.6 redis和数据库双写一致性问题

​ 一致性问题是分布式常见问题,还可以再分为最终一致性和强一致性。数据库和缓存双写,就必然会存在不一致的问题。
首先,采取正确更新策略,先更新数据库,再删缓存。其次,因为可能存在删除缓存失败的问题,提供一个补偿措施即可,例如利用消息队列。

1.7 如何应对缓存穿透和缓存雪崩问题

  • 缓存穿透,即黑客故意去请求缓存中不存在的数据,导致所有的请求都怼到数据库上,从而数据库连接异常。
  1. 利用互斥锁,缓存失效的时候,先去获得锁,得到锁了,再去请求数据库。没得到锁,则休眠一段时间重试
  2. 采用异步更新策略,无论key是否取到值,都直接返回。value值中维护一个缓存失效时间,缓存如果过期,异步起一个线程去读数据库,更新缓存。需要做缓存预热(项目启动前,先加载缓存)操作。
  3. 提供一个能迅速判断请求是否有效的拦截机制,比如,利用布隆过滤器,内部维护一系列合法有效的key。迅速判断出,请求所携带的Key是否合法有效。如果不合法,则直接返回。
  • 缓存雪崩,即缓存同一时间大面积的失效,这个时候又来了一波请求,结果请求都怼到数据库上,从而导致数据库连接异常。
  1. 给缓存的失效时间,加上一个随机值,避免集体失效。

  2. 使用互斥锁,但是该方案吞吐量明显下降了。

  3. 双缓存。我们有两个缓存,缓存A和缓存B。缓存A的失效时间为20分钟,缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点:

I 从缓存A读数据库,有则直接返回
II A没有数据,直接从B读数据,直接返回,并且异步启动一个更新线程。
III 更新线程同时更新缓存A和缓存B。  

1.8 Redis如何做持久化的?

​ bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会耗费较长时间,不够实时,在停机的时候会导致大量丢失数据,所以需要aof来配合使用。在redis实例重启时,会使用bgsave持久化文件重新构建内存,再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

1.9 Redis的同步机制了解么?

​ Redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

1.10 是否使用过Redis集群,集群的原理是什么?

Redis Sentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。

Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。

2.nginx常见面试题

2.1 什么是Nginx?

Nginx是一个高性能的HTTP和反向代理服务器,及电子邮件(IMAP/POP3)代理服务器,同时也是一个非常高效的反向代理、负载平衡。

2.2 为什么要用Nginx?

  1. 跨平台、配置简单
  2. 非阻塞、高并发连接:处理2-3万并发连接数,官方监测能支持5万并发
  3. 内存消耗小:开启10个nginx才占150M内存,Nginx采取了分阶段资源分配技术
  4. nginx处理静态文件好,耗费内存少
  5. 内置的健康检查功能:如果有一个服务器宕机,会做一个健康检查,再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。
  6. 节省宽带:支持GZIP压缩,可以添加浏览器本地缓存
  7. 稳定性高:宕机的概率非常小
  8. master/worker结构:一个master进程,生成一个或者多个worker进程
  9. 接收用户请求是异步的:浏览器将请求发送到nginx服务器,它先将用户请求全部接收下来,再一次性发送给后端web服务器,极大减轻了web服务器的压力
  10. 一边接收web服务器的返回数据,一边发送给浏览器客户端
  11. 网络依赖性比较低,只要ping通就可以负载均衡
  12. 可以有多台nginx服务器

2.3 为什么Nginx性能这么高?

得益于它的事件处理机制:
异步非阻塞事件处理机制:运用了epoll模型,提供了一个队列,排队解决

2.4 为什么不使用多线程?

Apache: 创建多个进程或线程,而每个进程或线程都会为其分配cpu和内存(线程要比进程小的多,所以worker支持比perfork高的并发),并发过大会榨干服务器资源。

Nginx: 采用单线程来异步非阻塞处理请求(管理员可以配置Nginx主进程的工作进程的数量)(epoll),不会为每个请求分配cpu和内存资源,节省了大量资源,同时也减少了大量的CPU的上下文切换。所以才使得Nginx支持更高的并发。

2.5 正向代理与反向代理

  • 正向代理
    一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器), 然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理

正向代理总结就一句话:代理端代理的是客户端

  • 反向代理
    反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求,发给内部网络上的服务器, 并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器

反向代理总结就一句话:代理端代理的是服务端

2.6 动态资源、静态资源分离

​ 动态资源、静态资源分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后, 我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路

动态资源、静态资源分离简单的概括是:动态文件与静态文件的分离

2.7 为什么要做动、静分离?

​ 在我们的软件开发中,有些请求是需要后台处理的(如:.jsp,.do等等),有些请求是不需要经过后台处理的(如:css、html、jpg、js等等文件, 这些不需要经过后台处理的文件称为静态文件,否则动态文件。因此我们后台处理忽略静态文件。这会有人又说那我后台忽略静态文件不就完了吗? 当然这是可以的,但是这样后台的请求次数就明显增多了。在我们对资源的响应速度有要求的时候,我们应该使用这种动静分离的策略去解决, 动、静分离将网站静态资源(HTML,JavaScript,CSS,img等文件)与后台应用分开部署,提高用户访问静态代码的速度,降低对后台应用访问

这里我们将静态资源放到nginx中,动态资源转发到tomcat服务器中

2.8 负载均衡

负载均衡即是代理服务器将接收的请求均衡的分发到各服务器中

负载均衡主要解决网络拥塞问题,提高服务器响应速度,服务就近提供,达到更好的访问质量,减少后台服务器大并发压力。
感兴趣的同学可以访问我的博客 浏览更多的内容哦https://tonymua.github.io


转载:https://blog.csdn.net/qq_36614875/article/details/102000962
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场