首页资讯扩展与Ruby和MongoDB的连接

扩展与Ruby和MongoDB的连接

分类:资讯

2020-06-19

477

Coinbase于8年前作为Ruby on Rails应用程序启动,使用MongoDB作为其主要数据存储。今天,Coinbase的主要铺路语言是Golang,但我们继续运行和维护原始的Rails整体,并大规模部署,并将数据存储在许多MongoDB集群中。

全局VM锁定

在Coinbase,我们使用CRuby(又名Ruby MRI)运行Ruby应用程序。 CRuby使用全局VM锁(GVL)来同步线程,以便一次只能执行一个线程。这意味着单个Ruby进程将只使用单个CPU内核,无论它运行的是单个线程还是100个线程。

Coinbase.com在具有大量CPU内核的机器上运行。为了充分利用这些核心,我们使用负载平衡父进程在许多子进程之间分配工作,从而启动了许多CRuby进程。在应用程序层中,很难在这些进程之间共享数据库连接,因此,每个进程都有自己的MongoDB连接池,该池由该进程的线程共享。这意味着每台机器都有到MongoDB集群的10-20K外向连接。

蓝绿色部署

在Coinbase中,保持产品速度至关重要。我们每天在整个机队中部署数百次生产。在一般情况下,我们使用蓝绿色部署,为每个部署分配一组新的实例,等待这些实例报告运行状况良好,然后再从之前的部署中关闭实例。

这种蓝绿色的部署方法意味着在这些部署期间,我们的服务器实例数量是原来的两倍。这也意味着与MongoDB的连接数是原来的2倍。

连接风暴

每个实例的大量连接,再加上在部署期间创建的实例数量,导致我们的应用程序为每个MongoDB集群打开数万个连接。在高流量期间进行部署,当我们的应用程序自动扩展以处理传入流量时,我们将在一分钟内看到将近60K的连接峰值,或每秒1K。

为了减少数据库上的某些连接负载,3月,我们修改了部署拓扑,引入了一个路由层,该路由层旨在将该负载从mongod核心数据库进程转移到mongos shard路由器进程。不幸的是,这些连接同样会影响“ mongos”进程,并且无法解决问题。

从这些连接计数中,我们经历了各种失败模式,包括不幸的交互,其中Ruby驱动程序可能会在已经降级的数据库上引起连接风暴(此问题已得到解决 )。正如本Post Mortem中所述,这是在4月的一次长时间事件中看到的,在该事件中,我们看到超过MongoDB最大128K的连接尝试到单个主机。

代理连接

根本的问题来自我们的Rails应用程序的连接。我们必须集中精力减少这些。分析查询MongoDB所花费的总时间表明,这些连接几乎没有使用。该应用程序可以使用当前连接数的5%提供相同数量的流量。显而易见的解决方案是某种形式的外部连接池,类似于PostgreSQL的PgBouncer。尽管存在现有技术 ,但是目前还没有用于MongoDB的连接池支持的解决方案。

我们决定为我们自己的MongoDB连接代理建立原型,我们将其称为“ mongobetween”。要求很简单:小型+快速,具有最小的复杂性和状态管理。我们希望避免在Rails中引入新的层,并且不想重新实现MongoDB的有线协议。

mongobetween是用Golang编写的,旨在与其他无法管理自己的MongoDB连接数的应用程序一起作为边车运行。它通过Golang MongoDB驱动程序管理的小型连接池多路复用来自应用程序的连接。它管理少量状态:一个MongoDB cursorID->服务器映射,它存储在内存中的LRU缓存中。

结果

自推出连接代理以来,我们已将与MongoDB的传出连接的总数大大减少了20倍。过去曾经达到30K的部署连接高峰现在达到1.5K连接。应用程序稳定状态(以前每个MongoDB路由器需要10K连接)现在总共只需要200–300个连接:

开源的

今天,我们宣布将在 github.com/coinbase/mongobetween中开源 MongoDB连接代理 如果您遇到类似的MongoDB连接风暴问题,我们非常希望收到您的来信,并希望聊聊我们的解决方案。如果您有兴趣解决具有挑战性的可用性问题并建立加密经济的未来,请加入我们 。

他们各自的所有者。


与Ruby和MongoDB的扩展连接最初发布在Medium上的The Coinbase Blog上,在那里人们通过突出并响应这个故事来继续对话。

声明:本资讯不能作为投资依据,与数字货币交易平台导航(https://www.heqi.cn/ex/)无关。

©2019-2020 数字货币交易所品牌网 JYSPP.COM