我们对对讲机可用性的目标是，我们的每个面向公众的端点（应用内信使、对讲机web应用程序和面向公众的API）的可用性都高于99.9%，这意味着每月停机时间不超过45分钟。这是我们定期发布的第二篇文章，其中我们提供了关于我们的操作性能的最新信息，并提供了一些关于我们为提高对讲机的可用性和性能所做的工作的技术细节。提醒–您可以从我们的状态页面获取有关我们绩效的实时更新和数据。2014年第四季度的主要架构说明：我们将我们的MongoDB集群从第三方托管平台迁移到AWS VPC中的一个自管理集群，物联网和互联网的区别，使用MongoDB的MMS来帮助我们构建和操作集群。我们还对MongoDB客户端配置进行了更改，这两个更改都有助于降低延迟和错误率。UI中的搜索使用ElasticSearch作为后端，显著加快了搜索的响应时间和可靠性。我们更新了所有端点的TLS/SSL配置。SSL实验室将我们的每个端点评为"A+"。以下是我们2014年第四季度的数据：请注意，App内的Messenger端点也称为Ping或jsapi。我们没有达到2014年第四季度99.9%的可用性目标。我们未能实现这一目标的两个主要原因也是我们2015年1月和2月过得很艰难的原因。从那时起，我们在这两个原因上都取得了重大进展和发现，所以它们就在这里。MySQL性能问题在10月底/11月初，然后在1月底/2月初，我们的主MySQL数据库出现了持续的性能问题。内部通信主要是一个整体的rubyonrails应用程序，使用ActiveRecord作为MySQL支持的ORM，我们使用amazonweb服务的关系数据库服务来托管MySQL数据库。随着时间的推移，应用程序和数据库都积累了一定的复杂性，我们已经做了很多事情来降低这种复杂性——例如，我们客户的用户数据和事件都在单独的专用数据存储中，我们还构建了许多执行独立功能的较小服务。然而，对讲机发展迅速，船舶频繁。工作量既难以预测，又增长迅速。一方面，这正是传统RDBMs所擅长的——它们是通用的瑞士军刀，能够处理不同的工作负载。另一方面，它们是难以捉摸的复杂动物，很难管理。MySQL性能问题的本质是，在我们每天最忙的时候，运行的活动线程数将激增1000倍，吞吐量将急剧下降，报告的CPU使用率将从大约10-15%跃升到90%左右。将数据库故障转移到一个读副本将使事情再次正常工作。我们反复寻找错误的查询或请求峰值，但都没有结果。我们最初与AWS合作，后来聘请外部MySQL顾问来评估数据库的总体健康状况并帮助稳定数据库。AWS在我们的RDS实例上禁用了透明的大页面，我们对MySQL的可调参数以及我们的应用程序如何使用连接池连接到MySQL进行了一些调整，这些操作停止了常规的中断。我们还开始收集更多关于MySQL实例性能的低级信息——尽管我们在这里受到使用托管服务的性质的限制。当问题在新的一年中再次出现时，MySQL指标表明锁争用是一个问题，在研究这个问题时，我们发现了许多长期运行的锁和事务。一些长时间运行的事务是可以预期的，因为运行对讲机的rubymri虚拟机可以暂停并在一个线程对数据库的锁打开的情况下进行完整的垃圾收集。然而，我们也发现我们的一些代码库正在执行其他例程，在某些情况下，在事务保持打开状态时调用外部服务。我们减少了长时间运行的事务数，同时减少了锁等待超时，这样等待锁将很快出错，公众号返利，而不是堆积起来。这使得性能事件更短，影响更小，并且不需要故障转移来恢复。我们还发现，在数据库中打开的大部分事务都被回滚了。回滚量导致了一些额外的负载，至少应该排除它是导致稳定性问题的因素。原因与对讲机端如何处理新类型的自定义数据有关–每个自定义数据字段都插入到MySQL表中的一行中，但是如果无法确定自定义数据的类型，我们的代码仍试图插入新发现的具有空值的自定义数据…然后（正确！）由于数据库限制，云端服务器，51返利，在MySQL级别失败。简单的检查确保非零的自定义数据不会试图写入已解决的数据库中，这使得回滚很少发生。在快速变化的环境中工作的一个问题是识别发生了什么变化。在应用程序、代码或基础结构级别，由于版本控制和审核跟踪，这并不太困难。然而，数据库通常不记录查询，而且很难发现新的查询或查询频率的变化，最重要的是它们的确切来源。我们通过扩展rubyonrails的ActiveRecord构建了一个SQL查询指纹器，并构建了一个简单的UI来导航收集到的数据，使发现新的查询和趋势变得容易。在未来的某个阶段，我们可能会考虑将其开源，尽管现在它对我们如何收集和存储指标有点拘泥。最终使我们恢复稳定的是减少数据库的总体负载。越来越清楚的是，我们所遇到的问题可能没有一个单一的触发器，总体上减少负载会有所帮助。数据库上的负载过去和现在都是读重的，虽然应用程序中有一些缓存，但没有使用通用的缓存框架，也没有应用一致的方法。输入shoppify的IdentityCache。这看起来非常适合我们正在做的事情——在一个现有的大型rubyonrails应用程序中实现缓存，同时不想编写大量新代码，并完全控制使用缓存的内容。为了使用IdentityCache，我们必须对ActiveRecord模型进行大量更改，并使调用方使用IdentityCache的方法来查找缓存的条目。这里的工作还没有完成，但是由于SQL查询指纹技术，我们能够将精力集中在最常见的数据库查询类型上。抵御Redis的困境Redis被用作对讲机传输的瞬时数据的低延迟数据存储，主要用于缓存数据和短期计数器。出于这些目的，这是一个相当好的数据存储选择。在12月底和2月中旬，我们有两个类似的事件需要一些时间来解决，每个事件都需要一个小时的停机时间。这两个事件都是由单个Redis节点的性能下降触发的。大多数代码调用Redis都使用了断路器来确保单个降级的Redis节点不会中断对讲机。在隔离测试时，断路器按设计工作，但是它们不能保护Redis在每个API请求中被调用很多次（在某些情况下超过100次），而且所有这些请求都比通常慢得多。显然，对讲机需要针对单个Redis节点性能下降的问题保持健壮性，而且我们没有预料到从应用程序调用Redis的频率。为了解决这个问题，我们将减少对Redis的调用频率，改进应用程序如何自动检测和响应这些问题，以及运行验证正确行为的游戏日（可能使用Vaurien来模拟运行缓慢的Redis节点–我们已经成功地使用它来模拟HTTP服务的问题）。充满挑战和乐趣上面的总结试图将大量的鲜血、勇气和混乱巧妙地浓缩成一个可读的叙述。我们尝试了很多不起作用或影响最小的事情，一路上遇到了很多麻烦。我们进一步了解了我们的产品，以及在不断增长的过程中如何考虑数据存储和弹性。在高速增长的环境中工作是很有挑战性和乐趣的，而且你的工作直接为客户喜欢使用的产品做出了贡献。如果你感兴趣的事情是做一些伟大的事情，物联网智能家居，这里有一个强制性的"我们正在招聘"链接。