百果园java拉勾_拉勾学子的面试系列最终稿

班主任：你们觉得拉勾教育怎么样？

博主：拉勾教育天下第一。

redis一致性(容灾)

故障检测

集群中每个节点都会定期的向集群中的其他节点发送PING信息。

如果在一定时间内，发送ping的节点A没有收到某节点B的pong回应，那么A将B标识为pfail。

A在后续发送ping时，会带上B的pfail信息，通知给其他节点。

如果B被标记为pfail的个数大于集群主节点个数的一半(N/2 + 1)时，B会被标记为fail，A向整个集群广播，该节点已经下线。 其他节点收到广播，标记B为fail。(又是过半原则)

从节点选举

每个从节点，根据自己对master复制数据的offset(偏移量)，来设置一个选举时间，offset越大的从节点，选举时间越靠前，

优先进行选举。

所有的Master开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node(N/2 +1)都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。 RedisCluster失效的判定： 1、集群中半数以上的主节点都宕机(无法投票) 2、宕机的主节点的从节点也宕机了(slot槽分配不连续)

当slave 收到过半的master 同意时，会成为新的master。此时会以最新的Epoch 通过PONG 消息广播 自己成为master，让Cluster 的其他节点尽快的更新拓扑结构(node.conf)。

ribbon源码解读

原面试题：讲一下spring cloud的负载均衡机制

使用@LoadBalanced注解后，可以将普通的RestTemplate对象使用LoadBalanceClient去处理。

老规矩，先找spring.factories,可以发现Ribbon的自动装配类为：

LoadBalancerClient类(实现类RibbonLoadBalancerClient，待用)

org.springframework.cloud.netflix.ribbon.RibbonAutoConfiguration

1)研究LoadBalancerAutoConfiguration

第一步：注入RestTemplate对象到集合待用。

第二步：注入RestTemplate定制器(RestTemplateCustomizer)

第三步：使用RestTemplateCustomizer为每一个RestTemplate对象添加拦截器

hystrix断路器

这个一般会问，先记录

关闭的条件

当满足一定的阈值的时候(默认10秒内超过20次请求)

当失败率到达一定的时候，默认10秒内超过50%的请求失败

到达以上阈值时，断路器将会开启

当开启的时候，所有的请求都不会进行转发

一段时间之后，默认5秒，这个时候断路器是半开状态，会让其中一些请求进行转发

断路器状态

Closed：关闭状态，所有请求都正常访问。

Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。

Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间(默认是5S)。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时

nacos原理

面试原题：服务发现原理

关键点：

org.springframework.cloud.client.serviceregistry.ServiceRegistry ：定义了服务注册接口

com.alibaba.cloud.nacos.registry.NacosServiceRegistry：nacos实现

引入nacos相关pom时，spring.factories文件会起作用，会去加载

org.springframework.cloud.client.serviceregistry.AutoServiceRegistrationAutoConfiguration

这个配置类。

nacos服务器(nacos-server.jar)启动时，会通过InstanceController 提供一些rest api。

NacosServiceRegistry在注册实例或者发送心跳信息时，会远程调用InstanceController

这里主要参考了上次的spring cloud直播课。

jvm gc

gc流程回顾

1.首先，eden区满时触发第一次GC，把还活着的对象拷贝到S0区，当eden去再次触发GC的时候会扫描eden区和S0区，对这两个区域进行垃圾回收，经过这次回收后还存活的对象，则直接复制到S1区，

同时把这些对象的年龄+1(如果有对象的年龄达到了老年的标准，默认15次垃圾回收，这个对象进入老年区)

2.新生代占1/3，Eden区占新生代的8/10空间，s0和s1分别占用1/10。

3.然后，清空eden区和s0的对象，也就是复制之后有交换，谁空谁是s1

4.最后，s1和s0互换，原s1成为下一次GC的s0区。

标记清除算法

不会浪费空间，但是会产生内存碎片。

CMS收集器

CMS(Concurrent Mark Sweep)收集器是⼀种以获取最短回收停顿时间为⽬标的收集器。它非常符合 在注重⽤户体验的应⽤上使⽤。 CMS(Concurrent Mark Sweep)收集器是HotSpot虚拟机第⼀款真正意义上的并发收集器，它第⼀次实 现了让垃圾收集线程与⽤户线程(基本上)同时⼯作。

cms采用了标记清除算法，仍然会产生内存碎片

cms 4个步骤

初始标记，并发标记，重新标记，并发清除。

G1收集器

G1 (Garbage-First)是⼀款⾯向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.

与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；

从局部上来看是基于“复制”算法实现的。

G1不会产生内存碎片。

G1主要是改变新生代和老年代，变成了一个个大小一样的region

每个region从1m到32m不等。

G1的核心思想是将整个堆内存分成大小相同的子区域(最多可以分2048个region)

G1 4个步骤

初始标记，并发标记，最终标记，筛选回收

垃圾回收器种类

串行,并行,并发,G1