雜談---資料庫連線中的藝術

隨著問問題的同學越來越多，公眾號內部私信回答問題已經很困難了，所以建立了一個群，關於各種資料庫的問題都可以，目前主要是 POSTGRESQL, MYSQL ,MONGODB ,POLARDB ,REDIS 等，期待你的加入，加群請新增微信liuaustin3. 群裡有各種資料庫的服務商，和大佬。

最近很忙沒有時間，但年前的一個群裡的問題，引發了我寫這個帖子的想法，現在閒下來了，可以來捋一捋這個問題。因為是雜談，所以想到哪裡寫哪裡，可能沒有一定的條理性。

一般連線數的這個問題到底應該由誰來負責的這個問題，是應該被注重的，到底應該是誰，這裡有以下的一些選擇

1  應用程式的架構方給定一定的標準

2  應用程式中懂得業務邏輯的程式部分給出大致的資料設定的想法

3  資料庫方給出資料庫在不同的配置下可以給出的一個設定的範圍

以上的這些資料設定兩個部分

1 最大連線數

2  瞬時最大可以承受的併發連線數

3  在業務低峰期可以保留的長時間與資料庫的保留連線數

為什麼要這樣來組織連線數的設定主要考慮有三個部分

1  業務架構有必要和能力來給出業務架構中的每個模組的在程式部分的理論的連線數需求，透過連線數需求來引導整體架構的設計，而不是應用架構設計完畢，在來討論連線數，那麼這樣壓力就直接傳導到 資料庫，變成一個風險和忍受的問題。

2  業務邏輯方必須瞭解你的應用需求的問題，你的應用在設計之初的業務需求特性是什麼是短時間高強度的連線方式，還是綿延不絕的資料庫連線方式，是OLTP 多 還是OLAP 多的資料庫使用屬性，這些都要進行規整和規劃。

3  資料庫硬體和資料庫本身來規劃資料庫連線數的問題，到了這個維度的情況下，實際上已經是下下之策了，因為資料庫只能是承受方，能做的工作不多，所以到這個維度的時候，就離出問題不遠了。

但即使這樣搞，一個連線數調整和設定的關鍵還未深入觸及，我們要討論的連線數實際上有兩個部分 1  理論連線數   2  實際連線數

理論連線數這個部分來自於資料庫廠商的一些對於資料庫方法的理論來給出一個資料庫硬體本身可以接受的連線數。基本主要圍繞了三個部分，

1  CPU 核心數

2  記憶體的大小

3  磁碟IOPS 的快慢

這三者之間的關係也分別為，CPU 的核心數，大家都瞭解核心數對於並行執行任務的重要性，CPU主要可以支援很多的任務的部分的主要關鍵在於任務的佔用CPU的時長和CPU 本身的核心數對應任務之間的對比。

我們引入這樣一個公式來計算你的應用系統在資料庫層面大概需要的CPU 核心數

併發任務數 * 任務的執行時間係數（必須大於1） = 你在瞬時需要的CPU核心數

舉例你的併發任務是在同一秒為5個任務，而每個任務執行的時間在1.5秒，那麼你的係數可以確認在1.5左右

5 * 1.5 = 7.5 個CPU ，我們可以等同於 8 個CPU ，可以滿足你的任務的需求，但實際上這裡有一個無法避免的問題，在於係數的確認，實際上這是一個非常困難的任務，係數針對與你在資料庫中執行的多個任務，那麼怎麼確定這個係數。

係數的確定

係數的確定實際上是一個非常困難的工作，但是否可以做到，答案是肯定的，那麼我們需要什麼資源來確認這個係數，測試，業務測試可以確認這個系統，尤其是壓力方面的業務測試。在測試中，我們找到一個硬體配置下，這個系統最大的併發的拋物線的定點，此時這時的併發數和CPU的數，就變成了我們可以確認的資訊。如

