• 关于

    维护策略有什么用

    的搜索结果

回答

首先来个高端的概念, 前者我们通常称之为设计模式之策略模式;说下这种模式对应的场景:假如现在你某个类想调用猫和老虎的叫方法, 怎么办? 用你后面的定义方式:class 别管我叫什么 { static void call(猫 cat) { cat.叫(); } static void call(老虎 tiger) { tiger.叫(); } } 别管我叫什么.call(new 猫()); 别管我叫什么.call(new 老虎());哎呀, 同样的代码, 我要写两遍诶! 现在是代码量小, 我还可以不怕麻烦人肉写. 如果代码很大的? 不但写起来费力气, 维护起来也恶心人啊!好了, 现在由策略模式来解放你!class 别管我叫什么 { static void call(猫科 cat) { cat.叫(); } } 别管我叫什么.call(new 猫()); 别管我叫什么.call(new 老虎());有么有很简单! 写起来好省心的说! 后面维护这段代码的人都会在心里默默的感谢你!

蛮大人123 2019-12-02 01:53:37 0 浏览量 回答数 0

问题

【精品问答】dubbo必备面试题集

游客pklijor6gytpx 2019-12-01 21:54:02 54 浏览量 回答数 1

问题

Windows服务器日常维护策略

我的中国 2019-12-01 21:57:39 2665 浏览量 回答数 1

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

【PDF下载】阿里研发峰会之阿里巴巴分层自动化实践之路

云栖技术 2019-12-01 21:01:34 1199 浏览量 回答数 1

回答

对于一个简单的数据库应用,由于对于数据库的访问不是很频繁。这时可以简单地在需要访问数据库时,就新创建一个连接,用完后就关闭它,这样做也不会带来什么明显的性能上的开销。但是对于一个复杂的数据库应用,情况就完全不同了。频繁的建立、关闭连接,会极大的减低系统的性能,因为对于连接的使用成了系统性能的瓶颈。连接复用。通过建立一个数据库连接池以及一套连接使用管理策略,使得一个数据库连接可以得到高效、安全的复用,避免了数据库连接频繁建立、关闭的开销。对于共享资源,有一个很著名的设计模式:资源池。该模式正是为了解决资源频繁分配、释放所造成的问题的。把该模式应用到数据库连接管理领域,就是建立一个数据库连接池,提供一套高效的连接分配、使用策略,最终目标是实现连接的高效、安全的复用。数据库连接池的基本原理是在内部对象池中维护一定数量的数据库连接,并对外暴露数据库连接获取和返回方法。如:外部使用者可通过getConnection 方法获取连接,使用完毕后再通过releaseConnection 方法将连接返回,注意此时连接并没有关闭,而是由连接池管理器回收,并为下一次使用做好准备。

huanhuanming 2019-12-02 01:50:31 0 浏览量 回答数 0

问题

什么是Memcache 管理控制台

云栖大讲堂 2019-12-01 21:30:32 1136 浏览量 回答数 0

问题

集群部署时的分布式 Session 如何实现?【Java问答学堂】59期

剑曼红尘 2020-07-16 15:14:21 5 浏览量 回答数 1

问题

如何整合入侵检测系统和入侵防御系统

elinks 2019-12-01 21:15:22 6216 浏览量 回答数 0

回答

静态方法获取session是通过ThreadLocal实现的,所以,你需要改一种实现思路。 比如,在往线程池提交任务之前,就先获取当前的session,然后将其set为Task类的一个属性,然后当Task被线程池执行的时候,直接通过get方法得到对应的session,然后setAttribute就没有问题啦。######嗯,通过构造函数传参。###### 都是基于线程上下文的用户Session,需要用Shiro的API来启动新的线程,这样才能传递Session绑定。 http://shiro.apache.org/static/1.2.3/apidocs/######好蛋疼吧,嘿嘿。###### @蓝水晶飞机 那为什么我使用java的线程池就没有问题,用spring的线程池就有问题 java线程池,在代码里面直接使用: Executors.newCachedThreadPool() spring线程池,在xml文件中的配置,通过@Autowired使用: <!-- 配置spring线程池 --> <bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor" scope="singleton"> <!-- 线程池维护线程的最少数量 --> <property name="corePoolSize" value="5" /> <!-- 允许的空闲时间 --> <property name="keepAliveSeconds" value="200" /> <!-- 线程池维护线程的最大数量 --> <property name="maxPoolSize" value="10" /> <!-- 缓存队列 --> <property name="queueCapacity" value="20" /> <!-- 对拒绝task的处理策略 --> <property name="rejectedExecutionHandler"> <bean class="java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy" /> </property> </bean>  ######回复 @蓝水晶飞机 : 嗯,通过构造函数传参######这个我不懂为什么了,我没用过这东西。不过能不能改一下设计,提交异步作业时,将用户信息传递到Job里面。######session信息存储到threadlocal里了,你另起线程当然取不到######我用java的连接池就没有问题,用spring的连接池就有问题######应该如何解决?

爱吃鱼的程序员 2020-06-01 14:28:13 0 浏览量 回答数 0

问题

为什么使用消息队列?【Java问答学堂】17期

剑曼红尘 2020-05-13 20:39:29 1 浏览量 回答数 1

回答

面试官心理分析 其实面试官主要是想看看: 第一,你知不知道你们系统里为什么要用消息队列这个东西? 不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。 没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿,不会自己思考。 第二,你既然用了消息队列这个东西,你知不知道用了有什么好处&坏处? 你要是没考虑过这个,那你盲目弄个 MQ 进系统里,后面出了问题你是不是就自己溜了给公司留坑?你要是没考虑过引入一个技术可能存在的弊端和风险,面试官把这类候选人招进来了,基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑,自己跳槽了,给公司留下无穷后患。 第三,既然你用了 MQ,可能是某一种 MQ,那么你当时做没做过调研? 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ,比如 Kafka,甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏,但是就是看用在哪个场景可以扬长避短,利用其优势,规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队,leader 交给他一个任务,去设计个什么系统,他在里面用一些技术,可能都没考虑过选型,最后选的技术可能并不一定合适,一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么? 面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃...... mq-1 在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办?要不要重发,要不要把消息存起来?头发都白了啊! 如果使用 MQ,A 系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可。这样下来,A 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。 mq-2 总结:通过一个 MQ,Pub/Sub 发布订阅消息这么一个模型,A 系统就跟其它系统彻底解耦了。 面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。 异步 再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。 mq-3 一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。 如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回了,爽!网站做得真好,真快! mq-4 削峰 每天 0:00 到 12:00,A 系统风平浪静,每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ,每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的,大量的请求涌入 MySQL,每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL,扛到每秒 2k 个请求就差不多了,如果每秒请求到 5k 的话,可能就直接把 MySQL 给打死了,导致系统崩溃,用户也就没法再使用系统了。 但是高峰期一过,到了下午的时候,就成了低峰期,可能也就 1w 的用户同时在网站上操作,每秒中的请求数量可能也就 50 个请求,对整个系统几乎没有任何的压力。 mq-5 如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来,就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。 mq-6 这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决掉。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊? 【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊? 【Java问答学堂】11期 es 生产集群的部署架构是什么?每个索引的数据量大概有多少? 【Java问答学堂】12期 项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果? 【Java问答学堂】13期 redis 和 memcached 有什么区别? 【Java问答学堂】14期 redis 都有哪些数据类型?分别在哪些场景下使用比较合适? 【Java问答学堂】15期redis 的过期策略都有哪些?内存淘汰机制都有哪些? 【Java问答学堂】16期如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍

剑曼红尘 2020-05-13 20:39:42 0 浏览量 回答数 0

问题

Hystrix 是什么?【Java问答学堂】60期

剑曼红尘 2020-07-20 12:49:25 2 浏览量 回答数 1

问题

直播|阿里巴巴持续集成持续交付之分层自动化

云效平台 2019-12-01 21:13:36 4738 浏览量 回答数 2

回答

