电商网站商品详情页系统架构设计
小型电商网站的商品详情页系统架构小型电商网站的页面展示采用页面全量静态化的思想。数据库中存放了所有的商品信息，页面静态化系统，将数据填充进静态模板中，形成静态化页面，推入 Nginx 服务器。用户浏览网站页面时，取用一个已经静态化好的 html 页面，直接返回回去，不涉及任何的业务逻辑处理。
如何使用 Hystrix 线程池技术实现资源隔离？
上一讲提到，如果从 Nginx 开始，缓存都失效了，Nginx 会直接通过缓存服务调用商品服务获取最新商品数据（我们基于电商项目做个讨论），有可能出现调用延时而把缓存服务资源耗尽的情况。这里，我们就来说说，怎么通过 Hystrix 线程池技术实现资源隔离。资源隔离，就是说，你如果要把对某一个依赖服务的所有调用请求，全部隔离在同一份资源池内，不会去用其它资源了，这就叫资源隔离。哪怕对这个依赖服务，比如说商品服务，现在同时发起的调用量已经到了 1000，但是分配给商品服务线程池内就 10 个线程，最多就只会用这 10 个线程去执行。不会因为对商品服务调用的延迟，将 Tomcat 内部所有的线程资源全部耗尽。
Hystrix 隔离策略细粒度控制
Hystrix 隔离策略细粒度控制Hystrix 实现资源隔离，有两种策略：线程池隔离信号量隔离对资源隔离这一块东西，其实可以做一定细粒度的一些控制。execution.isolation.strategy
基于 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 以及其它各种后端中间件的资源的访问的限制，其实是为了避免过大的流量直接打死后端的服务。
