分布式相关面试

Dubbo

1. dubbo的底层原理

dubbo十层架构

1. serivce服务层
   包含Provider,Consumer
2. Config配置层
   配置一些基本服务的基本信息
3. Registry注册层
   向注册中心注册，及提取注册信息
4. Proxy代理层
   生成接口代理对象，Filter等拦截功能实现，主要采用spi+asm(字节码增加技术)实现
5. Cluster集群层
   提供方可能不止一个服务隐藏在代理层后面，这层是均衡策略和容错策略的开发地
6. monitor监控层
   主要收集调用数据，给后台及均衡策略提供相应的数据
7. Protocol协议层
   把服务对象协议化
8. Exchange信息交换成
   用Fature处理request和response
9. transport传输层
   用netty,nima等框架实现传输
10. 序列化层
    将数据序列化

2. dubbo的均衡策略

1. Random LoadBalance
   随机，按权重设置随机概率。
2. RoundRobin LoadBalance
   轮循，按公约后的权重设置轮循比率。
3. LeastActive LoadBalance
   最少活跃调用数，相同活跃数的随机，活跃数指调用前后时间计数差。
4. ConsistentHash LoadBalance
   一致性Hash，相同参数的请求总是发到同一提供者。

公司使用的策略Random + LeastActive，防止新服务器启动，大量请求涌入

3. dubbo的容错策略

1. Failover Cluster（缺省）
   失败自动切换，当出现失败，重试其它服务器。
2. Failfast Cluster
   快速失败，只发起一次调用，失败立即报错。
3. Failsafe Cluster
   失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
4. Failback Cluster
   失败自动恢复，后台记录失败请求，定时重发。
5. Forking Cluster
   并行调用多个服务器，只要一个成功即返回。
6. Broadcast Cluster
   广播调用所有提供者，逐个调用，任意一台报错则报错。

4. dubbo的优雅停机

主要Jdk提供的关闭钩子，以下场景会触发钩子

1. 程序正常退出
2. 使用System.exit()
3. 终端使用Ctrl+C触发的中断
4. 系统关闭
5. 使用Kill pid命令干掉进程

dubbo中主要通过勾子执行

1. 注锁注销注册中心
   新的请求不能再发往正在停机的 Dubbo 服务提供者。
2. 关闭 Server
   若关闭服务提供者，已经接收到服务请求，需要处理完毕才能下线服务。
3. 关闭 Client
   若关闭服务消费者，已经发出的服务请求，需要等待响应返回。

5. dubbo限流策略

1. connections限流
   限制长连接个数，可作用于类或者方法，适用于客户端和服务端
2. actives限流
   表示当前长连接最多可以处理的请求个数，与长连接的数量没有关系。可作用于类或者方法，适用于客户端和服务端
3. accepts限流
   指定协议的连接数量进行限制，适用于服务端
4. executes直接限流
   限制的是服务（方法）并发执行数量，可作用于类或者方法，适用于客户端和服务端

Rocketmq

1.Rocketmq结构及作用

• NameServer集群
  1. Broker,Producer,Consumer都会向NameServer集群每一个NameServer注册。
  2. NameServer集群中NameServer互不通信
• Broker集群
  1. 每个Broker都可采用master/slave模式，主要同步方式有同步双写和异步复制
  2. 每个Broker将所在数据存储一个文件中，然后通过索引的方式关联Queue
  3. 每个Queue只会被一个Consumer消费，如果Consumer数>Queue数，则可能存在Consumer无消费的现象。反之，Consumer可消费多个Queue
• Producer集群
  1. Producer和与其关注topic的broker保持长连接(具体数据从NameServer)。默认情况下消息发送采用轮询方式，会均匀发到对应Topic的所有queue中。
• Consumer集群
  1. Consumer和与其关注topic的broker保持长连接(具体数据从NameServer)，在用相同的算法来分配Queue（保证Queue只对应一个Consumer）。当有个Consumer失去心跳后，并向该消费者分组的所有消费者发出通知，分组内消费者重新分配Queue继续消费。

2.消费者消费模式有几种

1. 集群消费
   一个 Consumer Group 中的各个 Consumer 实例分摊去消费消息，即一条消息只会投递到一个 Consumer Group 下面的一个实例。

2. 广播消费
   消息将对一 个Consumer Group 下的各个 Consumer 实例都投递一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

3. 消费者获取消息有几种模式？

1. PushConsumer
   推送模式的消费者。消息的能及时被消费。其原理是长轮询 + pull 模式结合的方式。因为每台服务器的消息能力是不一样的，pull是可以根据服务器的能力自己拉取。

2. PullConsumer
   拉取模式的消费者。应用主动控制拉取的时机，怎么拉取，怎么消费等。主动权更高。但要自己处理各种场景。

4. ACK——消息确认机制

1. consumer与对应的Queue连接
2. consumer向Queue，pull数据10条，offset 不变
3. consumer会创建一个线程池来消息（所以不能保证消息的顺序消费）
4. consumer会创建一个TreeMap, 按消息的 offset 升序排序
5. 如果对应offset消息被消费了，直打上标签
6. 如果1-10的，offset 1，2，5被打上标签，consumer会把1，2offset的消息同步给Queue。Queue向前+2.consumer继续等待offset为3的消息消费

优缺点：

• 优点：防止消息丢失（也就是没有消费到）。
• 缺点：会造成消息重复消费。

lucence

1.构建文件索引的过程

1. 先把要构建字段通过分词器分词

1.“AA,BB”—> AA,BB
2.“AA,CC”---->AA,CC

2. 将分好的词存入FST(类似字典树，使用起来了hashMap差不多)，建立倒排索引

字典	倒排表
AA	1,2
BB	1
CC	2

3. 查询BB的文本，结果为 1
4. 当然复杂查看可能用到更多的数据结构
   

分布式理论

幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

1. 悲观锁&状态机幂等
   select for update 或者 分布式锁，整个执行过程中锁定该订单对应的记录。如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

2. 全局唯一ID
   如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。

   • token机制，防止页面重复提交
     数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间
   • 去重表
     在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑
   • MVCC方案
     在更新的过程中利用version来防止，其他操作对对象的并发更新，导致更新丢失