Java面试题－互联网中间件（持续更新）

Flume Agent三个组件：Source、Channel、Sink

  Source 专门用来收集数据，可以处理各种类型、各种格式的日志数据，比如avro、exec、HTTP、Kafka、Spooling Directory等。
  Channel 是一个存储Source已经接收到的数据的缓冲区，简单来说就是对Source采集到数据进行缓存，可以缓存在memory、file、jdbc、Kafka等。
  Sink 用于把数据发送到目的地，目的地可以是：HDFS、Hive、HBase、ES、Kafka、Logger。

Flume 运行机制

  flume的核心就是一个agent，这个agent对外有两个进行交互的地方，一个是接受数据的输入——source，一个是数据的输出sink，sink负责将数据发送到外部指定的目的地。source接收到数据之后，将数据发送给channel，chanel作为一个数据缓冲区会临时存放这些数据，随后sink会将channel中的数据发送到指定的地方—-例如HDFS等，注意：只有在sink将channel中的数据成功发送出去之后，channel才会将临时数据进行删除，这种机制保证了数据传输的可靠性与安全性

什么是分布式系统？

  分布式系统是支持分布式处理的软件系统包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等
  1.增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。
  2.加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。
  3.因为模块化，所以系统模块重用度更高。
  4.因为软件服务模块被拆分，开发和发布速度可以并行而变得更快。
  5.系统扩展性更高。
  6.团队协作流程也会得到改善。

为什么使用消息队列

  核心的有 3 个：解耦、异步、削峰。

ElasticSearch

  ElasticSearch 设计的理念就是分布式搜索引擎，底层其实还是基于 lucene 的

ElasticSearch节点

候选主节点（Master-eligible node）

  集群中会从候选主节点中选举出一个主节点，主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch中的主节点的工作量相对较轻，用户的请求可以发往任何一个节点，由该节点负责分发和返回结果，而不需要经过主节点转发。

数据节点（Data node）

  数据节点负责数据的存储和相关具体操作，比如CRUD、搜索、聚合。所以，数据节点对机器配置要求比较高，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统CPU、Memory和IO的性能消耗都很大。

客户端节点（Client node）

  按照官方的介绍，客户端节点就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等等，也就是下面要说到的协调节点的角色。这样的工作，其实任何一个节点都可以完成，单独增加这样的节点更多是为了负载均衡。

协调节点（Coordinating node）

  协调节点，是一种角色，而不是真实的Elasticsearch的节点，你没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点，都可以充当协调节点的角色。

ES 写数据过程

  客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。然后将数据同步到 replica node。coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

ES 读数据过程

  可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。客户端发送请求到任意一个 node，成为 coordinate node。
coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。接收请求的 node 返回 document 给 coordinate node，coordinate node 返回 document 给客户端。

es 搜索数据过程

  客户端发送请求到一个 coordinate node。协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard。query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

写数据底层原理

  数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。数据写入 segment file 之后，同时就建立好了倒排索引。

dubbo

dubbo 工作原理

  service 层，接口层，给服务提供者和消费者来实现的
  config 层，配置层，主要是对 dubbo 进行各种配置的
  proxy 层，服务代理层，无论是 consumer 还是 provider，dubbo 都会给你生成代理，代理之间进行网络通信
  registry 层，服务注册层，负责服务的注册与发现
  cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
  monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控
  protocal 层，远程调用层，封装 rpc 调用
  exchange 层，信息交换层，封装请求响应模式，同步转异步
  transport 层，网络传输层，抽象 mina 和 netty 为统一接口
  serialize 层，数据序列化层

dubbo工作流程

  provider 向注册中心去注册
  consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务
  consumer 调用 provider
  consumer 和 provider 都异步通知监控中心

注册中心挂了可以继续通信吗？

  可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。

dubbo 有哪些通信协议

dubbo 协议

  默认就是走 dubbo 协议，单一长连接，进行的是 NIO 异步通信，基于 hessian 作为序列化协议。使用的场景是：传输数据量小（每次请求在 100kb 以内），但是并发量很高。

rmi 协议

  走 Java 二进制序列化，多个短连接，适合消费者和提供者数量差不多的情况，适用于文件的传输，一般较少用。

hessian 协议

  走 hessian 序列化协议，多个短连接，适用于提供者数量比消费者数量还多的情况，适用于文件的传输，一般较少用。

http 协议

  走 json 序列化。

webservice

  走 SOAP 文本序列化。

dubbo 支持哪些序列化协议

