一、前言哈喽！大家好，我是小奇，一位热爱分享的程序员
小奇打算以轻松幽默的对话方式来分享一些技术，如果你觉得通过小奇的文章学到了东西，那就给小奇一个赞吧
文章持续更新
书接上回，今天还是过周末，虽然不上班，但是周末得正常过呀，今天依旧躺在我家祖传的土炕上躺平。
哎，啥时候能老婆孩子热炕头啊，现在自己睡觉怪冷的（还得添把柴）。。。
算了，不想这有的没的了，一切随缘吧，是在不行就让刘婶给我说媒。。。先烧火做饭吧
就在我烧火的时候我的手机突然响了。
我：“喂您好”。
对面：“您好，请问是小奇吗”。
我：“是我，你是？”。
对面：“我是XXX公司的，我看到hr推给我你的简历，我感觉还不错，你什么时候方便来现场面试一下”。
我：“现在不方便现场面试了”。
对面：“好吧，那你现在方便吗？我们现在线上面试一下吧”。
二、面试我：“好的”。
面试官：我看你简历上写的精通Dubbo，那你能说一下Dubbo是什么吗？
我：Dubbo最开始是一款RPC框架，随着功能越来越完善，现在Dubbo是一款Java服务框架。
面试官：嗯，既然你说到了RPC，那么他是什么呢？
我：RPC是远程过程调用，RPC同时也是一种计算机通信协议，他可以从A机器调用B机器的程序，调用的时候就类似于调用本地程序一样方便。
面试官：嗯，那你说一下Dubbo都有哪些特性吧？
Dubbo具有负载均衡、服务超时处理、集群容错、服务降级、本地存根、本地伪装、参数回调、异步调用等特性。
面试官：嗯，那你说一下Dubbo的负载均衡是怎么实现的吧？
我：在Dubbo中，消费者调用服务者的时候会记录服务者的active，比如现在有一个消费者，有A、B两个服务者。
当消费者向A服务发送一条消息的时候，消费者自身会记录A服务的active会加1，当消费者接收到服务者A的相应结果后会将A服务的active减1。
而在消费者选择使用哪个服务者的时候正是根据每个服务者active的大小来判断的，首先选择active小的来调用。
面试官：嗯，那你说一下Dubbo服务超时怎么设置吧，有什么要注意的吗？
Dubbo可以在消费者和服务端都设置超时时间，消费者的超时时间是消费者发出消息后到消费者接收到消息的时间。
服务端的超时时间是服务端接收消息后到处理完毕后发出的时间。
需要注意的是消费端的时间尽量设置的要比服务端的时间要长，因为如果消费端设置的是2秒，服务端设置的是5秒，而服务执行就需要3秒，那么消费端肯定是超时了，但是这个时候服务端并没有超时，不会发生异常。
面试官：嗯，那你说一下Dubbo的集群容错吧？
集群容错是服务端有多个提供者，他们构成集群，当消费者调用服务端的时候服务端通过负载均衡策略选出一个提供者来提供服务，当调用这个服务者发生错误的时候，Dubbo后续采取了一系列策略。
Dubbo提供了多种集群容错模式。
Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster ：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
面试官：“小伙子不错呀，什么时候能回北京入职呢”
我：“额。。。等等吧，现在还有好多家公司等着谈薪资呢，我得挑一家合适的。”
面试官：“你要多少我都给你，来我这吧”
我：“额。。。那就月薪100个W吧”。
面试官：“喂，你说什么我听不见，信号不好。。。”
三、总结我：“喂喂喂”（嘟嘟嘟嘟嘟嘟嘟嘟。。。）。
这里的相关内容还没有整理完毕，文章后面持续更新，建议收藏。
文章中涉及到的命令大家一定要像我一样每个都敲几遍，只有在敲的过程中才能发现自己对命令是否真正的掌握了。
如果觉得我的文章还不错的话就点个赞吧