Java面试题

面试题：

HashMap底层实现原理，红黑树，B+树，B树的结构原理，volatile关键字，CAS（比较与交换）实现原理

Spring的AOP和IOC是什么？使用场景有哪些？Spring事务，事务的属性，传播行为，数据库隔离级别

Spring和SpringMVC，MyBatis以及SpringBoot的注解分别有哪些？SpringMVC的工作原理，SpringBoot框架的优点，MyBatis框架的优点

SpringCould组件有哪些，他们的作用是什么？（说七八个）微服务的CAP是什么？BASE是什么？

设计模式（说五六个）

Redis支持的数据类型以及使用场景，持久化，哨兵机制，缓存击穿，缓存穿透

线程是什么，有几种实现方式，它们之间的区别是什么，线程池实现原理，JUC并发包，ThreadLocal与Lock和Synchronize区别

分布式事务（不同系统之间如何保证数据的一致性（A系统写入数据，B系统因为某些原因没有写入成功，造成数据不一致））

安全性问题（数据篡改（拿到别人的URL,篡改数据（金额）发送给系统））

索引使用的限制条件,sql优化有哪些，数据同步问题（缓存，数据库数据同步）

初始化Bean对象有几个步骤，它的生命周期

JVM内存模型，算法，垃圾回收器，调优，类加载机制（双亲委派）,创建一个对象，这个对象在内存中是怎么分配的？

如何设计一个秒杀系统，（高并发高可用分布式集群）

悲观锁，乐观锁，读写锁，行锁，表锁，自旋锁，死锁，分布式锁，线程同步锁，公平锁，非公平锁分别是什么

堆溢出，栈溢出的出现场景以及解决方案

说出几种MQ之间的区别，以及为什么使用这种MQ，消息重复发送（幂等性），消息发送失败，消息掉包，长时间收不到消息，发送的消息太大造成接收不成功

单点登录实现原理

假如有上亿条数据，你如何快速找到其中一条你想要的数据（几种简单的算法）

Dubbo的运行原理，支持什么协议，与SpringCould相比它为什么效率要高一些，Zookeeper底层原理

假如你带一个团队，让你设计一个系统，你需要考虑哪些

写在前面：因平台限制，我只整理了部分面试题答案，需要完整面试、学习资料的，点赞+关注同时转发，然后私信“架构图”即可，文章最后有福利

好了，话不多说，来看面试题答案

答案：

HashMap底层实现原理，红黑树，B+树，B树的结构原理，volatile关键字，CAS（比较与交换）实现原理

首先HashMap是Map的一个实现类，而Map存储形式是键值对(key,value)的。可以看成是一个一个的Entry。Entry所存放的位置是由key来决定的。

Map中的key是无序的且不可重复的，所有的key可以看成是一个set集合，如果出现Map中的key如果是自定义类的对象，则必须重写hashCode和equals方法，因为如果不重写，使用的是Object类中的hashCode和equals方法，比较的是内存地址值不是比内容。

Map中的value是无序的可重复的，所有的value可以看成是Collection集合，Map中的value如果是自定义类的对象必须重写equals方法。

至于要重写hashCode和equals分别做什么用，拿hashMap底层原理来说：

当我们向HashMap中存放一个元素(k1,v1)，先根据k1的hashCode方法来决定在数组中存放的位置。

如果这个位置没有其它元素，将(k1,v1)直接放入Node类型的数组中，这个数组初始化容量是16，默认的加载因子是0.75，也就是当元素加到12的时候，底层会进行扩容，扩容为原来的2倍。如果该位置已经有其它元素(k2,v2)，那就调用k1的equals方法和k2进行比较二个元素是否相同，如果结果为true，说明二个元素是一样的，用v1替换v2，如果返回值为false，二个元素不一样，就用链表的形式将(k1,v1)存放。

不过当链表中的数据较多时，查询的效率会下降，所以在JDK1.8版本后做了一个升级，hashmap就是当链表中的元素达到8并且元素数量大于64时，会将链表替换成红黑树才会树化时，会将链表替换成红黑树，来提高查找效率。因为对于搜索，插入，删除操作多的情况下，使用红黑树的效率要高一些。

