怎么解決數據庫分庫分表無限擴容問題

這篇文章主要講解了“怎么解決數據庫分庫分表無限擴容問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么解決數據庫分庫分表無限擴容問題”吧！

單體應用

每個創業公司基本都是從類似 SSM 和 SSH 這種架構起來的，沒什么好講的，基本每個程序員都經歷過。

RPC 應用

當業務越來越大，我們需要對服務進行水平擴容，擴容很簡單，只要保證服務是無狀態的就可以了，如下圖：

當業務又越來越大，我們的服務關系錯綜復雜，同時，有很多服務訪問都是不需要連接 DB 的，只需要連接緩存即可，那么就可以做成分離的，減少 DB  寶貴的連接。

如下圖：

我相信大部分公司都是在這個階段。Dubbo 就是為了解決這個問題而生的。

分庫分表

如果你的公司產品很受歡迎，業務繼續高速發展，數據越來越多，SQL 操作越來越慢，那么數據庫就會成為瓶頸。

那么你肯定會想到分庫分表，不論通過 ID Hash 或者 Range 的方式都可以，如下圖：

這下應該沒問題了吧。任憑你用戶再多，并發再高，我只要無限擴容數據庫，無限擴容應用，就可以了。

這也是本文的標題，分庫分表就能解決無限擴容嗎?實際上，像上面的架構，并不能解決。

其實，這個問題和 RPC 的問題有點類似：數據庫連接過多!

通常，我們的 RPC 應用由于是使用中間件進行數據庫訪問，應用實際上是不知道到底要訪問哪個數據庫的，訪問數據庫的規則由中間件決定，例如 Sharding  JDBC。

這就導致，這個應用必須和所有的數據庫連接，就像我們上面的架構圖一樣，一個 RPC 應用需要和 3 個 MySQL 連接。

如果是 30 個 RPC 應用，每個 RPC 的數據庫連接池大小是 8，每個 MySQL 需要維護 240 個連接。

我們知道，MySQL 默認連接數是 100，最大連接數是 16384，也就是說，假設每個應用的連接池大小是 8 ，超過 2048  個應用就無法再繼續連接了，也就無法繼續擴容了。

注意，由于每個物理庫有很多邏輯庫，再加上微服務運動如火如荼，2048 并沒有看起來那么大。

也許你說，我可以通過前面加一個 Proxy 來解決連接數的問題，實際上，代理的性能也會成為問題，為什么?

代理的連接數也是不能超過 16384 的，如果并發超過 16384，變成 163840，那么 Proxy 也解決不了問題。

怎么辦?讓我們再看看上面的架構圖：

我們發現，問題是出在“每個 RPC 應用都要連所有的庫”，導致擴容應用的同時，每個數據庫連接數就要增加。

就算增加數據庫，也不能解決連接數的問題。那怎么辦呢?

單元化

單元化，聽起來高大上，通常在一些 XXX 大會上，分享“關于兩地三中心”，“三地五中心”，“異地多活”等等牛逼的名詞的時候，單元化也會一起出現。

這里我們不討論那么牛逼的，就只說“數據庫連接數過多” 的問題。實際上，思路很簡單：我們不讓應用連接所有的數據庫就可以了。

假設我們根據 Range 分成了 10 個庫，現在有 10 個應用，我們讓每個應用只連一個庫，當應用增多變成 20 個，數據庫的連接不夠用了，我們就將  10 個庫分成 20 個庫。

這樣，無論你應用擴容到多少個，都可以解決數據庫連接數過多的問題。

注意：做這件事的前提是，你必須保證，訪問你這個應用的 Request 請求的數據庫一定是在這個應用的。

換個說法，當用戶從 DNS 那里進來的時候，就知道自己要去那個應用了，所以，規則在 DNS  之前就定好了，雖然這有點夸張，但肯定在進應用之前就知道要去哪個庫了。

所以，這通常需要一個規則，例如通過用戶 ID Hash，由配置中心廣播 Hash 規則。

這樣，所有的組件都能保持一致的規則，從而正確的訪問到數據庫，如下圖：

感謝各位的閱讀，以上就是“怎么解決數據庫分庫分表無限擴容問題”的內容了，經過本文的學習后，相信大家對怎么解決數據庫分庫分表無限擴容問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！