隨著交流機(jī)會(huì)的增多（集中在金融行業(yè)，規(guī)模都在各自領(lǐng)域數(shù)一數(shù)二），發(fā)現(xiàn)大家對 Docker + Kubernetes 的接受程度超乎想象, 并極有興趣將這套架構(gòu)應(yīng)用到 RDS 領(lǐng)域。數(shù)據(jù)庫服務(wù)的需求可以簡化為：

實(shí)現(xiàn)數(shù)據(jù)零丟失的前提下，提供可接受的服務(wù)能力。

因此存儲(chǔ)架構(gòu)的選型至關(guān)重要。到底是選擇計(jì)算存儲(chǔ)分離還是本地存儲(chǔ)？

[[223859]]

本文就這個(gè)問題，從以下幾點(diǎn)展開：

• 回顧：計(jì)算存儲(chǔ)分離, 本地存儲(chǔ)優(yōu)缺點(diǎn)
• MySQL 基于本地存儲(chǔ)實(shí)現(xiàn)數(shù)據(jù)零丟失
• 性能對比
• 基于 Docker + Kubernetes 的實(shí)現(xiàn)

來分享個(gè)人理解。

回顧：計(jì)算存儲(chǔ)分離，本地存儲(chǔ)優(yōu)缺點(diǎn)

還是從計(jì)算存儲(chǔ)分離說起。

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

先說優(yōu)點(diǎn)：

• 架構(gòu)清晰
• 計(jì)算資源 / 存儲(chǔ)資源獨(dú)立擴(kuò)展
• 提升實(shí)例密度，優(yōu)化硬件利用率
• 簡化實(shí)例切換流程：將有狀態(tài)的數(shù)據(jù)下沉到存儲(chǔ)層，Scheduler 調(diào)度時(shí)，無需感知計(jì)算節(jié)點(diǎn)的存儲(chǔ)介質(zhì)，只需調(diào)度到滿足計(jì)算資源要求的 Node，數(shù)據(jù)庫實(shí)例啟動(dòng)時(shí)，只需在分布式文件系統(tǒng)掛載 mapping volume 即可。可以顯著的提高數(shù)據(jù)庫實(shí)例的部署密度和計(jì)算資源利用率。

以 MySQL 為例

• 通用性更好，同時(shí)適用于 Oracle、MySQL。

從部分用戶的上下文來看，存在如下客觀缺點(diǎn)：

• 引入分布式存儲(chǔ)，架構(gòu)復(fù)雜度加大。一旦涉及到分布式存儲(chǔ)的問題，DBA 無法閉環(huán)解決。
• 分布式存儲(chǔ)選型：

選擇商用，有 Storage Verdor Lock In 風(fēng)險(xiǎn)。

選擇開源，大多數(shù)用戶（包括沃趣）都測試過 GlusterFS 和 Ceph，針對數(shù)據(jù)庫（Sensitive Lantency）場景，性能完全無法接受。

本地存儲(chǔ)

如果在意計(jì)算存儲(chǔ)分離架構(gòu)中提到的缺點(diǎn)，本地存儲(chǔ)可以有效的打消類似顧慮，無需引入分布式存儲(chǔ)，避免Storage Verdor Lock In 風(fēng)險(xiǎn)，所有問題都由DBA 閉環(huán)解決，但是，需要依賴數(shù)據(jù)庫自有方案實(shí)現(xiàn)數(shù)據(jù)零丟失。

以 MySQL 為例

還會(huì)引入類似問題：

• 物理容量受限于單機(jī)容量；
• 調(diào)度更復(fù)雜，選定數(shù)據(jù)庫實(shí)例的存儲(chǔ)類型（比如 SSD）后，一旦該實(shí)例發(fā)生“failover”，只能調(diào)度到擁有 SSD 的物理節(jié)點(diǎn)，這導(dǎo)致調(diào)度器需要對物理節(jié)點(diǎn)“Physical Topology Aware”；

• 密度難提升，這是“Physical Topology Aware”的副作用；
• 因數(shù)據(jù)庫的不同方案差異性較大，通用性無法保證。

接下來，進(jìn)入正題，看一下 MySQL 基于本地存儲(chǔ)如何實(shí)現(xiàn)數(shù)據(jù)庫零丟失。

MySQL 基于本地存儲(chǔ)數(shù)據(jù)零丟失

最常用的是基于 Replication 模型將數(shù)據(jù)復(fù)制到 MySQL Cluster 中所有成員。

MySQL Master-Slave Replication（類似 Oracle DataGuard）提供了基于 binlog 的數(shù)據(jù)庫層的復(fù)制模型，在高并發(fā)壓力下節(jié)點(diǎn)間同步數(shù)據(jù)速率最快，單位時(shí)間內(nèi)的交易量受其他節(jié)點(diǎn)的影響極小，該架構(gòu)可通過 vip 漂移的方式實(shí)現(xiàn) “failover”。

MySQL Master-Slave Replication

但嚴(yán)格意義上來說，這是基于 binlog 的 Asynchronous Replication 模型，因此集群中所有成員存在數(shù)據(jù)不一致的可能，在“failover”時(shí)無法保證數(shù)據(jù)零丟失。

