第七篇：分布式组件（Dubbo、Netty、Nigix、Zookeeper、MQ、Job）
目录
一. Dubbo：高性能RPC框架
1、什么是Dubbo？Dubbo的工作流程知道吗？
2、在Provider上可以配置的Consumer属性有哪些？
3、Dubbo启动时如果服务不可用怎么办？
4、Dubbo使用什么序列化框架和通信框架，都支持什么协议？
5、Dubbo的负载均衡方案？
6、Dubbo的容错方案？
二. Netty：高性能NIO框架
1. Netty是什么？
2. BIO、NIO和AIO的区别？
三. Nigix：高性能Web容器
四. Zookeeper：分布式协调服务
1、Zookeeper是什么？能做什么事情？
2、Zookeeper是怎么保证主从同步的？
3、Zookeeper是怎么选举的？
4、Zookeeper如果宕机了怎么办？
5、Zookeeper的Watcher机制是什么样的？
五. MQ：分布式消息中间件
1. 为什么使用MQ？MQ的优缺点是什么？
2. ActiveMQ、RabbitMQ、RocketMQ、Kafka的优缺点和适应场景？
3. MQ有哪些常见问题？如何解决？
4. 如何解决消息队列延时及过期问题？消息队列满了怎么处理？几百万消息队列积压了几小时怎么处理？
5. 如何保证MQ高可用？
6. 如果让你写一个消息队列，该如何进行架构设计？说说你的思路
六. Job：分布式定时任务
（一）XXL-Job
一. Dubbo：高性能RPC框架
1、什么是Dubbo？Dubbo的工作流程知道吗？
Dubbo是分布式系统中常用的RPC框架，可以帮我们做服务地址的管理、服务的注册与发现、服务监控等。
角色：Container-容器、Provider-服务提供方、Consumer-服务消费方、Register-注册中心、Monitor-监控器
- Provider在Container上启动服务；
- Provider在Register上注册服务，Dubbo一般使用Zookeeper作为注册中心；
- Consumer在Register上订阅服务，注册中心返回服务器列表，如果列表有变更就通知Consumer；
- Conusmer根据负载均衡算法调用Provider；
- Monitor实时监控服务调用次数和时间。
2、在Provider上可以配置的Consumer属性有哪些？
超时时间、失败重试次数、负载均衡算法
3、Dubbo启动时如果服务不可用怎么办？
Dubbo启动时会监测服务可用性，不可用的话会抛出异常，阻止Spring启动。
4、Dubbo使用什么序列化框架和通信框架，都支持什么协议？
序列化框架：推荐Hessain，还有Dubbo，fastjson；通信框架：默认Netty；协议：Dubbo(推荐)、http、rest、redis等。
5、Dubbo的负载均衡方案？
随机、权重随机、轮训等
6、Dubbo的容错方案？
默认的是失败自动切换，这台服务器请求失败自动请求其他服务器；
还有快速失败，失败了就结束了；还有失败自动重试，记录下失败，定时重新请求。
二. Netty：高性能NIO框架
1. Netty是什么？
Netty是一个网络通信框架，一般用作基础通信组件。它封装了JDK的NIO，支持高并发，数据传输快，让我们使用起来更方便灵活。
2. BIO、NIO和AIO的区别？
BIO是同步阻塞IO，NIO是同步非阻塞IO，AIO是异步非阻塞IO。
三. Nigix：高性能Web容器
四. Zookeeper：分布式协调服务
1、Zookeeper是什么？能做什么事情？
Zookeeper是一个分布式协调框架，可以用来做服务注册中心、负载均衡、分布式协调、master选举、分布式锁等。
2、Zookeeper是怎么保证主从同步的？
使用了原子广播机制，它的核心是ZAB协议，ZAB协议有两个模式，恢复模式和广播模式。
当leader不可用时，ZAB就进入了崩溃模式，新领导选取出来后，崩溃模式结束，进入广播模式；
广播模式，只有leader能够处理写请求，当leader在本机写完之后，用广播通知其他follower，如果超过半数的follower都返回ACK，则commit。
3、Zookeeper是怎么选举的？
涉及到两个概念：
zxid：为了保证顺序性，每次更新请求都会有一个全局的时间戳，叫zxid
myid：每个集群的server都有一个唯一标识，server1，server2，12就是myid
PK规则：
每一轮投票，服务器都需要把自己的投票跟别人PK。PK规则是：先判断Zxid，谁的zxid大就投给谁，如果一样，则判断myid。
投票过程：假设有5台服务器
- server1给自己投了一票，并把（myid，zxid）发给其他服务器，此时server1的选票为（1，0）
- server2给自己投了一票， 同时跟server1交换结果，zxid都是0，server2的myid为2，所以server2胜出。但投票还没有超过半数，所以选举没结束
- server3给自己投了一票，同时跟server1、server2交换结果，server3的myid为3最大，所以server3胜出。此时投票超过半数，server3成为leader
- server4给自己投了一票，发现server3已经成为leader，则把自己的状态改为follower
- server5和server4一样
4、Zookeeper如果宕机了怎么办？
Zookeeper只要有超过半数的服务器可用，集群就可用。Zookeeper集群至少有3台服务器，如果是follower宕机还有其他follower可用，如果是leader宕机，就重新选取leader。
5、Zookeeper的Watcher机制是什么样的？
Zookeeper允许客户端向服务端注册一个watcher监听，如果服务端某个事件触发了watcher就通知客户端，客户端收到后回调服务端做相应的处理。
五. MQ：分布式消息中间件
1. 为什么使用MQ？MQ的优缺点是什么？
优点：
- 异步：相对于同步提高了吞吐量
- 解耦：系统间通过消息通信，不需要关系其他系统如何处理
- 削峰：可以使系统平稳地度过高峰期
缺点：
- 一致性问题：多个系统订阅消息，有的消费成功，有的消费失败，就会出现数据一致性问题
- 系统可用性降低：如果MQ挂了，系统就不可用了
- 系统复杂度增大：需要考虑很多问题，比如数据一致性问题，如果避免重复消费，如何保证消息传输的可靠性等
2. ActiveMQ、RabbitMQ、RocketMQ、Kafka的优缺点和适应场景？
- ActiveMQ 是老牌的消息中间件，国内很多传统企业在用，但是ActiveMQ不适合互联网公司，因为它对高并发高负载的支持不是很理想；
- RabbitMQ 可以支持高并发高负载高吞吐，并且开源社区也很活跃，较高频率的版本迭代来修复bug和优化，但是它是用erlang语言开发的，改造源码比较困难。一些中小型企业综合考虑会选择RabbitMQ。
- RocketMQ 是阿里开源的消息中间件，支持高并发高吞吐，以及分布式事务。而且RocketMQ是用java语言开发的，有需要可以对源码进行扩展和改造。
- Kafka 主要用于超高吞吐量的日志采集、实时数据同步、实时数据计算等场景。
3. MQ有哪些常见问题？如何解决？
- 解决 “消息的顺序问题” ：生产者和消息队列保持一对一的关系，由MQServer保证消息的顺序性，先收先发，后收后发
- 解决 “重复消费问题” ：由消费者保证处理消息的幂等性。只要消费消息的接口幂等，不管接收到多少条消息，结果都是一样的
- 解决 “消息的可靠性传输”：通过确认机制来保证。消费者接收到消息必须进行确认，只有消费者确认了消息，MQ才会把消息从队列中删除
- 解决 “消息不丢失”：[生产者丢消息]: 用transaction机制，发送消息前开启事务，如果异常，事务就会回滚；[消息队列丢消息]: 消息持久化；[消费者丢消息]: 把自动ack改为手动ack，自动ack是在接收到消息后就回复确认，手动ack是在处理完消息后手动回复确认
4. RocketMQ的发布订阅模式
参考文章：冒着期末挂科的风险也要给你看的消息队列和RocketMQ入门总结 - 掘金
Producer发送消息到Topic下的某一条Message Queue，Consumer订阅topic，消费的时候也会负载均衡的若干个Q，只拉去对应的Q消息
5. 如何解决消息队列延时及过期问题？消息队列满了怎么处理？几百万消息队列积压了几小时怎么处理？
6. 如何保证MQ高可用？
集群。
RabbitMQ一般使用镜像集群，也就是说创建的Queue存储在多台实例上，这样即使一台机器宕机了，其他机器仍然有这个Queue的信息。并且扩容也非常方便，只需增加机器，同步其他机器上的Queue即可。缺点是性能开销很大，消息要同步到所有机器上，导致网络带宽压力和消耗很重。
7. 如果让你写一个消息队列，该如何进行架构设计？说说你的思路
六. Job：分布式定时任务
（一）XXL-Job
1. xxl-job使用
可以在后台配置job的执行策略，包括：执行时间、路由策略、失败策略、超时策略等
