單點(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ù)說明：

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

這里我分別進(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集群