容错机制

需要关注点：恢复的时间和恢复的程度 恢复时间： 1、恢复中是否较快 2、恢复过程中出现慢的原因 3、是否出现中断 恢复程度： 1.文件个数是否完整 2.文件类型是否完整 3.文件里面的数据内容是否完整（之前运用数据恢复的软件恢复时出现word文件恢复了，但内容没有恢复里面显示乱码，大小也不符合，只有1M） 其他： 1.重新执行恢复，是否是覆盖式 2.执行过程中是否出现闪退 两种机制：容错机制+补充机制 容错机制：例如界面删除一个内容后，界面功能没有正常显示出来，（例如之前测试的一个网站，删了一个架构的目录分级，结果导致整个界面显示错位，混乱） 补充机制：例如上一次定时任务扣款的时候出现异常未扣款成功，会再次执行性下定时任务，进行第二次扣款，进行补充 来源： https://www.cnblogs.com/moll/p/12552020.html

转载： 一、微服务介绍 1. 什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微 狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。 2. 微服务由来 微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 3. 为什么需要微服务？ 在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高

前面的文章，已经单独对服务发现(Directory、RegistryDirectory)、路由机制(Router)、负载均衡机制( LoadBalance ),本节将重点分析集群容错机制 ( AbstractClusterInvoker), AbstractClusterInvoker 就是将上述机制融合在一起，整个集群容错中，上述组件扮演的角色见下图所示，本文将重点分析 AbstractClusterInvoker 是如何融合这些组件的。 AbstractClusterInvoker#invoke @Override public Result invoke(final Invocation invocation) throws RpcException { checkWhetherDestroyed(); LoadBalance loadbalance = null; List<invoker<t>> invokers = list(invocation); // @1 if (invokers != null && !invokers.isEmpty()) { loadbalance = ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl()

（1）9 shard，3 node （2）master node宕机，自动master选举，red （3）replica容错：新master将replica提升为primary shard，yellow （4）重启宕机node，master copy replica到该node，使用原有的shard并同步宕机后的修改，green 来源： CSDN 作者： 潇凝子潇 链接： https://blog.csdn.net/xu990128638/article/details/104108495

目录 前言 一、微服务介绍 1.什么是微服务 微服务由来 为什么需要微服务？ 3.1 早期的单体架构带来的问题 3.2 微服务与单体架构区别 3.3 微服务与SOA区别 微服务本质 什么样的项目适合微服务 微服务折分与设计 6.1 微服务设计原则 微服务优势与缺点 7.1 特性 7.2 特点 7.3 缺点 微服务开发框架 Sprint cloud 和 Sprint boot区别 二、微服务实践先知 客户端如何访问这些服务？（API Gateway） 服务之间如何通信？（服务调用） 这么多服务怎么查找？（服务发现） 服务挂了怎么办？ 微服务需要考虑的问题 三、微服务重要部件 微服务基本能力 服务注册中心 2.1 zookeeper服务注册和发现 负载均衡 3.1 负载均衡的常见策略 容错 4.1 容错策略 熔断 限流和降级 SLA API网关 多级缓存 超时和重试 线程池隔离 降级和限流 网关监控和统计 前言 到底什么是微服务？为什么要用微服务？微服务主要来做一些什么？微服务有哪些优势？什么样的服务属于微服务？本文所有资料来源网络，我只是整理一下，总结一下。仅供参考。 一、微服务介绍 1.什么是微服务 在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"， 微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释

在收到提供者执行的结果时，当结果处理失败时，需要对其进行处理。 在Reference中，返回的Invoker是根据对应的容错机制生成的Invoker <dubbo:reference id="testService" interface="com.test.ITestService" cluster="failfast"/> failover cluster 失败的时候自动切换并重试其他服务器。 通过retries=2。 来设置重试次数（默认） failfast cluster 快速失败，只发起一次调用 ; 写操作。比如新增记录的时候， 非幂等请求 failsafe cluster 失败安全。 出现异常时，直接忽略异常 – 写日志 failback cluster 失败自动恢复。 后台记录失败请求，定时重发 forking cluster 并行调用多个服务器，只要一个成功就返回。 只能应用在读请求 broadcast cluster 广播调用所有提供者，逐个调用。.3其中一台报错就会返回异常 @SPI(FailoverCluster.NAME) public interface Cluster { @Adaptive <T> Invoker<T> join(Directory<T> directory) throws RpcException; } FailoverCluster

