單點數(shù)據(jù)庫

數(shù)據(jù)庫往往是系統(tǒng)中的性能瓶頸，所以通常在系統(tǒng)設(shè)計中會引入各種各樣的緩存機制，以避免頻繁訪問數(shù)據(jù)庫。另外，數(shù)據(jù)庫由于其重要性，高可用要求也是避免不了的，因為一旦數(shù)據(jù)庫掛了基本上整個系統(tǒng)也就不能使用了。

成都創(chuàng)新互聯(lián)成立10年來，這條路我們正越走越好，積累了技術(shù)與客戶資源，形成了良好的口碑。為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)頁設(shè)計、域名與空間、網(wǎng)絡(luò)營銷、VI設(shè)計、網(wǎng)站改版、漏洞修補等服務(wù)。網(wǎng)站是否美觀、功能強大、用戶體驗好、性價比高、打開快等等，這些對于網(wǎng)站建設(shè)都非常重要，成都創(chuàng)新互聯(lián)通過對建站技術(shù)性的掌握、對創(chuàng)意設(shè)計的研究為客戶提供一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進步。

而以上這些常見問題都是單點數(shù)據(jù)庫帶來的限制，為了解決這些問題，達到高性能、高可用的目的，我們就需要在系統(tǒng)架構(gòu)設(shè)計中采用數(shù)據(jù)庫集群方案。

性能測試

既然單點數(shù)據(jù)庫存在性能問題，那么有沒有實際數(shù)據(jù)呢？下面我們就來對單點數(shù)據(jù)庫進行一個性能測試，看看其并發(fā)極限大概是多少。我這里使用了一臺2核2G的云服務(wù)，mysql版本為8.0.18。

mysql自帶了一個性能測試工具：mysqlslap，我們可以使用該工具進行測試，具體的測試參數(shù)如下：

[root@localhost ~]# mysqlslap -hlocalhost -uroot -pyour_password -P3306 --concurrency=500 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=500

主要參數(shù)說明：

參數(shù)	說明
--concurrency	并發(fā)數(shù)量，即模擬的客戶端數(shù)量
--iterations	執(zhí)行多少次該測試
--auto-generate-sql	使用系統(tǒng)自己生成的SQL腳本來測
--auto-generate-sql-load-type	要測試的是讀還是寫還是兩者混合的（取值：read, write, update, mixed）
--auto-generate-sql-add-autoincrement	將自增的列添加到自動生成的表中
--engine	要測試的存儲引擎
--number-of-queries	每個客戶端的訪問次數(shù)，該數(shù)值除以并發(fā)數(shù)量就是每個客戶端的訪問次數(shù)，在本例中：500 / 500 = 1

• 更多內(nèi)容詳見官方文檔

這里我分別進行了不同量級的測試，在并發(fā)500、1000和5000個連接時，數(shù)據(jù)庫還可以正常處理，沒有太大問題：

# 500個并發(fā)連接
Benchmark
    Running for engine innodb
    Average number of seconds to run all queries: 0.391 seconds
    Minimum number of seconds to run all queries: 0.391 seconds
    Maximum number of seconds to run all queries: 0.391 seconds
    Number of clients running queries: 500
    Average number of queries per client: 1

# 1000個并發(fā)連接
Benchmark
    Running for engine innodb
    Average number of seconds to run all queries: 0.802 seconds
    Minimum number of seconds to run all queries: 0.802 seconds
    Maximum number of seconds to run all queries: 0.802 seconds
    Number of clients running queries: 1000
    Average number of queries per client: 1

# 5000個并發(fā)連接
Benchmark
    Running for engine innodb
    Average number of seconds to run all queries: 3.884 seconds
    Minimum number of seconds to run all queries: 3.884 seconds
    Maximum number of seconds to run all queries: 3.884 seconds
    Number of clients running queries: 5000
    Average number of queries per client: 1

但在測試1w個并發(fā)連接時，數(shù)據(jù)庫就開始報無法連接的錯誤了：

