什么是像大型超市一样的高负荷信息系统？ 如果有1.5亿人同时到大卖场购物，该怎么办？ 您能惩罚一家大型超市的负责人，为什么不呢？ 为什么晚上的文档加载时间比白天少得多？ 为什么单个文档的加载时间实际上没有任何意义？

高负载的信息系统具有其自身的特征，这对于许多供应商组织而言并不明显。 我们将告诉您如何安排大量加载的文档（和其他数据），并详细考虑许多人这个难以理解的问题。

来源

在开发大型且高负载的信息系统（IS）时，会出现海量数据加载的任务。 数据类型无关紧要，取决于您的主题区域。 这可以是付款，账单，传感器读数，采购项目等。 GIS（状态信息系统）的创建和开发受到法律的监管，很容易发生法律要求组织一次将数百万个文档上载到系统中，或者更有趣的是，定期（例如每月）上载数百万个文档。

在我们的项目中（有关LANIT工作的一些信息可以在此处和此处阅读），我们会定期遇到此类任务并开发了所有必要的解决方案。 但是，事实证明，解决方案的某些特性对于许多供应商组织而言并不明显。 令我们惊讶的是，我们收到了这样的请求甚至投诉：

• “我们发送了一份文档进行下载，整个过程耗时长达10秒钟。 因此，如果我们的组织将需要上载10万个文档，那么我们将花费10万* 10/3600 = 277小时！”
• “我们加载，加载文档，但没有任何东西加载到系统中。”

将一个文档加载到信息系统可能需要10秒钟的事实本身并不能说明该系统。 如果我们在谈论排队系统，那么这个指标根本没有任何意义。 接下来，我们将告诉您如何安排大量加载的文档（和其他数据），并详细考虑许多人不清楚的问题。

至于加载错误，也并非一目了然：没有将数据加载到系统中的原因很多。 问题可能在信息提供者方面，也可能在IP方面。 下面我们将分析不同的情况并查看统计信息。

中国大卖场

例如，在一个偏远的中国省份，那里生活着约1.5亿人口，只有一个大型的全天候大型超市，那里的人口每月要购买一次大米。 居民可以在一个月的任何一天来大米。 大米很多，交易大厅里有很多地方。 主要瓶颈是在结帐时付款，因为此操作是强制性的（您不能不付款就跳过买家），这需要时间和使用专用设备（收银台）。 对于大卖场来说，人们之间以某种方式达成共识并平均购物（晚上和白天）会更好，在这种情况下，使用收银台将尽可能地高效。

然而，正如幸运的那样，买家不会进入大型超市。 首先，他们某种程度上并不想真的去晚上逛街。 其次，有时他们是无限的：要么没有人，然后有数百万人同时来。

来源 世界最大的购物中心，中国成都的新世纪全球中心。 它有18层，面积为1,700,000平方米。

在超市做什么？ 中国共产党已经确定了为全体中国人民服务的任务。 每个没有上任的中国人都是超市经理人缘的减号。 如果有太多不满意的中国人，请不要为他拆头！ 当然，与此同时，经理人无法交付1.5亿个收银台。 如果在一年之内，狡猾的控制者突然带来一份票房使用率为1％的报告，那么不幸的导演将面临令人羡慕的命运。 如果一个普通的买家等待的时间太长（超过一分钟），那么他将用光大卖场，写出一份声明，对毛泽东本人表示同情，向“你们五百四千个盖特瓦瑙的骗子可汗骗了你们”。

在看完海洋的工作原理之后，我们的朋友介绍了一个先进的队列管理系统。 现在，一切都像这样。 买完一包米饭后，买主到码头去排队等候。 排队的等待时间取决于收银处的数量。 从实验上讲，陪同主任发现应该有多少个收银台，以便买主一方面不会排队太长时间，另一方面，收银台的使用系数也不会太低。

来源

大家都很开心 票务系统非常简单，而且总是很快。 选择收银机数量，以便：

• 收银机的使用率使同级董事从此过上幸福的生活。
• 队列长度很小，中国人很少花时间（等待时间的95 ％ <合理值，例如5分钟）；
• 即使由于这种情况，许多购物者会同时来到商店，等待时间也会延长，但是他们的服务时间将持续到晚上23:00，以便他们可以回家睡觉前观看新闻发布。

就文件的大量接收而言，应安排与IP大致相同的IP。 例如，我们必须每月确保从10万个供应商处加载至少1.5亿个文档。 为了提高下载数据的质量，必须在下载之前检查所有数据。 不正确的数据将被丢弃。 并且应该以结构化的形式在系统存储中列出正确的内容，以便将来进行分析和使用。

