數(shù)據(jù)庫是如何重建連接從15000個到100個以下

這篇文章主要講解了“數(shù)據(jù)庫是如何重建連接從15000個到100個以下”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“數(shù)據(jù)庫是如何重建連接從15000個到100個以下”吧！

一切從哪里開始

從一開始，DigitalOcean就癡迷于簡潔。這是其核心價值觀之一：力求簡單而優(yōu)雅的解決方案。這不僅適用于我們的產(chǎn)品，也適用于我們的技術(shù)決策。在最初的系統(tǒng)設(shè)計中，這一點再明顯不過了。

像GitHub、Shopify和Airbnb一樣，DigitalOcean在2011年開始作為Rails應(yīng)用程序。Rails應(yīng)用程序(內(nèi)部稱為Cloud)管理UI和公共API中的所有用戶交互。幫助Rails的是兩個Perl服務(wù)：Scheduler和DOBE(DigitalOcean后端)。

Scheduler計劃并分配Droplet給管理程序，而DOBE負責(zé)創(chuàng)建實際的Droplet虛擬機。當(dāng)Cloud和Scheduler作為獨立服務(wù)運行時，DOBE在機隊的每臺服務(wù)器上運行。

Cloud、Scheduler和DOBE都不能直接交流。他們通過MySQL數(shù)據(jù)庫進行通信。這個數(shù)據(jù)庫有兩個作用：存儲數(shù)據(jù)和安排通信。這三個服務(wù)都使用一個數(shù)據(jù)庫表作為消息隊列來傳遞信息。

每當(dāng)用戶創(chuàng)建一個新的Droplet時，Cloud就會向隊列中插入一個新的事件記錄。Scheduler每秒連續(xù)調(diào)查數(shù)據(jù)庫以查找新的Droplet事件，并計劃在可用的管理程序上創(chuàng)建這些事件。

最后，每個DOBE事件將等待新的計劃Droplet被創(chuàng)建并完成任務(wù)。為了使這些服務(wù)器可以檢測到所有新改動，它們都需要調(diào)查數(shù)據(jù)庫以查找表中的新記錄。

在系統(tǒng)設(shè)計方面，無限循環(huán)和給每個服務(wù)器一個與數(shù)據(jù)庫的直接連接，這可能是最基本的，很簡單，而且很有效——特別是對于一個人手不足的技術(shù)團隊來說，他們面臨著緊迫的最后期限和快速增長的用戶群。

四年來，數(shù)據(jù)庫消息隊列構(gòu)成了DigitalOcean技術(shù)棧的主干。在此期間，我們采用了一種微服務(wù)體系結(jié)構(gòu)，用gRPC替換了HTTPS作為內(nèi)部通信量，用Golang代替Perl作為后端服務(wù)。然而，所有的路仍然通向那個MySQL數(shù)據(jù)庫。

重要的是，不能僅僅因為某些東西是陳舊的，就認為它就是不正常的，應(yīng)該被取代的。Bloomberg和IBM擁有用Fortran和COBOL編寫的遺留服務(wù)，它們所產(chǎn)生的收入比整個公司多得多。另一方面，每個系統(tǒng)都有一個比例限制。我們需要面對。

從2012年到2016年，DigitalOcean的用戶流量增長超過10000%。我們在產(chǎn)品目錄中增加了更多的產(chǎn)品，在基礎(chǔ)設(shè)施中增加了更多的服務(wù)。這增加了數(shù)據(jù)庫消息隊列上事件的進入量。

對Droplet的需求增加意味著Scheduler正在加班加點地將它們?nèi)糠峙浣o服務(wù)器。不幸的是，對于Scheduler來說，可用服務(wù)器的數(shù)量并不固定。

為了跟上不斷增長的Droplet需求，我們增加了越來越多的服務(wù)器來處理流量。每個新的管理程序意味著另一個到數(shù)據(jù)庫的持久連接。到2016年初，該數(shù)據(jù)庫擁有超過15000個直接連接，每個連接每1到5秒查詢一次新事件。

如果這還不夠糟糕的話，那么每個管理程序用來獲取新的Droplet事件的SQL查詢也變得越來越復(fù)雜。它已經(jīng)變成了一個150多行的巨人，橫跨18張表格。它既令人印象深刻，又岌岌可危，難以維持。

不出所料，就是在這個時期前后，裂縫顯現(xiàn)。一個單一的故障點和數(shù)千個依賴項爭奪共享資源，不可避免地導(dǎo)致了一段混亂的時期。表鎖和查詢積壓導(dǎo)致中斷和性能下降。

而且由于系統(tǒng)中的緊密耦合，沒有一個明確或簡單的解決方案。Cloud、Scheduler和DOBE都是瓶頸。僅修補一個或兩個組件只會將負載轉(zhuǎn)移到其余的瓶頸。于是，經(jīng)過反復(fù)考慮，工程人員想出了一個三管齊下的整改方案：

• 減少數(shù)據(jù)庫上的直接連接數(shù)。

