<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          分庫分表就能無限擴容嗎?

          共 2178字,需瀏覽 5分鐘

           ·

          2021-04-18 23:55

          程序員的成長之路
          互聯(lián)網/程序員/技術/資料共享 
          關注


          閱讀本文大概需要 4 分鐘。

          來自:thinkinjava.cn/2019/01/fkfb/

          前言

          像我這樣的菜鳥,總會有各種疑問,剛開始是對 JDK API 的疑問,對 NIO 的疑問,對 JVM 的疑問,當工作幾年后,對服務的可用性,可擴展性也有了新的疑問,什么疑問呢?其實是老生常談的話題:服務的擴容問題。

          正常情況下的服務演化之路


          讓我們從最初開始。

          • 單體應用 每個創(chuàng)業(yè)公司基本都是從類似 SSM 和 SSH 這種架構起來的,沒什么好講的,基本每個程序員都經歷過。


          • RPC 應用 當業(yè)務越來越大,我們需要對服務進行水平擴容,擴容很簡單,只要保證服務是無狀態(tài)的就可以了,如下圖:

          當業(yè)務又越來越大,我們的服務關系錯綜復雜,同時,有很多服務訪問都是不需要連接 DB 的,只需要連接緩存即可,那么就可以做成分離的,減少 DB 寶貴的連接。如下圖:
          我相信大部分公司都是在這個階段。Dubbo 就是為了解決這個問題而生的。

          如果你的公司產品很受歡迎,業(yè)務繼續(xù)高速發(fā)展,數(shù)據(jù)越來越多,SQL 操作越來越慢,那么數(shù)據(jù)庫就會成為瓶頸,那么你肯定會想到分庫分表,不論通過 ID hash 或者 range 的方式都可以。如下圖:
          這下應該沒問題了吧。任憑你用戶再多,并發(fā)再高,我只要無限擴容數(shù)據(jù)庫,無限擴容應用,就可以了。

          這也是本文的標題,分庫分表就能解決無限擴容嗎?

          實際上,像上面的架構,并不能解決。

          其實,這個問題和 RPC 的問題有點類似:數(shù)據(jù)庫連接過多!!!

          通常,我們的 RPC 應用由于是使用中間件進行訪問數(shù)據(jù)庫,應用實際上是不知道到底要訪問哪個數(shù)據(jù)庫的,訪問數(shù)據(jù)庫的規(guī)則由中間件決定,例如 sharding JDBC。這就導致,這個應用必須和所有的數(shù)據(jù)庫連接,就像我們上面的架構圖一樣,一個 RPC 應用需要和 3 個 mysql 連接,如果是 30 個 RPC 應用,每個 RPC 的數(shù)據(jù)庫連接池大小是8 ,每個 mysql 需要維護 240 個連接,我們知道,mysql 默認連接數(shù)是 100,最大連接數(shù)是 16384,也就是說,假設每個應用的連接池大小是 8 ,超過 2048 個應用就無法再繼續(xù)連接了,也就無法繼續(xù)擴容了。

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

          也許你說,我可以通過前面加一個 proxy 來解決連接數(shù)的問題,實際上,代理的性能也會成為問題,為什么?代理的連接數(shù)也是不能超過 16384 的,如果并發(fā)超過 16384,變成 163840,那么 proxy 也解決不了問題。

          怎么辦?讓我們再看看上面的架構圖:
          我們發(fā)現(xiàn),問題是出在“每個 RPC 應用都要連所有的庫”,導致擴容應用的同時,每個數(shù)據(jù)庫連接數(shù)就要增加。就算增加數(shù)據(jù)庫,也不能解決連接數(shù)的問題。

          那怎么辦呢?

          單元化


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

          這里我們不討論那么牛逼的,就只說“數(shù)據(jù)庫連接數(shù)過多” 的問題。

          實際上,思路很簡單:我們不讓應用連接所有的數(shù)據(jù)庫就可以了。

          假設我們根據(jù) range 分成了 10 個庫,現(xiàn)在有 10 個應用,我們讓每個應用只連一個庫,當應用增多變成 20個,數(shù)據(jù)庫的連接不夠用了,我們就將 10 個庫分成 20 個庫,這樣,無論你應用擴容到多少個,都可以解決數(shù)據(jù)庫連接數(shù)過多的問題。

          注意:做這件事的前提是:你必須保證,訪問你這個應用的 request 請求的數(shù)據(jù)庫一定是在這個應用的。

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

          所以,這通常需要一個規(guī)則,例如通過用戶 ID hash,由配置中心廣播 hash 規(guī)則。這樣,所有的組件都能保持一致的規(guī)則,從而正確的訪問到數(shù)據(jù)庫。如下圖:
          到這里,我們終于解決了無限擴容的問題。

          最后


          本文從單體應用開始,逐步講述了一個正常后臺的演進歷程,知道了分庫分表并不能解決“無限擴容” 的問題,只有單元化才能解決這問題。而單元化則帶來更多的復雜性。但是好處不言而喻。

          單元化帶來的更多的思路。

          有了單元化,解決了無限擴容的問題,但是我們還沒有考慮單點的問題,即服務的可用性。要知道,我們這里的數(shù)據(jù)庫都是單點的。

          <END>

          推薦閱讀:

          IntelliJ IDEA 2021.1正式發(fā)布!快來看看又有哪些神仙功能加入!

          SpringBoot 注解原理,自動裝配原理,圖文并茂,萬字長文!

          最近面試BAT,整理一份面試資料《Java面試BATJ通關手冊》,覆蓋了Java核心技術、JVM、Java并發(fā)、SSM、微服務、數(shù)據(jù)庫、數(shù)據(jù)結構等等。

          獲取方式:點個「在看」,點擊上方小卡片,進入公眾號后回復「面試題」領取,更多內容陸續(xù)奉上。

          朕已閱 

          瀏覽 49
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  免费一级a毛一级a看免费视频下载 | 黄色动漫成人视频在线观看 | 久久无码成人电影 | 久久精品噜噜噜成人88Aⅴ | 在线a视频免费观看 |