我如何将软件系统的性能提高35,000％( 五 ) _软件系统

对于需要大量计算的值，这意味着它可以快速阻塞数据库的资源：

文章插图
> When multiple cache misses occurred, the database could get overwhelmed quickly.

然后，用户的行为使问题更加复杂，并使整个问题变得更加糟糕。当用户遇到延迟时，他们将刷新页面并重试，从而导致更多的额外负载：

文章插图
> Long-running database queries retried repeatedly caused us to lose our ability to read from the da

解决方案的前三分之一-垂直缩放我实施的首批解决方案之一是垂直扩展—改进了数据库的资源配置。
扩展数据库只是解决该问题的一个临时工具。在负载增加的某个时刻，我们将再次遇到此问题。
这也是一个昂贵的解决方案-花数千美元垂直扩展数据库集群并不是一个合理的支出。
解决方案的第二个三分之一-水平缩放我们有一个数据库集群，其中没有以任何方式使用只读副本。我们可以转换长期运行的报表和其他对时间敏感的查询，以便在只读副本而不是主副本上运行，从而将负载分布在整个集群上，而不是只分布在整个集群上。
解决方案的最后三分之一-防止比赛条件我们需要一种方法，通过防止系统一次又一次地重新计算相同的精确数据来防止系统过载。
我解决了这一问题，方法是添加了在多个请求同时请求重新生成缓存时返回陈旧数据的功能。
只有一个请求会导致重新计算，其余请求将处理过时的数据，直到完成该计算，而不是一遍又一遍地触发相同的计算。
Rails通过race_condition_ttl和expires_in参数的组合来支持这一点：
Rails.cache.fetch(cache_key, race_condition_ttl: 30.seconds, expires_in: 15.minutes)
火车不准时随着我们成功的成长，我们进行的竞选活动也增加了。反过来，这使CacheUpdateJob花费的时间越来越长，才能遍历数千个广告系列。
有一天，我收到了团队遇到的潜在错误的通知。他们已经在几个小时前将电子邮件排队，但没有人收到。我检查并意识到，传统上只有几个作业的队列中有成千上万的作业-所有CacheUpdateJob 。
调查进一步表明发生了什么事。CacheUpdateJob达到了这样的程度，即作业的运行时间要比其运行的时间长。
这意味着，尽管CacheUpdateJob每5分钟运行一次，但要花费10多分钟才能完成。在此期间，纸从缓存中丢失，并且作业在队列中堆积。这也意味着CacheUpdateJob一直在运行，并收取相当可观的使用费。
这阻止了所有其他工作的进行。
分成多个队列这里的解决方案是将我们拥有的各种作业分成多个队列，我们可以独立扩展。
邮件程序和其他用户触发的批量作业被放在一个队列中。事务性工作被放置在另一个中。昂贵的报告作业被放置在第三个队列中。使系统保持运行状态的作业（例如CacheUpdateJob）被放置在资源丰富的队列中。
这有助于确保任何一个队列中的备份不会对系统的其余部分造成很大的影响，并且使我们能够在紧急情况下关闭系统中不需要的部分。
将触发器与执行分开我们进行的其他更改之一是确保CacheUpdateJob本身不会完成工作，并将此职责转移给它排队的其他作业。这也使我们能够在排队之前检查重复作业的存在。如果我们已经为某个广告系列排队等待缓存更新，则没有必要在队列中添加第二个作业以缓存同一广告系列。
这确保了我们可以与触发缓存更新的事物并行化并独立扩展缓存更新的处理，并以最佳方式进行。
在需要的地方分批我意识到，拆分成单个工作的开销抵消了最初将它们拆分出来的一些好处。
我们实施了批处理，以便CacheUpdateJob不会为每条记录创建一个新作业，而是将记录分为约100个左右的可自定义组。这确保了批次较小且可以快速完成，同时仍为我们提供了所需的分离功能。
仅缓存所需的内容我们还查看了CacheUpdateJob，发现它正在不加区别地更新缓存-甚至缓存了几年前运行的活动。
我创建了一个设置机制，使我们可以确定每个广告系列缓存内容的频率。
对于不经常访问的旧版广告系列，我们无需费心更新这些值。对于那些每天运行活跃的日子，我们更新的频率更高，并且它们具有更高的缓存优先级。
内存不足当我们付出很多天时，我们开始看到越来越多的企业成功。业务量的增加意味着以前可以接受的内存分配突然达到了极限。