大厂面试都这样了吗？

1、秒杀解决方案。

• 架构：扩容、业务分离、数据分离

• 产品：下单按钮控制、秒杀答题削峰、简化页面设计

• 前端：限流（反作弊）、静态化以及页面缓存

• 后端：内存数据库 ,消息队列、程序计数器、分布式锁

在回答问题的时候还需要拿出来其中一种做具体的探讨。回答思路为：分析其问题，秒杀会产生或带来什么问题，这些问题的解决方案有哪些，然后针对其中一种方案做具体的讲解。

 

2、最终一致性分布式事务如何保障实际生产中 99.99% 高可用？

对于常见的微服务系统，大部分接口调用是同步的，也就是一个服务直接调用另外一个服务的接口。

 

这个时候，用 TCC 分布式事务方案来保证各个接口的调用，要么一起成功，要么一起回滚，是比较合适的。

 

但是在实际系统的开发过程中，可能服务间的调用是异步的。也就是说，一个服务发送一个消息给 MQ，即消息中间件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。

 

然后，另外一个服务从 MQ 消费到一条消息后进行处理。这就成了基于 MQ 的异步调用了。

那么针对这种基于 MQ 的异步调用，如何保证各个服务间的分布式事务呢？也就是说，我希望的是基于 MQ 实现异步调用的多个服务的业务逻辑，要么一起成功，要么一起失败。

 

这个时候，就要用上可靠消息最终一致性方案，来实现分布式事务。

大家看上图，如果不考虑各种高并发、高可用等技术挑战的话，单从“可靠消息”以及“最终一致性”两个角度来考虑，这种分布式事务方案还是比较简单的。

 

可靠消息最终一致性方案的核心流程

①上游服务投递消息

如果要实现可靠消息最终一致性方案，一般你可以自己写一个可靠消息服务，实现一些业务逻辑。

 

首先，上游服务需要发送一条消息给可靠消息服务。这条消息说白了，你可以认为是对下游服务一个接口的调用，里面包含了对应的一些请求参数。

 

然后，可靠消息服务就得把这条消息存储到自己的数据库里去，状态为“待确认”。

 

接着，上游服务就可以执行自己本地的数据库操作，根据自己的执行结果，再次调用可靠消息服务的接口。

 

如果本地数据库操作执行成功了，那么就找可靠消息服务确认那条消息。如果本地数据库操作失败了，那么就找可靠消息服务删除那条消息。

 

此时如果是确认消息，那么可靠消息服务就把数据库里的消息状态更新为“已发送”，同时将消息发送给 MQ。

 

这里有一个很关键的点，就是更新数据库里的消息状态和投递消息到 MQ。这俩操作，你得放在一个方法里，而且得开启本地事务。

 

啥意思呢？如果数据库里更新消息的状态失败了，那么就抛异常退出了，就别投递到 MQ；如果投递 MQ 失败报错了，那么就要抛异常让本地数据库事务回滚。这俩操作必须得一起成功，或者一起失败。

 

如果上游服务是通知删除消息，那么可靠消息服务就得删除这条消息。

 

②下游服务接收消息

下游服务就一直等着从 MQ 消费消息好了，如果消费到了消息，那么就操作自己本地数据库。

 

如果操作成功了，就反过来通知可靠消息服务，说自己处理成功了，然后可靠消息服务就会把消息的状态设置为“已完成”。

 

③如何保证上游服务对消息的 100% 可靠投递？

上面的核心流程大家都看完：一个很大的问题就是，如果在上述投递消息的过程中各个环节出现了问题该怎么办？

 

我们如何保证消息 100% 的可靠投递，一定会从上游服务投递到下游服务？别着急，下面我们来逐一分析。

 

如果上游服务给可靠消息服务发送待确认消息的过程出错了，那没关系，上游服务可以感知到调用异常的，就不用执行下面的流程了，这是没问题的。

 

如果上游服务操作完本地数据库之后，通知可靠消息服务确认消息或者删除消息的时候，出现了问题。

 

比如：没通知成功，或者没执行成功，或者是可靠消息服务没成功的投递消息到 MQ。这一系列步骤出了问题怎么办？

 

其实也没关系，因为在这些情况下，那条消息在可靠消息服务的数据库里的状态会一直是“待确认”。

 

此时，我们在可靠消息服务里开发一个后台定时运行的线程，不停的检查各个消息的状态。

如果一直是“待确认”状态，就认为这个消息出了点什么问题。此时的话，就可以回调上游服务提供的一个接口，问问说，兄弟，这个消息对应的数据库操作，你执行成功了没啊？

如果上游服务答复说，我执行成功了，那么可靠消息服务将消息状态修改为“已发送”，同时投递消息到 MQ。

 

如果上游服务答复说，没执行成功，那么可靠消息服务将数据库中的消息删除即可。

 

通过这套机制，就可以保证，可靠消息服务一定会尝试完成消息到 MQ 的投递。

 

④如何保证下游服务对消息的 100% 可靠接收？

那如果下游服务消费消息出了问题，没消费到？或者是下游服务对消息的处理失败了，怎么办？

 

其实也没关系，在可靠消息服务里开发一个后台线程，不断的检查消息状态。

 

如果消息状态一直是“已发送”，始终没有变成“已完成”，那么就说明下游服务始终没有处理成功。

 

此时可靠消息服务就可以再次尝试重新投递消息到 MQ，让下游服务来再次处理。

 

只要下游服务的接口逻辑实现幂等性，保证多次处理一个消息，不会插入重复数据即可。

 

⑤如何基于 RocketMQ 来实现可靠消息最终一致性方案？

在上面的通用方案设计里，完全依赖可靠消息服务的各种自检机制来确保：

• 如果上游服务的数据库操作没成功，下游服务是不会收到任何通知。

• 如果上游服务的数据库操作成功了，可靠消息服务死活都会确保将一个调用消息投递给下游服务，而且一定会确保下游服务务必成功处理这条消息。

 

通过这套机制，保证了基于 MQ 的异步调用/通知的服务间的分布式事务保障。其实阿里开源的 RocketMQ，就实现了可靠消息服务的所有功能，核心思想跟上面类似。

 

只不过 RocketMQ 为了保证高并发、高可用、高性能，做了较为复杂的架构实现，非常的优秀。有兴趣的同学，自己可以去查阅 RocketMQ 对分布式事务的支持。

 

3、springcloud的组件你了解过哪些？

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

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

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

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

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

4、什么情况下会造成雪崩？该怎么避免这种情况？

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

 

解决方案：

1. 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。

2. 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。

3. 设置热点数据永远不过期。

另附资源下载：关注 “Java面试百分百”
1，后台回复：“面试资料”，可获取一份最新的Java面试资料。