1、对CAP、BASE的理解，项目中是怎么取舍的，常用中间件使用的是哪种组合方式
CAP：C 一致性 A 可用性 P 分区网络容错性（一般为必须） 另外2个2选1
对于需要确保强一致性的场景如银行一般会选择保证 CP
ETCD，强一致性，CP。ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构
CAP理论详解
BASE:
Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性）
牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”
BASE 是 CAP 理论中 AP 方案的延伸（放弃一定强一致性），但是要达到最终一致性，三种方式：读时修复、写时修复（推荐，性能消耗比较低）、异步修复
BASE理论介绍
2、对2PC、3PC、TCC的理解
https://www.cnblogs.com/wudimanong/p/10340948.html
2PC：2阶段提交，请求阶段，提交阶段，事务发起者、协调者、事务参与者（有超时机制）
3PC：precommit，cancommit，docommit，事务发起者、协调者（有超时机制）、事务参与者（有超时机制）
TCC（Try-Confirm-Cancel）又称补偿事务。其核心思想是："针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）"。对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作
《分布式事务之如何基于RocketMQ的事务消息特性实现分布式系统的最终一致性？》
3、Spring中Bean的生命周期和扩展点
详解
4、SpringBoot的启动流程
https://www.jianshu.com/p/bbb2cbe2c49a
https://www.cnblogs.com/javaguide/p/springboot-auto-config.html
@SpringBootApplication ==》@Configuration配置类，@ComponentScan类，包扫描，@EnableAutoConfiguration根据需求自动加载相关的bean
5、开放性问题
让你实现一个微服务框架，如何设计
6、动态代理是怎么实现的
详解
从 JVM 角度来说，动态代理是在运行时动态生成类字节码，并加载到 JVM 中的。
JDK 动态代理类使用步骤
1）定义一个接口及其实现类；
2）自定义 InvocationHandler 并重写invoke方法，在 invoke 方法中我们会调用原生方法（被代理类的方法）并自定义一些处理逻辑；
3）通过 Proxy.newProxyInstance(ClassLoader loader,Class[] interfaces,InvocationHandler h) 方法创建代理对象；
注意：JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。为了解决这个问题，我们可以用 CGLIB 动态代理机制来避免。
7、Spring的Aop？切入点是什么？环绕通知是什么？
AOP(Aspect-Oriented Programming:面向切面编程)能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任（例如事务处理、日志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。
Spring AOP就是基于动态代理的，如果要代理的对象，实现了某个接口，那么Spring AOP会使用JDK Proxy，去创建代理对象，而对于没有实现接口的对象，就无法使用 JDK Proxy 去进行代理了，这时候Spring AOP会使用Cglib生成一个被代理对象的子类来作为代理
使用 AOP 之后我们可以把一些通用功能抽象出来，在需要用到的地方直接使用即可，这样大大简化了代码量。我们需要增加新功能时也方便，这样也提高了系统扩展性。日志功能、事务管理等等场景都用到了 AOP 。
8、Spring IOC
IoC（Inverse of Control:控制反转）是一种设计思想，就是 将原本在程序中手动创建对象的控制权，交由Spring框架来管理。 IoC 在其他语言中也有应用，并非 Spring 特有。 IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个Map（key，value）,Map 中存放的是各种对象。
将对象之间的相互依赖关系交给 IoC 容器来管理，并由 IoC 容器完成对象的注入。这样可以很大程度上简化应用的开发，把应用从复杂的依赖关系中解放出来。 IoC 容器就像是一个工厂一样，当我们需要创建一个对象的时候，只需要配置好配置文件/注解即可，完全不用考虑对象是如何被创建出来的。
IoC源码阅读
9、spring框架用到了哪些设计模式？
详细介绍
工厂设计模式 : Spring使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
代理设计模式 : Spring AOP 功能的实现。
单例设计模式 : Spring 中的 Bean 默认都是单例的。
模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。
包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controller。
10、SpringMVC处理一个请求的过程
11、Springcloud微服务间的调用，如何设计权限限制服务进行调用？
12、RPC和HTTP
Http协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。基于TCP
RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。
1）差异：
RPC并没有规定数据传输格式，这个格式可以任意指定，不同的RPC协议，数据格式不一定相同。
Http中还定义了资源定位的路径，RPC中并不需要
最重要的一点：RPC需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进行封装。Http协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。
2）优点：RPC方式更加透明，对用户更方便；Http方式更灵活，没有规定API和语言，跨语言、跨平台
3）缺点：RPC方式需要在API层面进行封装，限制了开发的语言环境。
4）对比：
速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿
难度来看，RPC实现较为复杂，http相对比较简单
灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。
5）不同的使用场景：
如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。
如果需要更加灵活，跨语言、跨平台，显然http更合适
微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用基于Http的Rest风格服务。
RPC原理
RPC、IO多路复用、序列化&反序列化
13、Spring的事务是怎么实现的
底层是基于mysql的事务能力实现的
14、nginx原理
架构：多进程+异步非阻塞IO事件模型（epoll）
算法：
1）安装轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。虽然这种方式简便、成本低，但缺点是：可靠性低和负载分配不均衡。
2）权重：指定轮询几率，weight和访问比例成正比，用于后端服务器性能不均的情况。
3）ip_hash：上面2种方式都有一个问题，就是下一个请求来的时候，请求可能分发到另外一个服务器，当我们的程序不是无状态的时候（采用session保存数据），这个时候，就有一个很大的问题，比如把登录信息保存到了session中，那么跳转到另外一个服务器的时候就需要重新登录了，所以很多时候，我们只需要一个客户只访问一个服务器，那么就需要用到iphash。iphash的每个请求按访问ip的hash结果分配，这个每个访客访问一个后端服务器，可以解决session问题。
4）fair（第三方）：按后端服务器的响应时间来分配请求，响应时间短的优先分配。
5）url_hash（第三方）：按访问URL的hash结果进行分配请求，使每个URL定向到同一个后端服务器，后端服务器为缓存时比较有效。在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用hash算法。
15、服务注册、服务发现
一般如何实现？
16、一致性hash
https://www.cnblogs.com/lpfuture/p/5796398.html
17、微服务之间的调用，连接数怎么限制？
18、zookeeper如何保证数据一致性
https://www.cnblogs.com/zz-ksw/p/12786067.html
两阶段提交+过半写机制
19、zookeeper节点类型
临时节点（ephemeral）、持久节点（persistent）、顺序节点（sequence）。节点类型在创建时确定，之后不可修改。
（1）临时节点在客户端会话结束后，zookeeper会将该临时节点删除，且临时节点不可有子节点。
（2）持久节点不依赖于客户端的会话，只有客户端明确要删除该持久节点，才会将其删除。
也可以说是四种：
（1）PERSISTENT-持久节点除非手动删除，否则节点一直存在于 Zookeeper 上
（2）EPHEMERAL-临时节点临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
（3）PERSISTENT_SEQUENTIAL-持久顺序节点基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
（4）EPHEMERAL_SEQUENTIAL-临时顺序节点基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
20、Spring事务的传播
REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED
详解
21、zookeeper作为分布式锁
https://www.cnblogs.com/crazymakercircle/p/14504520.html
1）临时节点，所有等待节点监听锁节点--》一次释放锁的过程中要触发大量的watch，对集群造成冲击
2）临时顺序节点，只需监听上一个节点--》实现复杂（可用框架）
由于ZK本身的高可靠性、强一致性，ZK作为分布式锁性能不高，只适用于对可靠性要求高、并发量不是非常大的场景
22、注解的实现原理
https://zhuanlan.zhihu.com/p/387354943
元注解@Target,@Retention,@Documented,@Inherited
23、服务注册挂了后，消费者和生产者的通信会怎么样
消费者和生产者有保存对方的信息，还是可以相互通信，但是如果有ip变更，则不能通信了
24、ZK选举算法
选举算法详解
每当新Leader产生时，会生成一个epoch标号(标识当前属于那个Leader的统治时期)，这个epoch是递增的，followers如果确认了新的Leader存在，知道其epoch，就会拒绝epoch小于现任Leader epoch的所有请求。
投票信息包含 ：所选举leader的Serverid，Zxid，SelectionEpoch
Epoch判断，自身logicEpoch与SelectionEpoch判断：大于、小于、等于。
优先检查ZXID。ZXID比较大的服务器优先作为Leader。
如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
ZK中有三种选举算法，分别是LeaderElection,FastLeaderElection,AuthLeaderElection，FastLeaderElection和AuthLeaderElection是类似的选举算法，唯一区别是后者加入了认证信息， FastLeaderElection比LeaderElection更高效，后续的版本只保留FastLeaderElection。