（注意通信协议、序列化协议区别）
dubbo 支持 hession、Java 二进制序列化、json、SOAP 文本序列化多种序列化协议。但是 hessian 是其默认的序列化协议。

Hessian 的数据结构

  Hessian 的对象序列化机制有 8 种原始类型：原始二进制数据、boolean、64-bit date（64 位毫秒值的日期）、64-bit double、32-bit int、64-bit long、null、UTF-8 编码的 string
  另外还包括 3 种递归类型：list for lists and arrays、map for maps and dictionaries、object for objects
  还有一种特殊的类型：ref：用来表示对共享对象的引用。

dubbo 负载均衡策略

random loadbalance

  默认情况下，dubbo 是 random load balance ，即随机调用实现负载均衡，可以对 provider 不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。

roundrobin loadbalance

  这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。

leastactive loadbalance

  这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。

dubbo 集群容错策略

failover cluster 模式

  失败自动切换，自动重试其他机器，默认就是这个，常见于读操作。（失败重试其它机器）

failfast cluster 模式

  一次调用失败就立即失败，常见于非幂等性的写操作，比如新增一条记录（调用失败就立即失败）

failsafe cluster 模式

  出现异常时忽略掉，常用于不重要的接口调用，比如记录日志。失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种。

forking cluster 模式

  并行调用多个 provider，只要一个成功就立即返回。常用于实时性要求比较高的读操作，但是会浪费更多的服务资源，可通过 forks=“2” 来设置最大并行数。

broadcacst cluster

  逐个调用所有的 provider。任何一个 provider 出错则报错（从2.1.0 版本开始支持）。通常用于通知所有提供者更新缓存或日志等本地资源信息。

dubbo动态代理策略

  默认使用 javassist 动态字节码生成，创建代理类。但是可以通过 spi 扩展机制配置自己的动态代理策略。

dubbo的spi 是啥？

  spi，简单来说，就是 service provider interface，说白了是什么意思呢，比如你有个接口，现在这个接口有 3 个实现类，那么在系统运行的时候对这个接口到底选择哪个实现类呢？这就需要 spi 了，需要根据指定的配置或者是默认的配置，去找到对应的实现类加载进来，然后用这个实现类的实例对象。

zookeeper 的使用场景有哪些

1、分布式协调
2、分布式锁
3、元数据/配置信息管理
4、HA高可用性
  Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式。
  为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。
  实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。
低32位用于递增计数。Zookeeper下每个Server在工作过程中有三种状态，LEADING：当前Server即为选举出来的leader。
LOOKING：当前Server不知道leader是谁，正在搜寻；FOLLOWING：leader已经选举出来，当前Server与之同步

ZooKeeper提供了什么？

1、文件系统
2、通知机制

Zookeeper文件系统

  每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
有四种类型的znode：
1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

ZK服务器角色

Leader
  事务请求的唯一调度和处理者，保证集群事务处理的顺序性，集群内部各服务的调度者。
Follower
  处理客户端的非事务请求，转发事务请求给Leader服务器，参与事务请求Proposal的投票，参与Leader选举投票。
Observer
  3.3.0版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力，处理客户端的非事务请求，转发事务请求给Leader服务器，不参与任何形式的投票。

Zookeeper 下 Server工作状态

  服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。
  LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
  FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
  LEADING：领导者状态。表明当前服务器角色是Leader。
  OBSERVING：观察者状态。表明当前服务器角色是Observer。

ZK节点宕机如何处理？

  Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。
  如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；
  如果是一个Leader宕机，Zookeeper会选举出新的Leader。
  ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。所以3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)，2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)。

Zookeeper集群支持动态添加机器吗？

  其实就是水平扩容了，Zookeeper在这方面不太好。两种方式：全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。3.5版本开始支持动态扩容。

chubby是什么，和zookeeper比你怎么看？

  chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。

说几个zookeeper常用的命令。

常用命令：ls get set create delete等。

ZAB和Paxos算法的联系与区别？

相同点：
两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行
Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交
ZAB协议中，每个Proposal中都包含一个 epoch 值来代表当前的Leader周期，Paxos中名字为Ballot
不同点：
ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。

zookeeper选举

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。
　　(1) 服务器初始化启动。
　　(2) 服务器运行期间无法和Leader保持连接。