由該測試案例可知，普通的單節(jié)點數(shù)據(jù)庫性能瓶頸大概在1w個并發(fā)連接左右。當然這里的測試結(jié)果與機器的硬件差異有關(guān)，只是提供一個參考。

---

PXC集群方案

上一小節(jié)介紹了單點數(shù)據(jù)庫存在的問題，以及進行了一個簡單的性能測試。為了應(yīng)對這些問題，我們需要將單點數(shù)據(jù)庫向集群轉(zhuǎn)變。

目前存在許多的數(shù)據(jù)庫集群方案，而這些方案中也沒有哪個好那個壞，只有適合的才是好的。本小節(jié)則介紹一下主流的方案之一：PXC集群方案，其架構(gòu)圖大致如下：

• PXC集群大的特點就是數(shù)據(jù)讀寫的強一致性，在圖中的任意一個節(jié)點寫入數(shù)據(jù)，其他的節(jié)點就一定能讀到這個數(shù)據(jù)。不會出現(xiàn)A節(jié)點成功寫入，而讀B節(jié)點時讀取不到數(shù)據(jù)。該特性使得PXC集群適合存儲高價值重要數(shù)據(jù)，因為類似于訂單、錢有關(guān)的數(shù)據(jù)基本都有強一致性的要求

上圖只是PXC集群最基礎(chǔ)的架構(gòu)，所以還有優(yōu)化的余地。我們都知道m(xù)ysql的單表數(shù)據(jù)處理的性能極限在2千萬左右，當數(shù)據(jù)達到這個量級時，mysql的處理性能就會很低下了。而上圖中每個PXC節(jié)點都會進行數(shù)據(jù)的同步，所以當每個節(jié)點的數(shù)據(jù)量級都達到2千萬時，整個集群的性能就會降低。

這時就需要增加多一個集群，并且這兩個集群之間的數(shù)據(jù)是不進行同步的。為了讓不同的集群存儲不同的數(shù)據(jù)，就得引入Mycat這種數(shù)據(jù)庫中間件將數(shù)據(jù)進行切分，讓數(shù)據(jù)可以在不同的集群上進行讀寫，分散存儲壓力。在這個場景下，一個集群稱為一個數(shù)據(jù)分片。如圖：

PXC集群工作原理

我們知道數(shù)據(jù)庫數(shù)據(jù)的一致性和持久性是通過事務(wù)來保證的，而PXC集群的強一致性也是采用了事務(wù)，只不過這個事務(wù)是分布式事務(wù)。

客戶端在寫入數(shù)據(jù)完成后，同樣需要提交一個事務(wù)，在事務(wù)內(nèi)節(jié)點之間會進行數(shù)據(jù)的同步復(fù)制。該事務(wù)會作用到集群內(nèi)的所有節(jié)點上，保證所有節(jié)點要么全寫入成功，要么全寫入失敗。這里用一個時序圖表達一下大致流程：

搭建PXC集群需要注意的事項：

• PXC集群中的節(jié)點并不是越多越好，節(jié)點多并不能提高性能。相反，節(jié)點多意味著同步數(shù)據(jù)所需的耗時就越多，反而會降低性能。通常來講，一個PXC集群最好是不超過15個節(jié)點。若需要更多的節(jié)點時，應(yīng)當搭建一個新的集群，然后用中間件來做分片。
• PXC集群的性能不取決于配置最好的那個節(jié)點，而是取決于配置最差的那個節(jié)點，這和電腦硬件是類似的。所以我們應(yīng)當盡量保證PXC集群內(nèi)的節(jié)點配置都趨于一致，避免某個節(jié)點配置太差而拖慢了集群的整體性能。

PXC簡介

說了那么多，我們還沒介紹PXC是個啥玩意呢。PXC是Percona XtraDB Cluster的縮寫，PXC是基于mysql自帶的Galera集群技術(shù)，將不同的mysql實例連接起來，實現(xiàn)的多主集群。在PXC集群中每個mysql節(jié)點都是可讀可寫的，也就是主從概念中的主節(jié)點，不存在只讀的節(jié)點。

