问：
项目中接触到那些分布式框架？各有什么优缺点？
答：
接触到dubbo分布式框架，spring cloud分布式框架，还有分布式事物框架。dubbo框架
我这里是必须依赖zookeeper或者consul一些中间件，作为注册中心，而spring cloud是现
在流行的微服务分布式框架。他给你一套全家桶式的组件。eureka作为注册中心，ribbon作
为负载均衡，hystrix作为熔断器，zuul作为路由网关，stream作为mq中间件，config作为
配置中心，bus作为刷新机制，sleuth作为调用链。
分布式事物框架我这里主要二种方案，一MQ的解决方法，二是阿里巴巴的解决方法DTS方案。
MQ的解决依据是发送MQ消息成功，即代表发送消费者成功。这里的前提是消费者必须调用成功，
也就是如果消费者第一次没有调用成功，那么MQ将会继续堆给消费者。二DTS的解决方法，
这就是传统的二段式提交的加强版，也就是在主事物执行后将尝试调用从事物，让从事物尝试
执行事物，看是否执行执行事物，如果豫调用成功，则成功返回，主事物就正式发起从事物调用。
如果豫调用失败，则从事物可能不支持执行事物，失败返回，主事物就回滚之前的事物。
问：
你既然用到了dubbo，你可以简单介绍怎么使用的？还有他必须依赖zookeeper等中间件，那么
它怎么注册服务的？还有怎么做负载均衡？集群怎么搭建？
答：
在使用dubbo时就是调用RPC远程调用。RPC的协议hession协议。RPC的接口必须相同接口且
路径要相同，调用远程方法就像调用自己本地方法一样，hession协议的使用。netty使用。
在于协约头的约定,底层基于ip和tcp，中间dubbo协议采用hession协议，二进制RPC协议，
内置了序列化功能。总体就是说，他需要类似zookeeper作为注册中心，服务提供者向zookeeper
注册自己信息（服务名称，自己的ip和port）。服务消费者向zookeeper请求某个服务名称的
注册信息。通过rpc进行远程调用方法。
zookeeper对于dubbo非常重要，我在做项目中是以zookeeper作为注册中心。当然还可以以consul
,redis作为注册中心。zk有二个重要的功能。
1 选主，当zk集群启动时，或者当leader宕机时，会通过一系列算法进行选主。一般过程是
2n+1个节点各自都投票自己，将自己的zxid和id广播出去，每个节点接到每个信息进行pk,一般
选择zxid大的，如果一样大那么就选id大的。
2 数据同步，因为zxid是事物id,选出来的leader一定是zxid最大的。同步到其他节点有二步。
提出阶段和提交阶段，leader将事物生成提出阶段并广播给followers，收到半数以上的ACK后，
同步将事物进入提交阶段操作应用到内存中，followers收到提议先将事物写到本地事物，然后
反馈ACK。等leader的commit消息时（提交阶段），才将事物操作到内存中。
dubbo的负载均衡策略有四种，随机轮询算法，哈希算法，权重算法，最少活跃度算法。这里一般
是从zk中获得当前服务名的多个ip端口，来进行代码负载均衡算法。
zk集群就是启动多个zk,然后在conf下面的配置文件将多个zk的ip端口写上去，他们就会相互联系。
搭建成集群。
问：
你在使用dubbo时使用hession，有没有其他的协议？有什么优缺点？dubbo整体的使用过程
可以讲一下吗？
答：
首先先讲dubbo的使用过程，dubbo使用的rpc的远程调用方式，是基于netty和hession协议。
这里有个[实例](https://github.com/jack-zdl/spring-cloud/tree/master/spring-netty)。
hession的作用就是来定义传递数据时序列化成rpc的二进制时使用的协议，还有一种protobuf协议。
hession因为简单，效率高。
一个注册中心redis或者zookeeper,注册服务端，将注册服务端注册到redis中，服务提供者
将服务名称和ip和port注册到注册中心。服务消费者向注册中心获取提供者的信息，然后将接口
的方法和参数，做成代理，通过hession序列化成二进制，传递到服务提供者，然后提供者反序列化
成代理类，进行执行方法，返回结果再hession序列化二进制返回回去。消费者拿到在反序列化成
数据。
问：
你说基于netty,netty是NIO，那么你说一下NIO和AIO和BIO的区别，netty的使用讲一下？
答：
netty是基于NIO,全称为同步非阻塞IO。AIO为异步非阻塞IO，BIO为同步阻塞IO.
BIO一般做于正常的io输出，NIO作为连接数目多且连接数目断的例如聊天服务器。AIO作为链接
数目多且连接较长的架构。
spring cloud
问：
你在搭建spring cloud分布式架构时，怎么搭建的？各个组件的功能？内部原理？
答：
在搭建spring cloud项目时，因为他是一种全家桶是微服务方案，eureka作为注册中心，ribbon作
为负载均衡，hystrix作为熔断器，zuul作为路由网关，stream作为mq中间件，config作为
配置中心，bus作为刷新机制，sleuth作为调用链。要比dubbo只作为服务治理功能多的多。
前端工程搭建集群A，由nginx做反向代理127，所有访问127自动负载均衡并反向代理到A。
搭建zuul网关集群B，有keepalived主从切换，或者用nginx做zuul的负载均衡。zuul分发和
校验请求。将所有的微服务都注册到eureka注册中心中。zuul将获得微服务名称下的所有正式ip
和port.将使用ribbon作为负载均衡和hystrix作为熔断器。zuul将校验后的url分发到指定微服务
的路径中，然后微服务之间在进行微服务调用，使用resttemplate或者fegin，一般使用fegin。
因为fegin中已经包含了ribbon和hystrix。并且以申明式调用。方便使用。我们还涉及到分布式
事物。所有要使用mq,所有使用Stream进行mq的操作。还有使用了config来做灵活配置文件。
分布式事务
问：
你说你涉及到了分布式事物，你知道的分布式框架就会有分布式事物的难点。你们是如何做的？
答：
一般网上的分布式事物意见有二种，1 通过MQ来做，即用消息中间件的发送消息给中间件成功，
即代表调用消费者成功。这就要求消费者必须调用成功。可以多次被调用。但是最终一定调用
成功。因为当你把消息发送给消息中间件。消息中间件会不断的推送给消费者，直到消费成功。
当然你可以设计多次调用失败就停止发送。
另外一种是使用DTS的方案。这是阿里巴巴的一种方案。就是典型的二段式提交。首先主事物务执
行成功。就与发送请求调用从事务。看是否可以预执行成功，如果都可以则成功返回，主事务则
正式发送请求。但是这样效率不高，因为从开始到结束都是一直占用连接的。效率不高。
总结：
对于分布式框架和分布式事务。在蚂蚁金服的面试重点提到过，因为蚂蚁金服内部大多使用dubbo
相关的分布式框架。所以你要尽量了解dubbo框架，但是因为现在比较流行的cloud微服务。所以
我这二个都说了一些。但是在分布式事务，感觉自己表现的并不好。他很侧重这个分布式事务这
一块知识。所以他问的很详细，但是这一块我了解的不多。所以这一块是我的短板。
在这分布式知识中蚂蚁金服面试和平安健康的面试中涉及比较多。所以分布式知识你要大致
要了解。