首页 文章 精选 留言 我的

精选列表

搜索[学习],共10000篇文章
优秀的个人博客,低调大师

(二十七) 跟我学习SpringCloud-使用Hystrix实现容错处理

创建一个新的Maven项目 hystrix-feign-demo,增加 Hystrix 的依赖,代码如下所示。 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> 在启动类上添加 @EnableHystrix 或者 @EnableCircuitBreaker。注意,@EnableHystrix 中包含了 @EnableCircuitBreaker。 然后编写一个调用接口的方法,在上面增加一个 @HystrixCommand 注解,用于指定依赖服务调用延迟或失败时调用的方法,代码如下所示。 @GetMapping("/callHello") @HystrixCommand(fallbackMethod = "defaultCallHello") public String callHello() { String result = restTemplate.getForObject("http://localhost:8088/house/hello", String.class); return result; } 当调用失败触发熔断时会用 defaultCallHello 方法来回退具体的内容,定义 default-CallHello 方法的代码如下所示。 public String defaultCallHello() { return "fail"; } 只要不启动 8088 端口所在的服务,调用 /callHello 接口,就可以看到返回的内容是“fail”,如图 1 所示。 将启动类上的 @EnableHystrix 去掉,重启服务,再次调用 /callHello 接口可以看到返回的是 500 错误信息,这个时候就没有用到回退功能了。 { code: 500, message: "I/O error on GET request for "http://localhost:8088/house/hello": Connection refused; nested exception is java.net.ConnectException: Connection refused ", data: null } 配置详解 HystrixCommand 中除了 fallbackMethod 还有很多的配置,下面我们来看看这些配置,如下表所示: HystrixCommand 配置详解 名称 说明 hystrix.command.default.execution.isolation .strategy 该配置用来指定隔离策略,具体策略有下面 2 种。 THREAD:线程隔离,在单独的线程上执行,并发请求受线程池大小的控制。 SEMAPHORE:信号量隔离,在调用线程上执行,并发请求受信号量计数器的限制。 hystrix.command.default.execution.isolation .thread.timeoutInMilliseconds 该配置用于 HystrixCommand 执行的超时时间设置,当 HystrixCommand 执行的时间超过了该配置所设置的数值后就会进入服务降级处理,单位是毫秒,默认值为 1000。 hystrix.command.default.execution .timeout.enabled 该配置用于确定是否启用 execution.isolation.thread.timeoutInMilliseconds 设置的超时时间,默认值为 true。设置为 false 后 execution.isolation.thread.timeoutInMilliseconds 配置也将失效。 hystrix.command.default.execution.isolation .thread.interruptOnTimeout 该配置用于确定 HystrixCommand 执行超时后是否需要中断它,默认值为 true。 hystrix.command.default.execution.isolation .thread.interruptOnCancel 该配置用于确定 HystrixCommand 执行被取消时是否需要中断它,默认值为 false。 hystrix.command.default.execution.isolation .semaphore.maxConcurrentRequests 该配置用于确定 Hystrix 使用信号量策略时最大的并发请求数。 hystrix.command.default.fallback.isolation .semaphore.maxConcurrentRequests 该配置用于如果并发数达到该设置值,请求会被拒绝和抛出异常并且 fallback 不会被调用,默认值为 10。 hystrix.command.default.fallback.enabled 该配置用于确定当执行失败或者请求被拒绝时,是否会尝试调用 hystrixCommand.getFallback(),默认值为 true。 hystrix.command.default.circuitBreaker.enabled 该配置用来跟踪 circuit 的健康性,如果未达标则让 request 短路,默认值为 true。 hystrix.command.default.circuitBreaker .requestVolumeThreshold 该配置用于设置一个 rolling window 内最小的请求数。如果设为 20,那么当一个 rolling window 的时间内(比如说 1 个 rolling window 是 10 秒)收到 19 个请求,即使 19 个请求都失败,也不会触发 circuit break,默认值为 20。 hystrix.command.default.circuitBreaker .sleepWindowInMilliseconds 该配置用于设置一个触发短路的时间值,当该值设为 5000 时,则当触发 circuit break 后的 5000 毫秒内都会拒绝 request,也就是 5000 毫秒后才会关闭 circuit。默认值为 5000。 hystrix.command.default.circuitBreaker .errorThresholdPercentage 该配置用于设置错误率阈值,当错误率超过此值时,所有请求都会触发 fallback,默认值为 50。 hystrix.command.default.circuitBreaker.forceOpen 如果配置为 true,将强制打开熔断器,在这个状态下将拒绝所有请求,默认值为 false。 hystrix.command.default.circuitBreaker.forceClosed 如果配置为 true,则将强制关闭熔断器,在这个状态下,不管错误率有多高,都允许请求,默认值为 false。 hystrix.command.default.metrics .rollingStats.timeInMilliseconds 设置统计的时间窗口值,单位为毫秒。circuit break 的打开会根据 1 个 rolling window 的统计来计算。若 rolling window 被设为 10 000 毫秒,则 rolling window 会被分成多个 buckets,每个 bucket 包含 success、failure、timeout、rejection 的次数的统计信息。默认值为 10 000 毫秒。 hystrix.command.default.metrics .rollingStats.numBuckets 设置一个 rolling window 被划分的数量,若 numBuckets=10、rolling window=10 000,那么一个 bucket 的时间即 1 秒。必须符合 rolling window%numberBuckets==0。默认值为 10。 hystrix.command.default.metrics .rollingPercentile.enabled 是否开启指标的计算和跟踪,默认值为 true。 hystrix.command.default.metrics .rollingPercentile.timeInMilliseconds 设置 rolling percentile window 的时间,默认值为 60 000 毫秒 hystrix.command.default.metrics .rollingPercentile.numBuckets 设置 rolling percentile window 的 numberBuckets,默认值为 6。 hystrix.command.default.metrics .rollingPercentile.bucketSize 如果 bucket size=100、window=10 秒,若这 10 秒里有 500 次执行,只有最后 100 次执行会被统计到 bucket 里去。增加该值会增加内存开销及排序的开销。默认值为 100。 hystrix.command.default.metrics .healthSnapshot.intervalInMilliseconds 用来计算影响断路器状态的健康快照的间隔等待时间,默认值为 500 毫秒。 hystrix.command.default.requestCache.enabled 是否开启请求缓存功能,默认值为 true。 hystrix.command.default.requestLog.enabled 记录日志到 HystrixRequestLog,默认值为 true。 hystrix.collapser.default.maxRequestsInBatch 单次批处理的最大请求数,达到该数量触发批处理,默认为 Integer.MAX_VALUE。 hystrix.collapser.default.timerDelayInMilliseconds 触发批处理的延迟,延迟也可以为创建批处理的时间与该值的和,默认值为 10 毫秒。 hystrix.collapser.default.requestCache.enabled 是否启用对 HystrixCollapser.execute() 和 HystrixCollapser.queue() 的请求缓存,默认值为 true。 hystrix.threadpool.default.coreSize 并发执行的最大线程数,默认值为 10。 hystrix.threadpool.default.maxQueueSize BlockingQueue 的最大队列数。当设为 -1 时,会使用 SynchronousQueue;值为正数时,会使用 LinkedBlcokingQueue。该设置只会在初始化时有效,之后不能修改 threadpool 的 queue size。默认值为 -1。 hystrix.threadpool.default.queueSizeRejectionThreshold 即使没有达到 maxQueueSize,但若达到 queueSizeRejectionThreshold 该值后,请求也会被拒绝。因为 maxQueueSize 不能被动态修改,而 queueSizeRejectionThreshold 参数将允许我们动态设置该值。if maxQueueSize==-1,该字段将不起作用。 hystrix.threadpool.default.keepAliveTimeMinutes 设置存活时间,单位为分钟。如果 coreSize 小于 maximumSize,那么该属性控制一个线程从实用完成到被释放的时间。默认值为 1 分钟。 hystrix.threadpool.default .allowMaximumSizeToDivergeFromCoreSize 该属性允许 maximumSize 的配置生效。那么该值可以等于或高于 coreSize。设置 coreSize 小于 maximumSize 会创建一个线程池,该线程池可以支持 maximumSize 并发,但在相对不活动期间将向系统返回线程。默认值为 false。 hystrix.threadpool.default.metrics .rollingStats.timeInMilliseconds 设置滚动时间窗的时间,单位为毫秒,默认值是 10 000。 hystrix.threadpool.default.metrics .rollingStats.numBuckets 设置滚动时间窗划分桶的数量,默认值为 10。 官方的配置信息文档请参考:https://github.com/Netflix/Hystrix/wiki/Configuration。 上面列出来的都是 Hystrix 的配置信息,那么在Spring Cloud中该如何使用呢?只需要在接口的方法上面使用 HystrixCommand 注解(如下代码所示),指定对应的属性即可。 @HystrixCommand(fallbackMethod = "defaultCallHello",commandProperties = { @HystrixProperty(name="execution.isolation.strategy", value = "THREAD") } ) @GetMapping("/callHello") public String callHello() { String result = restTemplate.getForObject("http://localhost:8088/house/hello", String.class); return result; } 给大家推荐分布式架构源码

优秀的个人博客,低调大师

从头开始学习->java数据结构(一):物理上的存储结构

前言 我们都知道,所谓的数据结构,都是我们在为了更好的对数据的增删改查而创造出来的对数据的结构设计,但是我们要知道的是,这些数据结构都是抽象的逻辑结构,并不是真实的物理上的存储结构,大部分时候,我们对数据结构的讨论,也都是讨论的是逻辑上的数据结构,并不是对真实的存储在硬盘中的数据的存储结构的讨论。 真实的物理上的数据,存储到我们的硬盘上的或者是在内存上的时候,都是有着确切的存储结构的,而不是我们想象中的类似b树,二叉树这种抽象的逻辑结构。 那么,在我们的硬盘上,数据是如何存储的呢?这个问题,是我们去研究逻辑上的数据结构之前,需要搞清楚的问题,也是我们本篇文章的主题。 正文 物理存储结构,是数据的逻辑结构在计算机中的存储形式。 但是在理解物理上的数据存储结构之前,我们要先对硬盘有一个足够的了解。 硬盘是一个实际存在的物品,那么也就是说,这个硬盘不可能如我们想象出的逻辑设计那样,去存储我们的数据。想象一下,如果存一百万条数据,我们在硬盘中随意存储,不按照客观的物理规则来存储,那么我们会发现,硬盘的空间会被很大的浪费掉。 也因此,在硬盘中存储数据的时候,我们必须按照一定的客观规律来。而这种客观规律,在计算机发展的过程中,逐渐形成了现在比较常见的两种规律。 1.顺序存储结构 顺序存储结构,是将我们逻辑上的数据结构中相邻的数据,在物理位置上,也存储在相邻的位置。数据结构中的节点关系由存储单元的邻接关系来体现。 也就是说,数据间的逻辑关系和物理关系是一致的。 一般来说,在我们java语言中,描述这种物理存储结构的话,都是借助我们的 数组 来阐述的。如图所示: 这种存储结构,还是很好理解的,说白了,就是排队而已,每一条数据都是占一小段空间,按照顺序站好,占据着连续的存储空间。 1.1 优点 顺序存储结构的优点还是比较明显的,由于是按照物理上的存储空间的顺序存储数据,那么对存储空间的利用率就会非常高,存储密度比较大。 而且因为是顺序存储数据,那么也就是说,我们的数据,存储在这里的时候,天然在硬盘中的平均寻道时间中,就会快很多。 那么,什么是寻道时间呢? 先看一张关于磁盘的图片,如下: 我们发现,这种传统的硬盘,数据是存储到磁盘中的磁道(磁盘盘片)中,通过磁头(读写磁头)来查找数据。而平均寻道时间就是指磁头移动到数据所在的磁道所使用的时间的平均值。 如果硬盘的寻道速度变快,那么就意味着我们的查找数据能力也在变快。 而在我们的顺序存储结构中,我们的数据是按照磁道的轮转顺序存储到磁道上的,也就是说,当我们进行数据查找的时候,会更快的定位到实际的数据所在,这也就是意味着我们的数据查找速度变快。 <table><tr><td> 小知识; 在现代的计算机进化过程中,数据的存储有了很大的变化,比如说我们现在比较常见的固态硬盘,由于SSD固态硬盘没有磁头,所以几乎不存在寻道时间这一概念,当系统发出指令时,不需要磁头和盘片,而是直接从Flash颗粒上读取,相对传统的机械硬盘的寻道时间来说要快多了。 </td></tr></table> 顺序存储结构的优点总结如下: 数据存储密度大,存储空间的利用率要大。 查找速度比较快。 1.2 缺点 首先我们知道的是,顺序存储结构,存储的数据,在存储空间中,是连续的,如下图所示; 那么当我们要插入一条数据的时候,会怎么样呢?如图所示: 从图所示的插入过程中,我们发现,自插入位置起,后面的所有数据元素都往后面移动了一位,想一想,如果数据量上去了,那么等于大量的数据都要移动,而且实际的情况,远远比这个更糟糕,所以这样的插入效率,可想而知。 而删除的过程,虽然和插入恰恰相反,但是造成的后果,都是一样的,都是会导致大量的数据移动位置。 也因此,我们知道的是,顺序存储结构的缺点,就是在插入或者是删除的时候,效率会比较低。 2. 链式存储结构 在实际的数据操作过程中,有的数据结构需要的是查找的时候速度快一点,那么我们的顺序存储结构是符合这种需求的,但是也有很多时候,我们的数据会被多次删除也会被多次的插入,这就引发了一个问题,顺序存储结构不能满足这种需求场景,于是就出现了链式存储结构。 链式存储结构是将数据元素存放在任意的存储单元里,这组存储单元可以是连续的,也可以是不连续的。 也就是说,在链式存储结构中,数据是可以放到这个存储空间的任意位置,也因此,数据与数据之间物理位置的关系,不能表达出数据之间的逻辑关系。 那么,要如何解决这种逻辑关系呢? 于是在链式存储结构中,会将一个数据单元,分为两个区域,一个数据域,一个指针域。 数据域存储的就是我们实际的数据,而指针域则存储的是关联的其他数据的位置的指针,如果要通过链式存储结构存储数据 [A , B , C , D , E] ,存储的大概模型如图所示: 在这张图的基础上,经过转变后,将图变为如下的样子: 这样可以看的出来,指针域指向了下一个数据节点,也就是说,在连式存储结构中,数据之间的关系,是通过指针域的指向关系来表现的,和数据实际存储的位置没有关系。 2.1 优点 链式存储结构的优点是很好理解的,先看链式存储结构的插入图: 由于链式存储结构中,数据的关系不是由数据的实际存储位置表示的,而是由各个数据节点的指针域来表示的,那么也就是说,在数据插入或者删除的时候,不需要将插入数据后面的数据移动,只需要修改一下指针域的指向性就可以了。 也就是说,链式存储结构的插入或者删除元素很方便,比较灵活。而且我们看到的是,链式存储结构不需要连续的内存来存储,也就是说,对碎片型的内存的利用效率还是相对比较高的。 2.2 缺点 在顺序存储结构中,数据的存储就只需要存储这个数据就行。但是在链式存储结构中,数据的存储,除了存储的是这个数据外,还需要存储和这个数据相关的指针域。 这样,就相比于顺序存储结构外,链式存储结构多存储了一部分其他的数据,所以对存储空间的利用率就会降低。 而且要注意的是,链式存储结构,在物理逻辑上讲,因为实际存储的位置不是顺序的,那么读取的时候,效率会比较低。 总结 3.1 顺序存储结构 优点: 数据存储密度大,存储空间的利用率要大。 查找速度比较快。 缺点: 插入或者是删除的时候,效率会比较低 3.2 链式存储结构 优点: 插入或者删除的时候,效率比较高 对碎片型的内存利用率高。 缺点: 额外新增了指针域的数据,对内存的消耗大 在读取的时候效率比较低。

优秀的个人博客,低调大师

PaddleHub v2.0.0-beta1 已经发布,深度学习模型开发工具

PaddleHub v2.0.0-beta1 已经发布,此版本更新内容包括: BERT、ERNIE、RoBERTa等Transformer类模型升级至动态图,增加文本分类的Fine-Tune能力 新增自动数据增强能力Auto Augment,能高效地搜索适合数据集的数据增强策略组合。 支持搜索算法: PBA 支持任务: 图像分类、物体检测(待开放) 分布式自动数据增强搜索服务可以试用BML全功能AI开发平台 修复部分已知问题 详情查看:https://gitee.com/paddlepaddle/PaddleHub/releases/v2.0.0-beta1

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册