流量高峰时期的性能瓶颈有哪些、以及如何来解决，java面试项目中遇到的难点

每个服务端请求进而触发多个更底层服务的请求，这是第二次请求杠杆。每一层请求可能导致一次请求杠杆，请求层级越多，杠杆效应就越大。

在多次请求杠杆反模式下运行的分布式系统，处于深层次的服务需要处理大量请求，容易会成为系统瓶颈。

与此同时，大量请求也会给网络带来巨大压力，特别是对于单次请求数据量很大的情况，网络可能会成为系统彻底崩溃的导火索。典型恶化流程图如下图：

多次请求杠杆所导致的性能恶化现象非常常见。

例如：对于推荐系统，一个用户列表请求会有多个算法参与，每个算法会召回多个列表单元（商家或者团购），每个列表单元有多种属性和特征，而这些属性和特征数据服务又分布在不同服务和机器上面，所以客户端的一次用户展现可能导致了成千上万的最底层服务调用。

对于存在多次请求杠杆反模式的分布式系统，性能恶化与流量之间往往遵循指数曲线关系。这意味着，在平常流量下正常运行服务系统，在流量高峰时通过线性增加机器解决不了可用性问题。所以，识别并避免系统进入多次请求杠杆反模式对于提高系统可用性而言非常关键。

3.反复缓存造成性能瓶颈

为了降低响应时间，系统往往在本地内存中缓存很多数据。缓存数据越多，命中率就越高，平均响应时间就越快。为了降低平均响应时间，有些开发者会不加限制地缓存各种数据，在正常流量情况下，系统响应时间和吞吐量都有很大改进。

但是当流量高峰来临时，系统内存使用开始增多，触发了JVM进行full GC，进而导致大量缓存被释放（因为主流Java内存缓存都采用SoftReference和WeakReference所导致的），而大量请求又使得缓存被迅速填满，这就是反复缓存。反复缓存导致了频繁的full GC，而频繁full GC往往会导致系统性能急剧恶化。典型恶化流程图如下图：

反复缓存所导致性能恶化的原因是无节制地使用缓存。缓存使用的指导原则是：工程师们在使用缓存时必须全局考虑，精细规划，确保数据完全缓存的情况下，系统仍然不会频繁full GC。

为了确保这一点，对于存在多种类型缓存以及系统流量变化很大的系统，设计者必须严格控制缓存大小，甚至废除缓存（这是典型为了提高流量高峰时可用性，而降低平均响应时间的一个例子）。

反复缓存反模式往往发生在流量高峰时候，通过线性增加机器和提高机器内存可以大大减少系统崩溃的概率。

性能优化方式