高负载的WEB系统的关键任务是能够处理大量请求。 这个问题可以通过不同的方式解决。 在本文中，我建议考虑一种通过内容范围（范围）技术优化后端请求的不寻常方法。 即，通过有效的缓存来减少它们的数量而不损失系统质量。
首先，我建议研究
一篇文章 ，其中非常简洁明了地介绍S2S示例的技术序言。 此外，建议您熟悉我的第一
篇有关使用该技术来优化加密货币交换项目的市场数据工作的
文章 。
在本文中，我想表明该技术可以比第一篇文章更广泛地使用。 让我提醒您，那里的交易信息（
蜡烛 ）是通过对静态文件的范围请求获得的，这些文件是由特殊服务预先准备的。 现在，我想考虑使用相同的市场数据作为示例的完整后端请求，以及相同的蜡烛请求，同时又不损失关键利润。
那么计划要实现的目标是：
- 优化后端请求（减少其数量）；
- 提高向最终用户的内容交付速度；
- 优化流量。
我再次强调范围技术是一种标准（
RFC 2616 ）。 浏览器本身支持它，并且它们能够缓存接收到的数据部分。 因此，在没有干扰您的服务器的情况下，在客户端上实现了来自浏览器的下一个请求（如果存在所请求部分的实际缓存）。
如果在客户端和服务器之间添加
CDN ，则可以获得另一个强大的缓存层。 如果在第一种情况下，将为特定的最终客户端进行缓存，然后与CDN配对，则您将有机会为一组最终客户端缓存数据。
因此，为了向服务器发出真正的请求，该请求需要克服两个缓存级别，每个缓存级别都会减少对目标服务器的请求量。 当然，请求路径上最后的“疑问”可以是带有缓存的服务器。
在使用范围技术的功能中，您需要考虑到它可以处理部分字节。 即 与二进制数据。 我们可以精确地请求字节间隔。 它们必须分别响应-用二进制块。
我认为介绍足够。 让我们继续讨论一个特例，并且已经通过示例的方式，我们将弄清楚如何在一个特定问题中使用所有这些“幸福”-在给定的间隔内以给定的曝光量请求蜡烛。
对于初学者来说 我们需要使用二进制结构，让我们对烛进行编码。 为此，我们以以下结构为例：
moment: int32 // min: float64 // max: float64 // open: float64 // close: float64 // volume: float64 // average: float64 //
因此，我们的结构将占用52个字节。 我们将其视为量子-最小二进制块。
接下来，我们实现一个控制器，该控制器将接受GET请求并解析范围标头。 在这种情况下，我们将通过简单除法将请求的间隔转换为量子，而没有余数，即 例如，间隔请求：
Range: 5200-52000我们必须在量子范围内解释为：
Range: 100-1000从本质上讲，这将是数据库查询的偏移量和限制。
用暴露的定义很简单，我们可以把它放在URL中。 例如：
/api/v1/candles/7m即 我们将要求蜡烛暴露7分钟。 自然地，我们假定可以根据前端的请求更改此参数。
现在，知道所需的曝光量，前端请求的第一个蜡烛的数目和最后一个蜡烛的数目，我们可以对数据库执行相应的查询。
通常，这非常让人联想到经典的分页问题。
所剩无几。 查询结果的每一行都将转换为二进制结构（相同的量子），并且将生成的二进制数组显示为查询结果，并将内容范围返回到响应标头：
Content-Range: [ ] / [[ ] * [ ]]停下 但是前端如何能够请求所需的时间间隔，甚至在字节间隔内？ 他怎么知道那里的蜡烛数？ 在这里，一切都是发明的。 范围支持相对偏移量，例如
Range: -52从末尾请求52个字节。 即 最后一支蜡烛。 现在，知道最后一支蜡烛的最后时刻，从答案中知道“文件”的总大小，您可以计算出蜡烛的总数，并从此处确定用于请求所需时间曝光的字节间隔。
如果您突然想问一个问题-为什么会有这样的困难？ 请返回您的目标。 该技术将对数据库的分析查询“屏蔽”为CDN和浏览器的二进制文件。 这使您可以将大多数重复请求转移到CDN和最终客户端。
也许还会出现另一个问题-为什么不使用GET请求的简单缓存？ 好啊 让我们做对。 如果我们在经典REST中执行这样的请求：
GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018我们将为此请求获得唯一的缓存。 通过执行以下查询：
GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018我们将获得另一个独特的缓存...。 不过请注意，第二个请求请求包含在第一个请求的响应中的数据。
因此，在上述建议的实现方式（范围）的情况下，第二个请求将不会形成单独的缓存，而将使用从第一个请求中已经接收到的数据。 而且它不会在服务器上。 这样，可以节省缓存的大小并减少对服务器的调用次数。
这项技术有什么缺点吗？ 是的 它们很明显：
- 该技术不适用于随时间变化的数据，因为 基于总缓存。
- CDN CloudFlare仅完全缓存文件。 这意味着，如果最终客户端请求的间隔为1到100个字节，则CloudFlare实际上将向服务器请求整个文件。 即 在我们的情况下，它将以一定的曝光量加载所有蜡烛。 他将自己放置它，并将自己分发。 如果不是因为这个地方的限制，这甚至可以被认为是一个加号。 而且，如果您可以形成“繁重的”答案以及许多参数，那么...通常，很明显，该地点将结束。 也许我们无法正确配置它。 但是到目前为止，结果如下。
- 需要明智地管理缓存。 有足够的机制来执行此操作，但是需要进行调整。
- 前端应该能够解析二进制数据，并在板上具有一些ala数据集以处理范围请求。
我将制定实施该策略的可行性描述如下-当您需要时，您将了解。 如果现在有疑问，了解她会很有用，但不要打扰。