约的是上午9:30，我提前20分钟到（面试提前是好习惯，提早熟悉环境）花旗大厦，HR 小姑娘很NICE, 很有礼貌地寒暄几句后就将我带到了一个会议室，给了我一瓶农夫山泉，一份面试信息填报表。认真填写了基本信息后静静地等待面试官的到来。
五分钟后两位面试官敲门进来，一位三十来岁女性，打扮时尚，城市白领丽人气质，一位三十来岁男性，秃顶，格子衫，牛仔裤，黑框眼镜（不用我多想，程序员的屌丝气息毋庸置疑），果然不出我所料，女面试官是人事经理，男面试官是技术负责人。人事经理问的问题都很GENERAL, 主要围绕简历，工作经验，全程英文面试（还好这几年外企工作经历让我应付这样的面试还是很轻松的）。人事面试持续了二十分钟左右的样子，接下来重点就来了，秃顶男开始技术方面的面试。
秃顶男：看你简历写熟悉微服务架构和springboot 开发，那你就谈谈微服务和分布式应用下接口的幂等性问题和相应的解决方案。
我： （靠，幂等，好高大上的装逼问题，但面对面试官，还是应该表现出应有的谦虚）幂等的概念在编程领域里是指对于一个系统或者接口，在相同的条件，一次或者重复多次请求对系统或接口资源的影响是一致的。幂等函数，或者幂等方法是指使用相同参数重复执行，并获得相同结果的函数，这些函数不会影响系统状态。（概念阐述明确后，结合实际项目例子）举个实际项目例子，在支付系统中，用户购买了商品后点击支付，但返回结果时网络异常，钱已经扣了，用户再次点击支付，此时进行了第二次扣款。在单体应用系统中，我们可以通过事务来控制，但是在前后端分离的系统中，网络异常可能发生在前端，这时就会导致重复提交，两次扣款的问题。这类支付接口幂等需要通过唯一业务单号来保证。整个业务过程对应唯一业务单号，支付操作对应该唯一业务单号，实现幂等我们可以采用以下方案：
1. Token 机制， 服务端提供token 接口， 我们在分析业务时， 对于存在幂等问题的，就必须在执行业务前去服务端获取token， 服务端把token 存redis （唯一单号做key），请求业务接口时携带token，服务端判断token 是否存在redis，如果存在表示第一次请求，执行业务操作，然后删除redis 中的token，如果不存在，表示重复操作，直接返回重复标记给客户端。
2. 乐观锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，例如： update table1 set colum1 = value, version = version +1 where version = version.
3. 状态机（装逼），将这个业务流程设计成一个业务流转，每个业务状态都有前置状态和后置状态，以及最后的结束状态，这种状态机的流转可以控制请求幂等
秃顶男：（沉思片刻，点了点头，接着问道）eureka 和zookeeer 做为服务注册中心有哪些区别？
我： 每个微服务启动时，都需要去注册中心注册（eureka 或者zookeeper）, eureka 原理：eureka 分为eureka client 和eureka server， 当服务A 需要调用服务B 时，需要从eureka server 获得B服务的服务列表，然后把服务列表缓存，然后根据ribbon 的客户端负载均衡策略，从服务列表中取一个B服务，然后调用B服务，当A服务下次再调用B服务时，发现本地已经缓存了B的服务列表，就不需要从eureka server 来获取B服务列表，直接根据ribbon客户端负载策略获取B服务， 微服务默认每30秒从eureka sever 获取一次新的服务列表，如果某一台服务down 机或者添加了新服务，eureka server 会通知订阅他的客户端，并让客户端更新服务列表。而且还会通知其他eureka server 更新信息， eureka的心跳检查机制：微服务每30秒向eureka server 发送心跳，eureka server 若90 秒没有收到某个微服务的心跳，则会认为服务问题，会将该服务从服务列表删除，并通知客户端更新服务列表。eureka server 的保护机制：主要是让eureka server 不能因为网络原因盲目删除服务。
zookeeper 的工作原理：每启动一个微服务，就会去zookeeper 注册一个临时节点，当服务down 机，临时节点会被删除，当有节点更新，都会通知订阅的微服务更新服务列表，微服务每隔30秒从zookeeper 获取服务列表。分布式系统有三个服务指标：consistency 一致性， Availability 可用性， Partition tolerance 分区容错 （CAP），eureka 基于AP， zookeeper 基于CP
秃顶男:（继续沉思，继续点头，似乎是在想什么可以问住我）Spring 如何解决循环依赖？
我：（我故作深沉，持续应战，因为我对Spring 底层实现也不是很理解）循环依赖简单地说就是A依赖B，B 依赖A，在Spring 中一共有三种循环依赖，构造器循环依赖， setter 循环依赖，和Prototype作用域的循环依赖，spring 可以解决Setter 循环依赖，但对于其他两种循环依赖，Spring 是不能解决的。对于setter 循环依赖，Spring 先实例化A，实例化A后调用addSingletonFacotry 放入三级缓存池，然后Spring 调用setter 方法设置属性时发现依赖B，于是实例化B，发现B依赖A，就从三级缓存中取A 装配B, 然后A继续进行赋值。但是对于构造器循环依赖，Spring 是无法实例bean 的。
秃顶男：（似乎有理）好吧，今天的面试就到这里，回去等消息吧~
我：（我一脸懵逼，难道是挂了？？）