併發任務 16個 /  8核心CPU = 2  則經過壓測後，我們這個業務的係數就可以定製為2

那麼最終我們在這個業務中的資料庫產品可以透過硬體的CPU 來標定大概的業務併發支援

8 *  2 = 16 

16 * 2 = 32

以此類推。

那麼這樣來確認CPU 與併發連線數的關係合理嗎。實際上也不合理，我們忘記了另一個核心的硬體部分 記憶體。

記憶體部分如何進行標定，連線記憶體與連線數的設定，如我們的POSTGRESQL 部分，我們的work_mem是我們需要注意的連線記憶體，在我們設定了大量的 shared_buffer後，我們剩餘的記憶體的一部分多少，作為我們的連線記憶體。

這也是一個決定連線數的，或者說最大連線數的部分的設定。如我們的記憶體為32G .postgresql 在  shared buffer中的設定為 8G 則給我們剩餘的記憶體為

32 - 8 - 2 -16 -2 = 4G，那麼我們具體可以使用的連線的記憶體有 6G ，按照我們的work_mem =16MB 來計算我們可以最大支援的連線數為250個。

透過這樣的方式我們可以很簡單的邏輯推算出，實際中我們可以使用的最大連線數。（上述公式中 8 為shared buffer , 2 為系統預留，16為 file cache ,2 為 maintance meory）

所以一個決定MAX connections  記憶體最大的部分在於你的 work_mem 設計的大小，而這個大小有關於你所在的業務的部分的對於語句和事務的定義。

所以我們的最大的MAX_CONNECTION 的公式可以定義為

剩餘的記憶體 /  連線記憶體初始設定 = 最大連線數 *(1-壓測後的係數) = 最終最大連線數

那麼這個部分的係數是比較難獲得，主要是要觀察你的資料庫系統下壓測中是否有大量的連線，在本地進行資料的緩衝，那麼可以這樣在資料庫壓測中根據壓測的時間長度和存在的資料庫的連線中，出現使用磁碟作為緩衝的查詢數之比，作為這個係數。

舉例我們在1000個查詢中，發現有50個出現了使用本地磁碟方式進行資料處理的連線則上面的練習為

4G /16MB = 250 *  (1 - 0.05) = 250 * 0.95  = 237 個最大的連線

當然這裡面看上去這些數值的設計和獲取有些矯情，但對於一個正規的，可以標準化的大型企業，這些有是必須的，而不是可有可無的。

磁碟本身，實際上可以根據你在壓測中的磁碟的不同匹配來獲得另一個係數，並可以附加到上面的 最大連線數 和 最大併發數的設計中。

但是實際上，一個資料庫可以承受的最大連線數和併發數，是很難非常標準化的，我們舉一些列子來證明

1 某公司的應用產品，需要部署到資料庫上，但是此資料庫已經是很多應豔紅程式的資料庫，其中資料庫中包含了大量不同的應用產品，OLAP OLTP 均有，所以以上的公式，在這樣的節約成本的企業基本上是無效的。

給我們的現實的部分，只有等到這個資料庫本身無法進行運作了，發生問題了才會進入正題，進行應用的分庫的操作。

2  某公司應用程式，在資料庫上一直進行擴充套件，並且資料庫已經成為系統的瓶頸了，但是業務一直不進行架構的整改，拆分，在這樣的情況下，資料庫報警成為常態，最終無人關心報警，最終資料庫DOWN機，導致重大生產事故。

上面這樣的例子我還能舉出很多，一個好的資料庫所需要的不光是一個好的資料庫管理員，而是一個好的架構師，一個靠譜的業務邏輯規劃和程式設計師，綜合的進行規劃和業務上線前的大量的測試工作，而截至到目前那些公司可以做到這點。

所以一個公式或者標準或理論連線數，最大連線數帶給了我們什麼，是一個看上去很美的空殼，還是一個我們可以實際上可以操作的標準。