• 重構(gòu)調(diào)度器的排序算法以提高可用性。

• 解除其消息隊列職責(zé)的數(shù)據(jù)庫。

開始重構(gòu)

為了解決數(shù)據(jù)庫依賴性問題，DigitalOcean工程師創(chuàng)建了事件路由器。事件路由器充當(dāng)區(qū)域代理，代表每個數(shù)據(jù)中心的每個DOBE實例輪詢數(shù)據(jù)庫。而不是成千上萬的服務(wù)器每個查詢數(shù)據(jù)庫，將只有少數(shù)代理做查詢。

每個事件路由器代理將獲取特定區(qū)域中的所有活動事件，并將每個事件委托給相應(yīng)的管理程序。事件路由器還將龐大的輪詢查詢分解得更小、更易于維護。

當(dāng)事件路由器上線時，它將數(shù)據(jù)庫連接的數(shù)量從15000多個銳減到不到100個。

接下來，工程師們將目光投向了下一個目標：Scheduler。如前所述，Scheduler是一個Perl腳本，用于確定管理程序?qū)⒇撠?zé)創(chuàng)建的Droplet。它通過使用一系列查詢對服務(wù)器進行排名和排序來實現(xiàn)這一點。每當(dāng)用戶創(chuàng)建一個Droplet時，Scheduler就會用最好的機器更新表行。

雖然聽起來很簡單，但Scheduler有一些缺陷。它的邏輯很復(fù)雜，很難處理。它是單線程的，在流量高峰時性能會受到影響。最后，只有一個Scheduler實例而它必須服務(wù)于整個機隊。這是一個不可避免的瓶頸。為了解決這些問題，工程團隊創(chuàng)建了Scheduler  V2。

更新后的Scheduler徹底修改了排名系統(tǒng)。它沒有在數(shù)據(jù)庫中查詢服務(wù)器度量，而是從管理程序聚合并將其存儲在自己的數(shù)據(jù)庫中。此外，Scheduler團隊通過并發(fā)和復(fù)制使他們的新服務(wù)可在負載下運行。

事件路由器和Scheduler  V2都取得了巨大的成就，解決了許多體系結(jié)構(gòu)的故障。即便如此，還是有一個明顯的缺陷。到2017年初，集中式MySQL消息隊列仍在使用中，甚至很繁忙。它每天處理多達40萬條新記錄，每秒更新20次。

不幸的是，刪除數(shù)據(jù)庫的消息隊列并非易事。第一步是阻止服務(wù)直接訪問它。數(shù)據(jù)庫需要一個抽象層。它還需要一個API來聚合請求并代表它執(zhí)行查詢。如果任何服務(wù)想要創(chuàng)建一個新事件，它就需要通過API來創(chuàng)建。于是，Harpoon誕生了。

得到入股的時間比你想象的要長

但是，為事件隊列構(gòu)建接口是最簡單的部分。事實證明，要得到其他團隊的入股更加困難。與Harpoon集成意味著團隊必須放棄對數(shù)據(jù)庫的訪問，重寫部分代碼庫，并最終改變他們一直以來的工作方式。那并不容易。

一個團隊接著一個團隊，一個服務(wù)接著一個服務(wù)，Harpoon工程師成功地將整個代碼庫遷移到他們的新平臺上。這花了大約一年時間，但到2017年底，Harpoon成為數(shù)據(jù)庫消息隊列的唯一發(fā)布者。

現(xiàn)在真正的工作開始了。完全控制事件系統(tǒng)意味著Harpoon可以自由地重新設(shè)計Droplet工作流。

Harpoon的第一個任務(wù)是將消息隊列職責(zé)從數(shù)據(jù)庫提取到自身中。為此，Harpoon創(chuàng)建了自己的內(nèi)部消息傳遞隊列，該隊列由RabbitMQ和異步工作站組成。當(dāng)Harpoon把新事件推到一邊的隊列中時，工作站把它們從另一邊拉了出來。

由于RabbitMQ取代了數(shù)據(jù)庫的隊列，工作站可以自由地直接與Scheduler和事件路由器通信。因此，Harpoon沒有使用Scheduler  V2和Event Router輪詢數(shù)據(jù)庫中的新更改，而是直接將更新推送到數(shù)據(jù)庫中。2019年撰寫本文時，這就是Droplet事件體系結(jié)構(gòu)所處的位置。

在過去的七年里，DigitalOcean已經(jīng)從庫樂隊的根基成長為今天的老牌云提供商。與其他轉(zhuǎn)型期科技公司一樣，DigitalOcean定期處理遺留代碼和科技債務(wù)。無論是打破整體，創(chuàng)建多區(qū)域服務(wù)，或消除單一故障點，  DigitalOcean工程師始終致力于制定優(yōu)雅和簡單的解決方案。

感謝各位的閱讀，以上就是“數(shù)據(jù)庫是如何重建連接從15000個到100個以下”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對數(shù)據(jù)庫是如何重建連接從15000個到100個以下這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！