在下载之前需要验证数据的事实导致您需要执行许多“控制”，从格式化到以复杂的控制结束（例如，有时需要业务控制来证明组织具有下载传输对象的基础）。

我们通常不能牺牲支票的质量。 我们相信开发人员已经优化了所有算法，进一步的优化过于耗时，或者使系统的进一步维护和开发变得复杂。 在我们的项目中，一个请求的处理时间平均在后端是几秒钟，该请求包含一到五百个文档（付款，发票，合同，采购项目等）（请参见图1中的示例）。 这个时间不是恒定的，而是在一定的范围内变化的，因为在复杂的系统中，总是存在很多不同的因素会影响包装的处理。

图1.处理文档包的典型时间表。 平均时间在三秒钟左右。

即使对于您的IS，下载日期是受法律规定的，但对于文档提供者，通常也没有明确的下载时间表。 对于不同类型的文档，存在某些模板，例如，可以在月初开具发票，可以通过规范性文档的条款来确定加载其他数据的高峰，或者可以与年末相关联，等等。

因此，实际上，在任何给定的时刻，加载文档的强度可能会非常不同-几乎不可能准确地预见到它。 好的供应商的所有1.5亿个文档都可能决定同时上载到系统。 这根本不是一回事，就像他们严格按照每天500万的计划下载它们一样。

图2.最近六个月中每天下载文件数量分布的示例。

图2显示每天加载的文档数量差异很大。 显然，平均每天下载约4-5百万个文档。 同时，有几天有超过1000万份文档发送到该系统。 每天最多可以上传1700万个文档。

如果我们查看文档加载的每小时动态，则会发现流量波动更大。 在某些小时，将5万份文档加载到IS中，并且在某些小时，加载的文档数超过了100万，我们间隔的时间越短，看到的负载变化就越大。

显然，两个，三个和一千万个文档可以同时进入系统。 因此，在设计批量加载机制时，我们使用队列查询缓冲。 来自用户的任何请求都首先存储在队列中。 因此，因为接收请求的操作非常简单，所以我们可以将接收强度很高的文档接收到系统中。 但是文档的验证和加载已经由特殊的“处理器”完成，其数量取决于可用的容量。 铁越多，“处理器”越多，系统可以同时处理的请求越多。

IP硬件软件组合的功能取决于所需的带宽和硬件成本。 我们需要找到一个平衡点，以便使我们（客户）对低负载期间的铁利用率感到满意，同时，在高峰时段，用于负载的数据队列不会增加太多。 考虑到大多数情况下，晚上负载通常会自然减少，因此我们可以使用准则-所有数据应在当天或晚上下载。 如果越来越多的情况是数据没有足够的时间在一夜之间加载，则这是通过添加铁增加吞吐量的信号。

图3.更改队列长度以加载数据包的时间表的示例。

图3显示了有关下载数据包的队列长度的统计信息。 需要注意的是，在白天，我们会有一个典型的驼峰，而在晚上，队列将被重置。

由于数据包的加载时间是队列中的等待时间与后端上数据包的处理时间的总和，因此晚上的加载时间比白天少得多（请参见图4）。

图4.数据包的下载时间。 这段时间的平均时间为11.92分钟。 引导时间包括队列时间和后端处理时间。

我们可以得出结论：如果供应商在晚上发送数据包，则下载时间将最少。 另一方面，如果以某种方式选择IC的容量以在同一天或每晚最多处理预期的数据量，那么供应商就没有意义保持数据加载-您只需要发送全部文档，并将尽快处理它。

如何养活整个村庄

让我们回到我们的主张。 “我们发送了一份文档进行下载，整个过程耗时长达10秒钟。 因此，如果我们的组织需要上传10万个文档，那么我们将花费100,000 * 10/3600 = 277小时！”

可以在不同时间为每个在不同时间到达大卖场的客户提供服务。 这将取决于有多少顾客来商店。 到了晚上，收银台很可能是空的，买家将立即得到服务。 在高峰时间，您可以排队几个小时。

来源

如果您需要在一个有10万居民的村庄里购买大米，该怎么办？ 将每个村民一个接一个地送到大卖场是没有意义的（下一个只有在前一个村民回来之后才出现）。 显然，在这种情况下，整个村庄的大米采购将耗时数小时或一天，因为您必须连续排队10万次。 另一方面，如果所有村民立即来到大型超市，一起排队，那么他们将同时排队。 实际上，它们仅排队一次。 他们排队等候的时间也将大大取决于收银处的数量。

