第6次面试：华某永道(2022-03-16)

  首先讲清楚，这家公司是华某永道，不是某华永道。这次是中午休息的时间面试的，但是面试得比较短，因为有两个问题答不出来，所以面试官不想继续浪费时间了。闲话不说，整理经验，加油向前冲。

Nacos注册中心原理

  因为我根本不知道原理，所以直接就没回答这个问题。但是也给面试官留下了基础知识不牢固的印象。要在短短的面试时间里答好这个问题，就必须精简。所以必须从以下几个方面回答：数据模型、健康检查、一致性、负载均衡。

Nacos注册中心数据模型

  Nacos的数据模型是服务-集群-实例的三层模型。但是实际应用中可以降级，也就是去掉集群这层，变成服务-实例的模型。
  为了数据隔离，那么服务上面又有三层，组成Company-Namespace-Group-Service的四层模型。

Nacos注册中心健康检查

  目前主流的健康检查采用两种方式：客户端上报与服务端探测。采用客户端上报的有Netflix eureka，采用服务端探测技术的有Consul。客户端上报方式的叫非持久化实例，服务端探测的叫持久化实例。而Nacos同时支持两种方式。Nacos 1.0一个服务下，可以同时拥有持久化与非持久化实例，这样造成了管理混乱，而Nacos2.0则将这一属性移到了服务级别，也就是服务下所有集群下的所有实例，要么采用客户端上报，要么采用服务端探测。

Nacos注册中心数据一致性

  一致性，我现在才明白是指客户端往任意一台服务器写数据完成后，再从任何一台服务器都可以读到刚才写的数据。所以主要分两种一致性方案，一种是基于leader的单点写入，另一是对等的多点写入。Nacos采用了什么呢？Nacos可以使用两种协议：一种是简化的Raft协议，也就是放弃可用性，保证一致性和分区容错性；还有一种是基于阿里内部的Distro的AP协议，也就是放弃一致性，保证可用性和分区容错性。

Nacos注册中心负载均衡

  Nacos使用的是一种服务端实现的负载均衡方案，支持健康与权重的负载均衡，也支持基于CMDB(Configuration Management Database，配置管理数据库)的标签负载均衡器。标签负载均衡器，是指客户端和服务端同标签优先的一种负载均衡策略，可以实现优先访问同地域的需求。

Redis分布式锁方案

  这个问题我的回答是使用setNX命令和过期等命令。但是这个方案缺点十分明显，容易死锁，容易锁失效。死锁指的是释放锁失败时，就死锁了。失效是业务代码执行时间超过了设置的过期时间就锁失效了。这个方案，再怎么修改都无法解决，反而会增加实现复杂度。
  解开这个死局，就是使用优秀的框架redission。
  首先看面试官问的第一个问题，如何保证setnx和设置超时时间是原子的。这个redisson是用一个lua脚本去实现的，redis执行任何lua脚本都是原子的。
  面试第二个问题，如何保证重入的？而redisson的实现方案，其实模型和思想和单机多线程锁是一样的。我们回想下单机多线程的锁，为了实现重入，肯定是要记录锁属于哪个线程，以Java重量级锁为例子，使用队列的头来记录当前锁的拥有者。然后未得到锁的，就调用park去等待锁的释放。redisson的实现方案是用一个Hash，key是分布式客户端id和客户端线程id的组合，value是重入次数。
  redisson没有使用队列和栈来实现。在加锁后使用看门狗不断延长锁的失效时间。这使得前面说的锁失效现象不会发生。
  此外，redisson还使用了redis的发布订阅机制，来通知锁的释放，提前结束客户端的等待/阻塞。