Kirago啥都知道就是啥都不行！！

场景需求 假设你正在爬楼梯。需要 n 阶你才能到达楼顶。 每次你可以爬 1 或 2 个台阶。你有多少种不同的方法可以爬到楼顶呢？ 注意：给定 n 是一个正整数。 示例 1： 输入： 2 输出： 2 解释： 有两种方法可以爬到楼顶。 1. 1 阶 + 1 阶 2. 2 阶 示例 2： 输入： 3 输出： 3 解释： 有三种方法可以爬到楼顶。 1. 1 阶 + 1 阶 + 1 阶 2. 1 阶 + 2 阶 3. 2 阶 + 1 阶 解题分析 通过题目描述可以得知，有1阶楼梯的话 就仅仅只有1种方法， 2阶楼梯的话，我们可以第一步爬1阶，第二步爬1阶 + 第一步直接爬2阶 得到 2种解法。 3阶楼梯...

二叉搜索树 二叉搜索树可以是一颗空树或者具备如下特性的一棵树： 若任意节点的左子树不空，则左子树上所有节点的值均小于它的根节点的值 若任意节点的右子树不空，则右子树上所有节点的值均大于它的根节点的值 任意节点的左、右子树也分别为二叉搜索树 没有键值相等的节点 一个高度平衡二叉树是指一个二叉树每个节点 的左右两个子树的高度差的绝对值不超过 1。 前置条件 给定一个数组，但此数组是有序的。 解决思路 通过结合二叉搜索树的特性可以得知，二叉搜索树通过 中序遍历之后得到的是一个有序数组。 中序输出的过程为：左节点 -> 根节点 -> 右节点 此时发现其实这是一个逆向过程，根据已有的排序数组逆向构造二叉...

常规性扯淡 任何代码一线开发人员在任何阶段复习数据结构，学习算法阶段都是有收获的，更何况很多时候我们并没有真正掌握这门“技巧”。 为啥 ”技巧“ 一词是带有引号，个人觉得这其实是一种思维习惯与解决问题思路吧。代码开发工作实际上就是掌握开发语言工具，通过抽象现实世界通过机器能够读懂的方式让计算机能够根据我们设计的逻辑解决实际需求问题。经历了这么多年的发展，将场景需求拆分粒度够细，最终可能都会映射到数据结构比如 数组、链表、队列、栈、树、图 等等的应用上。 其实这也是一个建模的过程，通过掌握数据结构的特性，再粘合上特定的逻辑，加上那么点数学技巧处理，我们就能够解决问题。 很多高级语言，比如 Jav...

欢迎大家订阅本人维护的微信公众号或者今日头条头条号，第一时间获取分享：）。 Warning！！！内容较多备好板凳与瓜子矿泉水！！ 参考1 参考2 什么是TSDB？ TSDB(Time Series Database)时序列数据库，我们可以简单的理解为一个优化后用来处理时间序列数据的软件，并且数据中的数组是由时间进行索引的。 时间序列数据库的特点 大部分时间都是写入操作。 写入操作几乎是顺序添加，大多数时候数据到达后都以时间排序。 写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库。 删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。...

此文算是水文一篇了，还是很早以前突发心思搞下 Linux 内核编译时记录的，感觉可装X。。。 欢迎大家订阅本人维护的微信公众号或者今日头条头条号，第一时间获取分享：）。 升级一些依赖包 yum install -y rpm-build redhat-rpm-config asciidoc hmaccalc perl-ExtUtils-Embed pesign xmlto yum install -y audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-develsudo yum install -y ncurses-d...

欢迎大家订阅本人维护的微信公众号或者今日头条头条号，第一时间获取分享：）。 转载自阳明老哥技术blog，发现其中有部分问题加上自己实践踩坑 本人维护的yaml配置文件链接 一般情况下我们是直接通过Dashboard的资源统计图标进行观察的，但是很显然如果要上到生产环境，就需要更自动化的方式来对集群、Pod甚至容器进行监控了。Kubernetes内置了一套监控方案：influxdb+grafana+heapster。但由于之前我们的应用的业务监控使用的是Prometheus，所以这里准备使用Prometheus来完成k8s的集群监控。 Prometheus 简介 Prometheus是Sound...

Hystrix 线程隔离策略与传播上下文 hystrix 的隔离策略分为两种： THREAD （线程隔离）：使用该方式， HystrixCommand 将在单独的线程上执行，并发请求受到线程池中的线程数量的限制。【默认方式，因为此种方式有一个除网络超时以外的保护层】 SEMAPHORE（信号量隔离）：使用该方式， HystrixCommand 将在调用线程上执行，开销相对较小，并发请求受到信号量个数的限制。【负载非常高时采用，信号量隔离一般仅适用于非网络调用的隔离】 隔离策略的属性 key 为： execution.isolation.strategy 如果想传播线程本地的上下文到 @Hyst...

总结前面几篇实际上我们已经经历过了 RestTemplate（restful api 请求构造）、Eureka （服务发现与注册）、Ribbon（负载均衡）、Fegin（声明式Rest）。基础的内容算是有了大概的了解，虽然 demo 例子比较简单，其中也适当了引入了自己对这部分内容的理解与拓展思考。但是仅仅拥有以上的知识栈其实我觉得远远是不够的，肯定是不能够上生产的微服务应用。 此篇的内容实际上就是微服务处理中的高级话题-容错处理。 雪崩效应 在实际的微服务架构中，各个服务之间肯定会存在依赖关系。在生产环境中，对于网络来说可能是脆弱的，那么“基础服务故障”会导致“级联故障”从而引起“雪崩效应”...

由于在分布式框架处理中，我们对于 Restful 风格的请求可能在实际的场景中会越来越多，对于前面章节的几篇文章，我们是通过字符串拼接的方式构造 URL 的： public User findById(String id) { return this.ribbonRestTemplate.getForObJect("http://microservice-provider-user/+ id, User.class) } 多说一句源码范畴的解释就不在这个系列搞了，有机会和精力另起一系列吧 对于这种构造方式，我觉得肯定是个蛋疼的问题，当然在 Spring Cloud 中有更爽的方式去处...

鉴于章节（四）文章中引入了拓展思考，在很多场景下，我们需要自定义 Ribbon 的配置，此篇主要 demo 示例为修改 Ribbon 的负载均衡策略。 Ribbon 配置自定义 配置自定义可以分为如下两种： 使用 Java 代码自定义 Ribbon 配置，配置指定名称的 Ribbon Client IClientConfig ribbonClientConfig: DefaultClientConfigImpl IRule ribbonRule: ZoneAvoidanceRule IPing ribbonPing: DummyPing ServerList<Server> ribbonSer...