淺談數(shù)據(jù)庫集群方案

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

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

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

性能測試

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

mysql自帶了一個性能測試工具:mysqlslap,我們可以使用該工具進(jìn)行測試,具體的測試參數(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

這里我分別進(jìn)行了不同量級的測試,在并發(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ù)庫就開始報無法連接的錯誤了:


image.png

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


PXC集群方案

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

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


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

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

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


image.png

PXC集群工作原理

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

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


image.png

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

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

PXC簡介

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


image.png

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


Replication集群方案

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


image.png

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

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

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

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


image.png

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


image.png

總結(jié)

  • PXC集群采用同步復(fù)制,事務(wù)在所有的集群節(jié)點(diǎn)要么同時提交,要么不提交,能夠保證集群中的數(shù)據(jù)強(qiáng)一致性。但性能相對較低,客戶端需等待所有節(jié)點(diǎn)同步復(fù)制完成
  • Replication集群采用異步復(fù)制,無法保證數(shù)據(jù)的強(qiáng)一致性。性能相對較高,客戶端只需要等待目標(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ù)量大時,需要引入Mycat等數(shù)據(jù)庫中間件來做數(shù)據(jù)的切分及管理
  • PXC和Replication集群方案并不排他,且各有優(yōu)劣,可以結(jié)合一起使用,以達(dá)到取長補(bǔ)短的效果。高價值數(shù)據(jù)存儲至PXC集群,低價值數(shù)據(jù)存儲至Replication集群
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容