2017雙11技術揭祕—阿里數據庫計算存儲分離與離在線混布

摘要： 隨着阿里集團電商、物流、大文娛等業務的蓬勃發展，數據庫實例以及數據存儲規模不斷增加，在傳統基於單機的運維以及管理模式下，遇到諸多如成本，調度效率等問題，所以，2017年首次對數據庫實現計算存儲分離，計算存儲分離後，再將計算節點與離線資源混布，達到節省大促成本的目的。

做者：呂建樞（呂健）

背景
隨着阿里集團電商、物流、大文娛等業務的蓬勃發展，數據庫實例以及數據存儲規模不斷增加，在傳統基於單機的運維以及管理模式下，遇到很是多的困難與挑戰，主要歸結爲：

機型採購與預算問題
在單機模式下計算資源（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，從計算節點到存儲節點使用用戶態技術，更能充分知足集團電商業務對高吞吐低時延的極致要求。

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

歡迎有更多的存儲及數據庫內核專家一塊兒參與進來，一塊兒攜手邁進將來。

【引用】

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

[2] CRUSH: Controlled,Scalable, Decentralized Placement of Replicated Data
點擊查看原文