單點(diǎn)數(shù)據(jù)庫(kù)
數(shù)據(jù)庫(kù)往往是系統(tǒng)中的性能瓶頸筷弦，所以通常在系統(tǒng)設(shè)計(jì)中會(huì)引入各種各樣的緩存機(jī)制肋演，以避免頻繁訪問(wèn)數(shù)據(jù)庫(kù)。另外奸笤，數(shù)據(jù)庫(kù)由于其重要性惋啃，高可用要求也是避免不了的，因?yàn)橐坏?shù)據(jù)庫(kù)掛了基本上整個(gè)系統(tǒng)也就不能使用了监右。
而以上這些常見問(wèn)題都是單點(diǎn)數(shù)據(jù)庫(kù)帶來(lái)的限制边灭，為了解決這些問(wèn)題，達(dá)到高性能健盒、高可用的目的绒瘦，我們就需要在系統(tǒng)架構(gòu)設(shè)計(jì)中采用數(shù)據(jù)庫(kù)集群方案称簿。
性能測(cè)試
既然單點(diǎn)數(shù)據(jù)庫(kù)存在性能問(wèn)題，那么有沒有實(shí)際數(shù)據(jù)呢惰帽？下面我們就來(lái)對(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ù)說(shuō)明：
| 參數(shù) | 說(shuō)明 |
|---|---|
--concurrency |
并發(fā)數(shù)量悔叽，即模擬的客戶端數(shù)量 |
--iterations |
執(zhí)行多少次該測(cè)試 |
--auto-generate-sql |
使用系統(tǒng)自己生成的SQL腳本來(lái)測(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è)客戶端的訪問(wèn)次數(shù)，該數(shù)值除以并發(fā)數(shù)量就是每個(gè)客戶端的訪問(wèn)次數(shù)爵嗅，在本例中：500 / 500 = 1
|
- 更多內(nèi)容詳見官方文檔
這里我分別進(jìn)行了不同量級(jí)的測(cè)試娇澎，在并發(fā)500、1000和5000個(gè)連接時(shí)睹晒，數(shù)據(jù)庫(kù)還可以正常處理趟庄，沒有太大問(wèn)題：
# 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ù)存在的問(wèn)題虑鼎，以及進(jìn)行了一個(gè)簡(jiǎn)單的性能測(cè)試。為了應(yīng)對(duì)這些問(wèn)題键痛，我們需要將單點(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)轭愃朴谟唵谓贝拧㈠X有關(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ù)的一致性和持久性是通過(guò)事務(wù)來(lái)保證的，而PXC集群的強(qiáng)一致性也是采用了事務(wù)莉恼，只不過(guò)這個(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ì)降低性能踊餐。通常來(lái)講景醇，一個(gè)PXC集群最好是不超過(guò)15個(gè)節(jié)點(diǎn)。若需要更多的節(jié)點(diǎn)時(shí)吝岭，應(yīng)當(dāng)搭建一個(gè)新的集群三痰，然后用中間件來(lái)做分片。
- 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)介
說(shuō)了那么多，我們還沒介紹PXC是個(gè)啥玩意呢蜓肆。PXC是Percona XtraDB Cluster的縮寫颜凯，PXC是基于mysql自帶的Galera集群技術(shù)谋币，將不同的mysql實(shí)例連接起來(lái)，實(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ù)中間件來(lái)完成集群之間的數(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ù)中間件來(lái)做數(shù)據(jù)的切分及管理
- PXC和Replication集群方案并不排他越除，且各有優(yōu)劣，可以結(jié)合一起使用外盯，以達(dá)到取長(zhǎng)補(bǔ)短的效果摘盆。高價(jià)值數(shù)據(jù)存儲(chǔ)至PXC集群，低價(jià)值數(shù)據(jù)存儲(chǔ)至Replication集群
