修改后的数据库驱动措施会记录高出特定响应时间阈值的所有查询操纵，以及请求 / 响应巨细、响应时间、源代码和查询范例等重要信息。

Coinbase 已有的监控东西无法为其时碰着的一些要害问题提供明晰的谜底，我们把这个现象称为「鬼魂」。

固然才方才开始利用 Capture 和 Cannon 东西，但在 MongoDB 数据库集群上执行这类的负载测试时，我们取得了一些新发明。

借助这些修复和其他要领，Coinbase 平台就可以或许遭受更大的生意业务量激增。

在 2017 年的生意业务量开始井喷的早期，每分钟平台后端 API 请求的数量

为了办理这个问题，Coinbase 团队将这种多对多干系重构为简朴的一对多干系，个中每个设备只映射到一个用户。

有没有留意到 ping 呼吁（ping 呼吁用于查抄网络是否连通，可以辅佐阐明和鉴定网络妨碍。）与 find 呼吁（查找）殽杂在一起？

今朝，我们已经组建了三个独立的专注维护平台高机能和可扩展性团队，为将来加密钱币热情的暴涨做好筹备。

而与之相对的中心化机构 Coinbase 生意业务所，固然在 2017 年也曾受平台扩展性瓶颈影响而导致大局限妨碍停机，但自此今后，尽量数字钱币生意业务人群不绝暴增、生意业务请求数量呈指数增长，但 Coinbase 平台貌似并没有再受扩展性问题的影响，一连、不变地运行着，令人差别，他们是如何做到的？

在此期间，在中心化生意业务所 Coinbase 平台之上，险些所有技能组件都经验了残忍的实战检验。

2016 年，也就是加密钱币市场井喷的前一年，Coinbase 平台的生意业务量根基恒定。

譬喻，一些用户大概拥有多个设备，而某些设备大概由多名用户共用。 糟糕的设备指纹（用于标定设备）识别算法将大量用户置于同一设备中，从而导致单个设备拥有大量_user_id工具。

那么，Coinbase 团队是如何应对 2017 年突增的平台生意业务量？之后又是如何慢慢扩展平台容纳量、一连不变运行呢？其扩展性办理方案在去中心化应用规模是否有警惕意义？接下来，听 Luke Demi 报告 Coinbase 平台背后的故事！

2017 年的履历教导

在这个进程中，面对的挑战就是如何同时凌驾多个应用措施处事器来捕捉单个数据库集群的所有 MongoDB 流量。

办理要领就是，Cannon 东西通过从每次捕捉中打开一个 10MB 的缓冲区来同时举办归并和过滤捕捉。


尽量今朝各行各业的去中心化应用如雨后春笋一般一连涌现，但其机能问题一直是未能打破的瓶颈，仍然存在应用场景受限、可扩展性不强等问题。当下，就连 V 神也是三句话离不开可扩展性话题。

颠末以上要领改造，Coinbase平台压力临时得以缓解，但跟着时间流逝，生意业务量总在一连攀升，平台断断续续呈现了许多次妨碍。

这些改造提供的具体数据使团队可以或许快速找到一些妨碍停机期间的异常特征，甚至在非妨碍停机期间也可以。

好比，这些查询操纵来自那边？ 这些操纵是怎么回事？ 为什么 Ruby 时间显示出相关的峰值？ 问题大概源于应用措施方面吗？简而言之，团队现有的监控处事并没有完全操作 Coinbase 平台情况中的可用信息。

Cannon 东西答允准确选择回放捕捉信息的速度，从而模仿数千倍于平台一天大概碰着的生意业务数据量的负载。

2017 年的事件再次证明，给客户提供会见和查察资金的靠得住处事对付实现 Coinbase 成为值得信赖的购置、销售和打点加密钱币平台的方针至关重要。

克日，Coinbase 的大牛工程师 Luke Demi 发文总结了平台去年妨碍停机的履历与教导，并具体先容了其平台的可扩展性办理方案。

事实证明，数据库 MongoDB 的 Ruby 语言驱动措施未完全遵循 MongoDB 驱动措施的设计类型，而且在每次查询数据库时通过执行 ping 呼吁以查抄复制集状态。

本日，Coinbase 团队正努力尽力为下一次加密钱币市场的井喷做筹备。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。