java面试题收集(04)
1、rebbitmq的使用场景有哪些？
（1）单发送单接受
使用场景：简单的发送与接受，没有特别的处理。
（2）单发送多接受
使用场景：一个发送端，多个接收端，如分布式的任务发布，要保证消息发送的可靠性，不丢失消息，所以将消息队列持久化，同时为了防止接收端处理消息时宕机，所以在处理完成后再发送ack满息。
（3）Publish/Subscribe
使用场景：发布、订阅模式，发送端发送广播消息，多个接收端接受。
（4）Routing（按路线发送接收）
使用场景：发送端按routing key发送满息，不同的接收端按不同的routing key接收消息。
（5）Topics（按Topic发送接收）
使用场景：发送端不只按routing key发送消息，而是按字符串“匹配”发送，接收端同样如此。
2、Dubbo的容错机制有哪些？
（1）Failover Cluster模式
失败自动切换，当出现失败，重试其它服务器。（默认）
（2）Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
（3）Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
（4）Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
（5）Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过forks=”2”来设置最大并行数。
（6）Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错。（2.1.0开始支持）通常用于通知所有提供者更新缓存或日志等本地资源信息。
总结：
在实际应用中查询语句容错策略建议使用默认Failover Cluster，而增删改建议使用Failfast Cluster或者使用Failover Cluster（retries=”0”）策略防止出现数据重复添加等等其它问题！建议在设计接口时候把查询接口方法单独做一个接口提供查询。
3、Dubbo和Spring Cloud 有什么区别？
（1）通信方式不同
Dubbo使用的是RPC通信，而Spring Cloud使用的是HTTPRESTFul方式。
（2）组成部分不同
4、Dubbo 里面有哪几种节点角色？
（1）Provider
暴露服务的服务提供方。
（2）Consumer
调用远程服务的服务消费方。
（3）Registry
服务注册与发现的注册中心。
（4）Monitor
统计服务的调用次数和调用时间的监控中心。
（5）Container
服务运行容器。
5、Dubbo服务注册与发现的流程图
6、Dubbo 有几种负载均衡策略，默认是哪种？
（1）Random LoadBalance
随机，按权重设置随机概率（默认）。
（2）RoundRobin LoadBalance
轮询，按公约后的权重设置轮询比率。
（3）LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机。
（4）ConsistentHash LoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
7、ZooKeeper 是什么？
ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
Zookeeper保证了如下分布式一致性特性：
（1）顺序一致性
（2）原子性
（3）单一视图
（4）可靠性
（5）实时性（最终一致性）
客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。
有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper TransactionId）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。
8、Zookeeper Watcher 机制-数据变更通知
Zookeeper 允许客户端向服务端的某个Znode注册一个Watcher监听，当服务端的一些指定事件触发了这个Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据Watcher通知状态和事件类型做出业务上的改变。
工作机制：
（1）客户端注册 watcher
（2）服务端处理watcher
（3）客户端回调 watcher
Watcher特性总结：
（1）一次性
无论是服务端还是客户端，一旦一个Watcher被触发，Zookeeper都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。
（2）客户端串行执行
客户端Watcher回调的过程是一个串行同步的过程。
（3）轻量
Watcher通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容。
客户端向服务端注册 Watcher的时候，并不会把客户端真实的Watcher对象实体传递到服务端，仅仅是在客户端请求中使用boolean类型属性进行了标记。
watcher event 异步发送watcher的通知事件从server发送到client是异步的，这就存在一个问题，不同的客户端和服务器之间通过socket进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于Zookeeper本身提供了ordering guarantee，即客户端监听事件后，才会感知它所监视znode发生了变化。所以我们使用Zookeeper不能期望能够监控到节点每次的变化。
Zookeeper只能保证最终的一致性，而无法保证强一致性。
注册 watcher getData、exists、getChildren
触发watcher create、delete、setData
当一个客户端连接到一个新的服务器上时，watch将会被以任意会话事件触发。当与一个服务器失去连接的时候，是无法接收到watch的。而当client重新连接时，如果需要的话，所有先前注册过的watch，都会被重新注册。通常这是完全透明的。只有在一个特殊情况下，watch可能会丢失：对于一个未创建的znode的exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个watch事件可能会被丢失。
9、Zookeeper四种类型的数据节点Znode
（1）PERSISTENT-持久节点
除非手动删除，否则节点一直存在于Zookeeper上。
（2）EPHEMERAL-临时节点
临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
（3）PERSISTENT_SEOUENTIAL-持久顺序节点
基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
（4）EPHEMERAL_SEQUENTIAL-临时顺序节点
基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
10、Zookeeper选举算法及流程
假设有5台服务器，每台服务器均没有数据，它们的编号分别是1，2，3，4，5，按编号依次启动，它们的选择举过程如下：
（1）服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking（选举状态）。
（2）服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
（3）服务器3启动，给自己投票，同时与之前启动的服务器1，2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1.2成为小弟。
（4）服务器4启动，给自己投票，同时与之前启动的服务器1，2，3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
（5）服务器5启动，后面的逻辑同服务器4成为小弟。
11、集群中的机器角色都有哪些？
（1）Leader
事务请求的唯一调度和处理者，保证集群事务处理的顺序性，集群内部各服务的调度者。
（2）Follower
处理客户端的非事务请求，转发事务请求给Leader服务器参与事务请求Proposal的投票。参与Leader选举投票。
（3）Observer
3.3.0版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力处理客户端的非事务请求，转发事务请求给Leader服务器，不参与任何形式的投票。