原因是因为红黑树是一种特殊的二叉查找树，二叉查找树所有节点的左子树都小于该节点，所有节点的右子树都大于该节点，就可以通过大小比较关系来进行快速的检索。

在红黑树上插入或者删除一个节点之后，红黑树就发生了变化，可能不满足红黑树的5条性质，也就不再是一颗红黑树了，而是一颗普通的树，可以通过左旋和右旋，使这颗树重新成为红黑树。红黑树的5条性质（根节点是黑色，每个节点是黑色或者是红色，每个叶子节点是黑色，如果一个节点是红色它的子节点必须是黑色的，从一个节点到该节点的子孙外部节点的所有路径上包含相同数目的黑点）

而且像这种二叉树结构比较常见的使用场景是Mysql二种引擎的索引，Myisam使用的是B树，InnoDB使用的是B+树。

首先B树它的每个节点都是Key.value的二元组，它的key都是从左到右递增的排序，value中存储数据。这种模式在读取数据方面的性能很高，因为有单独的索引文件，Myisam 的存储文件有三个.frm是表的结构文件，.MYD是数据文件，.MYI是索引文件。不过Myisam 也有些缺点它只支持表级锁，不支持行级锁也不支持事务，外键等，所以一般用于大数据存储。

然后是InnoDB，它的存储文件相比Myisam少一个索引文件，它是以 ID 为索引的数据存储，数据现在都被存在了叶子结点，索引在非叶结点上。而这些节点分散在索引页上。在InnoDB里，每个页默认16KB，假设索引的是8B的long型数据，每个key后有个页号4B，还有6B的其他数据，那么每个页的扇出系数为16KB/(8B+4B+6B)≈1000，即每个页可以索引1000个key。在高度h=3时，s=1000^3=10亿！！也就是说，InnoDB通过三次索引页的I/O，即可索引10亿的key，而非叶节点这一行存储的索引，数量就多了，I/O的次数就少了。而Myisam在每个节点都存储数据和索引，这样就减少了每页存储的索引数量。而且InnoDB它还支持行级，表级锁，也支持事务，外键.

另外对于HashMap实际使用过程中还是会出现一些线程安全问题：

HashMap是线程不安全的，在多线程环境下，使用Hashmap进行put操作会引起死循环，导致CPU利用率接近100%，而且会抛出并发修改异常，导致原因是并发争取线程资源，修改数据导致的，一个线程正在写，一个线程过来争抢，导致线程写的过程被其他线程打断，导致数据不一致。

HashTable是线程安全的，只不过实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁。多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。

为了应对hashmap在并发环境下不安全问题可以使用，ConcurrentHashMap大量的利用了volatile，CAS等技术来减少锁竞争对于性能的影响。

在JDK1.7版本中ConcurrentHashMap避免了对全局加锁，改成了局部加锁（分段锁），分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。不过这种结构的带来的副作用是Hash的过程要比普通的HashMap要长。

所以在JDK1.8版本中CurrentHashMap内部中的value使用volatile修饰，保证并发的可见性以及禁止指令重排，只不过volatile不保证原子性，使用为了确保原子性，采用CAS（比较交换）这种乐观锁来解决。

CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。

如果内存地址里面的值和A的值是一样的，那么就将内存里面的值更新成B。CAS是通过无限循环来获取数据的，若果在第一轮循环中，a线程获取地址里面的值被b线程修改了，那么a线程需要自旋，到下次循环才有可能机会执行。

volatile有三个特性：可见性，不保证原子性，禁止指令重排。

可见性：线程1从主内存中拿数据1到自己的线程工作空间进行操作（假设是加1）这个时候数据1已经改为数据2了，将数据2写回主内存时通知其他线程（线程2，线程3），主内存中的数据1已改为数据2了，让其他线程重新拿新的数据（数据2）。

不保证原子性：线程1从主内存中拿了一个值为1的数据到自己的工作空间里面进行加1的操作，值变为2，写回主内存，然后还没有来得及通知其他线程，线程1就被线程2抢占了，CPU分配，线程1被挂起，线程2还是拿着原来主内存中的数据值为1进行加1，值变成2，写回主内存，将主内存值为2的替换成2，这时线程1的通知到了，线程2重新去主内存拿值为2的数据。

