Hystrix 隔离策略细粒度控制
Hystrix 隔离策略细粒度控制Hystrix 实现资源隔离，有两种策略：线程池隔离信号量隔离对资源隔离这一块东西，其实可以做一定细粒度的一些控制。execution.isolation.strategy
2021年9月
基于 request cache 请求缓存技术优化批量商品数据查询接口
Hystrix command 执行时 8 大步骤第三步，就是检查 Request cache 是否有缓存。首先，有一个概念，叫做 Request Context 请求上下文，一般来说，在一个 web 应用中，如果我们用到了 Hystrix，我们会在一个 filter 里面，对每一个请求都施加一个请求上下文。就是说，每一次请求，就是一次请求上下文。然后在这次请求上下文中，我们会去执行 N 多代码，调用 N 多依赖服务，有的依赖服务可能还会调用好几次。
说说 Hystrix 执行时的内部原理
前面我们了解了 Hystrix 最基本的支持高可用的技术：资源隔离 + 限流。创建 command；执行这个 command；配置这个 command 对应的 group 和线程池。这里，我们要讲一下，你开始执行这个 command，调用了这个 command 的 execute() 方法之后，Hystrix 底层的执行流程和步骤以及原理是什么。
如何从大量的 URL 中找出相同的 URL？
题目描述给定 a、b 两个文件，各存放 50 亿个 URL，每个 URL 各占 64B，内存限制是 4G。请找出 a、b 两个文件共同的 URL。解答思路1. 分治策略每个 URL 占 64B，那么 50 亿个 URL 占用的空间大小约为 320GB。
说说 Hystrix 断路器的执行原理
深入 Hystrix 断路器执行原理状态机Hystrix 断路器有三种状态，分别是关闭（Closed）、打开（Open）与半开（Half-Open），三种状态转化关系如下：Closed 断路器关闭：调用下游的请求正常通过Open 断路器打开：阻断对下游服务的调用，直接走 Fallback 逻辑Half-Open 断路器处于半开状态：SleepWindowInMilliseconds
说说基于本地缓存的 fallback 降级机制
基于本地缓存的 fallback 降级机制Hystrix 出现以下四种情况，都会去调用 fallback 降级机制：断路器处于打开的状态。资源池已满（线程池+队列 / 信号量）。Hystrix 调用各种接口，或者访问外部依赖，比如 MySQL、Redis、Zookeeper、Kafka 等等，出现了任何异常的情况。访问外部依赖的时候，访问时间过长，报了 TimeoutException 异常。
如何从大量数据中找出高频词？
题目描述有一个 1GB 大小的文件，文件里每一行是一个词，每个词的大小不超过 16B，内存大小限制是 1MB，要求返回频数最高的 100 个词(Top 100)。解答思路由于内存限制，我们依然无法直接将大文件的所有词一次读到内存中。因此，同样可以采用分治策略，把一个大文件分解成多个小文件，保证每个文件的大小小于 1MB，进而直接将单个小文件读取到内存中进行处理。
说说 Hystrix 线程池隔离与接口限流
前面讲了 Hystrix 的 request cache 请求缓存、fallback 优雅降级、circuit breaker 断路器快速熔断，这一讲，我们来详细说说 Hystrix 的线程池隔离与接口限流。Hystrix 通过判断线程池或者信号量是否已满，超出容量的请求，直接 Reject 走降级，从而达到限流的作用。限流是限制对后端的服务的访问量，比如说你对 MySQL、Redis、Zookeeper 以及其它各种后端中间件的资源的访问的限制，其实是为了避免过大的流量直接打死后端的服务。
如何找出某一天访问百度网站最多的 IP？
题目描述现有海量日志数据保存在一个超大文件中，该文件无法直接读入内存，要求从中提取某天访问百度次数最多的那个 IP。解答思路这道题只关心某一天访问百度最多的 IP，因此，可以首先对文件进行一次遍历，把这一天访问百度 IP 的相关信息记录到一个单独的大文件中。接下来采用的方法与上一题一样，大致就是先对 IP 进行哈希映射，接着使用 HashMap 统计重复 IP 的次数，最后计算出重复次数最多的 IP。
如何限流？说一下具体的实现？
什么是限流限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。
TimeoutMilliseconds
一般来说，在调用依赖服务的接口的时候，比较常见的一个问题就是超时。超时是在一个复杂的分布式系统中，导致系统不稳定，或者系统抖动。出现大量超时，线程资源会被 hang 死，从而导致吞吐量大幅度下降，甚至服务崩溃。你去调用各种各样的依赖服务，特别是在大公司，你甚至都不认识开发一个服务的人，你都不知道那个人的技术水平怎么样，对那个人根本不了解。
如何在大量的数据中找出不重复的整数？
题目描述在 2.5 亿个整数中找出不重复的整数。注意：内存不足以容纳这 2.5 亿个整数。解答思路方法一：分治法与前面的题目方法类似，先将 2.5 亿个数划分到多个小文件，用 HashSet/HashMap 找出每个小文件中不重复的整数，再合并每个子结果，即为最终结果。
单体式架构迁移到微服务架构
迁移单体式应用到微服务架构意味着一系列现代化过程，有点像这几代开发者一直在做的事情，实时上，当迁移时，我们可以重用一些想法。一个策略是：不要大规模（big bang）重写代码（只有当你承担重建一套全新基于微服务的应用时候可以采用重写这种方法）。重写代码听起来很不错，但实际上充满了风险最终可能会失败，就如 Martin Fowler 所说：“the only thing a Big Bang rewrite guarantees is a Big Bang!”
如何在大量的数据中判断一个数是否存在？
题目描述给定 40 亿个不重复的没排过序的 unsigned int 型整数，然后再给定一个数，如何快速判断这个数是否在这 40 亿个整数当中？解答思路方法一：分治法依然可以用分治法解决，方法与前面类似，就不再次赘述了。
说一下微服务的事件驱动数据管理
单体式应用一般都会有一个关系型数据库，由此带来的好处是应用可以使用 ACID transactions，可以带来一些重要的操作特性：原子性 – 任何改变都是原子性的一致性 – 数据库状态一直是一致性的隔离性 – 即使交易并发执行，看起来也是串行的Durable – 一旦交易提交了就不可回滚