ZK服务启动时期的Leader选举

  若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下
  (1) 每个Server发出一个投票，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid(SID)和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
  (2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
  (3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下
优先检查ZXID。ZXID比较大的服务器优先作为Leader。
如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
  (4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。
  (5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

服务器运行时期的Leader选举

  在Zookeeper运行期间，Leader与非Leader服务器各司其职，一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下
　　(1) 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
　　(2) 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为123，Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
　　(3) 接收来自各个服务器的投票。与启动时过程相同。
　　(4) 处理投票。与启动时过程相同，此时，Server1将会成为Leader。
　　(5) 统计投票。与启动时过程相同。
　　(6) 改变服务器的状态。与启动时过程相同。

Leader选举算法分析

  在3.4.0后的Zookeeper的版本只保留了TCP版本的FastLeaderElection选举算法(之前有LeaderElection和UDP版本的FastLeaderElection)。当一台机器进入Leader选举时，当前集群可能会处于以下两种状态

集群中已经存在Leader。

  对于集群中已经存在Leader而言，此种情况一般都是某台机器启动得较晚，在其启动之前，集群已经在正常工作，对这种情况，该机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器而言，仅仅需要和Leader机器建立起连接，并进行状态同步即可。

集群中不存在Leader。

  (1) 第一次投票。无论哪种导致进行Leader选举，集群的所有机器都处于试图选举出一个Leader的状态，即LOOKING状态，LOOKING机器会向所有其他机器发送消息，该消息称为投票。投票中包含了SID（服务器的唯一标识）和ZXID（事务ID），(SID, ZXID)形式来标识一次投票信息。假定Zookeeper由5台机器组成，SID分别为1、2、3、4、5，ZXID分别为9、9、9、8、8，并且此时SID为2的机器是Leader机器，某一时刻，1、2所在机器出现故障，因此集群开始进行Leader选举。在第一次投票时，每台机器都会将自己作为投票对象，于是SID为3、4、5的机器投票情况分别为(3, 9)，(4, 8)， (5, 8)。
　　(2) 变更投票。每台机器发出投票后，也会收到其他机器的投票，每台机器会根据一定规则来处理收到的其他机器的投票，并以此来决定是否需要变更自己的投票，这个规则也是整个Leader选举算法的核心所在，其中术语描述如下
　　　　· vote_sid：接收到的投票中所推举Leader服务器的SID。
　　　　· vote_zxid：接收到的投票中所推举Leader服务器的ZXID。
　　　　· self_sid：当前服务器自己的SID。
　　　　· self_zxid：当前服务器自己的ZXID。
　　(3) 确定Leader。经过第二轮投票后，集群中的每台机器都会再次接收到其他机器的投票，然后开始统计投票，如果一台机器收到了超过半数的相同投票，那么这个投票对应的SID机器即为Leader。此时Server3将成为Leader。
　　由上面规则可知，通常那台服务器上的数据越新（ZXID会越大），其成为Leader的可能性越大，也就越能够保证数据的恢复。如果ZXID相同，则SID越大机会越大。

ZK Leader选举四种状态

  服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。
　　LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
　　FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
　　LEADING：领导者状态。表明当前服务器角色是Leader。
　　OBSERVING：观察者状态。表明当前服务器角色是Observer。

Kafka 使用 Zookeeper 做什么？

  kafka使用ZooKeeper用于管理、协调代理。每个Kafka代理通过Zookeeper协调其他Kafka代理。当Kafka系统中新增了代理或某个代理失效时，Zookeeper服务将通知生产者和消费者。生产者与消费者据此开始与其他代理协调工作。
  Zookeeper在Kakfa中扮演的角色：Kafka将元数据信息保存在Zookeeper中，但是发送给Topic本身的数据是不会发到Zk上的kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。
  而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。这里的客户端指的是Kafka的消息生产端(Producer)和消息消费端(Consumer)。
  Broker端使用zookeeper来注册broker信息,以及监测partitionleader存活性。
  Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partitionleader建立socket连接,并获取消息。
  Zookeer和Producer没有建立关系，只和Brokers、Consumers建立关系以实现负载均衡，即同一个ConsumerGroup中的Consumers可以实现负载均衡（因为Producer是瞬态的，可以发送后关闭，无需直接等待

Eureka和ZooKeeper的区别

  Eureka和Zookeeper就是CAP定理中的实现，Eureka（保证AP），Zookeeper（保证CP）。
  RDBMS==>（MySql,Oracle,SqlServer等关系型数据库）遵循的原则是：ACID原则（A：原子性。C：一致性。I：独立性。D：持久性。）。
  NoSql==> （redis,Mogodb等非关系型数据库）遵循的原则是：CAP原则（C：强一致性。A:可用性。P：分区容错性）。在分布式领域有一个很著名的CAP定理：C：数据一致性。A：服务可用性。P：分区容错性（服务对网络分区故障的容错性）。Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）