31.dubbo注册中心挂了后能够继续通信么？
注册中心挂了之后，可以继续通信。因为初始化的时候，消费者已经将提供者的地址等信息拉取到本地缓存。
32.dubbo支持哪些序列化协议，知道PB么？为什么 PB 的效率是最高的？
1）dubbo 协议
hessian序列化协议 ，单一长连接，进行的是 NIO 异步通信
2）hessian 协议
hessian ，多个短连接，适用于提供者数量比消费者数量还多的情况，适用于文件的传输，一般较少用。
3）rmi 协议
Java 二进制序列化，多个短连接，适合消费者和提供者数量差不多的情况，适用于文件的传输，一般较少用。
4）http 协议
json 序列化。
5）webservice
SOAP 文本序列化。
Protocal Buffer 是一种轻量并且高效的结构化数据存储格式，性能比 XML 和 JSON 快上了 20~100 倍。
第一，它使用 proto 编译器，自动进行序列化和反序列化，速度非常快。第二，它的数据压缩效果好，就是说它序列化后的数据量体积小，传输带宽和速度上会有优化。
33.dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略呢？
负载均衡策略
1）random loadbalance 随机调用（默认）
可以对 provider 不同实例设置不同的权重，权重越大分配的流量就越高。
2）roundrobin loadbalance 轮训调用
均匀地将流量打到各个机器上（如果各个机器的性能不一样，容易导致性能差的机器负载过高，可以调整权重，让性能差的机器承载权重小一些）。
3）leastactive loadbalance 最小活跃树
给性能差的机器更少的请求。
4）consistanthash loadbalance 一致性 Hash
使用一致性 Hash 算法，相同参数的请求一定分发到一个 provider 上去。
dubbo 集群容错策略
1）failover cluster 故障转移模式（默认）
失败自动重试其他机器。
2）failfast cluster 快速失败模式
一次调用失败就立即失败。
3）failsafe cluster 失效安全模式
出现异常时忽略掉（常用于不重要的接口调用）。
4）failback cluster 自动恢复模式
失败了后台自动记录请求，然后定时重发。（适用于写消息队列）
5）forking cluster 分叉模式
并行调用多个 provider，只要一个成功就立即返回。（实时性要求较高的读操作，但是需要消耗更多的资源）
6）broadcast cluster 广播模式
广播调用所有提供者，逐个调用（任意一台报错则报错）。通常用于通知所有提供者更新缓存或日志等本地资源信息。
dubbo动态代理策略
默认使用 javassist 动态字节码（高层的Java字节码处理类库，能运行时动态生成、修改类）生成，创建代理类。可以通过 spi 扩展机制配置自己的动态代理策略。
34.dubbo 的 spi 思想是什么？
spi（service provider interface），如果一个接口存在多个实现类，那么在系统运行的时候需要根据指定的配置或者是默认的配置，去找到对应的实现类加载进来，然后用这个实现类的实例对象。
dubbo自己实现的一套 spi 机制-Protocol（协议）。
Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
根据以上代码可知Protocol 接口在系统运行时，dubbo 会判断一下选用哪个实现类来实例化对象来使用。
dubbo 的/META_INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol文件中存在以下配置，通过 SPI 机制来提供实现类，实现类是通过 dubbo 作为默认 key 去配置文件里获取，然后选用该实现类来实例化对象。
dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol（默认）
http=com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
35.如何进行服务治理、服务降级、失败重试以及超时重试
服务治理
1）链路治理
各个服务之间的交互根据一个统一标示串联起来，采集信息生成各个服务之间的依赖关系和调用链路。
2）服务访问压力和访问延时
自动统计各个接口和服务之间的调用次数以及访问延时，方便实时了解线上情况，并可以根据数据反馈完成接口优化和扩容
3）调用链路失败监控和报警
监控接口错误日志和成功率，方便实时了解线上问题，及时排查和修复
4）服务鉴权
系统间相互调用引入鉴权，提高安全性。
服务降级
dubbo：
1）mock配置，如下
<dubbo:reference id="testService" interface="com.test.service.TestService" timeout="10000" check="false" mock="return null">
2）自定义mock业务处理类，实现TestServiceMock（接口名+Mock后缀）
<dubbo:reference id="testService" interface="com.test.service.TestService" check="false" mock="true" />
springcloud：
1）feign组件，自定义一个类实现FallbackFactory
2）zuul网关，自定义一个类实现ZuulFallbackProvider接口
失败重试以及超时重试
dubbo：
<dubbo:reference id=“testService” interface=“com.test.service.TestService” check=“false” retries=“3” timeout=“200”/>
springcloud：
1）ribbon 配置
MaxAutoRetries: 1 #最大重试次数
MaxAutoRetriesNextServer: 1 #重试负载均衡其他的实例最大重试次数
OkToRetryOnAllOperations: false #是否所有操作都重试
36.分布式服务接口请求的顺序性如何保证
1）分布式锁（redis、zookeeper等实现），会导致系统复杂度上升、效率低下、热点数据压力过大等问题
2）一致性 hash 负载均衡策略，将具有相同特征的数据交由一个节点处理，但是同样存在热点数据压力
3）业务逻辑合并，避免过多要求顺序性的接口请求
37.如何自己设计一个类似 dubbo 的 rpc 框架
1）服务提供者初始化、注册、以及响应远程调用的实现
2）服务消费者订阅注册中心、监听服务提供者的变化的实现
3）动态代理的实现。
4）负载均衡、序列化协议
5）实现监视器，负责统计服务的消费和调用情况
38.springcloud和dubbo
Dubbo是高性能服务框架，SpringCloud则是一个完整的分布式一站式框架，基于SpringBoot的便利性融合了一整套实现微服务的框架，除了Dubbo已有的功能外，还提供管控台，断路器，分布式配置服务等服务。
Dubbo底层使用Netty基于TCP协议传输+Hession序列化完成RPC通信，SpringCloud是基于Http协议+rest接口调用远程过程的通信。Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，不存在代码级别的强依赖，更加灵活。
39.threadlocal应用解决了什么问题
1）使用 ThreadLocal代替 Synchronized来保证线程安全，每个线程都持有一份变量，访问时互不影响。
2）ThreadLocal为变量在每个线程中创建了一个副本，所以每个线程可以访问自己内部的副本变量。
40.分布式事务
两阶段提交（2PC）
两阶段提交，通过引入协调者来协调参与者，并最终决定这些参与者是否要真正执行事务。
第一阶段，协调者询问参与者事务是否执行成功，参与者发回事务执行结果。
第二阶段，如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务。如果一旦有参与者执行失败，协调者发送通知让参与者回滚事务。
存在的问题：
1）所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，效率低。
2）协调者存在单点问题，一旦挂了会造成很大影响。
3） 第二阶段如果协调者部分 Commit 消息发送失败，部有收到消息的参与者会出现问题。
4）没有完善的容错机制。
补偿事务（TCC）
针对每个操作，都要注册一个与其对应的确认和撤销操作。
Try阶段通知业务系统做检测及资源预留。（默认只要Try成功，第二阶段Confirm就成功）
Confirm阶段，业务系统做确认提交
Cancel 阶段，业务执行错误，回滚的状态下执行的业务取消并预留资源释放。
存在的问题：
1）Confirm和Cancel都有可能失败
2）需要多写很多代码
业务轮训表+消息队列
建立业务轮训表保存业务执行状态，按异步的方式协调完成事务，实现最终一致性。
存在的问题：
1）轮训表会耦合业务，不够灵活。
2）会出现频繁读写数据库记录，高并发可能存在平静
