在高吞吐下，總存儲(chǔ)集群整體RT表現(xiàn)平穩(wěn)，與離線資源聯(lián)合***發(fā)力，最終***完成2017年“11.11”大促10%的交易支撐；

并為明年全面擁抱計(jì)算存儲(chǔ)分離與大規(guī)模離在線混布，打下堅(jiān)實(shí)的基礎(chǔ)。

二、計(jì)算存儲(chǔ)分離

在所有業(yè)務(wù)中，數(shù)據(jù)庫(kù)的計(jì)算存儲(chǔ)分離最難，這是大家公認(rèn)的。因?yàn)閿?shù)據(jù)庫(kù)對(duì)于存儲(chǔ)的穩(wěn)定性以及單路端到端的時(shí)延有著***的要求：

 1.   存儲(chǔ)穩(wěn)定性

在分布式存儲(chǔ)的穩(wěn)定性方面，我們做了非常多的有意探索，并且逐一落地。這些新技術(shù)的落地，使得數(shù)據(jù)庫(kù)計(jì)算存儲(chǔ)分離成為可能：

• 單機(jī)failover

單機(jī)failover我們做到業(yè)界的***，5s內(nèi)完成fo，對(duì)整體集群的影響在4%以內(nèi)（以集群規(guī)模24臺(tái)為例，集群機(jī)器越多，影響越?。Ａ硗?，我們對(duì)分布式存儲(chǔ)的狀態(tài)機(jī)進(jìn)行加速優(yōu)化，使得基于paxos的選舉在秒級(jí)內(nèi)進(jìn)行集群視圖更新推送。

• 長(zhǎng)尾時(shí)延優(yōu)化

計(jì)算存儲(chǔ)分離后，所有的IO都變成了網(wǎng)絡(luò)IO，因此對(duì)于單路IO時(shí)延影響的因素非常多，如網(wǎng)絡(luò)抖動(dòng)，慢盤，負(fù)載等，而這些因素也是不可避免的。我們?cè)O(shè)計(jì)了“副本達(dá)成多數(shù)寫入即返回的策略（commit majority feature）”，能夠有效地使長(zhǎng)尾時(shí)延抖動(dòng)做到合理的控制，以滿足業(yè)務(wù)的需求。

以下是commit majority feature開起前后的效果對(duì)比。其中“藍(lán)色”為優(yōu)化后的長(zhǎng)尾時(shí)延，“紅色”為優(yōu)化前長(zhǎng)尾時(shí)延，效果非常顯著。

• 流控

我們實(shí)現(xiàn)了基于滑動(dòng)窗口的流控功能，使得集群后臺(tái)活動(dòng)（如backfill和recovery）能根據(jù)當(dāng)前的業(yè)務(wù)流量進(jìn)行自適配的調(diào)整，在業(yè)務(wù)與后臺(tái)數(shù)據(jù)恢復(fù)之間做到***平衡。

一般如果集群后端活動(dòng)太低，會(huì)影響數(shù)據(jù)恢復(fù)，這會(huì)提高多盤故障的概率，降低了數(shù)據(jù)的可靠性。我們經(jīng)過優(yōu)化后，通過滑動(dòng)窗口機(jī)制，做到了前后端數(shù)據(jù)寫入的速動(dòng)，在不影響業(yè)務(wù)寫入的情況下，盡***可能提高數(shù)據(jù)恢復(fù)速度，保證多副本數(shù)據(jù)的完整性。

提高數(shù)據(jù)重平衡的速度，也是為了保證整個(gè)集群的性能。因?yàn)橐怀霈F(xiàn)數(shù)據(jù)傾斜時(shí)，部分盤的負(fù)載將變大，從而會(huì)影響整個(gè)集群的時(shí)延和吞吐。

流控效果如下： 

• 高可用部署

在高可用部署上，我們引入的故障域的概念。多個(gè)數(shù)據(jù)副本存儲(chǔ)在多個(gè)故障域，分布到至少4個(gè)RACK以上的機(jī)架上，用于保障底層機(jī)柜電源以及網(wǎng)絡(luò)交換設(shè)備引起的故障等。

為了能夠更好的理解數(shù)據(jù)副本存儲(chǔ)位置（data locality），需要知道數(shù)據(jù)散射度（scatter width）的概念。怎么來理解數(shù)據(jù)散射度？

舉個(gè)例子：我們定義三個(gè)copy set（存放的都是不同的數(shù)據(jù)）:{1，2，3}，{4，5，6}，{7，8，9}。任意一組copy set中存放的數(shù)據(jù)沒有重復(fù)，也就是說一份數(shù)據(jù)的三個(gè)副本分別放置在：{1，4，7}或者{2，5，8}或者{3，6，9}。那么這個(gè)時(shí)候，其數(shù)據(jù)散射度遠(yuǎn)小于隨機(jī)組合的C(9,3)。