可見如果基于 Replication 模型，Synchronous Replication 是實(shí)現(xiàn)數(shù)據(jù)零丟失的前提。

傳統(tǒng)的 Synchronous Replication 一般會(huì)采用兩階段提交或分布式鎖，這會(huì)帶來如下幾個(gè)問題：

單位時(shí)間內(nèi)事務(wù)能力（TPS）會(huì)跟集群成員數(shù)量成反比

增加集群成員會(huì)顯著且無法預(yù)期的增加事務(wù)響應(yīng)時(shí)間

增加了集群成員數(shù)據(jù)復(fù)制的沖突和死鎖的可能性

針對以上問題 Galera Cluster 提出 Certification-based Replication 來解決傳統(tǒng) Synchronous Replication 中遇到的問題，實(shí)現(xiàn)如下：

Deferred Update Replication 延遲更新復(fù)制

這個(gè)流程圖中，有幾個(gè)細(xì)節(jié)需要分享：

• 將基于 binlog 改為基于 write-set，write-set 中包含修改的數(shù)據(jù)，Global Transaction ID（后面簡稱 GTID）和 Primary Key。

GTID 類似 45eec521-2f34-11e0-0800-2a36050b826b:94530586304

94530586304 為 64-bit 有符號(hào)整型，用來表示事務(wù)在序列中的位置

• 將傳統(tǒng)的 Synchronous Replication 改為 Deferred Update Replication，并將整個(gè)過程大致分解成四個(gè)階段，本地階段、發(fā)送階段、驗(yàn)證階段和應(yīng)用階段，其中：

本地階段：樂觀執(zhí)行，在事務(wù) Commit 前，假設(shè)該 Transcation 在集群中復(fù)制時(shí)不會(huì)產(chǎn)生沖突。

發(fā)送階段：優(yōu)化同步時(shí)間窗口，除去全局排序并獲取 GTID 為同步操作，沖突驗(yàn)證和事務(wù)應(yīng)用都為異步，極大的優(yōu)化了復(fù)制效率。

驗(yàn)證階段：只有收到該事務(wù)的所有前置事務(wù)后（不能有 “hole”），該事務(wù)和所有未執(zhí)行的前置事務(wù)才能并發(fā)驗(yàn)證，不然不能保證 Global Ordering，因此這里需要犧牲效率，引入一定的串行化。

需要等待事務(wù) 3

于是就有了 Galera Cluster 在 MySQL 分支中的實(shí)現(xiàn) MariaDB Galera Cluster（簡稱 MGC）和 Percona Xtradb Cluster（簡稱 PXC）。

為避免“split-brain”問題，需要至少三節(jié)點(diǎn)組成集群，對計(jì)算資源和存儲(chǔ)資源的容量要求至少增加2倍，會(huì)進(jìn)一步降低資源的部署密度。

越來越多的用戶也期望通過該方案實(shí)現(xiàn)跨 IDC 多活，那么需要在規(guī)劃階段想清楚：

IDC 和數(shù)據(jù)庫節(jié)點(diǎn)的拓?fù)浼軜?gòu)，以保證在 1 個(gè) IDC 出問題的情況，集群可以持續(xù)提供服務(wù)。

首先 IDC（物理或邏輯）最少需要3個(gè)，再看看數(shù)據(jù)庫節(jié)點(diǎn)數(shù)量分別為 3、4、5、6、7 的拓?fù)潢P(guān)系 :

• 3 數(shù)據(jù)庫節(jié)點(diǎn)：

• 4 數(shù)據(jù)庫節(jié)點(diǎn)：設(shè)置權(quán)重避免”split-brain” (? + ? ) + ? + ?

• 5 數(shù)據(jù)庫節(jié)點(diǎn)：

6 數(shù)據(jù)庫節(jié)點(diǎn)：

7 數(shù)據(jù)庫節(jié)點(diǎn) : 可支持兩種拓?fù)潢P(guān)系

同時(shí)，還有 MySQL Group Replication（簡稱 MGR）[1]，類似 Galera Cluster：

• 基于Corosync實(shí)現(xiàn)（Totem協(xié)議），插件式安裝，MySQL 官方原生插件。
• 集群架構(gòu)，支持多寫（建議單寫）
• 允許少數(shù)節(jié)點(diǎn)故障，同步延遲較小，保證強(qiáng)一致，數(shù)據(jù)零丟失
• 單位時(shí)間的交易量受 flow control 影響。

這里還需要提一下 Vitess：

• 該項(xiàng)目由 Youtube 開源，從文檔看功能極為強(qiáng)大，高度產(chǎn)品化。
• 作為第二個(gè)存儲(chǔ)類項(xiàng)目（***個(gè)是 Rook，有意思是存儲(chǔ)類而不是數(shù)據(jù)庫類）加入 CNCF，目前還處于孵化階段（incubation-level）。
• 筆者沒有使用經(jīng)驗(yàn)，也不知道國內(nèi)有哪些用戶，不做評(píng)論。

