“明天是20号，这意味着将会再次有暴风雨。 阻止它是不可能的，只是准备并希望这次会吹响，奇迹将会发生，我们的湖渡轮将征服海洋 。
” 这种想法使几年前参与支持市政服务门户的团队无法承受。 下面将介绍如何进入这种情况以及如何找到解决方法。
一切如何开始
在遥远的1990年代，住房和公用事业部门经历了蓬勃发展，引入了新技术，自动化信息系统，并购买了新设备。 但是，有一些东西在很长一段时间内几乎没有变化，即支付公寓的费用。 是的，是的，那些相同的公寓收据已经变成纸张，变成了付款文件，获得了条形码，进行了详细解密。 住房和公共服务企业或资源供应企业定居中心的典型工作方案如下：
人们逐渐想到，现代互联网被宽带接入所取代，为什么不以电子形式接收在线支付文件？ 与此同时，住房和公共服务部门以组织形式动摇，MPP住房和公共服务（住房和公共服务的市政生产企业）被市政单一企业（市政单一企业），DEZ（单个客户的主管）取代。 所有这些转换的结果是，住房和公共服务企业的IT部门被疏远了，并在此基础上诞生了各种安置中心。 实际上，定居中心的实质是计算租金和人口的信息支持。
成长阶段，00s
正是在那时，第一个信息门户诞生了，为人们提供了电子服务。 第一个用户的数量以数十个为单位进行衡量，并不是每个人都信任电子支付文件，其他人则没有听说过创新，公共服务领域的移动应用程序很少。 信息门户网站的工作与熟悉的信息系统的工作没有太大不同，当然，它从来都不是高负载架构。
几年过去了，门户网站得到了改善，还有机会读取计量设备，生成证书等。 正是在这个时候，第一个“云”出现了，越来越多的用户开始在门户网站上注册并请求数据。 在远处，出现了第一波接近载荷。
小组（以下简称小组1）采取了以下优化措施：
- 将PDF中的付款文档的大小从0.5MB调整为0.2MB
- 创建付款单形成队列
- 存储生成的付款凭证以供重复请求
- 创建仅满足门户需求的主数据库副本
几年来，情况似乎一直稳定，单个门户网站的用户数以千计，虽然还没有猛烈发展，但是却大为震撼，清算中心的分散化在开发商的手中。
大跳台
历史上的一个新里程碑是在区域一级开发市政服务门户。 为该共和国的任何居民提供一个单一的入境点是一个诱人的想法;此外，这会将州级站点的评级提高到最佳商业或银行站点的水平，在那里该地区的每个居民将获得许多不同种类的服务。 最受欢迎的方法之一可能是支付住房和公共服务费用，并包括抄表。
因此，下一步是将结算中心的运营信息与付款凭证中显示的信息分开。 为此，开发了一种简单的数据传输格式和一个用于存储信息的数据库，并进行了5年的存储所需空间的计算。
在此阶段做出的关键决定：
- 信息部业务数据库的一部分；
- 开发用于存储这种格式的数据库；
- 将各地区定居中心的数据合并到一个数据库中；
- 与门户流程集成，开发服务。
在此阶段，由于门户网站为用户提供了单个界面，因此该解决方案已从成熟的后端转变为后端。 该门户网站拥有自己的团队，无论解决中心目前的解决方案如何，门户网站都可以开发。 在我们的历史上，出现了
第二个团队（以下称为第2团队）和一个新的供应商。 正如我们稍后将看到的那样，这极大地影响了问题的发展和解决。 设计解决方案的实质如下：
在设计数据库时，可以接受格式到数据库的简单映射，因此选择PostgreSQL 9.3作为DBMS（当时它是一个非常新的版本）。 该格式由9个平面文件组成，每个文件都由COPY命令（我们非常快地读取）加载到门户网站数据库的特定结算中心的许多表中（每个结算中心都有其自己的注册号）。 在某些结算中心，形成付款文件所需的记录数达到1,000,000，而在5年的-60,000,000的这一年中，这一记录数达到了1,200万，该数据库的请求数量增加到所有地区门户用户的总数，并且可以组成数万个 有一些事情要考虑。
没有这样的经验，
第1团队采取了以下步骤来减少潜在的负担：
- 表格按结算中心和划分月份划分；
- 对于不同的计费中心，数据加载过程是有时间间隔的。
增长过快的挑战
门户启动，准备好的计划面临现实：
- 用户数量很快超过了估计值。
- 查询进入主表，但是DBMS仍然轮询所有表
- 数据库服务器上的虚假负载。 在此服务器上，还有其他无与伦比的大型数据库，这些信息是随机出现的，加载时占用了所有可用资源
- 由于执行效率低下，形成付款凭证的服务变慢了
- 来自用户的负载并非在一个月内平均分配，而是集中在两个时期：
此刻将在帖子开头进行说明。 诊断问题很困难，因为问题似乎一次出现在所有地方。 团队1和团队2同样受到领导的喜爱，他们采取了一些措施来摆脱困境，但实际上他们之间没有任何沟通：
团队2似乎采取了一个逻辑且有用的步骤：用户进入系统后立即开始要求形成付款单据，以期在他到达页面中的页面时已经形成AP，并且可以快速提取完成的单据。
这时，
第1小组每月英雄化地解决了一个问题，每次都使客户确信问题的根源正在隐藏：
- 优化的SQL（有时会获得性能提升）；
- 将门户网站的数据库服务器与其余数据库分开；
- 我们在单独的应用程序中进行了付款单据的形成，并对其进行了优化。
- 我们修改了对主表的吸引力，更改了PostgreSQL的版本；
- 我们再次修改了上诉（现在从主表中只请求了一个特定的分区-有时甚至是加速）。
团队的英勇努力导致了当地的成功（在2-3个月内，问题似乎已经解决了）。 但是现实一直在引发新的介绍性笔记：
- 该数据库已经包含了数年，并且增长了1 TB以上；
- 用户数量已经达到数十万。
在斗争进行期间，
第2小组设置了自动服务测试，因此任何性能问题都在几分钟之内就被发现，并且该问题通过电子邮件自动升级为最高控制级别。
目前在
小组1中 ：
- 数据库存档时间开始超过允许的限制（该服务不可用）；
- 对该服务的一次呼叫立即影响了许多个月，分别产生了许多请求。
- 由于表（分区）数量的增加，DBMS在执行查询时变得更糟。
- 只想进行票据读取的用户仍然要求形成付款单据（请记住小组2的决定）。
很明显，从技术角度来看，该解决方案已达到极限，现在是时候开始分析用户行为以优化流程或从根本上改变技术了。
分析的结果（这是另一篇文章的主题），已采取以下措施：
- 数据截止到最近3年，因为前一期间没有通话。 从那以后，旧时期每年都被切断；
- 我们再次呼吁主表直接引用特定分区（从而减轻了DBMS的负担）。
现在
现在，该系统已经相当稳定，可以满足法规规定的时间范围和对非功能性特征的要求，但是再次出现了乌云：
- 用户数量进一步增加；
- 服务家庭数量的增长；
- 增加所提供服务的复杂性；
- 用户可用数据的粒度增加。
因此，拟定了一个计划，并正在准备执行以下措施：
- 用户行为分析：其中有多少人实际上正在查看付款单据，有多少人只是简单地付款（如手机）；
- 那些通常在最小负载时查看付款文件的用户的付款文件的初步形成；
- 向替代技术的过渡（是的，很多达到这一点的人都拥有更先进的解决方案，这些解决方案最初使用手机资源解决了所有问题）。
看来这可以提出很大的乐观点。 一切都做得很好：那些做的和那些本可以立即做的更好的人。 但是明天将会有新的Highload项目，新的陌生问题。 现在如何为他们做好准备，如果还没有数据，可以设想什么？
解决问题的系统方法
我们能否将经验转变为解决高负荷项目中问题的方法？ 奇怪的是，答案是肯定的，一切都已经为我们发明了，并且属于
约束理论TOC的框架
之内。 仅需5个简单步骤：
- 查找系统的限制。
- 确定如何充分利用系统的限制。
- 使其他一切服从于此决定。
- 扩展系统的限制。
- 注意！ 如果在前4个步骤中已取消限制，则返回步骤1，但不允许惯性引起系统限制。
本文末尾的文献中对这种理论的描述和步骤的本质进行了很好的描述，但是我将在当前过程的框架内写下我的看法：
- 限制：付款单据的形成时间。
- 解决方案：下载数据时，预先生成所有付款单据。
- 服从该决定：与用户联系时，签发一份完成的文件。
- 扩大限制：优化付款单形成的时间。
- 放弃所有家庭的预建系统，定义新的限制。
这种方法可以将解决方案时间减少数年，并且使程序员的人工成本降至最低。 该帖子指出了远远没有出现的所有问题，并且没有解决方案的一些细节，因为它们在建议的方法中并不那么重要。
关于该主题的内容：
- “目标。 持续改进过程，” Eliyahu Goldratt
- “约束理论。 基本方法，工具和解决方案” ，德米特里·埃格罗夫（Dmitry Egorov）
- 戈德拉特的约束理论。 持续改进的系统方法，” William Detmer