一、Dubbo服务注册和发现的流程？

1、容器启动；
2、服务提供者连接注册中心，将接口信息保存到注册中心中；
3、服务消费者从注册中心订阅所需要的服务并缓存本地，
4、服务提供方有变更时，注册中心将提供一份新的列表给消费者并缓存在消费者端；
5、消费者根据接口地址调用服务提供者；
6、监听器定时监听接口的调用次数和调用时长；

二、dubbo支持哪些协议？

• dubbo：dubbo默认推荐的协议，单一长连接和NIO异步通讯，适用于高并发小数据量的请求，以及消费者远大于提供者，tcp传输协议，Hessian序列化；
• rmi：基于java标准的rmi协议实现，传输参数和返回参数都需要实现Serializable接口，使用java标准序列化方式，采用阻塞式短连接，tcp传输协议，可传文件；
• webservice：基于webservice的远程调用协议，多个短连接，基于Http传输，同步传输；
• http：基于http表单提交的远程调用协议，使用spring的HttpInvoke实现，多个短连接，传输协议http；
• hession：集成Hession服务，基于Http通讯，采用Servlet暴露服务，Dubbo内嵌Jetty作为服务器时的默认实现，多个短连接，同步Http传输，Hessian序列化，传入参数较大，可穿文件；
• memcache:基于memcache实现的RPC协议；
• redis：基于redis实现的RPC协议

三、Dubbo有哪些注册中心？

• zookeeper：基于zookeeper的watch机制实现数据变更，官方推荐使用
• redis：基于redis的订阅/发布形式实现数据变更
• multicast；
• simple；

四、Dubbo的注册中心挂掉，消费者还能调用吗？

可以，Dubbo启动时，消费者会从注册中心拉取一份接口的信息缓存在本地，每次调用时都会根据本地缓存的地址进行调用；

五、Dubbo提供了哪些负载均衡策略？

• Random LoadBanance：随机选取提供者策略，当调用越频繁，分布越平均
• RoundRobin LoadBanance：随机轮训提供者策略，平均分布，但是存在请求积累问题；
• LeastActive LoadBanance：最少活跃调用策略，活跃数是指调用前后计数差，是慢机器调用最少；比如同事有A和B两个服务，两个服务内部都维护了一个计数器，当A处理一个请求的时候，计数器+1，此时还未处理完，等处理完请求之后，计数器-1，若此时B服务响应较快，很快就处理完请求了，此时A的计数器为1，B的计数器为0，那么下一个请求过来的时候，会发到B服务器上；
• ConstantHash LoadBanance：一致性hash策略，使相同参数请求总是发送到统一提供者，当有一台宕机了后，可以基于虚拟节点，分发至其他提供者上；

六、Dubbo的集群容错方法有哪些？

• Failover Cluster：失败自动切换，当出现失败重试其他服务器，通常用于读操作，默认重试2次；
• Failfast Cluster：快速失败，只发起一次调用，当出现失败的时候，立即报错，通常用于非幂等性的写操作，比如新增记录；
• Failsafe Cluster：失败安全，当出现异常时，直接忽略，通常应用于写入日志操作；
• Failback Cluster：失败自动恢复，当出现失败时，后台记录请求，定时重发。通常用于消息通知等操作；
• Forking Cluster：并行调用多个服务器，只要有一个成功则返回，适用于实时性很高的读操作，但是会对服务器造成很大压力，可以通过"forks = 2"来设置最大并行数；
• Broadcast Cluster：广播调用所有提供者，只要有一个失败则都失败，通常应用于通知所有的提供者更新本地缓存等操作；

七、Dubbo提供了哪些序列化方式？

默认使用Hessian序列化，还提供了fastjson、Dubbo以及java自带序列化；

八、Dubbo超时时间设置

dubbo推荐在服务提供者端设置超时时间，因为服务提供者更能清楚的知道自己服务的特性，若是在消费者端设置了超时时间，则以消费者端的设置为准，因为消费者端设置更加灵活；

当超时之后，dubbo默认会重试两次；

九、服务上线如何兼容旧版本？

通过版本号version来进行过渡，不同版本号的服务注册到注册中心，版本号不同的服务相互之间不引用；

十、当一个服务有多个不同的实现时如何操作？

通过对不同的实现通过group分组来区分，不同的分组有不同的响应，服务的提供者和消费者指向同一个分组即可

十一、当开发过程中，多个开发人员同时将接口注册到同一个注册中心时，会发生什么，如何解决？

可能会出现调用的服务在对方电脑上，有以下两个方式解决：
1、每个开发人员的接口设置各自的分组，项目之间调用互不影响；
2、可以通过设置点对点直连的方式，在消费者端指定到本地的服务地址；

<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20880" />

十二、Dubbo服务之间的调用是阻塞的吗？

Dubbo默认是同步等待结果阻塞的，支持异步调用；
Dubbo是基于NIO的非阻塞式实现并行调用，调用过程如下：

1、工作线程调用findUser方法；
2、IO线程负责调用对象的服务端；
3、IO线程setFuture到RpcContent中
4、工作线程读取Future的值，若为空，则调用wait方法等待；
6、服务端响应结果到调用者；
7、IO线程将返回结果set到future中并唤醒工作线程；
8、工作线程读取future并返回；

十三、Dubbo分布式事务？

分布式事务的实现主要有以下五种方案：
1、XA方案；
2、TCC方案；
3、本地消息表；
4、可靠消息最终一致性方案；
5、最大努力通知方案
基于XA协议的两阶段提交：
XA分为两部分，事务管理器和本地资源管理器，本地资源管理器由各个数据库实现，而事务管理器作为一个管理者，管理着所有本地资源管理器的提交和回滚；
所有的参与者准备执行事务并锁住资源，参与者ready时，向事务管理器发送就绪的指令，当所有的参与者都达到就绪时，事务管理器向所有的参与者发送commit命令；
缺点：效率低下，准备节点的成本很大，性能差；提交前，发生故障难以恢复；
TCC方案：
TCC方案分为Try和Confirm、Cancel，一般在try里面锁住资源，资源校验；Confirm里面确认执行业务操作；Cancel里面取消执行业务操作；
github上面有基于tcc的java实现：tcc-transaction
可靠消息最终一致性方案:
基于RocketMQ实现分布式事务，解决最终事务一致性方案：
为什么不采用kafka等消息中间件呢，因为考虑到发送消息和处理业务没办法保证同时成功，所以基于RocketMQ的预发消息和确认消息来实现；
以转账为例：A转账给B，所以A需要减100元，B需要加100元，
1、先发送B+100元的预发消息到RocketMQ中，此时该条消息只存在commitLog中，在consumeQueue中不可见，也就无法被消费；
2、在执行扣款逻辑，若扣款成功则发送确认消息到RocketMQ中；
3、若扣款失败，则预发消息不会被确认，也就无法被消费；
4、若扣款成功、发送确认消息失败，则通过状态回查的方式来确定消息状态，也就是RocketMQ会定时遍历commitlog中的消息，来确认该消息最终是commit还是rollback，如果发现本地业务为执行成功则rollback，如果执行成功就commit；
5、如何进行状态回查：可以在本地设计一个事务状态表，记录transactional事务的状态，若业务执行成功则为success，为业务执行失败则为fail；