禁止指令重排：首先指令重排是程序执行的时候不总是从上往下执行的，就像高考答题，可以先做容易的题目再做难的，这时做题的顺序就不是从上往下了。禁止指令重排就杜绝了这种情况。

（一般面试官开始问你会从java基础问起，一问大多数会问到集合这一块，而集合问的较多的是HashMap，这个时候你就可以往这些方向带着面试官问你，而且扩展的深度也够，所以上面的干货够你说个十来分钟吧，第一个问题拿下后，面试官心里至少简单你的基础够扎实，第一印象分就留下了）

Spring的AOP和IOC是什么？使用场景有哪些？Spring事务与数据库事务，传播行为，数据库隔离级别

AOP：面向切面编程。

即在一个功能模块中新增其他功能，比方说你要下楼取个快递，你同事对你说帮我也取一下呗，你就顺道取了。在工作中如果系统中有些包和类中没有使用AOP，例如日志，事务和异常处理，那么就必须在每个类和方法中去实现它们。 代码纠缠每个类和方法中都包含日志，事务以及异常处理甚至是业务逻辑。在一个这样的方法中，很难分清代码中实际做的是什么处理。AOP 所做的就是将所有散落各处的事务代码集中到一个事务切面中。

场景

比方说我现在要弄一个日志，记录某些个接口调用的方法时间。使用Aop我可以在这个接口前插入一段代码去记录开始时间，在这个接口后面去插入一段代码记录结束时间。

又或者你去访问数据库，而你不想管事务（太烦），所以，Spring在你访问数据库之前，自动帮你开启事务，当你访问数据库结束之后，自动帮你提交/回滚事务！

异常处理你可以开启环绕通知，一旦运行接口报错，环绕通知捕获异常跳转异常处理页面。

动态代理

Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。它的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理。JDK动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是InvocationHandler接口和Proxy类。如果目标类没有实现接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。

IOC：依赖注入或者叫做控制反转。

正常情况下我们使用一个对象时都是需要new Object()的。而ioc是把需要使用的对象提前创建好，放到spring的容器里面。

所有需要使用的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。DI(依赖注入)其实就是IOC的另外一种说法，其实它们是同一个概念的不同角度描述。

什么叫事务传播行为？

传播，至少有两个东西，才可以发生传播。单体不存在传播这个行为。事务传播行为就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行。

Spring支持7中事务传播行为

propagation_required（需要传播）：当前没有事务则新建事务，有则加入当前事务

propagation_supports（支持传播）：支持当前事务，如果当前没有事务则以非事务方式执行

propagation_mandatory（强制传播）：使用当前事务，如果没有则抛出异常

propagation_nested（嵌套传播）：如果当前存在事务，则在嵌套事务内执行，如果当前没有事务，则执行需要传播行为。

propagation_never（绝不传播）：以非事务的方式执行，如果当前有事务则抛出异常

propagation_requires_new（传播需要新的）：新建事务，如果当前有事务则把当前事务挂起

propagation_not_supported（不支持传播）：以非事务的方式执行，如果当前有事务则把当前事务挂起

数据库事务的隔离级别

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

√: 可能出现 ×: 不会出现

Spring和SpringMVC，MyBatis以及SpringBoot的注解分别有哪些？SpringMVC的工作原理，SpringBoot框架的优点，MyBatis框架的优点

Spring注解：

声明bean的注解

@Component 组件，没有明确的角色

@Service 在业务逻辑层使用（service层）

@Repository 在数据访问层使用（dao层）

@Controller 在展现层使用，控制器的声明（C）

注入bean的注解

@Autowired 由Spring提供

@Resource 由JSR-250提供

java配置类相关注解

@Bean 注解在方法上，声明当前方法的返回值为一个bean，替代xml中的方式（方法上）

@Configuration 声明当前类为配置类，其中内部组合了@Component注解，表明这个类是一个bean（类上）

@ComponentScan 用于对Component进行扫描，相当于xml中的（类上）

切面（AOP）相关注解

@Aspect 声明一个切面（类上） 使用@After、@Before、@Around定义建言（advice），可直接将拦截规则（切点）作为参数。

