分布式服务（RPC）+分布式消息队列（MQ）面试题精选

分布式系统（distributed system）是创建在网络之上的软件系统。正是由于软件的特性，因此分布式系统具备高度的内聚性和透明性。所以，网络和分布式系统之间的区别更多的在于高层软件（特别是操做系统），而不是硬件。

分布式消息队列（MQ）

为何使用 MQ？

• 异步处理 - 相比于传统的串行、并行方式，提升了系统吞吐量。
• 应用解耦 - 系统间经过消息通讯，不用关心其余系统的处理。
• 流量削锋 - 能够经过消息队列长度控制请求量；能够缓解短期内的高并发请求。
• 日志处理 - 解决大量日志传输。
• 消息通信 - 消息队列通常都内置了高效的通讯机制，所以也能够用在纯的消息通信。好比实现点对点消息队列，或者聊天室等。

如何保证 MQ 的高可用？

1. 将全部 Broker 和待分配的 Partition 排序
2. 将第 i 个 Partition 分配到第（i mod n）个 Broker 上
3. 将第 i 个 Partition 的第 j 个 Replica 分配到第（(i + j) mode n）个 Broker 上

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

MQ 的常见问题有：

1. 消息的顺序问题
2. 消息的重复问题

消息的顺序问题

消息有序指的是能够按照消息的发送顺序来消费。

假如生产者产生了 2 条消息：M一、M2，假定 M1 发送到 S1，M2 发送到 S2，若是要保证 M1 先于 M2 被消费，怎么作？

解决方案：

（1）保证生产者 - MQServer - 消费者是一对一对一的关系

缺陷：

• 并行度就会成为消息系统的瓶颈（吞吐量不够）

• 更多的异常处理，好比：只要消费端出现问题，就会致使整个处理流程阻塞，咱们不得不花费更多的精力来解决阻塞的问题。 （2）经过合理的设计或者将问题分解来规避。

• 不关注乱序的应用实际大量存在

• 队列无序并不意味着消息无序 因此从业务层面来保证消息的顺序而不只仅是依赖于消息系统，是一种更合理的方式。

消息的重复问题

形成消息重复的根本缘由是：网络不可达。

因此解决这个问题的办法就是绕过这个问题。那么问题就变成了：若是消费端收到两条同样的消息，应该怎样处理？

消费端处理消息的业务逻辑保持幂等性。只要保持幂等性，无论来多少条重复消息，最后处理的结果都同样。保证每条消息都有惟一编号且保证消息处理成功与去重表的日志同时出现。利用一张日志表来记录已经处理成功的消息的 ID，若是新到的消息 ID 已经在日志表中，那么就再也不处理这条消息。

Kafka, ActiveMQ, RabbitMQ, RocketMQ 各有什么优缺点？

若是您对java技术很感兴趣能够加入个人粉丝学习交流群java架构交流群：571617441通过一段时间整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货，但愿对大家的技术提高有必定的参考和帮助

分布式服务（RPC）

Dubbo 的实现过程？

节点角色：

调用关系：

1. 务容器负责启动，加载，运行服务提供者
2. 服务提供者在启动时，向注册中心注册本身提供的服务。
3. 服务消费者在启动时，向注册中心订阅本身所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo 负载均衡策略有哪些？

Random

• 随机，按权重设置随机几率。
• 在一个截面上碰撞的几率高，但调用量越大分布越均匀，并且按几率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin

• 轮循，按公约后的权重设置轮循比率。
• 存在慢的提供者累积请求的问题，好比：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，长此以往，全部请求都卡在调到第二台上。

LeastActive

• 最少活跃调用数，相同活跃数的随机，活跃数指调用先后计数差。
• 使慢的提供者收到更少请求，由于越慢的提供者的调用先后计数差会越大。

ConsistentHash

• 一致性 Hash，相同参数的请求老是发到同一提供者。
• 当某一台提供者挂时，本来发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引发剧烈变更。
• 缺省只对第一个参数 Hash，若是要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虚拟节点，若是要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

Dubbo 集群容错策略 ？

• Failover - 失败自动切换，当出现失败，重试其它服务器。一般用于读操做，但重试会带来更长延迟。可经过 retries="2" 来设置重试次数(不含第一次)。
• Failfast - 快速失败，只发起一次调用，失败当即报错。一般用于非幂等性的写操做，好比新增记录。
• Failsafe - 失败安全，出现异常时，直接忽略。一般用于写入审计日志等操做。
• Failback - 失败自动恢复，后台记录失败请求，定时重发。一般用于消息通知操做。
• Forking - 并行调用多个服务器，只要一个成功即返回。一般用于实时性要求较高的读操做，但须要浪费更多服务资源。可经过 forks="2" 来设置最大并行数。
• Broadcast - 播调用全部提供者，逐个调用，任意一台报错则报错。一般用于通知全部提供者更新缓存或日志等本地资源信息。

动态代理策略？

Dubbo 做为 RPC 框架，首先要完成的就是跨系统，跨网络的服务调用。消费方与提供方遵循统一的接口定义，消费方调用接口时，Dubbo 将其转换成统一格式的数据结构，经过网络传输，提供方根据规则找到接口实现，经过反射完成调用。也就是说，消费方获取的是对远程服务的一个代理(Proxy)，而提供方由于要支持不一样的接口实现，须要一个包装层(Wrapper)。调用的过程大概是这样：

消费方的 Proxy 和提供方的 Wrapper 得以让 Dubbo 构建出复杂、统一的体系。而这种动态代理与包装也是经过基于 SPI 的插件方式实现的，它的接口就是ProxyFactory。