隨機(jī)組合時(shí)，任意3臺(tái)機(jī)器Down機(jī)都會(huì)存在數(shù)據(jù)丟失。而采用此方案后，只有當(dāng){1，4，7}或者{2，5，8}或者{3，6，9}其中的任意一個(gè)組合不可用時(shí)，才會(huì)影響高可用性，才會(huì)有數(shù)據(jù)丟失。

綜上可知，我們引入copy set的目標(biāo)就是盡量的降低數(shù)據(jù)散射度“S“。下圖中兩組replica set，其中每一組的三個(gè)副本分別放置到不同的RACK中。

我們的優(yōu)化還有很多，這里不再一一列舉。

 2.    數(shù)據(jù)庫(kù)吞吐優(yōu)化

當(dāng)所有的IO都變成網(wǎng)絡(luò)IO后，我們要做的就是如何減少單路IO的延遲，當(dāng)然這個(gè)是分布式存儲(chǔ)以及網(wǎng)絡(luò)要解的問題。

分布式存儲(chǔ)需要優(yōu)化自身的軟件stack以及底層SPDK的結(jié)合等。

而網(wǎng)絡(luò)層則需要更高帶寬以及低時(shí)延技術(shù)，如25G TCP或者25G RDMA，或者100G等更高帶寬的網(wǎng)絡(luò)等。

但是我們可以從另外一個(gè)角度來考慮問題，如何在時(shí)延一定的情況下，提高并發(fā)量，從而來提高吞吐。或者說在關(guān)鍵路徑上減少IO調(diào)用的次數(shù)，從而從某種程度上提高系統(tǒng)的吞吐。

大家知道，影響數(shù)據(jù)庫(kù)事務(wù)數(shù)的最關(guān)鍵因素就是事務(wù)commit的速度，commit的速度依賴于寫REDO時(shí)的IO吞吐。所謂的REDO也就是大家熟知的WAL(Write Ahead Log)日志。

在臟數(shù)據(jù)flush回存儲(chǔ)時(shí)，日志必須先落地，這是因?yàn)閿?shù)據(jù)庫(kù)的Crash Recovery是重度以來于此的。在recovery階段，數(shù)據(jù)庫(kù)先利用redo進(jìn)行roll forward；再利用undo進(jìn)行roll backward，***再撤銷用戶未提交的事務(wù)。

因此，存儲(chǔ)計(jì)算分離下，要想在單路IO時(shí)延一定時(shí)提高吞吐，就必須要優(yōu)化commit提交時(shí)的效率。我們通過優(yōu)化redo的寫入方式，讓整個(gè)提高吞吐100%左右，效果如下： 

另外，也可以優(yōu)化redo group commit的大小，結(jié)合底層存儲(chǔ)stripe能力，做并發(fā)與吞吐優(yōu)化。

備注：”D13”是一種已經(jīng)做過raid的SATASSD

 3.    數(shù)據(jù)庫(kù)原子寫

在數(shù)據(jù)庫(kù)內(nèi)存模型中，數(shù)據(jù)頁(yè)通常是以16K做為一個(gè)bufferpage來管理的。當(dāng)內(nèi)核修改完數(shù)據(jù)之后，會(huì)有專門的“checkpoint”線程按一定的頻率將Dirty Page flush到磁盤上。我們知道，通常os的page cache是4K，而一般的文件系統(tǒng)block size也是4K。所以一個(gè)16k和page會(huì)被分成4個(gè)4k的os filesystem block size來存儲(chǔ)，物理上不能保證連續(xù)性。

那么會(huì)帶來一個(gè)嚴(yán)重的問題，就是當(dāng)fsync語(yǔ)義發(fā)出時(shí)，一個(gè)16k的pageflush，只完成其中的8k，而這個(gè)時(shí)候client端crash，不再會(huì)有重試；那么整個(gè)fsync就只寫了一半，fsync語(yǔ)義被破壞，數(shù)據(jù)不完整。上面的這個(gè)場(chǎng)景，我們稱之為“partial write”。

對(duì)于MySQL而言，在本地存儲(chǔ)時(shí)，使用Double Write Buffer問題不大。但是如果底層變成網(wǎng)絡(luò)IO，IO時(shí)延變高時(shí)，會(huì)使MySQL的整體吞吐下降，而Double Write Buffer會(huì)加重這個(gè)影響。

我們實(shí)現(xiàn)了原子寫，關(guān)閉掉Double Write Buffer，從而在高并發(fā)壓力及高網(wǎng)絡(luò)IO時(shí)延下，讓吞吐至少提高50%以上。

4.    網(wǎng)絡(luò)架構(gòu)升級(jí)