@After 在方法执行之后执行（方法上） @Before 在方法执行之前执行（方法上） @Around 在方法执行之前与之后执行（方法上）

@PointCut 声明切点 在java配置类中使用@EnableAspectJAutoProxy注解开启Spring对AspectJ代理的支持（类上）

@Value注解

@Value 为属性注入值 注入操作系统属性@Value("#{systemProperties['os.name']}")String osName;

注入表达式结果@Value("#{ T(java.lang.Math).random() * 100 }") String randomNumber;

注入其它bean属性@Value("#{domeClass.name}")String name;

注入文件资源@Value("classpath:com/hgs/hello/test.txt")String Resource file;

注入网站资源@Value("http://www.cznovel.com")Resource url;

注入配置文件Value("${book.name}")String bookName;

异步相关

@EnableAsync 配置类中，通过此注解开启对异步任务的支持，叙事性AsyncConfigurer接口（类上）

@Async 在实际执行的bean方法使用该注解来申明其是一个异步任务（方法上或类上所有的方法都将异步，需要@EnableAsync开启异步任务）

定时任务相关

@EnableScheduling 在配置类上使用，开启计划任务的支持（类上）

@Scheduled 来申明这是一个任务，包括cron,fixDelay,fixRate等类型（方法上，需先开启计划任务的支持）

SpringMVC注解

@EnableWebMvc 在配置类中开启Web MVC的配置支持，如一些ViewResolver或者MessageConverter等，若无此句，重写WebMvcConfigurerAdapter方法（用于对SpringMVC的配置）。

@Controller 声明该类为SpringMVC中的Controller

@RequestMapping 用于映射Web请求，包括访问路径和参数（类或方法上）

@ResponseBody 支持将返回值放在response内，而不是一个页面，通常用户返回json数据（返回值旁或方法上）

@RequestBody 允许request的参数在request体中，而不是在直接连接在地址后面。（放在参数前）

@PathVariable 用于接收路径参数，比如@RequestMapping(“/hello/{name}”)申明的路径，将注解放在参数中前，即可获取该值，通常作为Restful的接口实现方法。

@RestController 该注解为一个组合注解，相当于@Controller和@ResponseBody的组合，注解在类上，意味着，该Controller的所有方法都默认加上了@ResponseBody。

@ControllerAdvice 通过该注解，我们可以将对于控制器的全局配置放置在同一个位置，注解了@Controller的类的方法可使用@ExceptionHandler、@InitBinder、@ModelAttribute注解到方法上， 这对所有注解了 @RequestMapping的控制器内的方法有效。

@ExceptionHandler 用于全局处理控制器里的异常

@InitBinder 用来设置WebDataBinder，WebDataBinder用来自动绑定前台请求参数到Model中。

@ModelAttribute 本来的作用是绑定键值对到Model里，在@ControllerAdvice中是让全局的@RequestMapping都能获得在此处设置的键值对。

Mybatis注解：（偷个懒，不使用表格了，嘻嘻）

增删改查：@Insert、@Update、@Delete、@Select、@MapKey、@Options、@SelelctKey、@Param、@InsertProvider、@UpdateProvider、@DeleteProvider、@SelectProvider

结果集映射：@Results、@Result、@ResultMap、@ResultType、@ConstructorArgs、@Arg、@One、@Many、@TypeDiscriminator、@Case

缓存：@CacheNamespace、@Property、@CacheNamespaceRef、@Flush

SpringBoot注解：

@SpringBootApplication：申明让spring boot自动给程序进行必要的配置，这个配置等同于：

@Configuration ，@EnableAutoConfiguration 和 @ComponentScan 三个配置。

@ResponseBody：表示该方法的返回结果直接写入HTTP response body中，一般在异步获取数据时使用，用于构建RESTful的api。在使用@RequestMapping后，返回值通常解析为跳转路径，加上@esponsebody后返回结果不会被解析为跳转路径，而是直接写入HTTP response body中。比如异步获取json数据，加上@Responsebody后，会直接返回json数据。该注解一般会配合@RequestMapping一起使用。

@Controller：用于定义控制器类，在spring项目中由控制器负责将用户发来的URL请求转发到对应的服务接口（service层），一般这个注解在类中，通常方法需要配合注解@RequestMapping。