换句话说，大量数据的加载时间受系统当前的负载（队列中数据包的数量）和系统吞吐量（处理这些数据包的强度）的影响。 诸如单个包装的装载时间这样的指标本身是不足的，并导致错误的结论。

为了将大量数据加载到IS中，不必依次发送请求，等待上一个请求的处理。 有必要立即将所有请求发送到IS，这些请求将由特殊的“处理器”进行排队和处理，其强度取决于可用的能力。 显然，通常IP的带宽大大超过了每个特定数据提供者的需求。

结果，同步方法不适用于批量加载-这是一种反模式。

你能惩罚一位导演主任吗？

这个故事中最令人担心的是同伴导演吗？ 他们能为他惩罚什么？

可能会拒绝客户服务-这总是令人不愉快的。 但是，发生这种情况的原因有很多，它们具有不同的性质。 让我们列出。

1.如果队列发布系统不起作用，则非常糟糕。 真是太糟糕了，第二天这种情况就在毛同志的办公室里解决了。

2.如果大型超市中的生产线增加，并且客户开始在该处挂了很长时间，那么这是可疑的，但不一定马上就变坏了。 必须对此进行监视，但是有两种情况：

• 排队人数的增加是由于事实上有太多中国人同时到来，例如，有传言称价格上涨。
• 由于许多票房已经中断的事实，排队人数正在增加。 这种情况已经很糟了，在计划会议上将可以理解，并且可能会导致谴责。

3.如果特定的中国人无法购买大米，则可能由于多种原因：

• 如果中国人忘了拿钱，那不是导演的错。
• 如果在结帐时出现故障或收银员责骂中国人，那么这已经是大卖场问题。 如果此类事件的比例增加到一定水平，那么这将成为一个大问题。

显然，对于任何IP而言，大量加载机制的重要特征是拒绝服务的百分比。 有必要区分由于与IS操作有关的技术原因（设备故障，系统错误等）而拒绝服务，以及由于与供应商方面的问题有关的原因（错误的数据包格式，从业务的角度来看不正确的数据）而导致的拒绝。控件等）。

情况可能有所不同。 但是，如果在开发知识产权时考虑到上述原则，并且有一个持续监控和消除技术错误的过程，那么情况早晚会稳定下来。 在运行良好的系统上，软件包下载的统计信息类似于表1。

	下载请求数，个	占％
完全成功上传的软件包	125977459	79.94％
由于供应商方面的问题（FLC，业务控制）未完全或部分装载的包裹	29936543	19％
由于IP端的问题而未下载的软件包	38805	0.02％
重复包装	1,638,886	1.04％
合计	156812782	100％

表1. 2018年7月的下载统计数据

该表显示大多数软件包已成功加载。 此外，信息提供者方面的错误比例很高。 这可能是由于供应商数量众多以及他们准备进行信息交换的程度不同。 供应商的数据质量可能低下，他们的信息系统可能存在问题。 某些数据可能无法以电子结构形式获得，因此接收它会花费一些时间。

不幸的是，可能会发生IP错误，尤其是在快速发展的过程中。 启动监视工业环境中的错误并分析其发生原因的过程非常重要。 我们在LANIT项目中使用了用于集成机制的已开发监视系统，如果我们发现错误的数量开始增加，我们将确定错误的来源并尝试快速采取纠正措施。

结论

最后，我想再次重申要点。

1. 在国家或公司IP的发展和发展中，海量数据加载的任务出现了。 通常，下载请求到IS的流是随机的。 这意味着我们大概知道了分布，但是在任何给定的时刻，可能会出现很少的许多请求。
2. 应当使用队列来构建用于批量加载的接收数据的机制。 这一点是不可能的。 否则，如果要下载大量数据，我们必须允许数据丢失，否则我们需要使用非常多的铁，这将导致99％的时间处于空闲状态。
3. 数据加载时间包括队列中的等待时间和数据处理时间。 经过适当设计和开发过程的后端数据包处理时间为几秒或几毫秒。 队列超时（分钟）取决于系统使用的处理程序数量。 处理器的数量取决于软硬件组合的功能。 更多铁-更多处理程序，更快的队列。 反之亦然。
4. 同步服务不适用于批量下载，因此不建议使用它们。
5. 如果您是供应商，并且需要上传大量数据，请立即将它们全部发送到IP。 在任何情况下，您都不应一个接一个地依次发送数据（在下载前一个数据包之前，不会发送下一个数据包）。