分布式存儲(chǔ)，對(duì)于網(wǎng)絡(luò)的帶寬要求極高，我們引入了25G網(wǎng)絡(luò)。高帶寬能更好的支持阿里集團(tuán)的大促業(yè)務(wù)。另外，對(duì)于存儲(chǔ)集群后臺(tái)的活動(dòng)，如數(shù)據(jù)重平衡以及恢復(fù)都提供了有力的保障。 

三、離在線混布

計(jì)算存儲(chǔ)分離后，離在線混布成為可能；今年完成數(shù)據(jù)庫(kù)離在線混布，為2017年大促節(jié)省了計(jì)算資源成本。

在與離線混布的方案中，我們對(duì)數(shù)據(jù)庫(kù)與離線任務(wù)混跑的場(chǎng)景進(jìn)行了大量的測(cè)試。

實(shí)踐證明，數(shù)據(jù)庫(kù)對(duì)時(shí)延極度敏感，所以為了達(dá)到數(shù)據(jù)庫(kù)混布的目的，我們采用了以下的隔離方案： 

• CPU與內(nèi)存隔離技術(shù)

CPU的L3是被各個(gè)核共享的，如果在一個(gè)socket內(nèi)部進(jìn)行調(diào)度，會(huì)對(duì)數(shù)據(jù)庫(kù)業(yè)務(wù)有抖動(dòng)。因此，在大促場(chǎng)景下，我們會(huì)對(duì)CPU進(jìn)行獨(dú)立socket 綁定，避免L3 cache干擾；另外，內(nèi)存不超賣。當(dāng)然，大促結(jié)束后，在業(yè)務(wù)平峰時(shí)，可以擇機(jī)進(jìn)行調(diào)度和超賣。 

• 網(wǎng)絡(luò)QOS

我們對(duì)數(shù)據(jù)庫(kù)在線業(yè)務(wù)進(jìn)行網(wǎng)絡(luò)打標(biāo)，NetQoS中將數(shù)據(jù)庫(kù)計(jì)算節(jié)點(diǎn)的所有通信組件加入到高優(yōu)先級(jí)group中。

• 基于分布式存儲(chǔ)的彈性效率

基于分布式存儲(chǔ)，底層分布式存儲(chǔ)支持多點(diǎn)mount，用于將計(jì)算節(jié)點(diǎn)快速?gòu)椥缘诫x線機(jī)器。

另外，數(shù)據(jù)庫(kù)Buffer Pool可以進(jìn)行動(dòng)態(tài)擴(kuò)容。大促ODPS任務(wù)撤離，DB實(shí)例Buffer Pool擴(kuò)容；大促結(jié)束后，Buffer Pool回縮到平峰業(yè)務(wù)時(shí)的大小。

以下是今年離在線混布的部署圖： 

四、雙11大促求證

 我們拿了其中一個(gè)中等壓力的數(shù)據(jù)庫(kù)的業(yè)務(wù)，其吞吐達(dá)到將近3w tps，RT在1ms以內(nèi)，基本上與本地相當(dāng)，很好的支撐了2017年大促。

 這就是我們今年所做的諸多技術(shù)創(chuàng)新的結(jié)果。

五、展望

目前我們正在進(jìn)行軟硬件結(jié)合（RDMA，SPDK）以及上層數(shù)據(jù)庫(kù)引擎與分布式存儲(chǔ)融合優(yōu)化，性能將會(huì)超出傳統(tǒng)SATA SSD本地盤的性能。

RDMA和SPDK的特點(diǎn)就是kernel pass-by。未來，我們數(shù)據(jù)庫(kù)將引入全用戶態(tài)IO Stack，從計(jì)算節(jié)點(diǎn)到存儲(chǔ)節(jié)點(diǎn)使用用戶態(tài)技術(shù)，更能充分滿足集團(tuán)電商業(yè)務(wù)對(duì)高吞吐低時(shí)延的***要求。

下面是我們進(jìn)行測(cè)試的一組數(shù)據(jù)，其中本地用的是SATA SSD，并且做了raid，但是其性能略低于基于RDMA和SPDK的分布式存儲(chǔ)。

這些網(wǎng)絡(luò)和硬件技術(shù)的發(fā)展，將會(huì)給“云計(jì)算”帶來更多的可能性，也會(huì)給真正的“云計(jì)算”新的商業(yè)模式帶來更多憧憬，而我們已經(jīng)在這條陽(yáng)光的大道上。 

歡迎有更多的存儲(chǔ)及數(shù)據(jù)庫(kù)內(nèi)核專家一起參與進(jìn)來，一起攜手邁進(jìn)未來。 

【引用】

[1] Copysets:Reducing the Frequency of Data Loss in Cloud Storage

[2] CRUSH: Controlled,Scalable, Decentralized Placement of Replicated Data