阿里云二面 高级Java开发工程师整个流程：4轮 初面-二面-三面-hr面-可能加面公司介绍：滴滴，互联网出行行业巨头福利待遇：福利待遇还可以，不是很卷，年终奖可能要打折整个流程1 自我介绍2 考察环节3 问答环节面试题目：1. Redis 大 key 删除时容易把 redis 搞崩，接触过这类问题吗？怎么解决？2.Redis内存淘汰机制是怎么样的？3. Redis 分布式锁和 Zookeeper 分布式锁有什么区别？4Zookeeper的 CP ，如何保障的？5.Sentinel内部是怎么统计 QPS 指标达到限流的目的？滑动窗口算法的实现？如何判断一个请求在哪个时间窗口内？6．怎么处理外部调用你们的 dubbo 接口超时的7.dubbo超时内部是怎么实现的？如果调用方已经超时产生异常了，提供者执行完毕后还会向调用方写返回值吗？8．一个表有两个索引（ A ）和（ A , B , C ), SQL : WHERE A =1AND B >2 AND C =3，会走哪个索引？为什么？只用主键 ID 查找时 B ＋树和 B 树哪个快？总结：侧重项目加一些八股文和实际场景，没有涉及算法适合去面试的朋友：原理比较清楚，底层比较熟悉的朋友

面试官：Dubbo 常用配置策略用法有哪些？1、启动时检查：默认不可用时会抛出异常，为防循环依赖， check = false2、集群容错配置：缺省为failover重试，自动切换其他服务器。其他：Failfast、Failsafe、Failback。3、负载均衡配置：Random随机、RandomRobin轮询、LeastActive少活跃数4、只订阅/只注册：禁止注册register=false；禁止订阅 subscribe = false5、服务分组：group = "XXXXX"6、多版本：version = "1.0.0"7、结果缓存：cache = "lru"8、泛化调用：generic，boolean，非必填，缺省值false，是否缺省泛化接口，如果为泛化接口，将返回GenericService9、回声测试所有rpc引用的代理对象，都实现了接口 EchoService ，可用于测试Reference的服务是否都就绪。10、异步调用异步执行，不可靠的异步，只是忽略返回值，不阻塞执行线程11、事件通知onreturn：方法执行返回后拦截onthrow：方法执行有异常拦截。

一直以为微服务必须要配合注册中心，否则就变得不可控，可是经过这两年的实战证明，其实微服务也是可以不需要注册中心的。如果只把注册中心当做节点维护，节点状态监控的工具其实是没必要使用的，服务有问题几乎不会去注册中心查看情况。一般还是得通过其他监控工具查看，比如skywalking,elk,grafana等平台查看。网络调用遵循CAP原则，springcloud基于Eureka满足AP，Dubbo基于Zookeeper满足CP，如果使用注册中心，就得去拉取注册表的IP端口，然后通过服务名调用，我们没有注册中心所以使用域名进行服务调用，算是AP吧。我们大部分应用都是有springboot，部分在使用go。400多个应用，1700多个左右的pod节点，目前没有使用任何注册中心，已平稳运行多年，这样反而让程序变得更轻量。省去了节点和注册中心之间的心跳，注册表拉取，健康检查，也没有了注册中心和注册中心之间的心跳，健康检查以及信息的同步，自然就省了不少消耗资源。

Dubbo中如何实现服务注册和发现？在Dubbo中，服务注册和发现是实现RPC框架的重要基础功能。它允许服务提供者在启动时将自己的服务提交到注册中心，供消费者使用，并支持消费者根据服务名、版本号、分组等条件去查询并调用对应的服务。在Dubbo中，服务注册和发现有两个核心角色：服务提供者和消费者。服务提供者需要在服务启动时将自身信息注册到注册中心上，而消费者则需要从注册中心上查询对应的服务提供者地址，然后利用RPC协议进行远程调用。Dubbo中支持多种注册中心的实现方式，包括Zookeeper、Redis、Simple、Multicast等。其中，Zookeeper是目前常用的一种注册中心，因为它具有高可靠性、强一致性和较好的性能表现。服务提供者在Dubbo中注册服务需要经过以下步骤：1、配置注册中心在Dubbo配置文件中，需要指定注册中心的类型、地址、连接超时时间等参数。2、实现服务接口服务提供者需要实现要发布的服务接口，并通过指定version、group等元数据描述服务的版本、分组等信息。3、创建服务提供者Dubbo提供了ProviderConfig类来创建服务提供者，该类可以设置一些提供者相关的配置信息，如超时时间、线程数、负载均衡策略等。4、发布服务使用ProviderConfig中的export()方法发布服务，该方法会将服务信息打包成URL，并向注册中心提交。消费者在Dubbo中发现服务需要经过以下步骤：1、配置注册中心与服务提供者类似，消费者在Dubbo配置文件中也需要指定注册中心的类型、地址、连接超时时间等参数。2、创建引用服务接口Dubbo提供了ReferenceConfig类来创建引用服务，该类不仅可以描述要引用的服务接口名、版本号、分组等元数据信息，还可设置超时时间、重试次数、异步调用等相关属性。3、获取服务代理对象使用ReferenceConfig中的get()方法获取服务代理对象，并通过该对象调用远程服务。总体而言，Dubbo通过服务注册中心实现了服务提供者和消费者之间的解耦，让服务的部署和扩展更加灵活高效。不过，在实际应用中，仍需考虑注册中心的高可用性、服务故障熔断、负载均衡策略、限流等诸多问题，以系统的稳定性和可靠性。#Dubbo##dubbo简介#

