作者：呂建樞（呂健）

背景
隨著阿里集團電商、物流、大文娛等業務的蓬勃發展，資料庫例項以及資料儲存規模不斷增長，在傳統基於單機的運維以及管理模式下，遇到非常多的困難與挑戰，主要歸結為：

機型採購與預算問題
在單機模式下計算資源（CPU和記憶體）與儲存資源（主要為磁碟或者SSD）存在著不可調和的衝突；計算與儲存資源繫結緊密，無法進行單獨預算。資料庫儲存時，要麼計算資源達到瓶頸，要麼是儲存單機儲存容量不足。這種繫結模式下，註定了有一種資源必須是浪費的。
排程效率問題
在計算與儲存繫結的情況下，計算資源無法做無狀態排程，導致無法實現大規模低成本排程，也就無法與在大促與離線資源進行混布。
大促成本問題
在計算資源無法做到排程後，離線混布就不再可能；為了大促需要採購更多的機器，大促成本上漲嚴重。
因此，為了解決諸多如成本，排程效率等問題，2017年首次對資料庫實現計算儲存分離；計算儲存分離後，再將計算節點與離線資源混布，達到節省大促成本的目的。

2017年資料庫計算儲存分離，

使得資料庫進行大規模無狀態化容器排程成為可能！

使得資料庫與離線業務混布成為可能!

使得低成本支援大促彈性成為可能！

在高吞吐下，總儲存叢集整體RT表現平穩，與離線資源聯合首次發力，完成2017年“11.11”大促的交易支撐。

計算儲存分離
在所有業務中，資料庫的計算儲存分離最難，這是大家公認的。因為資料庫對於儲存的穩定性以及單路端到端的時延有著極致的要求：

儲存穩定性
在分散式儲存的穩定性方面，我們做了非常多的有意探索，並且逐一落地。這些新技術的落地，使得資料庫計算儲存分離成為可能：

單機failover
單機failover我們做到業界的極致，5s內完成fo，對整體叢集的影響在4%以內（以叢集規模24臺為例，叢集機器越多，影響越小）。另外，我們對分散式儲存的狀態機進行加速優化，使得基於paxos的選舉在秒級內進行叢集檢視更新推送。

長尾時延優化
計算儲存分離後，所有的IO都變成了網路IO，因此對於單路IO時延影響的因素非常多，如網路抖動，慢盤，負載等，而這些因素也是不可避免的。我們設計了“副本達成多數寫入即返回的策略（commit majority feature）”，能夠有效地使長尾時延抖動做到合理的控制，以滿足業務的需求。

以下是commit majority feature開起前後的效果對比。其中“藍色”為優化後的長尾時延，“紅色”為優化前長尾時延，效果非常顯著。

流控
我們實現了基於滑動視窗的流控功能，使得集群后臺活動（如backfill和recovery）能根據當前的業務流量進行自適配的調整，在業務與後臺資料恢復之間做到最佳平衡。

一般如果集群后端活動太低，會影響資料恢復，這會提高多盤故障的概率，降低了資料的可靠性。我們經過優化後，通過滑動視窗機制，做到了前後端資料寫入的速動，在不影響業務寫入的情況下，盡最大可能提高資料恢復速度，保證多副本資料的完整性。

提高資料重平衡的速度，也是為了保證整個叢集的效能。因為一出現數據傾斜時，部分盤的負載將變大，從而會影響整個叢集的時延和吞吐。
流控效果如下：

高可用部署
在高可用部署上，我們引入的故障域的概念。多個數據副本儲存在多個故障域，分佈到至少4個RACK以上的機架上，用於保障底層機櫃電源以及網路交換裝置引起的故障等。

為了能夠更好的理解資料副本儲存位置（data locality），需要知道資料散射度（scatter width）的概念。怎麼來理解資料散射度？

舉個例子：我們定義三個copy set（存放的都是不同的資料）:{1，2，3}，{4，5，6}，{7，8，9}。任意一組copy set中存放的資料沒有重複，也就是說一份資料的三個副本分別放置在：{1，4，7}或者{2，5，8}或者{3，6，9}。那麼這個時候，其資料散射度遠小於隨機組合的C(9,3)。

隨機組合時，任意3臺機器Down機都會存在資料丟失。而採用此方案後，只有當{1，4，7}或者{2，5，8}或者{3，6，9}其中的任意一個組合不可用時，才會影響高可用性，才會有資料丟失。

綜上可知，我們引入copy set的目標就是儘量的降低資料散射度“S”。下圖中兩組replica set，其中每一組的三個副本分別放置到不同的RACK中。

我們的優化還有很多，這裡不再一一列舉。