@RestController：用于标注控制层组件(如struts中的action)，@ResponseBody和@Controller的合集。

@RequestMapping：提供路由信息，负责URL到Controller中的具体函数的映射。

@EnableAutoConfiguration：SpringBoot自动配置（auto-configuration）：尝试根据你添加的jar依赖自动配置你的Spring应用。例如，如果你的classpath下存在HSQLDB，并且你没有手动配置任何数据库连接beans，那么我们将自动配置一个内存型（in-memory）数据库”。你可以将@EnableAutoConfiguration或者@SpringBootApplication注解添加到一个@Configuration类上来选择自动配置。如果发现应用了你不想要的特定自动配置类，你可以使用@EnableAutoConfiguration注解的排除属性来禁用它们。

SpringMVC的工作原理：

SpringBoot框架的优点:

--创建独立的 Spring 应用程序 ；

--嵌入的 Tomcat 、 Jetty 或者 Undertow，无须部署 WAR 文件：

--允许通过 Maven 来根据需要获取 starter;

--尽可能地自动配置 Spring;

--提供生产就绪型功能，如指标、健康检查和外部配置；

--绝对没有代码生成，对 XML 没有要求配置 。

MyBatis框架的优点：

JDBC相比，减少了50%以上的代码量，消除了JDBC大量冗余的代码，不需要手动开关连接

很好的与各种数据库兼容（因为MyBatis使用JDBC来连接数据库，所以只要JDBC支持的数据库MyBatis都支持，而JDBC提供了可扩展性，所以只要这个数据库有针对Java的jar包就可以就可以与MyBatis兼容），开发人员不需要考虑数据库的差异性。

提供了很多第三方插件（分页插件 / 逆向工程）

SQL写在XML里，从程序代码中彻底分离，解除sql与程序代码的耦合，便于统一管理和优化，并可重用。

提供映射标签，支持对象与数据库的ORM字段关系映射。

SpringCould组件有哪些，他们的作用是什么（说七八个）？微服务的CAP是什么？BASE是什么？

一、业务场景介绍

先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下：

创建一个订单后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付”

扣减相应的商品库存

通知仓储中心，进行发货

给用户的这次购物增加相应的积分

针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下：

用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态

订单服务调用库存服务，完成相应功能

订单服务调用仓储服务，完成相应功能

订单服务调用积分服务，完成相应功能

至此，整个支付订单的业务流程结束

下图这张图，清晰表明了各服务间的调用过程：

好！有了业务场景之后，咱们就一起来看看Spring Cloud微服务架构中，这几个组件如何相互协作，各自发挥的作用以及其背后的原理。

二、Spring Cloud核心组件：Eureka

咱们来考虑第一个问题：订单服务想要调用库存服务、仓储服务，或者积分服务，怎么调用？

订单服务压根儿就不知道人家库存服务在哪台机器上啊！他就算想要发起一个请求，都不知道发送给谁，有心无力！

这时候，就轮到Spring Cloud Eureka出场了。Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。

咱们来看看下面的这张图，结合图来仔细剖析一下整个流程：

如上图所示，库存服务、仓储服务、积分服务中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。说白了，就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口。而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号

订单服务里也有一个Eureka Client组件，这个Eureka Client组件会找Eureka Server问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢？然后就可以把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。

这时如果订单服务想要调用库存服务，不就可以找自己本地的Eureka Client问一下库存服务在哪台机器？监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。

总结一下：

Eureka Client：负责将这个服务的信息注册到Eureka Server中

Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号

三、Spring Cloud核心组件：Feign

现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。但是新问题又来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？

这是上述流程翻译的代码片段，咱们一起来看看，体会一下这种绝望而无助的感受！！！

友情提示，前方高能：

看完上面那一大段代码，有没有感到后背发凉、一身冷汗？实际上你进行服务间调用时，如果每次都手写代码，代码量比上面那段要多至少几倍，所以这个事压根儿就不是地球人能干的。

既然如此，那怎么办呢？别急，Feign早已为我们提供好了优雅的解决方案。来看看如果用Feign的话，你的订单服务调用库存服务的代码会变成啥样？

