在重构我们的加密货币交易所期间，决定修改与市场日期协作的概念。 在经典情况下，市场日期有两种分配方式：
1. REST接口；
2. WEBSocket广播订阅。
REST方法通常用于获取历史数据，而WEBSocket在线发送实时信息。 在某些情况下，根本不使用WEBSocket，而是通过REST通过常规请求执行更新。
似乎每个人都很高兴。 但是，经过仔细检查，这种概念的巨大开销显而易见。 它们的大部分依赖于REST。 为了确保REST接口的功能，我们必须创建一个满足高负载系统要求的后端。 自然地，您可以在这里选择各种解决方案，从PHP到现在流行的Golang。
还需要创建一个高度可访问的基础结构，实现诸如CI / CD之类的琐事以提供服务，并为所有这些人员提供合适的开发，维护等专家，等等。
同时，占据磁盘空间大部分的是历史市场日期。 它通常存储在数据库中。 一方面，这使我们能够解决集群问题，但在关键规模上，这将成为难以承受的负担，并给DevOps团队和开发人员带来不平凡的任务。
总的来说，这个概念的表面上的简单性和一致性被打碎了。
另外，您需要注意市场日期的特殊性。 它总是累积（增长）。 即 用数据库程序员的语言，我们总是先插入然后选择。 但不可分割。 即 出色的数据库功能，可用于系统化，优化等。 存储的数据将无人认领。
市场日期的另一个重要属性是其明确定义的结构。 例如，图表中的蜡烛只有八个参数：
1.时刻；
2.博览会；
3.最高价格；
4.最低价格；
5.开盘价；
6.收盘价；
7.音量；
8.平均价格。
关于交易也可以这样说。
基于这些先决条件以及经验，我很快得出结论，将市场日期视为结构化流是更正确的。
例如，带有蜡烛的流可以视为二进制结构的数组：
moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64总计：56个字节。
例如，JSON中的这种蜡烛将描述如下：
{ "date":1501004700, "high":0.08053391, "low":0.08020004, "open":0.08030001, "close":0.0803542, "volume":48.62169347, "weightedAverage":0.08038445 }
总计：167个字节。
规模上的利润是显而易见的。 而且这减少了流量，提高了向客户的交付速度。
在这里，当然会想到BSON。 但是它不能解决后端需求的问题，并且通常不能从根本上解决问题。 此外，浏览器本身不支持它。
我换了个方向。 网络上有很多使用线程的资源。 这些是音频和视频资源。 它们展示了所有必要的标志：
- 处理大量数据；
- 完美应对高负荷；
- 他们可以在线提供内容，但同时也可以访问历史数据。
我更深入地研究了流视频，这使我能够按市场日期从根本上解决所有上述问题。 事实证明，所有魔力都隐藏在开箱即用的
Content-Range技术中，例如Nginx。 它使您无需使用后端即可访问静态资源的任何区域（服务器上的文件）。 通常，发生这种情况的方式如下：在标题中引用URL指示要返回的曝光。 例如：范围：100-200。 我不会过多地介绍复杂性，您可以在专业文章中找到所有技术上的细微差别。 我认为本质很明确。
实际上，现在，您可以在正面对文件的必要部分（例如包含蜡烛的文件）进行申诉。 并且由于确切知道每支蜡烛需要多少字节（56个字节），因此我们可以轻松确定所需的偏移量。 没错，我们仍然需要知道时间表开始的时间点。 这很容易通过在文件中添加标头来解决，该标头的大小也是一个常数。
即 首先，前端从零位置访问文件，并接收
标题。 同时，nginx将返回文件大小。 这将确定文件中蜡烛的总数和开始时间。
现在，知道了时间的起点，对蜡烛的数量有了清晰的了解，我们就可以在不使用后端的情况下，从前面获得任何时间的蜡烛。
嗯，是的……再等一会……我们有一个参数，例如蜡烛的暴露程度。 这里的解决方案也很简单-我们一次保存多个文件以进行不同的曝光。 作为额外的小奖励，蜡烛结构的大小又减少了4个字节。
总体来说，该解决方案对于实施已经足够有趣了，但结果却是，我并不感到羞耻-非常可观的利润。 事实是浏览器可以缓存range方法接收的数据。 即 在对服务器的下一个前端请求时，如果文件的这一部分是浏览器较早收到的，它将不会到达您的服务器，而是会从缓存中获取。
但这还不是全部。 使用CDN，也可以通过其方式配置缓存。 即 总而言之，您可以获得一个能够给出大量上市日期的信息，同时最大程度地减少基础结构和服务器的负载。
不用说，人们对这个想法的忠诚度不再有任何疑问？ 现在几乎没有什么东西了……您需要生成这些相同的文件。
如上所述，通常，交易所使用市场日期的两种交付方式：REST和WEBSocket。 后者在线广播当前市场日期。 这通常是一项单独的服务。 如实践所示，完成此服务以使其将数据附加到必要的文件中并不难，并且实际上需要开发人员花费几个小时才能解决。 我们可以说他与新闻通讯同时登录。
将文件传送到节点的问题是经典的文件系统同步问题。 DevOps团队可以轻松自然地解决它。 例如使用rsync。
现在，我们可以放心地说-BINGO！
也许会出现问题-为什么所有的加密货币交易所做的都不一样？ 我对这个问题没有可靠的答案。 但是有一些想法：
- 交易所是由富有同情心的加密开发商创建的。 也许他们对经典交易所的工作一无所知，没有考虑到他们的经验，而是使用现成的解决方案来获得快速的结果。 这些是模板解决方案：相同的REST和随附的JSON；
- 正如他们在人们中所说的那样-有用吗？ 请勿触摸。 -因为 主要交易所已经创造了技术趋势，新兴的交易所已经借用了它们。
如果这个话题对社区感兴趣，我将继续撰写有关在我们的项目中实现的其他非标准解决方案的文章。 在实践中这是如何工作的，您可以在交易所网站上查看（请参阅我的个人资料）。 我特别建议注意图表的工作，该图表清楚地说明了此技术的所有收益。