一. MQ：分布式消息中间件

1. 为什么使用MQ？MQ的优缺点是什么？

优点：

• 异步：相对于同步提高了吞吐量
• 解耦：系统间通过消息通信，不需要关系其他系统如何处理
• 削峰：可以使系统平稳地度过高峰期

缺点：

• 系统可用性降低：如果MQ挂了，系统就不可用了
• 系统复杂度增大：需要考虑很多问题，比如数据一致性问题（多个系统订阅消息，有的消费成功，有的消费失败，就会出现数据一致性问题），如何避免重复消费，如何保证消息传输的可靠性等
• 代码可读性降低：业务没有明显的调用链，出现问题不好追踪

2. ActiveMQ、RabbitMQ、RocketMQ、Kafka的优缺点和适应场景？

• ActiveMQ 是老牌的消息中间件，国内很多传统企业在用，但是ActiveMQ不适合互联网公司，因为它对高并发高负载的支持不是很理想；
• RabbitMQ 可以支持高并发高负载高吞吐，并且开源社区也很活跃，较高频率的版本迭代来修复bug和优化，但是它是用erlang语言开发的，改造源码比较困难。一些中小型企业综合考虑会选择RabbitMQ。
• RocketMQ 是阿里开源的消息中间件，支持高并发高吞吐，以及分布式事务。而且RocketMQ是用java语言开发的，有需要可以对源码进行扩展和改造。
• Kafka 主要有超高吞吐量，但是这是以牺牲消息可靠性为前提的。如果你的业务追求极致的吞吐量，又对可靠性没有极强的要求，就可以使用kafka。比如日志采集、实时数据同步、实时数据计算等场景。

3. MQ有哪些常见问题？如何解决？

• 解决 “消息的顺序问题” ：生产者和消息队列保持一对一的关系，由MQServer保证消息的顺序性，先收先发，后收后发
• 解决 “重复消费问题” ：由消费者根据业务保证处理消息的幂等性。只要消费消息的接口幂等，不管接收到多少条消息，结果都是一样的
• 解决 “消息的可靠性传输”：通过确认机制来保证。消费者接收到消息必须进行确认，只有消费者确认了消息，MQ才会把消息从队列中删除
• 解决 “消息不丢失”：[生产者丢消息]: 用transaction机制，发送消息前开启事务，如果异常，事务就会回滚；[消息队列丢消息]: 消息持久化；[消费者丢消息]: 把自动ack改为手动ack，自动ack是在接收到消息后就回复确认，手动ack是在处理完消息后手动回复确认

4. RocketMQ的架构是什么样？

        RocketMQ有两个核心组件，NameServer和Broker。

• NameServer是注册中心，Broker把自身注册到注册中心，生产者和消费者从NameServer获取Broker信息。
• Broker用接收、存储、投递消息，Broker中有多个Message Queue，每个Message Queue都必须归属于一个Topic，用于给消息分类，将来消费者可以订阅Topic。

5. RocketMQ的工作模式是什么？

        RocketMQ的工作模式是发布订阅模式：Producer发送消息到Topic下的某一条Message Queue，Consumer订阅Topic，消费的时候就拉取对应Topic中的消息。

 参考文章：👉冒着期末挂科的风险也要给你看的消息队列和RocketMQ入门总结 - 掘金

 6. RabbitMQ的架构和工作模式？

        生产者把消息发送到交换机，交换机把消息路由到不同queue，消费者再从queue消费消息。

RabbitMQ的交换机有三种类型

• Fanout：广播，把消息交给所有绑定了交换机的队列
• Direct：定向，把消息交给符合指定routing key的队列
• Topic：通配符，把消息交给符合routing pattern(路由模式)的队列

7. 几百万消息队列积压了几小时怎么处理？

消息大量积压有两个可能的原因：consumer出问题了 或 消息激增