資料庫吞吐優化
當所有的IO都變成網路IO後，我們要做的就是如何減少單路IO的延遲，當然這個是分散式儲存以及網路要解的問題。

分散式儲存需要優化自身的軟體stack以及底層SPDK的結合等。

而網路層則需要更高頻寬以及低時延技術，如25G TCP或者25G RDMA，或者100G等更高頻寬的網路等。

但是我們可以從另外一個角度來考慮問題，如何在時延一定的情況下，提高併發量，從而來提高吞吐。或者說在關鍵路徑上減少IO呼叫的次數，從而從某種程度上提高系統的吞吐。

大家知道，影響資料庫事務數的最關鍵因素就是事務commit的速度，commit的速度依賴於寫REDO時的IO吞吐。所謂的REDO也就是大家熟知的WAL(Write Ahead Log)日誌。

在髒資料flush回儲存時，日誌必須先落地，這是因為資料庫的Crash Recovery是重度以來於此的。在recovery階段，資料庫先利用redo進行roll forward，再利用undo進行roll backward，最後再撤銷使用者未提交的事務。

因此，儲存計算分離下，要想在單路IO時延一定時提高吞吐，就必須要優化commit提交時的效率。我們通過優化redo的寫入方式，讓整個提高吞吐100%左右。另外，也可以優化redo group commit的大小，結合底層儲存stripe能力，做併發與吞吐優化。

資料庫原子寫
在資料庫記憶體模型中，資料頁通常是以16K做為一個bufferpage來管理的。當核心修改完資料之後，會有專門的“checkpoint”執行緒按一定的頻率將Dirty Page flush到磁碟上。我們知道，通常os的page cache是4K，而一般的檔案系統block size也是4K。所以一個16k和page會被分成4個4k的os filesystem block size來儲存，物理上不能保證連續性。

那麼會帶來一個嚴重的問題，就是當fsync語義發出時，一個16k的pageflush，只完成其中的8k，而這個時候client端crash，不再會有重試；那麼整個fsync就只寫了一半，fsync語義被破壞，資料不完整。上面的這個場景，我們稱之為“partial write”。

對於MySQL而言，在本地儲存時，使用Double Write Buffer問題不大。但是如果底層變成網路IO，IO時延變高時，會使MySQL的整體吞吐下降，而Double Write Buffer會加重這個影響。

我們實現了原子寫，關閉掉Double Write Buffer，從而在高併發壓力及高網路IO時延下，讓吞吐至少提高50%以上。

網路架構升級
分散式儲存，對於網路的頻寬要求極高，我們引入了25G網路。高頻寬能更好的支援阿里集團的大促業務。另外，對於儲存集群后臺的活動，如資料重平衡以及恢復都提供了有力的保障。

離線上混布
計算儲存分離後，離線上混布成為可能；今年完成資料庫離線上混布，為2017年大促節省了計算資源成本。

在與離線混布的方案中，我們對資料庫與離線任務混跑的場景進行了大量的測試。

實踐證明，資料庫對時延極度敏感，所以為了達到資料庫混布的目的，我們採用了以下的隔離方案：

CPU與記憶體隔離技術
CPU的L3是被各個核共享的，如果在一個socket內部進行排程，會對資料庫業務有抖動。因此，在大促場景下，我們會對CPU進行獨立socket 繫結，避免L3 cache干擾；另外，記憶體不超賣。當然，大促結束後，在業務平峰時，可以擇機進行排程和超賣。

網路QOS
我們對資料庫線上業務進行網路打標，NetQoS中將資料庫計算節點的所有通訊元件加入到高優先順序group中。

基於分散式儲存的彈性效率
基於分散式儲存，底層分散式儲存支援多點mount，用於將計算節點快速彈性到離線機器。

另外，資料庫Buffer Pool可以進行動態擴容。大促ODPS任務撤離，DB例項Buffer Pool擴容；大促結束後，Buffer Pool回縮到平峰業務時的大小。

雙11大促求證
大促期間，其中一個庫吞吐達到將近3w tps，RT在1ms以內，基本上與本地相當，很好的支撐了2017年大促。這就是我們今年所做的諸多技術創新的結果。

展望
目前我們正在進行軟硬體結合（RDMA，SPDK）以及上層資料庫引擎與分散式儲存融合優化，效能將會超出傳統SATA SSD本地盤的效能。

RDMA和SPDK的特點就是kernel pass-by。未來，我們資料庫將引入全使用者態IO Stack，從計算節點到儲存節點使用使用者態技術，更能充分滿足集團電商業務對高吞吐低時延的極致要求。

這些網路和硬體技術的發展，將會給“雲端計算”帶來更多的可能性，也會給真正的“雲端計算”新的商業模式帶來更多憧憬，而我們已經在這條陽光的大道上。