在Dubbo中，“服务接口+服务分组+服务版本”地确定一个服务——《深度剖析ApacheDubbo核心技术内幕》

从源码层面剖析挖掘「互联网行业主流技术」的底层实现原理，目前开放了Spring全家桶、Mybatis、Netty、Dubbo框架、Redis、Tomcat中间件等。具体内容如下：Spring系列，包括了IoC容器、AOP、SpringMVC、Spring源码故事（瞎编版）、Spring事务、Spring整体脉络、Spring类解析、Spring5新特性、Spring RMI、Spring Message、SpringBoot、SpringSecurity和SpringJDBC（努力编写中）。MyBatis，包括基础支持层、核心处理层和类解析。Netty，包括网络IO技术基础、JDK1.8 NIO包核心组件源码剖析、Netty拆包及解决方案、Netty多协议开发、基于Netty开发服务端及客户端、Netty主要组件的源码分析、Netty高级特性以及Netty技术细节源码分析。Dubbo，包括架构设计、SPI机制、注册中心、远程通信、RPC和集群。Tomcat，包括Servlet与Servlet容器、Web容器。Redis，深挖Redis 6.0源码——SDS。Nacos，nacos服务注册。Sentinel，包括sentinel时间窗口实现等。RocketMQ，包括RocketMQ NameServer与Broker的通信等。此外还有番外篇，包括基础类库、集合和并发编程。后还介绍了个人经验、编码规范、设计模式和多线程。项目创建者为GitHub技术社区Doocs，已经在GitHub上获得了10.2k的Star。项目地址：GitHub - doocs/source-code-hunter: ? 从源码层面，剖析挖掘互联网行业主流技术的底层实...开源协议：CC-BY-SA-4.0 license

记录一次线上异常，dubbo大数据传输异常当dubbo服务提供者传输的数据大小超过8m时，会抛出如下异常：org.apache.dubbo.remoting.RemotingException 9754703 max pavload: 8388608dubbo默认配置的传输大小的8m配置 dubbo.protocol.payload 属性来修改大小:dubbo.protocol.payload=20971520dubbo是单一的长连接，不适合传输大数据，他的瓶颈是网络io；优化点：1、文件传输应该传递url2、数据分页传输，少量多次

美团二面：聊一下Dubbo的服务请求失败怎么处理？Dubbo是一个分布式服务框架，它可以通过网络连接不同的服务节点，使它们在分布式环境下进行通信和调用。然而，由于网络等原因，Dubbo的服务请求可能会失败。当这种情况发生时，我们需要采取一些措施来处理它。首先，我们需要了解服务请求失败的原因。 Dubbo会记录请求的错误信息，可以在日志中查看。通过查看错误日志，我们可以确定错误的类型和位置，从而采取相应的措施。例如，如果错误是由于网络问题造成的，我们可以尝试重新连接或延迟重试；如果是由于服务节点崩溃或停止工作，我们可以将请求发送到其他可用的服务节点。其次，我们可以采取一些策略来降低服务请求失败的概率。例如，我们可以使用负载均衡来均匀地分配请求到不同的服务节点，避免某个节点过载或崩溃导致请求失败；我们还可以通过配置超时时间来避免请求在等待响应时无限期地阻塞。后，我们可以考虑使用Dubbo提供的一些高可用性解决方案来处理服务请求失败。Dubbo提供了多种高可用性解决方案，如集群容错、故障转移和注册中心等。这些解决方案可以帮助我们在服务节点崩溃或停止工作时自动切换到其他可用的节点，从而服务的可用性。总之，处理Dubbo的服务请求失败需要我们采取一些措施，包括了解失败原因、降低失败概率和使用高可用性解决方案等。只有在遇到问题时采取及时有效的措施，才能Dubbo的分布式服务在高效、稳定、可靠的情况下运行。