看完上面的代码什么感觉？是不是感觉整个世界都干净了，又找到了活下去的勇气！没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。人家Feign Client会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起靕求、获取响应、解析响应，等等。这一系列脏活累活，人家Feign全给你干了。

那么问题来了，Feign是如何做到这么神奇的呢？很简单，Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：

首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理

接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心

Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址

最后针对这个地址，发起请求、解析响应

四、Spring Cloud核心组件：Ribbon

说完了Feign，还没完。现在新的问题又来了，如果人家库存服务部署在了5台机器上，如下所示：

192.168.169:9000

192.168.170:9000

192.168.171:9000

192.168.172:9000

192.168.173:9000

这下麻烦了！人家Feign怎么知道该请求哪台机器呢？

这时Spring Cloud Ribbon就派上用场了。Ribbon就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上

Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。这是啥？简单来说，就是如果订单服务对库存服务发起10次请求，那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器，接着再来—个循环，第1台机器、第2台机器。。。以此类推。

此外，Ribbon是和Feign以及Eureka紧密协作，完成工作的，具体如下：

首先Ribbon会从 Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。

然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器

Feign就会针对这台机器，构造并发起请求。

对上述整个过程，再来一张图，帮助大家更深刻的理解：

五、Spring Cloud核心组件：Hystrix

在微服务架构里，一个系统会有很多的服务。以本文的业务场景为例：订单服务在一个业务流程里需要调用三个服务。现在假设订单服务自己最多只有100个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。

咱们一起来分析一下，这样会导致什么问题？

如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的100个线程都会卡在请求积分服务这块。导致订单服务没有一个线程可以处理请求

然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了

上面这个，就是微服务架构中恐怖的服务雪崩问题，

如下图所示：

如上图，这么多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。

但是我们思考一下，就算积分服务挂了，订单服务也可以不用挂啊！为什么？

我们结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了

如果积分服务挂了，大不了等他恢复之后，慢慢人肉手工恢复数据！为啥一定要因为一个积分服务挂了，就直接导致订单服务也挂了呢？不可以接受！

现在问题分析完了，如何解决？

这时就轮到Hystrix闪亮登场了。Hystrix是隔离、熔断以及降级的一个框架。啥意思呢？说白了，Hystrix会搞很多个小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。

打个比方：现在很不幸，积分服务挂了，会咋样？

当然会导致订单服务里那个用来调用积分服务的线程都卡死不能工作了啊！但由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。

这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟干啥呢？有意义吗？当然没有！所以我们直接对积分服务熔断不就得了，比如在5分钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断！

那人家又说，兄弟，积分服务挂了你就熔断，好歹你干点儿什么啊！别啥都不干就直接返回啊？没问题，咱们就来个降级：每次调用积分服务，你就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，你可以根据这些记录手工加一下积分。这个过程，就是所谓的降级。

为帮助大家更直观的理解，接下来用一张图，梳理一下Hystrix隔离、熔断和降级的全流程：

六、Spring Cloud核心组件：Zuul

说完了Hystrix，接着给大家说说最后一个组件：Zuul，也就是微服务网关。这个组件是负责网络路由的。不懂网络路由？行，那我给你说说，如果没有Zuul的日常工作会怎样？

假设你后台部署了几百个服务，现在有个前端兄弟，人家请求是直接从浏览器那儿发过来的。打个比方：人家要请求一下库存服务，你难道还让人家记着这服务的名字叫做inventory-service？部署在5台机器上？就算人家肯记住这一个，你后台可有几百个服务的名称和地址呢？难不成人家请求一个，就得记住一个？你要这样玩儿，那真是友谊的小船，说翻就翻！

上面这种情况，压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。

而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

七、总结：

最后再来总结一下，上述几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：

Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里

Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台

Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求

Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题

Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务

以上就是我们通过一个电商业务场景，阐述了Spring Cloud微服务架构几个核心组件的底层原理。

文字总结还不够直观？没问题！我们将Spring Cloud的5个核心组件通过一张图串联起来，再来直观的感受一下其底层的架构原理：

