返回目录：经济新闻
首先了解下什么是容错机制？
容错机制指的是某种系统控制在一定范围内的一种允许或者包容犯错情况的发生，主要用于系统设计，当然容错不等于无限宽容，更不等于可以胡来。
那么dubbo作为一款高性能轻量级的RPC框架，它的容错机制有哪些呢？
failover cluster(失败快速切换)
1:失败快速切换，当出现失败，重试其它服务器
2：通常用于读操作，但是重试会带来更长的延迟
3：可通过设置reties重试次数参数来设置重试
failfast cluster
1：快速失败，只发起一次调用，失败立即报错
2：通常用于非幂等性的写操作，比如新增记录
falisafe cluster
1:失败安全，出现异常，直接忽略
2：通常用于写入审计日志等操作
failback cluster
1:失败自动恢复，后台记录失败请求，定时重发
2：通常用于消息通知
broadcast cluster
1：广播调用所有提供者，逐个调用，任意一台报错则报错
2：通常用于通知所有提供者更新缓存或者日志
总结：
如果是实际中查询语句建议使用默认的faliover cluster ,而增删改建议使用failfast,或者failover 同时设置reties=0防止重复操作
dubbo的负载均衡有哪些？
1：Random loadbalance 随机，按照权重设计随机概率，Random的权重可以使用@Service(weight=10来设置)
2:RoundRobin loadbalance 轮询，按照公约后的权重设置轮询比率，存在慢的提供者积累请求问题，比如：第二台机器很慢，但是没挂，当请求调到第二台时就卡在那，久而久之所有的请求都卡在第二台机器上
解决办法：结合权重，把第二台机器的权重设置低一点
3：leastActive loadbalance 最少活跃调用次数，相同活跃的数的随机，活跃数指调用前后计数差。使用慢的提供者收到更少的请求，因为越慢的提供者调用前后计数差越大
4：Consistenthash loadbalance 一致性hash，相同的请求参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不然会引起剧烈变动
服务降级的简单介绍
服务降级
服务压力剧增的时候更据当前的业务情况及流量对一些服务和页面有策略的降级，以此缓解服务器的压力，以保证核心任务的进行。
同时保证部分甚至大部分任务可以得到正确的响应。也就是当前的请求处理不了了或者出错给一个默认的返回。
服务熔断：在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。
降级分类：
降级按照是否自动化分为：自动开关降级和人工降级
降级按照功能可分为：读服务降级，写服务降级
降级按照处于的系统层次分为：多级降级
自动降级分类
1：超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测恢复情况
2：失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阈值自动降级，同样要使用异步机制探测回复情况
3：故障降级：比如要调用的远程服务挂掉了（网络故障，dns故障，http服务返回错误的状态码，rpc服务抛出异常），则可以直接降级，降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货），兜底数据（比如广告挂了，返回提前准备好的一些静态页面），缓存
（之前暂存的一些缓存数据）
4：限流降级
当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会采用限流来进行限制访问量，当达到限流阈值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户倒流到排队页面等一会重试），无货（直接告知用户没货了），错误页面（如活动太火，稍后重试）等
服务熔断和服务降级比较：
1：目的很一致，都是从可用可靠性着想，为防止系统的整体缓慢甚至崩溃采用的技术手段
2：最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达货不可用
3：粒度一般都是服务级别，当然，业界也有更少更细粒度的做法，比如做到持久层（允许写，不允许读）
4：自治性要求搞，熔断模式一般都是服务基于策略的自动触发，降级虽说可以人工干预，单在微服务下，完全靠人显然不可能，开关预置，配置中心都是必要手段
服务熔断和服务降级的区别：
1：触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般从整体负荷考虑
2：管理目标的层次不一样，熔断其实是一个框架级的处理，每一个微服务都需要，而降级一般对业务有层级之分
服务降级考虑的问题：
1：核心和非核心
2：是否支持降级，降级策略
3：业务放通的场景，策略