[从初创企业毕业到scaleup意味着必须不断改进应用程序以跟上客户的增长。在这个新生工程系列中，轨道刻度，我们将讨论我们用于扩大产品规模的一些技术。]数据库是大多数应用程序的核心组件。但客户的响应速度会很慢，这会导致应用程序负载缓慢，从而导致性能下降。虽然大多数数据库访问是必需的，但有些访问是可以避免的。最明显的例子是确保应用程序有效地利用缓存数据。然而，也可能有疏忽。我们发现了这种错失的机会，并进行了最小限度的代码更改，欧洲云服务器，大数据是啥意思，以减少对数据库的大量查询。利用委派模式进行缓存访问委派是面向对象编程领域中常见的软件开发模式。它使用对象组合来实现类似于继承世界的代码可重用性。有一些非常详细的文章介绍了委派模式以及如何在Ruby/Rails应用程序中应用这些原则。在本博客中，我们将讨论如何在对现有委派代码进行少量更改的情况下优化性能。与其他Freshworks产品一样，Freshservice是一个多租户SaaS web应用程序。每个租户都是唯一的，可以有特定于他们的配置。我们将这些配置中的一部分存储在Redis中，另一部分存储在旧的关系数据库中。酸或其他因素是基于储存条件的选择。基于RDBMS的配置表由名为TenantConfigs的ActiveRecord模型支持，并与has-one关系的租户模型直接相关。为了减少数据库的负载并更快地访问频繁读取的数据，我们使用memcached作为LRU缓存。TenantConfigs对象也为每个租户缓存，以便更快地访问。租户模型具有一些委托给TenantConfigs关联的属性。我们注意到，这些属性中至少有一个作为对应用程序的每个web请求的一部分被访问。代表团是一个很好的老Ruby代表团，定义如下：1234567类Tenant<；ActiveRecord:：Base…#关联有"一个：租户配置委托：区域设置，：时区，：日期格式，…，收件人：：租户配置…结束"每次我们都这么做租户.locale，Rails将启动一个DB查询来从tenant_configs表获取区域设置信息。因为我们已经缓存了这些信息，企业管理软件开发，所以我们希望利用它来更快地访问并减少数据库的负载。为了实现这一点，我们只需将delegate从tenant_configs替换为tenant_configs_from_cache。1234567891011class Tenant<；ActiveRecord:：Base…\。。。，收件人：：租户配置来自缓存def租户配置来自缓存Rails.cache.fetch.获取（"租户配置：#{自身id}:#{self.tenant_配置。已更新_在toéi}") { self.tenant_配置}结束…结束delegate方法来自ActiveSupport，它要求delegate是定义类范围内的有效方法。因此，减少替换的工作方式没有改变。正如预期的那样，这些更改使我们显著减少了为tenant_configs模型激发的查询数，从每分钟1500个查询减少到接近零。这是通过添加两个单词的代码来实现的。反应式唯一性验证方法rubyonrails允许您通过ActiveRecord中神奇的"validates_university_of"验证，在ORM级别强制执行属性或函数的唯一性。这将使ActiveRecord查询检查数据库是否已包含所述属性的记录。如果是这样，验证将失败，Rails不会保存记录。这符合Rails进行验证的方式，并且可以无缝地工作。但是，如果你google验证了的唯一性，你会发现很多类似这样的文章在谈论为什么这个验证不完全可靠。简而言之，主要的缺陷是：它们不可靠。即使进行了唯一性检查，仍然可能存在争用条件，并且可以尝试在唯一列中插入重复的值；当依赖于验证的唯一性时，上面的场景将无法得到干净的处理，并且会抛出一个500，即使您使用了更安全的".save"；根据规模的不同，会生成太多的SELECT 1查询。我们很幸运在生产中没有遇到比赛条件的问题。然而，大数据与人工智能，随着规模的不断扩大，对我们数据库的"exists"/"select 1"查询的数量也在增加。因此，我们决定放弃一些核心模型的唯一性验证（validates_university_of）。因为我们的数据库已经有了唯一的索引，我们所要做的就是删除模型中调用的validates\u university_。但这种方法有一个问题。当试图保存重复项时，数据库将发出回滚，Rails将引发"ActiveRecord:：RecordNotUnique"异常。通常，您只希望方法以"！"喜欢"救命！"引发例外。但是，即使使用常规的"save"也会引发此异常。如果我们要从我们的模型中删除validates_uniquency_，我们的控制器将必须专门处理这个异常。为了解决这个问题并保持与当前代码流的一致性，我们最终编写了一个gem（record_not_unique），在模型级别捕获ActiveRecord:：RecordNotUnique异常，淘客系统开发，并在相关属性上添加验证错误。只有对于异常安全的方法（如"save"和"update_columns"）才会捕获异常。"救命！'会继续抛出异常。在用handle_record_not_unique替换validates_unique后，我们使用日志聚合器测量结果。123456789#Beforeclass User<；ActiveRecord:：Base验证以下项的唯一性：用户名，消息：：takenend#课后用户<；ActiveRecord:：Base handle_record_not_unique（字段：用户名"]，消息：{username:：taken}）结束一些值得注意的结果如下：1将更改部署到生产（1）后，tickets表上"Select 1"查询的下降趋势。从一周20多万次查询到零。2将更改部署到生产（1）后，用户表上"Select 1"查询的下降趋势。从一周57000多个查询到零。三。对于其他较小的"写入"模块（如组），每周每个表的"select 1"查询减少约20000个。这是在不改变现有代码流的情况下显著降低了数据库的负载。比尔盖茨正确地说："用代码行来衡量编程进度就像用重量来衡量飞机制造进度"。我们可以用上面的两行代码来实现最小的收益。相关岗位使用定制中间件的Sidekiq队列管理功能切换如何允许我们在规模上进行实验