五大核心组件讲完了，面试官心中已经知道你对SpringCould的有一定的了解了，但这还不够，你如果讲到这个层面，部分面试官还会继续问，因为你讲解的这些其他面试者也讲过，可能也就你讲的比较细一些，但本质还是和他们差不了太多，有些公司可能集中招人，负责面试的可能就一个，你想想他这一天可以面试多少个人，这个时候你就需要继续拓展其他组件，来突出你的不同了。

Spring Cloud Sleuth（服务链路追踪），Spring Cloud Bus（消息总线），Spring Cloud Config（分布式配置中心）之类的，这里我就不继续写了，给上一个SpringCould专栏（一位大佬写的，挺不错的）你去看看吧，最好能实现动手敲上一套，后面你会发现自己对SpringCould的理解远超其他人。

CAP 定论

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

C 一致性即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

A 可用性服务一直可用，而且是正常响应时间。

P 分区容错性即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

对于多数大型互联网应用的场景，一般保证满足 P 和 A，舍弃 C（一致性无法保证，退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流失的严重程度。如原来同步架构的时候如果没有库存，就马上告诉客户库存不足无法下单。但在微服务框架下订单和库存可能是两个微服务对应两个数据库，用户下单时订单服务是立即生成的，很可能过了一会系统通知你订单被取消掉（最终一致性）。就像抢购“小米手机”一样，几十万人在排队，排了很久告诉你没货了，明天再来吧。

对于涉及到钱财这样不能有一丝让步的场景，C 必须保证。网络发生故障宁可停止服务，这是保证 CA，舍弃 P。

还有一种是保证 CP，舍弃 A。例如网络故障事只读不写。

设计模式

1. 根据目的来分

根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。

创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。

结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。

行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。

2. 根据作用范围来分

根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。

类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。

对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上 4 种，其他的都是对象模式。

3.设计模式的功能

1、FACTORY 工厂方法：追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory 工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

2、BUILDER建造者模式：MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖） 建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD抽象工厂：请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。 工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

4、PROTOTYPE 原型模式：跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

5、SINGLETON 单态模式：俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事) 单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 [b:9ceca65206]结构型模式[/b:9ceca65206]

6、ADAPTER 适配器模式：在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我) 适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

7、BRIDGE 桥梁模式：早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了 桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

8、COMPOSITE合成模式：Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？ 合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

9、DECORATOR装饰模式：Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？ 装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。1增加由一些基本功能的排列组合而产生的非常大量的功能。

10、FACADE门面模式：我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。 门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

11、FLYWEIGHT享元模式：每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。 享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

12、PROXY代理模式：跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自己的回答，接收到其他的话时再通知我回答，怎么样，酷吧。 代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。

Redis支持的数据类型以及使用场景，持久化，哨兵机制，缓存击穿，缓存穿透

简单介绍一个redis？

redis是内存中的数据结构存储系统，一个key-value类型的非关系型数据库，可持久化的数据库，相对于关系型数据库（数据主要存在硬盘中），性能高，因此我们一般用redis来做缓存使用；并且redis支持丰富的数据类型，比较容易解决各种问题，因此redis可以用来作为注册中心，数据库、缓存和消息中间件。Redis的Value支持5种数据类型，string、hash、list、set、zset（sorted set）;

String类型：一个key对应一个value

Hash类型：它的key是string类型，value又是一个map（key-value），适合存储对象。

List类型：按照插入顺序的字符串链表（双向链表），主要命令是LPUSH和RPUSH，能够支持反向查找和遍历

Set类型：用哈希表类型的字符串序列，没有顺序，集合成员是唯一的，没有重复数据，底层主要是由一个value永远为null的hashmap来实现的。

zset类型：和set类型基本一致，不过它会给每个元素关联一个double类型的分数（score），这样就可以为成员排序，并且插入是有序的。

你还用过其他的缓存吗？这些缓存有什么区别？都在什么场景下去用？

对于缓存了解过redis和memcache

Memcache和redis的区别：

数据支持的类型：redis不仅仅支持简单的k/v类型的数据，同时还支持list、set、zset、hash等数据结构的存储；memcache只支持简单的k/v类型的数据，key和value都是string类型

可靠性：memcache不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的；redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价

性能上：对于存储大数据，memcache的性能要高于redis

应用场景：

