当您启动一个新特性时，当您的代码和数据库每天都要处理数以百万计的最终用户时，对beta用户有效的功能并不总是那么有效。这正是我们在去年推出的一个功能Smart Campaigns时遇到的问题。（简而言之，活动是通过对讲机向一组用户发送的一组消息，以实现一个共同的目标，例如将免费用户转换为付费用户）。当我们最初启动这个特性时，后端管道运行得很好。但随着这个功能越来越受到客户的欢迎，我们成了自己成功的牺牲品。

消耗的资源量在急剧增长。例如，处理活动所需的worker实例的数量已经相当高，变得异常多了。在下面的图表中，您将看到愤怒的红色箭头是我们需要的实例数，其增长率明显高于特性使用率。以这样的速度，我们的活动功能很快变得非常昂贵。

这也给我们的数据库带来了很大的压力。这不仅仅是一个负载问题。这可能会给整个对讲机应用程序带来灾难？一个新的，大规模的活动即将上线，可能会引起一个突然的负载，摧毁我们的整个数据库和对讲机应用程序。当然，对于我们的工程师来说，这是一个可怕的情况。我们生活在害怕对讲机坏掉的恐惧中，我们半夜被传呼说数据库负载的危险程度，我们还在加班救火。我们需要使智能活动更有效地扩大规模。

我们自己提出了一系列的问题。我们如何在团队中建立对系统如何工作及其缺点的理解？我们能做哪些最简单、最快的事情来减轻影响如何更快、更有效地优化系统。通过查看功能的使用情况，我们如何调整产品以使其更易于扩展？建立理解我们做的第一件事就是让每个人都在同一个房间里，用白板、记号笔和许多便利贴。我们一起绘制了一个大流程图，展示了所有不同的队列、工作组和数据源是如何交互的。

在这之前，整个画面还只是一个工程师的脑袋。后来，所有的工程师都有了相同的最新思维模式，即不同的部件是如何组合在一起的。现在我们有五倍的工程师有效地工作，所有人都对系统有着共同的理解。既然我们对这个系统有了共同的理解，我们就可以真正开始了解它的问题所在了。我们在代码库中添加了大量的指标，这样我们就可以准确地找出性能瓶颈的真正所在，并逐一解决了最具影响力的问题。减轻缺点的影响作为我们在深入研究时发现的一个例子，我们意识到，一个特定的子特征导致了战役进程缓慢。不幸的是，我们没有快速的工程技术来修复它。我们可以做的是限制慢代码的爆炸半径，从而限制受影响的客户数量。下图显示了该管道的一个大大简化的版本。在左边，我们有一组工人，他们将工作分解，并将其传递到我们的排队系统中，如下图所示。然后我们在右边有另一组工人处理这些活动并发送信息。

这里重要的是，慢代码是在右边的一群工人身上运行的，他们处理的是慢和快的混合作业。快的工作落后于慢的工作。我们怎样才能使快速的工作过程快速而不因落后于缓慢的工作而被耽搁？我们通过创建一个新的队列和新的工人队伍来解决这个问题，把慢工和快工分开。

缓慢的工作虽然没有好转，但也没有恶化。然而，快速作业现在得到处理并迅速发送信息，这代表了99%的客户的活动。我们可能还没有找到问题的根源，但我们至少给自己争取了一些时间。优化系统要真正解决这个问题，我们需要加快速度。我们的指标告诉我们，从数据存储中提取数据（需要处理活动）是我们花费最多时间的地方。下面的图表总结了我们为解决这个问题所做的许多改进性能的更改。简而言之，我们希望将所有的数据访问尽可能地移到金字塔的高处。

我们有很好的度量每个查询需要多长时间，不仅仅是平均值，还有中间值和最坏情况。所以我们看了这些指标。我们确保在我们的查询中总能找到有效的索引。我们重构了代码，这样我们就可以成批地查询500、1000或5000，无论哪种查询性能最好。我们大幅提高了缓存的使用率，以便尽可能避免对数据库服务器的攻击。正如我前面提到的，Campaigns是我们数据库的一个非常大的用户，特别是我们的MongoDB集群。单是竞选活动就承担了大约一半的工作量？

我们发现大型活动的平均用户对象几乎没有变化，通常两三个星期都没有变化。我们每两个小时从MongoDB中取出一次，所以我们知道我们可以得到一个巨大的缓存命中率。有了这些知识，我们为Mongo数据库引入了Redis缓存，这是一个巨大的性能和可用性胜利。

我们很快看到Mongo数据库的负载大大减少。在下图的左侧，您将看到添加Redis缓存之前的查询量。右侧显示添加Redis缓存后，负载几乎为零。

如果我们的Mongo数据库崩溃，整个对讲机应用程序也会崩溃。引入这意味着我们可以防止最坏的情况发生。另一个重要的性能改进是，我们重新评估了当我们处理数百万用户而不是处理单个用户时活动的工作方式。为了简单起见，在这两个过程中，智能活动的工作方式大致相同。它从Mongo加载一个用户，然后找出要发送的消息。这在我们只处理单个用户的情况下是有意义的，但是在处理数百万用户时使用Elasticsearch的效率要高得多。

为作业选择正确的工具、正确的数据存储会带来所有的不同，尤其是在扩展功能时。看看你的用户是如何使用这个功能的即使在所有改进之后，仍有少数活动处理得不快。我们发现的是一个无法通过工程改进的问题。它要求我们对产品稍作调整，以使其更具可扩展性。通过与产品研究和产品管理部门的密切合作，我们找到了一条通向更快、更好产品的道路。我们的问题是，一个活动有可能积累大量用户。有时这些用户会变得"不活跃"——他们永远不会退出活动，因为他们永远不会收到任何消息。处理大量非活动用户的活动需要很长时间，并且给我们的数据库带来了巨大的负担。这也是最初设计智能营销活动时从未打算过的事情，而且它的发生通常是我们客户不希望看到的。限制用户在活动中不活动的时间可以有效地限制最坏情况下的处理情况，并使我们的客户更容易使用和理解该功能。

上图显示了我们工作：-开在左边，您可以看到运行活动所需的实例数量的增长速度明显快于功能的使用。自从我们进行了更改之后，活动处理的成本几乎没有增加，即使活动的使用率每月都在不断增加。基本上，负载的轨迹和运行活动的成本已经从可怕变成了真正的可怕。另外，我们不再担心活动的使用会影响对讲机应用程序的整体可用性。我再也不会因为竞选活动的页面而半夜醒来了。我睡了好几个月了？TL；DR如果你发现自己处于这样一个位置，你的功能发挥得比预期的要快，这里是我的建议。建立理解：让团队在同一页面上尽可能多地使用指标。减轻性能较差的代码的影响。优化：假设数据访问是你的代码花费时间最多的地方，努力使它变得便宜。并为您的工作负载使用正确的数据存储。最后，看看你的功能是如何被使用的，看看你可以做什么小的产品调整，使我