[上海-java-白夜] 前端跨域用jsonp封装js回调 [健] 天猫和淘宝使用同一个SSO服务器。不管token  cookie 什么机制。同一个标识符,两个网站的辨识逻辑都是一样的**[重庆-后端-谭鹏] **这个标识符是什么呀 肯定的得前端携带了什么东西的在服务端进行鉴别的 不然服务端是怎么确定用户身份的,直到他已经在淘宝登陆过了 [上海-java-白夜] 天猫,淘宝的认证中心都在一起的,cookie信息是在你客户端的,通过请求传到服务器去的localstorage 或者 cookie 的 一个token。 是什么无所谓。重要的是两个网站去同一个地方去校验token  所以结果是一样的。不管你哪个域,服务端的认证中心是同一个,阿里都是中台,怎么可能每个项目一个认证中心,基础服务都统一出来了你用它旗下的网站的服务,用的cookie里面的那个表示你身份的信息key都可以是同一个,你回调的时候把token作为js传过去不就行了,正常情况下,你认证成功,直接会把你的token跟在你要跳转的新页面一起跳转过去**[重庆-后端-谭鹏] 嗯 假设这一次是登陆了淘宝嘛,那我再访问天猫的时候 前端怎么携带淘宝登陆后返回的票据?如果不携带的话 认证服务 肯定就认为你没有登陆[上海-java-白夜] 或者你后端将cros设置一下也是可以跨域接收资源的,这个票据在你的cookie里面,cookie是在你的客户端浏览器储存的[重庆-后端-谭鹏] 哪一个的cookie ?淘宝登陆了的话肯定这个token是存在淘宝域名下的。 天猫怎么能拿到这个token的 这就是我的这个疑问点,还是说前端有这样的技术 可以拿跨主域名的的cookie信息吗[上海-java-白夜] **或者服务器端cros设置一下就可以跨了,或者nginx代理一下也是可以跨的 [深圳-后端-章鱼] 说了半天,不如一张图清楚,关键在第七步,单点登录系统将ticket加载A系统的URL后面,A系统使用过滤器,将ticket写到自己域名下,应该没问题吧[成都-java-creed] 关键是输入用户名成功后,会生成sso认证的cookice,这个cookie就是跨域名访问的关键了[java-刘锦] 这个cookie是全局的?[杭州-后端-xinhe] 不是,每个域名各自维护自己的cookie,通过ticket传递用户身份[java-刘锦****] ticket是全局?[北京-java-犀利豆] ticket只用一次,session是全局的[杭州-后端-xinhe] 是的,我当时做的session各应用独立管理本地部分,但是生命周期会统一管理,全局统一登录登出和保活[深圳-后端-章鱼] 很强,关键就在sso.com认证中心自己的cookie[成都-java-creed] 我认证sso自己的cookie是认证里面的关键,没有这玩不了的[杭州-后端-xinhe] 对,这个把整个流程串起来了 [北京-JAVA-阿轩] 当我访问b系统,ticket哪里来的[成都-java-creed]1 用户在www.a.com正常上网,突然想访问www.b.com,于是发起访问www.b.com的请求。2 www.b.com接收到请求,发现第一次访问,于是给他一个重定向的地址,让他去找认证中心登录。3 浏览器根据返回的地址,发起重定向,因为之前访问过一次了,因此这次会携带上次返回的Cookie:认证中心。4 认证中心收到请求,发现cookie内容能取到对应的认证信息,生成ticket,并且返回给浏览器,让他重定向到www.b.com[北京-java-犀利豆] 登录了a系统 说明 你已经登录了oss。等你登录b的时候,b会让你先到oss那里领一个ticket。你用ticket到b那里验证,验证成功了,b给你种上cookie[北京-JAVA-阿轩] 同一个session去oss索取的ticket是一样的呗[北京-java-犀利豆] @北京-JAVA-阿轩 不一定一样。[深圳-后端-章鱼] session会被状态限制,cookie则是时间限制[北京-JAVA-阿轩] 那b是通过解析ticket来确认是不是a登录过么[北京-java-犀利豆] 用户从oss拿到ticket,然后去b访问,b也会在后端 问一下oss,这个ticket是不是他发的。如果验证成功,b会给用户种上cookie。ticket就可以作废了。这个是后你去c,c会让你先去oss看看有没有ticket,如果有,就回到上面我说的流程。[java-刘锦] 那session干了啥[深圳-后端-章鱼] session只是用于获取token后,各自服务器里存用户的登录状态和权限等,方便后续的访问[北京-JAVA-阿轩] 那单点登录难点,和安全性,是哪里!感觉不难啊,安全也不太安全,窃取到了ticket,不就谁都可以登录了[北京-java-犀利豆] ticket是一次性的。[java-刘锦] 怎么保证一次性[北京-java-犀利豆] 在ticket里面,你可以加上ip之类的标识,加上时间,次数的限制,比ticket只能被校验一次,再来校验就不行了。手机充值卡怎么保证只能充一次,ticket就怎么保证只用一次。 [北京-JAVA-阿轩] 跨域原理是什么[福建-后端-Rule] 浏览器同源策略[北京-java-犀利豆] ticket 你可放在url。或者header里面。就不存在跨越问题[北京-JAVA-阿轩] 这可以避免同源策略么[北京-JAVA-阿轩] 浏览器怎么做到同源策略的,怎么和服务器配合支持和不支持跨域的!跟TCP协议有关么[北京-java-犀利豆] 跨域是浏览器实现的安全策略[北京-JAVA-阿轩] 原来测试的时候,发现前端会有一个预请求!确认,接口无感知!这个是和什么打交道的[北京-java-犀利豆] option?[上海-JAVA开发] 这个一般解决跨服务器请求的,如果程序里面有第三方服务器的话会先发个option探探情况 来源:云原生后端社区https://www.yuque.com/server_mind/answer

montos 2020-04-20 20:44:31 0 浏览量 回答数 0

回答