@SPI("javassist")
public interface ProxyFactory {
 @Adaptive({Constants.PROXY_KEY})
 <T> T getProxy(Invoker<T> invoker) throws RpcException;
 @Adaptive({Constants.PROXY_KEY})
 <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) throws RpcException;
}
复制代码

ProxyFactory 有两种实现方式，一种是基于 JDK 的代理实现，一种是基于 javassist 的实现。ProxyFactory 接口上定义了@SPI("javassist")，默认为 javassist 的实现。

Dubbo 支持哪些序列化协议？Hessian？Hessian 的数据结构？

1. dubbo 序列化，阿里尚不成熟的 java 序列化实现。
2. hessian2 序列化：hessian 是一种跨语言的高效二进制的序列化方式，但这里实际不是原生的 hessian2 序列化，而是阿里修改过的 hessian lite，它是 dubbo RPC 默认启用的序列化方式。
3. json 序列化：目前有两种实现，一种是采用的阿里的 fastjson 库，另外一种是采用 dubbo 中自已实现的简单 json 库，通常状况下，json 这种文本序列化性能不如二进制序列化。
4. java 序列化：主要是采用 JDK 自带的 java 序列化实现，性能很不理想。
5. Kryo 和 FST：Kryo 和 FST 的性能依然广泛优于 hessian 和 dubbo 序列化。

Hessian 序列化与 Java 默认的序列化区别？

Hessian 是一个轻量级的 remoting on http 工具，采用的是 Binary RPC 协议，因此它很适合于发送二进制数据，同时又具备防火墙穿透能力。

1. Hessian 支持跨语言串行
2. 比 java 序列化具备更好的性能和易用性
3. 支持的语言比较多 Protoco Buffer 是什么？

Protocol Buffer 是 Google 出品的一种轻量 & 高效的结构化数据存储格式，性能比 Json、XML 真的强！太！多！

Protocol Buffer 的序列化 & 反序列化简单 & 速度快的缘由是：

1. 编码 / 解码 方式简单（只须要简单的数学运算 = 位移等等）
2. 采用 Protocol Buffer 自身的框架代码 和 编译器 共同完成

Protocol Buffer 的数据压缩效果好（即序列化后的数据量体积小）的缘由是：

1. 采用了独特的编码方式，如 Varint、Zigzag 编码方式等等
2. 采用 T - L - V 的数据存储方式：减小了分隔符的使用 & 数据存储得紧凑

注册中心挂了能够继续通讯吗？

能够。Dubbo 消费者在应用启动时会从注册中心拉取已注册的生产者的地址接口，并缓存在本地。每次调用时，按照本地存储的地址进行调用。

ZooKeeper 原理是什么？ZooKeeper 有什么用？

ZooKeeper 是一个分布式应用协调系统，已经用到了许多分布式项目中，用来完成统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工做。

1. 每一个 Server 在内存中存储了一份数据；
2. Zookeeper 启动时，将从实例中选举一个 leader（Paxos 协议）；
3. Leader 负责处理数据更新等操做（Zab 协议）；
4. 一个更新操做成功，当且仅当大多数 Server 在内存中成功修改数据。

Netty 有什么用？NIO/BIO/AIO 有什么用？有什么区别？

Netty 是一个“网络通信框架”。

Netty 进行事件处理的流程。Channel是链接的通道，是 ChannelEvent 的产生者，而ChannelPipeline能够理解为 ChannelHandler 的集合。

IO 的方式一般分为几种：

• 同步阻塞的 BIO
• 同步非阻塞的 NIO
• 异步非阻塞的 AIO 在使用同步 I/O 的网络应用中，若是要同时处理多个客户端请求，或是在客户端要同时和多个服务器进行通信，就必须使用多线程来处理。

NIO 基于 Reactor，当 socket 有流可读或可写入 socket 时，操做系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操做系统。也就是说，这个时候，已经不是一个链接就要对应一个处理线程了，而是有效的请求，对应一个线程，当链接没有数据时，是没有工做线程来处理的。

与 NIO 不一样，当进行读写操做时，只须直接调用 API 的 read 或 write 方法便可。这两种方法均为异步的，对于读操做而言，当有流可读取时，操做系统会将可读的流传入 read 方法的缓冲区，并通知应用程序；对于写操做而言，当操做系统将 write 方法传递的流写入完毕时，操做系统主动通知应用程序。便可以理解为，read/write 方法都是异步的，完成后会主动调用回调函数。

为何要进行系统拆分？拆分不用 Dubbo 能够吗？

系统拆分从资源角度分为：应用拆分和数据库拆分。

从采用的前后顺序可分为：水平扩展、垂直拆分、业务拆分、水平拆分。

是否使用服务依据实际业务场景来决定。

当垂直应用愈来愈多，应用之间交互不可避免，将核心业务抽取出来，做为独立的服务，逐渐造成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提升业务复用及整合的分布式服务框架(RPC)是关键。

当服务愈来愈多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增长一个调度中心基于访问压力实时管理集群容量，提升集群利用率。此时，用于提升机器利用率的资源调度和治理中心(SOA)是关键。

Dubbo 和 Thrift 有什么区别？

• Thrift 是跨语言的 RPC 框架。
• Dubbo 支持服务治理，而 Thrift 不支持。

本文到此结束！！喜欢的朋友别忘了点点关注和赞！！

若是您对java技术很感兴趣能够加入个人粉丝学习交流群java架构交流群 ：571617441通过一段时间整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货，但愿对大家的技术提高有必定的参考和帮助