PXC可以集群任何mysql的衍生版本，例如MariaDB和Percona Server。由于Percona Server的性能最接近于mysql企業(yè)版，性能相對于標準版的mysql有顯著的提升，并且對mysql基本兼容。所以在搭建PXC集群時，通常建議基于Percona Server進行搭建。

---

Replication集群方案

PXC集群的數(shù)據(jù)強一致性是以犧牲性能為代價的，因為客戶端需要等待所有的節(jié)點寫入數(shù)據(jù)。而與之相反的一種集群方案就是本小節(jié)要介紹的Replication集群。該方案不犧牲性能，但不具有數(shù)據(jù)強一致性，正可謂魚和熊掌不可兼得。

所謂讀寫非強一致的意思就是在A節(jié)點成功寫入數(shù)據(jù)，并提交了事務(wù)。但在B節(jié)點上進行讀取時，可能會讀取不到寫入的數(shù)據(jù)。

因為這里提交的事務(wù)只是該節(jié)點的本地事務(wù)，只能保證數(shù)據(jù)成功寫入了該節(jié)點，而不保證數(shù)據(jù)成功寫入整個集群內(nèi)的節(jié)點。當該節(jié)點與其他節(jié)點進行數(shù)據(jù)同步時，可能會由于種種原因沒有成功同步數(shù)據(jù)，從而導(dǎo)致在其他節(jié)點上讀不到該數(shù)據(jù)。

所以該集群方案就不適合保存高價值的數(shù)據(jù)，但對于非高價值的數(shù)據(jù)，又對讀寫性能要求高的，就適合采用該集群方案。例如，用戶行為日志、操作日志及商品描述等這類非重要的數(shù)據(jù)。

同樣的，上圖只是Replication集群最基礎(chǔ)的架構(gòu)，也需要在數(shù)據(jù)量達到一定規(guī)模時采用Mycat對數(shù)據(jù)進行分片處理。如圖：

實際上，在大型的系統(tǒng)架構(gòu)中，往往不是單獨采用某一種特定的集群方案，而是多種方案進行結(jié)合。例如，PXC集群和Replication集群就可以結(jié)合使用，讓PXC集群存儲高價值數(shù)據(jù)，Replication集群存儲低價值數(shù)據(jù)。然后采用Mycat等數(shù)據(jù)庫中間件來完成集群之間的數(shù)據(jù)分片及管理，如圖：

---

總結(jié)

• PXC集群采用同步復(fù)制，事務(wù)在所有的集群節(jié)點要么同時提交，要么不提交，能夠保證集群中的數(shù)據(jù)強一致性。但性能相對較低，客戶端需等待所有節(jié)點同步復(fù)制完成
• Replication集群采用異步復(fù)制，無法保證數(shù)據(jù)的強一致性。性能相對較高，客戶端只需要等待目標節(jié)點的本地事務(wù)提交成功即可，而不需要等待所有節(jié)點成功復(fù)制完數(shù)據(jù)
• PXC和Replication集群都只實現(xiàn)了數(shù)據(jù)的同步，沒有數(shù)據(jù)切分功能。當數(shù)據(jù)量大時，需要引入Mycat等數(shù)據(jù)庫中間件來做數(shù)據(jù)的切分及管理
• PXC和Replication集群方案并不排他，且各有優(yōu)劣，可以結(jié)合一起使用，以達到取長補短的效果。高價值數(shù)據(jù)存儲至PXC集群，低價值數(shù)據(jù)存儲至Replication集群

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)站標題：淺談數(shù)據(jù)庫集群方案-創(chuàng)新互聯(lián)
本文路徑：http://www.rwnh.cn/article18/gdhgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、動態(tài)網(wǎng)站、網(wǎng)站排名、自適應(yīng)網(wǎng)站、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)