數據庫是如何重建連接從15000個到100個以下

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

一切從哪里開始

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

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

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

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

每當用戶創建一個新的Droplet時，Cloud就會向隊列中插入一個新的事件記錄。Scheduler每秒連續調查數據庫以查找新的Droplet事件，并計劃在可用的管理程序上創建這些事件。

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

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

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

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

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

對Droplet的需求增加意味著Scheduler正在加班加點地將它們全部分配給服務器。不幸的是，對于Scheduler來說，可用服務器的數量并不固定。

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

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

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

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

• 減少數據庫上的直接連接數。

• 重構調度器的排序算法以提高可用性。

• 解除其消息隊列職責的數據庫。

開始重構

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

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

當事件路由器上線時，它將數據庫連接的數量從15000多個銳減到不到100個。

接下來，工程師們將目光投向了下一個目標：Scheduler。如前所述，Scheduler是一個Perl腳本，用于確定管理程序將負責創建的Droplet。它通過使用一系列查詢對服務器進行排名和排序來實現這一點。每當用戶創建一個Droplet時，Scheduler就會用最好的機器更新表行。

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

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

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

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

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

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

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

現在真正的工作開始了。完全控制事件系統意味著Harpoon可以自由地重新設計Droplet工作流。

Harpoon的第一個任務是將消息隊列職責從數據庫提取到自身中。為此，Harpoon創建了自己的內部消息傳遞隊列，該隊列由RabbitMQ和異步工作站組成。當Harpoon把新事件推到一邊的隊列中時，工作站把它們從另一邊拉了出來。

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

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

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