• consumer出问题：如果说之前好好的消费，突然消费速度变慢甚至不消费，可能是consumer故障，此时需要修复consumer的问题
• 消息激增：消息量突然增加了许多，此时需要进行增加queue和consumer的数量（因为一个queue只能被一个consumer消费）。新建一个Topic，queue是原来的10倍，把原来topic下的消息直接转发到新的topic下，然后部署10倍的consumer进行消费

8. 消息队列满了导致消息丢失怎么处理

        消息队列满了必然是消息大量积压，甚至队列都无法存储，导致消息丢失。丢失的消息只能人工从业务系统中查询数据（比如1万个订单没处理），然后手动重新补发到mq里。

9. 如何解决消息队列延时过期问题？

        如果创建队列的时候配置了死信交换机和死信队列，过期消息就会被投递到死信队列里。否则就只能人工从业务系统中查询数据，然后补发到mq中了。

死信队列：死信队列是一种特殊队列，用于处理消费失败的消息，比如消息超时消费、消费者异常处理等，这些消息会被投递到死信队列，等待后续处理。

10. 如何保证MQ高可用？

        集群。RabbitMQ一般使用镜像集群，也就是说创建的Queue存储在多台实例上，这样即使一台机器宕机了，其他机器仍然有这个Queue的信息。并且扩容也非常方便，只需增加机器，同步其他机器上的Queue即可。缺点是性能开销很大，消息要同步到所有机器上，导致网络带宽压力和消耗很重。

11. 如果让你写一个消息队列，该如何进行架构设计？说说你的思路

• 实现核心功能：消息投递、存储、消费。生产者投递过来的消息，如何分发到broker -> topic -> queue；消息如何落磁盘持久化；消费者如何跟队列绑定消费消息等等。
• 保证数据不丢失：比如用事务保证生产者投递消息的过程；用持久化保证Message Queue中消息不丢失；用确认机制保证消息被消费者成功消费之后才会删除
• 高可用：可以参考RabbitMQ的镜像集群，每个queue都会存储在多台实例上，即使一个实例挂掉，其他实例依然可用。

二. Job：分布式定时任务

1. 分布式定时任务方案对比

• quartz：是一个轻量级的分布式任务组件。依赖数据库锁来任务执行的唯一性。缺点是没有图形化界面，且不支持任务分片(大任务拆成小任务分布式执行)，不适合分布式场景
• elastic-job：当当开发的分布式任务调度系统，功能强大，利用Zookeeper实现分布式协调。缺点是需要引入Zookeeper，mesos，增加系统复杂度，且学习成本高
• xxl-job：是大众点评员工开发的，优点是轻量级、简单易用，支持图形化界面，支持任务分片。缺点是其通过数据库锁保证任务执行的唯一性，如果短时间任务很多，那数据库锁竞争就会比较厉害，性能不好

2. xxl-job使用

可以在后台配置job的执行策略，包括：执行时间、路由策略、失败策略、超时策略等

3. xxl-job的系统架构是什么样？

        xxl-job 是一个分布式调度平台，有调度中心和执行器两大部分组成。

• 调度中心：负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。支持可视化界面，可以在调度中心对任务进行新增、修改、删除，可以查看日志，失败告警等。
• 执行器：负责接受调度请求，执行业务逻辑。接收调度中心发出的执行请求，终止请求，日志请求等。

4. xxl-job工作原理是什么？

• 任务执行器根据配置的调度中心地址，自动注册到调度中心
• 达到任务触发条件，调度中心下发任务
• 执行器基于线程池执行任务，并把执行结果放入内存队列，执行日志写入日志文件
• 执行器回调线程消费内存队列里的执行结果，并主动上报给调度中心
• 当用户在调度中心查看任务日志，调度中心请求任务执行器，查询日志结果并返回

三. Seata：分布式事务

四. Netty：高性能NIO框架

1. Netty是什么？

Netty是一个网络通信框架，一般用作基础通信组件。它封装了JDK的NIO，支持高并发，数据传输快，让我们使用起来更方便灵活。

2. BIO、NIO和AIO的区别？

BIO是同步阻塞IO，NIO是同步非阻塞IO，AIO是异步非阻塞IO。

五. Nigix：高性能Web容器