Memcache：适合多读少写，大数据量的情况（一些官网的文章信息等）

Redis：适用于对读写效率要求高、数据处理业务复杂、安全性要求较高的系统

案例：分布式系统，存在session之间的共享问题，因此在做单点登录的时候，我们利用redis来模拟了session的共享，来存储用户的信息，实现不同系统的session共享；

对redis的持久化了解不？

redis的持久化方式有两种：

RDB（半持久化方式）：按照配置不定期的通过异步的方式、快照的形式直接把内存中的数据持久化到磁盘的一个dump.rdb文件（二进制的临时文件）中，redis默认的持久化方式，它在配置文件（redis.conf）中。

优点：只包含一个文件，将一个单独的文件转移到其他存储媒介上，对于文件备份、灾难恢复而言，比较实用。

缺点：系统一旦在持久化策略之前出现宕机现象，此前没有来得及持久化的数据将会产生丢失

RDB持久化配置：

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF（全持久化的方式）：把每一次数据变化都通过write()函数将你所执行的命令追加到一个appendonly.aof文件里面，Redis默认是不支持这种全持久化方式的，需要在配置文件（redis.conf）中将appendonly no改成appendonly yes

优点：数据安全性高，对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机问题，也不会破坏日志文件中已经存在的内容；

缺点：对于数量相同的数据集来说，aof文件通常要比rdb文件大，因此rdb在恢复大数据集时的速度大于AOF；

AOF持久化配置:

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会都调用fsync刷新到aof文件，非常慢，但是安全；

appendfsync everysec #每秒钟都调用fsync刷新到aof文件中，很快，但是可能丢失一秒内的数据，推荐使用，兼顾了速度和安全；

appendfsync no #不会自动同步到磁盘上，需要依靠OS（操作系统）进行刷新，效率快，但是安全性就比较差；

二种持久化方式区别：

AOF在运行效率上往往慢于RDB，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效；

如果缓存数据安全性要求比较高的话，用aof这种持久化方式（比如项目中的购物车）；

如果对于大数据集要求效率高的话，就可以使用默认的。而且这两种持久化方式可以同时使用。

做过redis的集群吗？你们做集群的时候搭建了几台，都是怎么搭建的？

Redis的数据是存放在内存中的，不适合存储大数据，大数据存储一般公司常用hadoop中的Hbase或者MogoDB。redis主要用来处理高并发的，用我们的项目来说，电商项目如果并发大的话，一台单独的redis是不能足够支持我们的并发，这就需要我们扩展多台设备协同合作，即用到集群。

Redis搭建集群的方式有多种，例如：客户端分片、Twemproxy、Codis等，但是redis3.0之后就支持redis-cluster集群，这种方式采用的是无中心结构，每个节点保存数据和整个集群的状态，每个节点都和其他所有节点连接。如果使用的话就用redis-cluster集群。集群这块是公司运维搭建的，具体怎么搭建不是太了解。

我们项目中redis集群主要搭建了6台，3主（为了保证redis的投票机制）3从（高可用），每个主服务器都有一个从服务器，作为备份机。所有的节点都通过PING-PONG机制彼此互相连接；客户端与redis集群连接，只需要连接集群中的任何一个节点即可；Redis-cluster中内置了16384个哈希槽，Redis-cluster把所有的物理节点映射到【0-16383】slot上，负责维护。

redis有事务吗？

Redis是有事务的，redis中的事务是一组命令的集合，这组命令要么都执行，要不都不执行，保证一个事务中的命令依次执行而不被其他命令插入。redis的事务是不支持回滚操作的。redis事务的实现，需要用到MULTI（事务的开始）和EXEC（事务的结束）命令 ;

缓存穿透

缓存查询一般都是通过key去查找value，如果不存在对应的value，就要去数据库中查找。如果这个key对应的value在数据库中也不存在，并且对该key并发请求很大，就会对数据库产生很大的压力，这就叫缓存穿透

解决方案：

1.对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。

2.将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

3.如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存雪崩

当缓存服务器重启或者大量缓存集中在一段时间内失效，发生大量的缓存穿透，这样在失效的瞬间对数据库的访问压力就比较大，所有的查询都落在数据库上，造成了缓存雪崩。 这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。