關(guān)于 MGR 和 Vitess 網(wǎng)上已有大量介紹，這里不再贅述。

性能對比

在數(shù)據(jù)零丟失的前提下，看看這幾種架構(gòu)在性能上的對比：

• MGR 5.7.17 / PXC 5.7.14-26.17
• MGR 5.7.17 / PXC 5.7.17-29.20 / MariaDB 10.2.5 RC
• 本地存儲(chǔ) / 計(jì)算存儲(chǔ)分離

性能對比 1：MGR 5.7.17 / PXC 5.7.14-26.17

測試背景描述：

• MGR 5.7.17 對比 PXC 5.7.14-26.17（基于 Galera 3實(shí)現(xiàn)）
• 負(fù)載模型：OLTP Read/Write (RW)
• durability：sync_binlog=1，innodb_flush_log_at_trx_commit=1
• non-durability：sync_binlog=0，innodb_flush_log_at_trx_commit=2

測試數(shù)據(jù) :

來自于 MySQL 官方[2]

測試結(jié)果：

在設(shè)置 durability 的情況下，MGR ***吞吐約是PXC 5.7.14-26.17（基于 Galera 3 實(shí)現(xiàn)）的3倍，優(yōu)勢明顯。

以上數(shù)據(jù)來自于MySQL 官方，公平起見，再來看看 Percona 在相同負(fù)載模型下的測試數(shù)據(jù)。

性能對比 2：MGR 5.7.17 / PXC 5.7.17-29.20 / MariaDB 10.2.5 RC

測試背景描述：

• 增加了 MariaDB 參與對比
• PXC 升級(jí)到 5.7.17-29.20，該版本改進(jìn)了MySQL write-set 復(fù)制層性能[3]。
• 負(fù)載模型：依然使用 OLTP Read/Write (RW)
• durability：sync_binlog=1
• non-durability：sync_binlog=0

測試數(shù)據(jù)：

設(shè)置 durability，數(shù)據(jù)來自于 Percona[3]

設(shè)置 non-durability，數(shù)據(jù)來自于 Percona[3]

測試結(jié)果：

在負(fù)載模型相同的情況下（durability 和 non-durability）PXC 5.7.17-29.20 性能與 MGR 5.7.17 不分伯仲。如果使用 PXC，推薦使用 5.7.17-29.20 或以上版本。

性能對比3：本地存儲(chǔ) / 計(jì)算存儲(chǔ)分離

為了對比本地存儲(chǔ)和計(jì)算存儲(chǔ)分離，專門使用 MGR + 本地存儲(chǔ)架構(gòu)和 基于分布式存儲(chǔ)的計(jì)算存儲(chǔ)分離架構(gòu)做性能對比。

測試結(jié)果：

在負(fù)載模型相同的情況下，前者比后者 OLTP 下降32.12%，Select 下降5.44%，Update 下降 24.18%，Insert 下降 58.18%，Delete 下降 11.44%。

基于 Docker + Kubernetes 的實(shí)現(xiàn)

Docker + Kubernetes + MGR / Galera Cluster

在 GitHub 上，可以看到基于 Docker + Kuberetes + PXC 的 demo[4]。需要說明的是，這僅僅是個(gè)玩具，離部署到生產(chǎn)環(huán)境還有極大差距。

我們已有計(jì)劃實(shí)現(xiàn)滿足生產(chǎn)環(huán)境的：

• Docker + Kubernetes + PXC
• Docker + Kubernetes + MGC
• Docker + Kubernetes + MGR

并集成到 QFusion 來支持計(jì)算存儲(chǔ)分離架構(gòu)和本地存儲(chǔ)架構(gòu)混合部署，架構(gòu)示意圖如下：

目前原型驗(yàn)證階段已通過，預(yù)計(jì)2018年Q2發(fā)布。

Docker + Kubernetes + Vitess

在 GitHub 上，同樣可以看到基于 Docker + Kubernetes 的 demo[5]，有興趣的同學(xué)可以玩一下。

性能只是選型需要考量的一部分，要使用到生產(chǎn)環(huán)境或者產(chǎn)品化，實(shí)際要考量的因素更多：

• 運(yùn)維：部署、備份
• 彈性：計(jì)算存儲(chǔ)擴(kuò)容，集群擴(kuò)容
• 高可用：比如 “failover” 的細(xì)微差別對業(yè)務(wù)的影響
• 容錯(cuò)：比如網(wǎng)絡(luò)對集群的影響，尤其是在網(wǎng)絡(luò)抖動(dòng)或有明顯延時(shí)的情況下
• 社區(qū)活躍度
• ……

以現(xiàn)有軟硬件的開放程度，各種架構(gòu)或者產(chǎn)品狹義上的“黑科技”并不多，常常看到的：『xxx 比 xxx 快 xxx 倍』嚴(yán)格來說應(yīng)該是『xxx 比 xxx 在特定場景 xxx 下快 xxx 倍』。

并不存在“一槍斃命”的“Silver Bullet”，只是 Docker + Kubernetes 為混合部署帶來可能。哪種更受青睞，拭目以待，用戶會(huì)是***的老師。