一：负载均衡
为什么要负载均衡
当服务端存在集群时，需要通过一定的调度算法将流量分发到不同的应用服务器上面。
Dubbo 中负载均衡的应用
Dubbo 中负载均衡的应用
配置的属性名称： roundrobin/random/leastactive/ consistenthash
<dubbo:service interface="..." loadbalance="roundrobin" />
<dubbo:reference interface="..." loadbalance="roundrobin" />
可以在服务端配置，也可以在客户端配置。
如果是基于注解，配置如下
@Service(loadbalance = "roundrobin")
public class HelloServiceImpl implements IHelloService{
或者
@Reference(loadbalance = "random")
IHelloService helloService;
Dubbo 负载均衡算法
RandomLoadBalance
权重随机算法，根据权重值进行随机负载
它的算法思想很简单。假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为
weights = [5, 3, 2]，权重总和为 10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区
间属于服务器 A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器 C。接下来通过
随机数生成器生成一个范围在 [0, 10) 之间的随机数，然后计算这个随机数会落到哪个
区间上。比如数字 3 会落到服务器 A 对应的区间上，此时返回服务器 A 即可。权重
越大的机器，在坐标轴上对应的区间范围就越大，因此随机数生成器生成的数字就会
有更大的概率落到此区间内。只要随机数生成器产生的随机数分布性很好，在经过多
次选择后，每个服务器被选中的次数比例接近其权重比例
LeastActiveLoadBalance
最少活跃调用数算法，活跃调用数越小，表明该服务提供者效率越高，单位时间内可
笔记是帮助大家回顾和掌握的手段，不要过多依赖于笔记，转载请注明《咕泡学院》
处理更多的请求这个是比较科学的负载均衡算法。
每个服务提供者对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为 0。
每收到一个请求，活跃数加 1，完成请求后则将活跃数减 1。在服务运行一段时间后，
性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服
务提供者能够优先获取到新的服务请求
ConsistentHashLoadBalance
hash 一致性算法，相同参数的请求总是发到同一提供者
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，
不会引起剧烈变动
RoundRobinLoadBalance
加权轮询算法
所谓轮询是指将请求轮流分配给每台服务器。举个例子，我们有三台服务器 A、B、C。
我们将第一个请求分配给服务器 A，第二个请求分配给服务器 B，第三个请求分配给
服务器 C，第四个请求再次分配给服务器 A。这个过程就叫做轮询。轮询是一种无状
态负载均衡算法，实现简单，适用于每台服务器性能相近的场景下。但现实情况下，
我们并不能保证每台服务器性能均相近。如果我们将等量的请求分配给性能较差的服
务器，这显然是不合理的。因此，这个时候我们需要对轮询过程进行加权，以调控每
台服务器的负载。经过加权后，每台服务器能够得到的请求数比例，接近或等于他们
的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在 8 次请求中，服务器 A 将
收到其中的 5 次请求，服务器 B 会收到其中的 2 次请求，服务器 C 则收到其中的 1
笔记是帮助大家回顾和掌握的手段，不要过多依赖于笔记，转载请注明《咕泡学院》
次请求
二：集群容错
在分布式网络通信中，容错能力是必须要具备的，什么叫容错呢？ 从字面意思来看：
容：是容忍， 错：是错误。 就是容忍错误的能力。
我们知道网络通信会有很多不确定因素，比如网络延迟、网络中断、服务异常等，会
造成当前这次请求出现失败。当服务通信出现这个问题时，需要采取一定的措施应对。
而 dubbo 中提供了容错机制来优雅处理这种错误
在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。
@Service(loadbalance = "random", cluster = "failsafe")
Failover Cluster
失败自动切换，当出现失败，重试其它服务器。(缺省)
通常用于读操作，但重试会带来更长延迟。
可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。
通常用于非幂等性的写操作，比如新增记录。
笔记是帮助大家回顾和掌握的手段，不要过多依赖于笔记，转载请注明《咕泡学院》
Failsafe Cluster
失败安全，出现异常时，直接忽略。
通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。
通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0 开始支持)
通常用于通知所有提供者更新缓存或日志等本地资源信息。
在实际应用中 查询语句容错策略建议使用默认 Failover Cluster ，而增删改 建议使用
Failfast Cluster 或者 使用 Failover Cluster（retries=”0”） 策略 防止出现数据 重复
添加等等其它问题！建议在设计接口时候把查询接口方法单独做一个接口提供查询。
三：降级
降级的概念
当某个非关键服务出现错误时，可以通过降级功能来临时屏蔽这个服务。降级可以有
几个层面的分类： 自动降级和人工降级； 按照功能可以分为：读服务降级和写服务
降级；
- 对一些非核心服务进行人工降级，在大促之前通过降级开关关闭哪些推荐内容、评
价等对主流程没有影响的功能 - 故障降级，比如调用的远程服务挂了，网络故障、或者 RPC 服务返回异常。 那么
可以直接降级，降级的方案比如设置默认值、采用兜底数据（系统推荐的行为广告
挂了，可以提前准备静态页面做返回）等等 - 限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特
别大可能会导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阀值
时，后续的请求被降级，比如进入排队页面，比如跳转到错误页（活动太火爆，稍
后重试等）
那么，Dubbo 中如何实现服务降级呢？Dubbo 中提供了一个 mock 的配置，可以通过
mock 来实现当服务提供方出现网络异常或者挂掉以后，客户端不抛出异常，而是通过
Mock 数据返回自定义的数据
Dubbo 实现服务降级
在 dubbo-client 端创建一个 mock 类，当出现服务降级时，会被调用
public class MockSayHelloService implements IHelloService {
@Override
public String sayHello() {
return "Sorry, 服务端发生异常，被降级啦！";
}
}
修改客户端的注解，增加 mock 配置，以及修改 timeout=1， 表示本次调用的超时时
间是 1 毫秒，这样可以模拟出失败的场景
需要配置 cluster=failfast，否则因为默认是 failover 导致客户端会发起 3 次重试，等待
的时间比较长
@Reference(
loadbalance = "random",
mock =
"com.springboot.practice.springbootdubboclient.MockSayHelloService",
timeout =1000,
cluster = "failfast")
IHelloService helloService;
四：主机绑定
默认的主机绑定方式
- 通过 LocalHost.getLocalHost()获取本机地址。
- 如果是 127.*等 loopback（环路地址）地址，则扫描各网卡，获取网卡 IP。
- 如果是 springboot，修改配置：dubbo.protocol.host=””
- 如果注册地址获取不正确，可以通过在 dubbo.xml 中加入主机地址的配置
<dubbo:protocol host="205.182.23.201">
缺省主机端口
dubbo: 20880
rmi: 1099
http: 80
hessian: 80
webservice: 80
memcached: 11211
redis: 6379
以上内容来自《咕泡学院》