伸缩组是具有相同应用场景的ECS实例集合。您可以通过伸缩组定义可容纳ECS实例数量的边界值、弹性扩张时创建ECS实例的模板、弹性收缩时移出ECS实例的策略等属性,让伸缩组按照您的需求维护一组ECS实例。您还可以为伸缩组关联负载均衡实例和RDS实例,以便加入伸缩组的ECS实例快速提供服务。 前提条件 如果选择实例启动模板作为自动创建ECS实例的模板,您需要提前创建好实例启动模板,具体操作请参见创建实例启动模板。 如果需要为伸缩组关联负载均衡实例,请确保满足以下条件: 您持有一个或多个处于运行中状态的负载均衡实例,具体操作请参见创建负载均衡实例。 负载均衡实例和伸缩组必须位于同一地域。 如果负载均衡实例和伸缩组的网络类型均为专有网络,则必须位于同一专有网络。 当负载均衡实例的网络类型为经典网络,伸缩组的网络类型为专有网络时,如果负载均衡实例的后端服务器组中包含专有网络ECS实例,该ECS实例必须与伸缩组位于同一专有网络。 负载均衡实例配置至少一个监听,具体操作请参见监听概述。 负载均衡实例必须开启健康检查,具体操作请参见配置健康检查。 如果需要为伸缩组关联RDS实例,请确保满足以下条件: 您持有一个或多个处于运行中状态的RDS实例,具体操作请参见什么是云数据库RDS。 RDS实例和伸缩组必须位于同一地域。 背景信息 您能创建的伸缩组数量有上限,更多信息请参见使用限制。 操作步骤 登录弹性伸缩控制台。 单击创建伸缩组。 设置伸缩配置来源。 选择来源类型。 来源类型 说明 选择实例启动模板 扩容时使用实例启动模板中的实例配置信息。 选择已有实例 提取已有ECS实例的配置信息创建一个默认伸缩配置,作为自动创建ECS实例的模板。提取的配置信息包括实例的实例规格、镜像、网络类型、安全组、登录密码、标签等。 从0开始创建 不指定自动创建ECS实例的模板,伸缩组创建完成后进入停用状态。您需要继续创建伸缩配置或指定启动模板作为自动创建ECS实例的模板,然后才能启用伸缩组。 可选: 根据伸缩配置来源类型设置必要信息。 如果伸缩配置来源类型为选择实例启动模板,选择已创建的实例启动模板和实例启动模板版本。 如果伸缩配置来源类型为选择已有实例,选择已创建的ECS实例。 设置伸缩组基本信息。 填写伸缩组名称。 填写组内实例数。 数量类型 说明 组内最大实例数 当前ECS实例数量超过上限时,弹性伸缩会自动移出ECS实例,使得伸缩组内的ECS实例数量等于上限。 组内最小实例数 当前ECS实例数量低于下限时,弹性伸缩会自动添加ECS实例,使得伸缩组内的ECS实例数量等于下限。 组内期望实例数 伸缩组会自动将ECS实例数量维持在期望实例数,更多说明请参见期望实例数。 填写默认冷却时间。 单位为秒,伸缩组发生伸缩活动后的默认冷却时间。在冷却时间内,伸缩组会拒绝由云监控报警任务触发的伸缩活动请求,但其他类型任务触发的伸缩活动可以绕过冷却时间立即执行,例如手动执行任务、定时任务。 可选: 选择实例移出策略。 当需要从伸缩组移出ECS实例并且有多种选择时,按该策略选择需要移出的ECS实例,支持两段设置。如果按策略筛选后仍有多台ECS实例满足要求,则随机移出一台。 设置类型 设置选项 说明 第一段设置 最早伸缩配置对应的实例 此处伸缩配置泛指组内实例配置信息来源,包括伸缩配置和启动模板。 筛选添加时间最早的伸缩配置和启动模板对应的实例。手动添加的实例没有关联伸缩配置或启动模板,因此不会首先选出手动添加的实例。如果已移出全部关联的实例,仍需要继续移出实例,则随机移出手动添加的实例。 启动模板的版本号低不代表添加时间早,例如在创建伸缩组时选择实例启动模板lt-foress的版本2,然后修改伸缩组,选择实例启动模板lt-foress的版本1,则对伸缩组来说,启动模板lt-foress的版本2是最早的。 最早创建的实例 筛选创建时间最早的实例。 最新创建的实例 筛选创建时间最新的实例。 第二段设置 无策略 不进行第二段筛选。 最早创建的实例 在第一段筛选出的实例中,再筛选创建时间最早的实例。 最新创建的实例 在第一段筛选出的实例中,再筛选创建时间最新的实例。 默认先筛选最早伸缩配置对应的实例,在结果中再筛选并移出最早创建的实例。 可选: 设置伸缩组删除保护。 开启伸缩组保护后,您不能在控制台或者通过API删除该伸缩组,有效避免误删除伸缩组。 添加标签。 添加标签便于搜索和聚合伸缩组,更多标签介绍请参见标签概述。 完成组内实例扩缩容配置。 选择网络类型。 注意 伸缩组创建完成后,不支持修改网络类型。 网络类型 说明 经典网络 创建伸缩配置时,只能选择支持经典网络的实例规格。 手动添加已有ECS实例时,只能选择经典网络实例。 专有网络 创建伸缩配置时,只能选择支持专有网络的实例规格。 手动添加已有ECS实例时,只能选择同一专有网络中的实例。 可选: 如果网络类型为专有网络,配置专有网络相关选项。 注意 伸缩组创建完成后,不支持修改专有网络、多可用区扩缩容策略和实例回收模式。 专有网络和虚拟交换机。 一个虚拟交换机只能属于一个可用区,您可以指定多个属于不同可用区的虚拟交换机,从而达到多可用区的效果。多可用区可以规避单可用区库存不足的风险,提高扩容成功率。 多可用区扩缩容策略。 策略名称 说明 优先级策略 先选择的虚拟交换机优先级高。当伸缩组无法在优先级较高的虚拟交换机所在可用区创建ECS实例时,会自动使用下一优先级的虚拟交换机创建ECS实例。 均衡分布策略 在伸缩组关联多个虚拟交换机且虚拟交换机分布在两个以上可用区时生效,支持在虚拟交换机所在的可用区之间均衡分布ECS实例。如果由于库存不足等原因导致可用区之间ECS实例的数量不均衡,您可以执行再均衡分布操作来平衡ECS实例的分布情况,具体操作请参见ECS实例再均衡分布。 成本优化策略 在伸缩配置中指定了多个可选实例规格时生效,按vCPU单价从低到高尝试创建ECS实例。 如果伸缩配置中计费方式选择抢占式实例,优先创建抢占式实例。由于库存等原因无法创建各实例规格的抢占式实例时,再自动尝试创建按量付费实例。 如果您选择成本优化策略,还可以设置以下参数启用混合实例功能: 混合实例选项 说明 组内最小按量实例数 伸缩组所需按量付费ECS实例的最小台数,默认为0台。如果伸缩组内的按量付费ECS实例的台数小于该值,将优先创建按量付费实例。 按量实例所占比例 自动创建ECS实例时按量付费实例所占的比例,默认为70%。计算该值时,不包括组内最小按量实例数对应的台数。 最低价的多个实例规格 价格最低的实例规格的个数,默认为1个。在伸缩配置中指定了多个可选实例规格时生效。创建抢占式实例时,弹性伸缩会在价格最低的几个实例规格之间均衡创建ECS实例。 是否开启抢占式实例补偿 开启抢占式实例补偿后,在抢占式实例被回收前5分钟,弹性伸缩会主动创建新的抢占式实例,并替换掉将被回收的抢占式实例。 实例回收模式。 模式名称 说明 释放模式 在弹性收缩时自动释放合适数量的ECS实例,在弹性扩张时创建新的ECS实例加入伸缩组。 停机回收模式 使用停机回收模式可以提高扩缩容的效率。 在弹性收缩时,自动创建的ECS实例将进入停机不收费状态。ECS处于停机不收费状态时,vCPU、内存和固定公网IP被回收,因此vCPU、内存和固定公网带宽不再收费,但是云盘、弹性公网IP等资源仍然保留并收费,更多信息请参见按量付费实例停机不收费。这些处于停机不收费状态ECS实例形成了停机实例池。 说明 如果ECS实例进入停机不收费状态前有固定公网IP,重新启动时会重新分配一个固定公网IP,但可能发生变化。 在弹性扩张时,停机实例池内的ECS实例会优先进入运行中状态,在停机实例池内ECS实例数量不足以满足需求时,会继续自动创建新的ECS实例。 弹性扩张时,停机实例池内ECS实例不能保证成功进入运行中状态。如果由于库存等原因,处于停机不收费状态的ECS实例不能进入运行中状态,弹性伸缩会释放这些ECS实例并创建新的ECS实例,保证弹性扩张的结果达到预期。 可选: 添加已有实例。 如果勾选将实例的生命周期托管给伸缩组,添加的已有实例处于不健康状态时,会被自动释放。 说明 伸缩配置来源类型为从0开始创建时不支持配置此项。 完成高级配置。 一个伸缩组支持关联的负载均衡实例和RDS实例数量有限,更多信息请参见使用限制。 关联负载均衡实例。 关联负载均衡实例后,加入伸缩组的ECS实例会自动添加为负载均衡实例的后端服务器。您可以指定ECS实例需要加入的服务器组,支持以下两种服务器组: 服务器组类型 端口 权重 说明 默认服务器组 为负载均衡实例配置监听时填写。 默认为50,您也可以在伸缩配置中填写其它权重值。 用来接收前端请求的ECS实例,如果监听没有设置虚拟服务器组或主备服务器组,默认将请求转发至默认服务器组中的ECS实例。 虚拟服务器组 选择虚拟服务器组时填写。 默认为50,您也可以在选择虚拟服务器组时填写其它权重值。 当您需要将不同的请求转发到不同的后端服务器上时,或需要通过域名和URL进行请求转发时,可以选择使用虚拟服务器组。 一个伸缩组支持指定多个虚拟服务器组,但是数量有限,更多信息请参见使用限制。 说明 如果您同时指定了默认服务器组和多个虚拟服务器组,ECS实例会同时添加至这些服务器组中。 关联RDS数据库实例。 关联RDS实例后,加入伸缩组的ECS实例的内网IP会自动加入RDS实例的访问白名单,允许ECS实例和RDS实例内网通信。 单击创建伸缩组。 伸缩组创建完成后,伸缩组处于启用状态才可以将ECS实例添加至伸缩组。 如果伸缩配置来源类型为从0开始创建,您需要创建一个伸缩配置或指定一个启动模板,然后再启用伸缩组。 如果伸缩配置来源类型为选择实例启动模板或选择已有实例,伸缩组创建完成后会自动启用。

1934890530796658 2020-03-23 09:44:17 0 浏览量 回答数 0

回答