一、dubbo容错 1、配置方式 1 ）服务端设置 < dubbo : service cluster = "failsafe" retries = "2" / > 2 ）调用端设置 < dubbo : reference cluster = "failsafe" retries = "2" / > 2、FailoverClusterInvoker FailoverClusterInvoker是一种失败后，重新换其他机器重试，并设有重试次数的一种容错机制 @Override @SuppressWarnings ( { "unchecked" , "rawtypes" } ) public Result doInvoke ( Invocation invocation , final List < Invoker < T > > invokers , LoadBalance loadbalance ) throws RpcException { List < Invoker < T > > copyinvokers = invokers ; // 对 copyinvokers 进行判空检查 checkInvokers ( copyinvokers , invocation ) ; //获取重试次数，如果参数没配，默认是2次，再加上第一次调用，总共调用3次 int len =

什么是POS？ POS是一种在公链中的共识算法，可作为POW算法的一种替换。POW是保证比特币、当前以太坊和许多其它区块链安全的一种机制，但是POW算法在挖矿过程中因破坏环境和浪费电力而受到指责。POS试图通过以一种不同的机制取代挖矿的概念，从而解决这些问题。 POS机制可以被描述成一种虚拟挖矿。鉴于POW主要依赖于计算机硬件的稀缺性来防止女巫攻击，POS则主要依赖于区块链自身里的代币。在POW中，一个用户可能拿1000美元来买计算机，加入网络来挖矿产生新区块，从而得到奖励。而在POS中，用户可以拿1000美元购买等价值的代币，把这些代币当作押金放入POS机制中，这样用户就有机会产生新块而得到奖励。在POW中，如果用户花费2000美元购买硬件设备，当然会获得两倍算力来挖矿，从而获得两倍奖励。同样，在POS机制中投入两倍的代币作为押金，就有两倍大的机会获得产生新区块的权利。 总体上说，POS算法如下所示。存在一个持币人的集合，他们把手中的代币放入POS机制中，这样他们就变成验证者。假设在区块链最前面一个区块（区块链中最新的块），这时POS算法在这些验证者中随机选取一个（选择验证者的权重依据他们投入的代币多少，比如一个投入押金为10000代币的验证者被选择的概率是一个投入1000代币验证者的10倍），给他们权利产生下一个区块。如果在一定时间内，这个验证者没有产生一个区块

在此基础上记录dubbo官网介绍的常用属性配置,dubbo读取我们配置的属性时是有优先级的,优先级如下图：　　 　　　　　　　　　　　　　　　　　　 　　如图所示，优先级的属性依次为虚拟机参数>xml配置>dubbo.properties,虚拟机参数即程序启动之前我们通过-D配置的dubbo属性,xml配置即我们项目中自己写的xml文件或者是springboot中的application.properties，当公共配置很简单，没有多注册中心，多协议等情况，或者想多个 Spring 容器想共享配置的情况下可以用dubbo.properties作为缺省配置；需要注意的是我这里的测试用例都是写在application.properties中,当然如果感觉不习惯,也可以跟普通maven项目一样新建xml文件,在xml中进行配置，只是不要忘了在springboot的启动类中添加@ImportResource(locations="xml路径")注解来引入就行,下面开始记录dubbo的常用配置； 　　一、启动时检查(check) 　　默认情况下dubbo是开启自动检查的,即当项目启动时会自动检查其依赖的服务是否开启,如果没开是会阻止spring的初始化的,即check=true;我们可以将check置为false来关闭启动时检查,如我们在测试或者对其他服务没有依赖的时候可以关闭检查

　　之前记录了基于springboot的dubbo入门案例,今天在此基础上记录dubbo官网介绍的常用属性配置,dubbo读取我们配置的属性时是有优先级的,优先级如下图：　　 　　　　　　　　　　　　　　　　　　 　　如图所示，优先级的属性依次为虚拟机参数>xml配置>dubbo.properties,虚拟机参数即程序启动之前我们通过-D配置的dubbo属性,xml配置即我们项目中自己写的xml文件或者是springboot中的application.properties，当公共配置很简单，没有多注册中心，多协议等情况，或者想多个 Spring 容器想共享配置的情况下可以用dubbo.properties作为缺省配置；需要注意的是我这里的测试用例都是写在application.properties中,当然如果感觉不习惯,也可以跟普通maven项目一样新建xml文件,在xml中进行配置，只是不要忘了在springboot的启动类中添加@ImportResource(locations="xml路径")注解来引入就行,下面开始记录dubbo的常用配置； 　　一、启动时检查(check) 　　默认情况下dubbo是开启自动检查的,即当项目启动时会自动检查其依赖的服务是否开启,如果没开是会阻止spring的初始化的,即check=true;我们可以将check置为false来关闭启动时检查