單點(diǎn)數(shù)據(jù)庫(kù)

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

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

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

性能測(cè)試

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

mysql自帶了一個(gè)性能測(cè)試工具：mysqlslap，我們可以使用該工具進(jìn)行測(cè)試，具體的測(cè)試參數(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í)行多少次該測(cè)試
--auto-generate-sql	使用系統(tǒng)自己生成的SQL腳本來測(cè)
--auto-generate-sql-load-type	要測(cè)試的是讀還是寫還是兩者混合的（取值：read, write, update, mixed）
--auto-generate-sql-add-autoincrement	將自增的列添加到自動(dòng)生成的表中
--engine	要測(cè)試的存儲(chǔ)引擎
--number-of-queries	每個(gè)客戶端的訪問次數(shù)，該數(shù)值除以并發(fā)數(shù)量就是每個(gè)客戶端的訪問次數(shù)，在本例中：500 / 500 = 1

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

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

# 500個(gè)并發(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個(gè)并發(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個(gè)并發(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

但在測(cè)試1w個(gè)并發(fā)連接時(shí)，數(shù)據(jù)庫(kù)就開始報(bào)無(wú)法連接的錯(cuò)誤了：

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

---

PXC集群方案

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

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

• PXC集群大的特點(diǎn)就是數(shù)據(jù)讀寫的強(qiáng)一致性，在圖中的任意一個(gè)節(jié)點(diǎn)寫入數(shù)據(jù)，其他的節(jié)點(diǎn)就一定能讀到這個(gè)數(shù)據(jù)。不會(huì)出現(xiàn)A節(jié)點(diǎn)成功寫入，而讀B節(jié)點(diǎn)時(shí)讀取不到數(shù)據(jù)。該特性使得PXC集群適合存儲(chǔ)高價(jià)值重要數(shù)據(jù)，因?yàn)轭愃朴谟唵?、錢有關(guān)的數(shù)據(jù)基本都有強(qiáng)一致性的要求

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

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

PXC集群工作原理

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

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

搭建PXC集群需要注意的事項(xiàng)：

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

PXC簡(jiǎn)介

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

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

---

Replication集群方案

PXC集群的數(shù)據(jù)強(qiáng)一致性是以犧牲性能為代價(jià)的，因?yàn)榭蛻舳诵枰却械墓?jié)點(diǎn)寫入數(shù)據(jù)。而與之相反的一種集群方案就是本小節(jié)要介紹的Replication集群。該方案不犧牲性能，但不具有數(shù)據(jù)強(qiáng)一致性，正可謂魚和熊掌不可兼得。

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

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

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

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

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

---

總結(jié)

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

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

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

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

廣告

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