重试作用: 对于重试是有场景限制的,不是什么场景都适合重试,比如参数校验不合法、写操作等(要考虑写是否幂等)都不适合重试。 远程调用超时、网络突然中断可以重试。在微服务治理框架中,通常都有自己的重试与超时配置,比如dubbo可以设置retries=1,timeout=500调用失败只重试1次,超过500ms调用仍未返回则调用失败。 比如外部 RPC 调用,或者数据入库等操作,如果一次操作失败,可以进行多次重试,提高调用成功的可能性。 优雅的重试机制要具备几点: 无侵入:这个好理解,不改动当前的业务逻辑,对于需要重试的地方,可以很简单的实现 可配置:包括重试次数,重试的间隔时间,是否使用异步方式等 通用性:最好是无改动(或者很小改动)的支持绝大部分的场景,拿过来直接可用 优雅重试共性和原理: 正常和重试优雅解耦,重试断言条件实例或逻辑异常实例是两者沟通的媒介。 约定重试间隔,差异性重试策略,设置重试超时时间,进一步保证重试有效性以及重试流程稳定性。 都使用了命令设计模式,通过委托重试对象完成相应的逻辑操作,同时内部封装实现重试逻辑。 Spring-tryer和guava-tryer工具都是线程安全的重试,能够支持并发业务场景的重试逻辑正确性。 优雅重试适用场景: 功能逻辑中存在不稳定依赖场景,需要使用重试获取预期结果或者尝试重新执行逻辑不立即结束。比如远程接口访问,数据加载访问,数据上传校验等等。 对于异常场景存在需要重试场景,同时希望把正常逻辑和重试逻辑解耦。 对于需要基于数据媒介交互,希望通过重试轮询检测执行逻辑场景也可以考虑重试方案。 优雅重试解决思路: 切面方式 这个思路比较清晰,在需要添加重试的方法上添加一个用于重试的自定义注解,然后在切面中实现重试的逻辑,主要的配置参数则根据注解中的选项来初始化 优点: 真正的无侵入 缺点: 某些方法无法被切面拦截的场景无法覆盖(如spring-aop无法切私有方法,final方法) 直接使用aspecj则有些小复杂;如果用spring-aop,则只能切被spring容器管理的bean 消息总线方式 这个也比较容易理解,在需要重试的方法中,发送一个消息,并将业务逻辑作为回调方法传入;由一个订阅了重试消息的consumer来执行重试的业务逻辑 优点: 重试机制不受任何限制,即在任何地方你都可以使用 利用EventBus框架,可以非常容易把框架搭起来 缺点: 业务侵入,需要在重试的业务处,主动发起一条重试消息 调试理解复杂(消息总线方式的最大优点和缺点,就是过于灵活了,你可能都不知道什么地方处理这个消息,特别是新的童鞋来维护这段代码时) 如果要获取返回结果,不太好处理, 上下文参数不好处理 模板方式 优点: 简单(依赖简单:引入一个类就可以了; 使用简单:实现抽象类,讲业务逻辑填充即可;) 灵活(这个是真正的灵活了,你想怎么干都可以,完全由你控制) 缺点: 强侵入 代码臃肿 把这个单独捞出来,主要是某些时候我就一两个地方要用到重试,简单的实现下就好了,也没有必用用到上面这么重的方式;而且我希望可以针对代码快进行重试 这个的设计还是非常简单的,基本上代码都可以直接贴出来,一目了然: 复制代码 public abstract class RetryTemplate { private static final int DEFAULT_RETRY_TIME = 1; private int retryTime = DEFAULT_RETRY_TIME; private int sleepTime = 0;// 重试的睡眠时间 public int getSleepTime() { return sleepTime; } public RetryTemplate setSleepTime(int sleepTime) { if(sleepTime < 0) { throw new IllegalArgumentException("sleepTime should equal or bigger than 0"); } this.sleepTime = sleepTime; return this; } public int getRetryTime() { return retryTime; } public RetryTemplate setRetryTime(int retryTime) { if (retryTime <= 0) { throw new IllegalArgumentException("retryTime should bigger than 0"); } this.retryTime = retryTime; return this; } /** * 重试的业务执行代码 * 失败时请抛出一个异常 * * todo 确定返回的封装类,根据返回结果的状态来判定是否需要重试 * * @return */ protected abstract Object doBiz() throws Exception; //预留一个doBiz方法由业务方来实现,在其中书写需要重试的业务代码,然后执行即可 public Object execute() throws InterruptedException { for (int i = 0; i < retryTime; i++) { try { return doBiz(); } catch (Exception e) { log.error("业务执行出现异常,e: {}", e); Thread.sleep(sleepTime); } } return null; } public Object submit(ExecutorService executorService) { if (executorService == null) { throw new IllegalArgumentException("please choose executorService!"); } return executorService.submit((Callable) () -> execute()); } } 复制代码 使用示例: 复制代码 public void retryDemo() throws InterruptedException { Object ans = new RetryTemplate() { @Override protected Object doBiz() throws Exception { int temp = (int) (Math.random() * 10); System.out.println(temp); if (temp > 3) { throw new Exception("generate value bigger then 3! need retry"); } return temp; } }.setRetryTime(10).setSleepTime(10).execute(); System.out.println(ans); } 复制代码 spring-retry Spring Retry 为 Spring 应用程序提供了声明性重试支持。 它用于Spring批处理、Spring集成、Apache Hadoop(等等)的Spring。 在分布式系统中,为了保证数据分布式事务的强一致性,在调用RPC接口或者发送MQ时,针对可能会出现网络抖动请求超时情况采取一下重试操作。 用的最多的重试方式就是MQ了,但是如果你的项目中没有引入MQ,就不方便了。 还有一种方式,是开发者自己编写重试机制,但是大多不够优雅。 缺陷 spring-retry 工具虽能优雅实现重试,但是存在两个不友好设计: 一个是重试实体限定为 Throwable 子类,说明重试针对的是可捕捉的功能异常为设计前提的,但是我们希望依赖某个数据对象实体作为重试实体, 但 sping-retry框架必须强制转换为Throwable子类。 另一个是重试根源的断言对象使用的是 doWithRetry 的 Exception 异常实例,不符合正常内部断言的返回设计。 Spring Retry 提倡以注解的方式对方法进行重试,重试逻辑是同步执行的,当抛出相关异常后执行重试, 如果你要以返回值的某个状态来判定是否需要重试,可能只能通过自己判断返回值然后显式抛出异常了。只读操作可以重试,幂等写操作可以重试,但是非幂等写操作不能重试,重试可能导致脏写,或产生重复数据。 @Recover 注解在使用时无法指定方法,如果一个类中多个重试方法,就会很麻烦。 spring-retry 结构 BackOff:补偿值,一般指失败后多久进行重试的延迟值。 Sleeper:暂停应用的工具,通常用来应用补偿值。 RetryState:重试状态,通常包含一个重试的键值。 RetryCallback:封装你需要重试的业务逻辑(上文中的doSth) RecoverCallback:封装了多次重试都失败后你需要执行的业务逻辑(上文中的doSthWhenStillFail) RetryContext:重试语境下的上下文,代表了能被重试动作使用的资源。可用于在多次Retry或者Retry 和Recover之间传递参数或状态(在多次doSth或者doSth与doSthWhenStillFail之间传递参数) RetryOperations: 定义了“重试”的模板(重试的API),要求传入RetryCallback,可选传入RecoveryCallback; RetryTemplate :RetryOperations的具体实现,组合了RetryListener[],BackOffPolicy,RetryPolicy。 RetryListener:用来监控Retry的执行情况,并生成统计信息。 RetryPolicy:重试的策略或条件,可以简单的进行多次重试,可以是指定超时时间进行重试(上文中的someCondition),决定失败能否重试。 BackOffPolicy: 重试的回退策略,在业务逻辑执行发生异常时。如果需要重试,我们可能需要等一段时间(可能服务器过于繁忙,如果一直不间隔重试可能拖垮服务器),当然这段时间可以是0,也可以是固定的,可以是随机的(参见tcp的拥塞控制算法中的回退策略)。回退策略在上文中体现为wait(); RetryPolicy提供了如下策略实现: NeverRetryPolicy:只允许调用RetryCallback一次,不允许重试; AlwaysRetryPolicy:允许无限重试,直到成功,此方式逻辑不当会导致死循环; SimpleRetryPolicy:固定次数重试策略,默认重试最大次数为3次,RetryTemplate默认使用的策略; TimeoutRetryPolicy:超时时间重试策略,默认超时时间为1秒,在指定的超时时间内允许重试; CircuitBreakerRetryPolicy:有熔断功能的重试策略,需设置3个参数openTimeout、resetTimeout和delegate delegate:是真正判断是否重试的策略,当重试失败时,则执行熔断策略;应该配置基于次数的SimpleRetryPolicy或者基于超时的TimeoutRetryPolicy策略,且策略都是全局模式,而非局部模式,所以要注意次数或超时的配置合理性。 openTimeout:openWindow,配置熔断器电路打开的超时时间,当超过openTimeout之后熔断器电路变成半打开状态(主要有一次重试成功,则闭合电路); resetTimeout:timeout,配置重置熔断器重新闭合的超时时间 CompositeRetryPolicy:组合重试策略,有两种组合方式,乐观组合重试策略是指只要有一个策略允许重试即可以,悲观组合重试策略是指只要有一个策略不允许重试即可以,但不管哪种组合方式,组合中的每一个策略都会执行。 BackOffPolicy 提供了如下策略实现: NoBackOffPolicy:无退避算法策略,即当重试时是立即重试; FixedBackOffPolicy:固定时间的退避策略,需设置参数sleeper(指定等待策略,默认是Thread.sleep,即线程休眠)、backOffPeriod(休眠时间,默认1秒); UniformRandomBackOffPolicy:随机时间退避策略,需设置sleeper、minBackOffPeriod、maxBackOffPeriod,该策略在[minBackOffPeriod,maxBackOffPeriod之间取一个随机休眠时间,minBackOffPeriod默认500毫秒,maxBackOffPeriod默认1500毫秒; ExponentialBackOffPolicy:指数退避策略,需设置参数sleeper、initialInterval、maxInterval和multiplier。initialInterval指定初始休眠时间,默认100毫秒,maxInterval指定最大休眠时间,默认30秒,multiplier指定乘数,即下一次休眠时间为当前休眠时间*multiplier; ExponentialRandomBackOffPolicy:随机指数退避策略,引入随机乘数,固定乘数可能会引起很多服务同时重试导致DDos,使用随机休眠时间来避免这种情况。 RetryTemplate主要流程实现: 复制代码 //示例一 public void upload(final Map<String, Object> map) throws Exception { // 构建重试模板实例 RetryTemplate retryTemplate = new RetryTemplate(); // 设置重试策略,主要设置重试次数 SimpleRetryPolicy policy =         new SimpleRetryPolicy(3, Collections.<Class<? extends Throwable>, Boolean> singletonMap(Exception.class, true)); // 设置重试回退操作策略,主要设置重试间隔时间 FixedBackOffPolicy fixedBackOffPolicy = new FixedBackOffPolicy(); fixedBackOffPolicy.setBackOffPeriod(100); retryTemplate.setRetryPolicy(policy); retryTemplate.setBackOffPolicy(fixedBackOffPolicy); // 通过RetryCallback 重试回调实例包装正常逻辑逻辑,第一次执行和重试执行执行的都是这段逻辑 final RetryCallback<Object, Exception> retryCallback = new RetryCallback<Object, Exception>() { //RetryContext 重试操作上下文约定,统一spring-try包装 public Object doWithRetry(RetryContext context) throws Exception { System.out.println("do some thing"); Exception e = uploadToOdps(map); System.out.println(context.getRetryCount()); throw e;//这个点特别注意,重试的根源通过Exception返回 } }; // 通过RecoveryCallback 重试流程正常结束或者达到重试上限后的退出恢复操作实例 final RecoveryCallback recoveryCallback = new RecoveryCallback() { public Object recover(RetryContext context) throws Exception { System.out.println("do recory operation"); return null; } }; try { // 由retryTemplate 执行execute方法开始逻辑执行 retryTemplate.execute(retryCallback, recoveryCallback); } catch (Exception e) { e.printStackTrace(); } } //示例二 protected <T, E extends Throwable> T doExecute(RetryCallback<T, E> retryCallback,RecoveryCallback recoveryCallback,   RetryState state) throws E, ExhaustedRetryException { //重试策略 RetryPolicy retryPolicy = this.retryPolicy; //退避策略 BackOffPolicy backOffPolicy = this.backOffPolicy; //重试上下文,当前重试次数等都记录在上下文中 RetryContext context = open(retryPolicy, state); try { //拦截器模式,执行RetryListener#open boolean running = doOpenInterceptors(retryCallback, context); //判断是否可以重试执行 while (canRetry(retryPolicy, context) && !context.isExhaustedOnly()) { try {//执行RetryCallback回调 return retryCallback.doWithRetry(context); } catch (Throwable e) {//异常时,要进行下一次重试准备 //遇到异常后,注册该异常的失败次数 registerThrowable(retryPolicy, state, context, e); //执行RetryListener#onError doOnErrorInterceptors(retryCallback, context, e); //如果可以重试,执行退避算法,比如休眠一小段时间后再重试 if (canRetry(retryPolicy, context) && !context.isExhaustedOnly()) { backOffPolicy.backOff(backOffContext); } //state != null && state.rollbackFor(context.getLastThrowable()) //在有状态重试时,如果是需要执行回滚操作的异常,则立即抛出异常 if (shouldRethrow(retryPolicy, context, state)) { throw RetryTemplate. wrapIfNecessary(e); } } //如果是有状态重试,且有GLOBAL_STATE属性,则立即跳出重试终止;       //当抛出的异常是非需要执行回滚操作的异常时,才会执行到此处,CircuitBreakerRetryPolicy会在此跳出循环; if (state != null && context.hasAttribute(GLOBAL_STATE)) { break; } } //重试失败后,如果有RecoveryCallback,则执行此回调,否则抛出异常 return handleRetryExhausted(recoveryCallback, context, state); } catch (Throwable e) { throw RetryTemplate. wrapIfNecessary(e); } finally { //清理环境 close(retryPolicy, context, state, lastException == null || exhausted); //执行RetryListener#close,比如统计重试信息 doCloseInterceptors(retryCallback, context, lastException); } } 复制代码 有状态or无状态 无状态重试,是在一个循环中执行完重试策略,即重试上下文保持在一个线程上下文中,在一次调用中进行完整的重试策略判断。如远程调用某个查询方法时是最常见的无状态重试: 复制代码 RetryTemplate template = new RetryTemplate(); //重试策略:次数重试策略 RetryPolicy retryPolicy = new SimpleRetryPolicy(3); template.setRetryPolicy(retryPolicy); //退避策略:指数退避策略 ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy(); backOffPolicy.setInitialInterval(100); backOffPolicy.setMaxInterval(3000); backOffPolicy.setMultiplier(2); backOffPolicy.setSleeper(new ThreadWaitSleeper()); template.setBackOffPolicy(backOffPolicy); //当重试失败后,抛出异常 String result = template.execute(new RetryCallback<String, RuntimeException>() { @Override public String doWithRetry(RetryContext context) throws RuntimeException { throw new RuntimeException("timeout"); } }); //当重试失败后,执行RecoveryCallback String result = template.execute(new RetryCallback<String, RuntimeException>() { @Override public String doWithRetry(RetryContext context) throws RuntimeException { System.out.println("retry count:" + context.getRetryCount()); throw new RuntimeException("timeout"); } }, new RecoveryCallback () { @Override public String recover(RetryContext context) throws Exception { return "default"; } }); 复制代码 有状态重试,有两种情况需要使用有状态重试,事务操作需要回滚、熔断器模式。 事务操作需要回滚场景时,当整个操作中抛出的是数据库异常DataAccessException,则不能进行重试需要回滚,而抛出其他异常则可以进行重试,可以通过RetryState实现: 复制代码 //当前状态的名称,当把状态放入缓存时,通过该key查询获取 Object key = "mykey"; //是否每次都重新生成上下文还是从缓存中查询,即全局模式(如熔断器策略时从缓存中查询) boolean isForceRefresh = true; //对DataAccessException进行回滚 BinaryExceptionClassifier rollbackClassifier = new BinaryExceptionClassifier(Collections.<Class<? extends Throwable>>singleton(DataAccessException.class)); RetryState state = new DefaultRetryState(key, isForceRefresh, rollbackClassifier); String result = template.execute(new RetryCallback<String, RuntimeException>() { @Override public String doWithRetry(RetryContext context) throws RuntimeException { System.out.println("retry count:" + context.getRetryCount()); throw new TypeMismatchDataAccessException(""); } }, new RecoveryCallback () { @Override public String recover(RetryContext context) throws Exception { return "default"; } }, state); 复制代码 RetryTemplate中在有状态重试时,回滚场景时直接抛出异常处理代码: //state != null && state.rollbackFor(context.getLastThrowable()) //在有状态重试时,如果是需要执行回滚操作的异常,则立即抛出异常 if (shouldRethrow(retryPolicy,context, state)) { throw RetryTemplate. wrapIfNecessary(e); } 熔断器场景。在有状态重试时,且是全局模式,不在当前循环中处理重试,而是全局重试模式(不是线程上下文),如熔断器策略时测试代码如下所示。 复制代码 RetryTemplate template = new RetryTemplate(); CircuitBreakerRetryPolicy retryPolicy = new CircuitBreakerRetryPolicy(new SimpleRetryPolicy(3)); retryPolicy.setOpenTimeout(5000); retryPolicy.setResetTimeout(20000); template.setRetryPolicy(retryPolicy); for (int i = 0; i < 10; i++) { try { Object key = "circuit"; boolean isForceRefresh = false; RetryState state = new DefaultRetryState(key, isForceRefresh); String result = template.execute(new RetryCallback<String, RuntimeException>() { @Override public String doWithRetry(RetryContext context) throws RuntimeException { System.out.println("retry count:" + context.getRetryCount()); throw new RuntimeException("timeout"); } }, new RecoveryCallback () { @Override public String recover(RetryContext context) throws Exception { return "default"; } }, state); System.out.println(result); } catch (Exception e) { System.out.println(e); } } 复制代码 为什么说是全局模式呢?我们配置了isForceRefresh为false,则在获取上下文时是根据key “circuit”从缓存中获取,从而拿到同一个上下文。 Object key = "circuit"; boolean isForceRefresh = false; RetryState state = new DefaultRetryState(key,isForceRefresh); 如下RetryTemplate代码说明在有状态模式下,不会在循环中进行重试。 if (state != null && context.hasAttribute(GLOBAL_STATE)) { break; } 判断熔断器电路是否打开的代码: 复制代码 public boolean isOpen() { long time = System.currentTimeMillis() - this.start; boolean retryable = this.policy.canRetry(this.context); if (!retryable) {//重试失败 //在重置熔断器超时后,熔断器器电路闭合,重置上下文 if (time > this.timeout) { this.context = createDelegateContext(policy, getParent()); this.start = System.currentTimeMillis(); retryable = this.policy.canRetry(this.context); } else if (time < this.openWindow) { //当在熔断器打开状态时,熔断器电路打开,立即熔断 if ((Boolean) getAttribute(CIRCUIT_OPEN) == false) { setAttribute(CIRCUIT_OPEN, true); } this.start = System.currentTimeMillis(); return true; } } else {//重试成功 //在熔断器电路半打开状态时,断路器电路闭合,重置上下文 if (time > this.openWindow) { this.start = System.currentTimeMillis(); this.context = createDelegateContext(policy, getParent()); } } setAttribute(CIRCUIT_OPEN, !retryable); return !retryable; } 复制代码 从如上代码可看出spring-retry的熔断策略相对简单: 当重试失败,且在熔断器打开时间窗口[0,openWindow) 内,立即熔断; 当重试失败,且在指定超时时间后(>timeout),熔断器电路重新闭合; 在熔断器半打开状态[openWindow, timeout] 时,只要重试成功则重置上下文,断路器闭合。 注解介绍 @EnableRetry 表示是否开始重试。 序号 属性 类型 默认值 说明 1 proxyTargetClass boolean false 指示是否要创建基于子类的(CGLIB)代理,而不是创建标准的基于Java接口的代理。当proxyTargetClass属性为true时,使用CGLIB代理。默认使用标准JAVA注解 @Retryable 标注此注解的方法在发生异常时会进行重试 序号 属性 类型 默认值 说明 1 interceptor String ”” 将 interceptor 的 bean 名称应用到 retryable() 2 value class[] {} 可重试的异常类型 3 include class[] {} 和value一样,默认空,当exclude也为空时,所有异常都重试 4 exclude class[] {} 指定异常不重试,默认空,当include也为空时,所有异常都重试 5 label String ”” 统计报告的唯一标签。如果没有提供,调用者可以选择忽略它,或者提供默认值。 6 maxAttempts int 3 尝试的最大次数(包括第一次失败),默认为3次。 7 backoff @Backoff @Backoff() 重试补偿机制,指定用于重试此操作的backoff属性。默认为空 @Backoff 不设置参数时,默认使用FixedBackOffPolicy(指定等待时间),重试等待1000ms 序号 属性 类型 默认值 说明 1 delay long 0 指定延迟后重试 ,如果不设置则默认使用 1000 milliseconds 2 maxDelay long 0 最大重试等待时间 3 multiplier long 0 指定延迟的倍数,比如delay=5000l,multiplier=2时,第一次重试为5秒后,第二次为10秒,第三次为20秒(大于0生效) 4 random boolean false 随机重试等待时间 @Recover 用于恢复处理程序的方法调用的注释。返回类型必须与@retryable方法匹配。 可抛出的第一个参数是可选的(但是没有它的方法只会被调用)。 从失败方法的参数列表按顺序填充后续的参数。 用于@Retryable重试失败后处理方法,此注解注释的方法参数一定要是@Retryable抛出的异常,否则无法识别,可以在该方法中进行日志处理。 说明: 使用了@Retryable的方法不能在本类被调用,不然重试机制不会生效。也就是要标记为@Service,然后在其它类使用@Autowired注入或者@Bean去实例才能生效。 要触发@Recover方法,那么在@Retryable方法上不能有返回值,只能是void才能生效。 使用了@Retryable的方法里面不能使用try...catch包裹,要在发放上抛出异常,不然不会触发。 在重试期间这个方法是同步的,如果使用类似Spring Cloud这种框架的熔断机制时,可以结合重试机制来重试后返回结果。 Spring Retry不只能注入方式去实现,还可以通过API的方式实现,类似熔断处理的机制就基于API方式实现会比较宽松。 转载于:https://www.cnblogs.com/whatarewords/p/10656514.html

养狐狸的猫 2019-12-02 02:11:54 0 浏览量 回答数 0

问题

Windows Server 2008云主机安全配置基础教程

ap2836i0b 2019-12-01 20:21:48 20372 浏览量 回答数 9

问题

分布式事务了解吗?你们是如何解决分布式事务问题的?【Java问答学堂】58期

剑曼红尘 2020-07-16 15:11:28 5 浏览量 回答数 1

问题

dubbo 的工作原理?注册中心挂了的问题?说说一次 rpc 请求的流程?【Java问答】47期

剑曼红尘 2020-06-30 09:02:47 8 浏览量 回答数 1

问题

为什么要分库分表(设计高并发系统的时候,数据库层面该如何设计)?【Java问答】41期

剑曼红尘 2020-06-19 13:47:21 0 浏览量 回答数 0

问题

大数据 比你更懂自己

柚子 2019-12-01 21:40:32 5650 浏览量 回答数 0

问题

为什么要进行系统拆分?如何进行系统拆分?拆分后不用 dubbo 可以吗?【Java问答学堂】46期

剑曼红尘 2020-06-29 16:39:00 6 浏览量 回答数 1

问题

Redis 集群模式的工作原理能说一下么?【Java问答】36期

剑曼红尘 2020-06-12 15:07:18 2 浏览量 回答数 1

回答

<p>你得贴出报错信息,  光这么问, 没法troubleshooting</p> <p>组策略,系统设置,ip网段,workgroup,都检查下,不行就重启,手动滑稽</p> <p>不把错误提示贴出来,如何叫人发表解决意见?</p> <p>windows 服务器运维<span>,一般的话可以用宝塔windows版本或者云帮手,云帮手是兼容windows/linux系统,所以也不会有什么限制,就算你以后有别linux服务器,也可以一起使用,不用再重复下载linux系统可以用的面板。其他的比如面板功能之类的,我觉得你可以自己下载试试,基础类的功能网上都差不多,主要还是看自己的操作使用体验,</span><br> <span>最后分享官网下载地址(</span><a>云帮手</a><span>),希望能帮助到您!</span></p> <p><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span>学会利用工具,是一个优秀的运维要做的事情。</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></p> 我个人会比较喜欢云帮手,全面兼容所有云服务商,同时兼容Windows、CentOS、Ubuntu、Debian、OpenSUSE、Fedora等云服务器操作系统,对服务器、主机、站点的数量没有限制,哪怕我加了近百台服务器,依旧运行得很流畅。 而且像服务器的监控、安全巡检这种维护的功能也比较完善,有一键巡检和修复的功能,对于服务器平时的小问题,这个功能省去了我极大的功夫。 如果你有兴趣的话,也可以去尝试下载试试:云帮手官网地址 真的对运维的工作很有帮助!

爱吃鱼的程序员 2020-06-06 15:15:09 0 浏览量 回答数 0

回答

回楼主北京亿网的帖子 感谢你的关注,以后有什么问题可以咨询我们北京亿网,由于给客户上了一台阿里云产品,深深体会到了客户的不容易,我们亲自沟通都不行,最后还是自己查出原因,投诉什么的是没用的,你自己生气还不如自己想办法,指不上,第三方公司一等一小天,并且真的问题他们也是处理不了,只有普通客户的问题才能解决估计,比如这次,一分钟就明白的事,万网和第三方弄四天,我们客户急了都,没办法我们通地不断检查测试,查清原因了. ------------------------- Re使用阿里云ECS无法安装SQL2005系统的问题 引用楼主北京亿网于2014-12-06 08:15发表的 使用阿里云ECS无法安装SQL2005系统的问题 : 问题描述 : 在安装mssql2005时,安装CD1顺利完成,在安装CD2时无法进行,双击安装文件后自动关闭,无提示!怎么解决? 看的日志提示是: 事件 ID ( 11260 )的描述(在资源( MsiInstaller )中)无法找到。本地计算机可能没有必要的注册信息或消息 DLL 文件来从远程计算机显示消息。您可能可以使用 /AUXSOURCE= 标识来检索词描述;查看帮助和支持以了解详细信息。下列信息是事件的一部分: 产品: Microsoft SQL Server 安装程序支持文件(英语) -- 错误 1260。由于一个软件限制策略的阻止,Windows 无法打开此程序。要获取更多信息,请打开事件查看器或与系统管理员联系。 ....... [url=http://bbs.aliyun.com/job.php?action=topost&tid=187191&pid=tpc][/url] 服务态度还行,就是服务方式不好,回复你的售后基本可以讲不算是一名技术人员,他不这样说也没什么可说的了,不过有一点说的没错,你这边不急不投诉他真不给你重视起来呢,你说怪不怪! ------------------------- Re使用阿里云ECS无法安装SQL2005系统的问题 问题已经自行查明原因,阿里提供镜象问题,暂时还无法加其他版本镜象,只能更换系统. ------------------------- 回6楼云追溯的帖子 好久没来阿里云论坛了,今天打开一看自己的贴子又跑首页了,你们就别指着给你解决什么,就一个弄清问题叫他们承认都要用我一个来月的时间,最后的结果是清楚原因,但不能给解决,只能逼着你换系统,所以别指望了,如果实在用不了,还是用我们的产品吧,还有代维服务,我们给客户代购的阿里云产品叫我们技术部操了不少心,要是我们的产品直接帮解决了,我这只能帮查出问题,叫人家解决,但后台没几个技术是专业的,全是叫第三方给查看,就算指出原因,也不会给解决,估计是反应不上去,没人重视,只要广告打的响,你们这些用不了的还不如新来的人多,不可能重视,大公司没办法! ------------------------- 回7楼ftp4oss的帖子 你的企业版2005数据库是装在阿里云2003系统上的吗,要是装2008系统上的这种另类反搭配就别在这讲了,那不如直接装SQL2008了.这个贴子的前题时指2003系统通常搭配的2005数据库无法安装的问题.原因是阿里云没有提供专业的服务器版系统静象,这种不专业的系统来当服务器系统,也只能装个人用的精简的数据库2005,企业的装不了. ------------------------- 回8楼拔刀斋的帖子 阿里云的技术支持仅限安装系统这部分,然后有什么问题安装什么他们也没个专业的技术来判断,只会告诉你支持,或是没限制,事实不是这样,因为他们提供的系统本身就有局限,等你问个半个月了也搞不了,他们换几个技术也搞不了时,会推荐你叫第三方服务,基本上所谓的第三方也没有几个专业的,提问一次两三天有个结果吧,建议没有技术力量的客户不要在折磨自己了,因为你搞什么想弄个对错都没有人帮你去判断!如果一定用阿里云可以联系我们代购,至少我们负责代维,不是他们后台不专业的技术说什么是什么,就是不给解决他也得承认我们查出的问题,到时你想退款也有依据.如果就是租了一个月也别退了,就当交学费了,直接在我们这买产品,我们可以代购阿里云,也有自己的产品,包维护,支持环境应用技术支持. ------------------------- 回9楼中国舞曲网的帖子 SQL2000这个版本有点低了,几年前我们就不装这种环境了,没有试,是不是阿里系统静象问题也不好说,如果还是那个静象那就是有问题,虽然此前有一个用户和我说同样的静象版本在另一个区购买的高配置就可以安装,这个我没亲自看,所以也不确定他说的是不是真实的,总之吧,服务器系统应用服务器版系统才是专业的,用什么标准,,精简,就是能装上以后也会有各种各样的问题,不专业的表现,配套能装上的也全是一些精简的个人研究之用的数据库版本,所以从专业角度就是系统问题,从相对论上来说,装个个人研究之用的数据库2005我也可以给客户装上,但那是精简的,你懂的! ------------------------- Re使用阿里云ECS无法安装SQL2005系统的问题 好久没来了,今天来看发现自己的贴子又叫顶到首页了,看来好有后来人在受困扰,那就全回复一下吧,另外有一些看了广告就来买阿里云又不会用的,又不会装环境的亲们,来北京亿网寻求帮助吧,提供代维服务. ------------------------- 回7楼ftp4oss的帖子 你要不是提供个截图我还真以为你装了个企业版,我贴子中似乎有讲过在我们遇到这个问题后,也有万网多名技术员测试安装无法成功,并且万网委托的第三方技术公司也未能安装成功,最后认同了我们的结论,他这个静象就不能装企业版2005,用一些方法装上后在以后使用和更新时会更多的麻烦,所以放下研究真的使用这样免强装上是不行的,但你这里还截了图,还安静的讲装上了还用了一年多,,为了不叫看我贴的其他用户叫你误导,本楼主在此有必要回复一下,你讲的可能是一个事实,但你截图的这个版本并不是企业版SQl2005,从你截图显示的版本号1399来看,似乎是开发版,并不是真正的企业版,所以和我讲的阿里云目前的提供的2003系统并不能完美安装SQL2005企业版不是同一个问题.看签名你还是级别: 工具与镜像服务商 ?那就向万网要求提供下服务器版2003静象吧,这样专业一些,能适合不同版SQL2005,就不会有这么多客户的各种问题了,我没有时间在建议这些. ------------------------- 回17楼数据佰度的帖子 17楼看来是真的去安装测试了,看得出 是比较认真的一个人,你的测试是正确的,万网电话客服人员普遍技术水平是零,包括后台技术的回复也是相当不负责,这一点我早早有提出过,但建议是建议,人家还是那样,从你讲的看来他们还是在和客户不停的讲这句,系统工程纯净的,全可以装,看来这个含糊不负责的回答现在想想不是他们不清楚这样回答不负责,这样回签对销量有意义,一些客户就是因为这句回答就买了,买完装不了就郁闷去吧.另外你楼上16楼他没你认真,他装的根本也不是企业版,所以他的测试没意义,你的结论是正确的. ------------------------- 回19楼围观群众1的帖子 只为了装上通过查看系统日志提示,通过结束进程,移队插件,直接用静象文件修复安装等多种方式都能完成安装过程,但这种安装并不是真的成功,特别是配套其他软件使用时,以后在更新升级时问题多多,这些最开始我们公司全有测试过,所以最后才有以上结论,阿里云这个2003系统并不是他们讲的那样可以装企业版2005,如果他们不能提供服务器版2003系统,大家就不要在浪费时间了. ------------------------- 回26楼围观群众1的帖子 这个贴子这么久还有人围观,首先感谢大家的关注和支持! 26楼看得出也是一个热爱技术和喜欢发现问题,研究问题,解决问的人,这很好! 但关于微软的系统版本和数据库版本对应问题,官方版本的划分已经是一个答案了,如果全通用还划分版本做什么,这本不是一个值得讨论的事情,此问题其根本是源于我的客户在咨询阿里售后时得到的精典答复是:系统是纯净的,全可以装"有关这个说法建议可以直接咨询微软方面,本人不过多说明,只是对热爱技术的网友回下贴,感谢关注. 你这种测试是有主观倾向的,什么也证明不了,服务器技术管理人员哪有不打补丁的呢,如果要把补丁移除才能装那本身就是个问题,为了解决一个问题而把一年的补丁移除来说明是补丁问题这相当的不可取,很危险的维护方式.补丁也是系统的一部分,并且不出意外你这种方式 装上了,在以后打补丁还会出问题,到时你来此贴报个道吧,如果只是为了能装上,方法很多,我的贴子中也有提到,但用户他租这个是用来使用的,不是一时研究之用,所以只有根本的解决方法才是真的解决,踏实的按微软的版本对应要求配置安装才是正道,其他全是取巧,如果就是暂时解决,以后服务器也是要升级补下的,如果微软某个补丁就是适于对应版本才可以时,那时才要换成对应版本吗,更何况叫服务商增加服务器版系统对客户是好事,对服务商来说也是更专业,难道租这个不是来当服务器吗 ------------------------- 回29楼兔子王的帖子 感谢围观,你这种租台机器挂QQ用的,是不需要装数据库的,所以你放不放心都没意义,更不会懂技术间讨论的那种乐趣,如果你的水平都可以来判断专业与否了,那会上网打字全是高级技术员了,如果你的乐趣就是用言语挑事,打个嗝都要说所处地气候环境不适合你生长,很不巧我向来以言语犀利 为自我评价。要不你开个贴我可以和你一样不知天高地厚的用敲字来PK下双方的神经反应系统灵敏度。所以不要在我的贴子上面发广告,还留个QQ,还网络公司,先不说你在我贴子下留广告这是一种不尊重,其次你那所谓的解决方式不是误人子弟吗,自己坑了不要急,不能坑了客户,给别人留后患.还某人某人的,如果没有建设性的技术方案要和大这交流的就收起你的广告和管好你地张嘴. ------------------------- 回 17楼(数据佰度) 的帖子 这个人厚道,至少他清楚我发这个贴子在说什么和我的用意,这是广大用户对阿里方面要求提升服务的一种鞭策,阿里方面至少和我直接沟通的人员也很认可我讲的这一点,至少态度是友好的,并且我发这个贴子时离2003官方不在支持还有半年,有一天我们也要给客户最好的支持,这才是服务,现在我们自己都不用2003了,因为官方不支持了,这个是一个硬性依据! ------------------------- 回 29楼(兔子王) 的帖子 对,这种人你得捧,给他勇气,叫他一直傻下去,一个版本对应问题官方都有说明的事,还搞的这么复杂,没人说镜象问题,我一直在说版本,要提供服务器版本,对大众客户来说,用标准版装去装企业版数据库就会碰到这样的问题,他们不是技术人员,你叫他们每个人和你一样去这样弄几天才成就了你的自尊心是吗,你那叫解决了是吗,过了半年你现在还这样想,那你真没救了,你看你已经把这位误导了。自己偶尔的一个测试原因尚不明确就拿 出来当论据了,很不负责任做为一个技术人员! ------------------------- 北京亿网感谢大家的关注,这个贴子很久了,今天上来结下贴的,欢迎大家交流,但希望发表技术类方面的言论时不要给其他人造成误导,否则我讲话可是很直接的叫你不舒服的,为了证明我不是恶意针对某人,在这里结贴时也给感谢一下阿里方面的回复,我今天 才上来看到,这对于个别人来讲,可能看了会感觉打脸,阿里人家不需要你的跪添,所以在讨论技术问题时至少不要在我面前硬装人,看下吧,那位硬说版本没半毛钱关系的那位,顺便说句这个贴子就结了,以后大家关注北京亿网新贴子,我们已经为用户提阿里美国,香港,国内的阿里云空间产品,新加坡的也要上线了,谢谢大家来使用,联系我们吧! 下面是阿里云工程师对我们这个提问的回复,结贴了,大家以后不要在讨论了。 售后工程师 :  您好,从如下微软官方SQL Server安装说明来看,Windows Server 2003标准版确实不支持安装SQL Server 2005企业版。http://technet.microsoft.com/zh-cn/library/ms143506(v=sql.90).aspx 当前查看您已经将服务器系统更换为2008。对于该问题给您带来的不便很抱歉。感谢您的问题反馈和对阿里云的信赖。  2014-12-29 18:35:29 ------------------------- 回 42楼(bjyw用户) 的帖子 用户您好,请别激动,也不要生气了!首先要感谢你告诉我们的账号叫封停了,你不告诉我们都不知道!刚已经联系阿里解封了,那个版主我就不点名了,他自己发的帖子植入广告别人又不是看不出来,估计当这个版主就是为了自己发广告方便才申请的吧,但你自己方便也就算了,怎么还乱用权限了呢, 有点自知之明好不好,我们下边的客户草根站长多的事,全应可以来申请版主,哪轮得到你删贴和禁言的,有事你说事啊,直接封公司的账号你脑子是不是缺点什么? 还有我这个帖子早就结贴了,那个小号上来骂骂咧咧的,某版主没见你一起封啊,用我们用户的话讲你是不是瞎?还有那个小号你也不要在这骂,我也理解你一万年解决了一个问题出来显摆下的心情,这类问题在技术部天天都有的事,我们都表示没什么可说的了,我都结贴了你怎么还没脸没皮的上来发上面的话?阿里工程师都回复,我都贴 出来了,告诉大家不要在讨论了,你看你把我们用户气的!在贴下你看看吧,无知喷人不要紧,但你也看明白人家讲什么你在喷啊,我在这里给大家讨福利的事,你在那折什么台呢,我们客户举的例子你要是看不懂,我给你举个吧:话说一个通道,客户人家就要正常的直接走过去,因为一直这样走,可你一定要来个左三步,右三步,退一步,进两步,搞的和过关一样,最后也能过去,或者叫用户记得这个口决每次也可以过去,你认为这个就不需要解决了是吧?问题是客户为什么要记这些,会这些呢,人家的软件又无问题,人家客户又不想聘个技术人员,如果说一次免费两次免费我们可以帮,但经常的重装我们没事就给处理这个问题吗?为什么不能一劳永逸?明白我发贴的意思了吗?还不理解我也没办法,我承认我嘴比较黑,但对客户这块不含糊,但你看客户有骂我的吗? 下面是阿里云工程师对我们这个提问的回复,结贴了,大家以后不要在讨论了。 售后工程师 :  您好,从如下微软官方SQL Server安装说明来看,Windows Server 2003标准版确实不支持安装SQL Server 2005企业版。 http://technet.microsoft.com/zh-cn/library/ms143506(v=sql.90).aspx 当前查看您已经将服务器系统更换为2008。对于该问题给您带来的不便很抱歉。 感谢您的问题反馈和对阿里云的信赖。  2014-12-29 18:35:29 看到了吧?看清了吗?可能有人会问,你知道这个原因为什么要发求助贴呢,为什么还讨论这么久呢?能这样问的只能说你没认真看我发的相关贴子,我在最开始联系阿里方面时就告诉是这个原因,要提供一个服务器版镜象就没问题了,但阿里后台客服坚持那句话“我们的系统没有问题,可以直接装你的那个企业版2005”并且客户自己也打电话问了,也是那样回答的!所以我们只能把处理记录和进程贴出来,叫客户也看到,最后客户也完全理解我们和阿里方面了不是吗?如果说我们是为了显摆什么技术,那这类问题每天给阿里发来10个贴子, 我们还得聘一个阿里论坛编辑了,所以这个贴子完全是因为用户要看,我们才发的!如果我们经常来,也不会叫某傻X版主封号都不知道了!

北京亿网 2019-12-02 01:11:23 0 浏览量 回答数 0

问题

简单浅析下如何巧用OSS、RDS缓解磁盘IO瓶颈

enj0y 2019-12-01 20:22:01 18461 浏览量 回答数 13

问题

简单浅析下如何巧用OSS、RDS缓解磁盘IO瓶颈

enj0y 2019-12-01 21:09:47 15549 浏览量 回答数 15

问题

18108830011Win10更新失败了wwwdv66668com怎么办

dv66668com 2019-12-01 21:55:35 2349 浏览量 回答数 0

问题

会话保持常见问题

行者武松 2019-12-01 21:43:17 3972 浏览量 回答数 0

问题

ES 的分布式架构原理能说一下么(ES 是如何实现分布式的啊)?【Java问答学堂】26期

剑曼红尘 2020-05-26 20:30:13 41 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站