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

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

因此存儲架構的選型至關重要。到底是選擇計算存儲分離還是本地存儲？

本文就這個問題，從以下幾點展開：回顧：計算存儲分離, 本地存儲優(yōu)缺點

MySQL 基于本地存儲實現(xiàn)數(shù)據(jù)零丟失

性能對比

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

來分享個人理解。

| 回顧：計算存儲分離，本地存儲優(yōu)缺點

還是從計算存儲分離說起。

計算存儲分離

先說優(yōu)點：架構清晰

計算資源 / 存儲資源獨立擴展

提升實例密度，優(yōu)化硬件利用率

簡化實例切換流程：將有狀態(tài)的數(shù)據(jù)下沉到存儲層，Scheduler 調度時，無需感知計算節(jié)點的存儲介質，只需調度到滿足計算資源要求的 Node，數(shù)據(jù)庫實例啟動時，只需在分布式文件系統(tǒng)掛載 mapping volume 即可。可以顯著的提高數(shù)據(jù)庫實例的部署密度和計算資源利用率。以 MySQL 為例通用性更好，同時適用于 Oracle、MySQL，詳見：《容器化RDS——計算存儲分離架構下的"Split-Brain"》。

從部分用戶的上下文來看，存在如下客觀缺點：引入分布式存儲，架構復雜度加大。一旦涉及到分布式存儲的問題，DBA 無法閉環(huán)解決。

分布式存儲選型：

選擇商用，有 Storage Verdor Lock In 風險。

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

本地存儲

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

還會引入類似問題：物理容量受限于單機容量；

調度更復雜，選定數(shù)據(jù)庫實例的存儲類型(比如 SSD)后，一旦該實例發(fā)生“failover”，只能調度到擁有 SSD 的物理節(jié)點，這導致調度器需要對物理節(jié)點“Physical Topology Aware”；密度難提升，這是“Physical Topology Aware”的副作用；

因數(shù)據(jù)庫的不同方案差異性較大，通用性無法保證。

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

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

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

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

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

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

傳統(tǒng)的 Synchronous Replication 一般會采用兩階段提交或分布式鎖，這會帶來如下幾個問題：單位時間內事務能力(TPS)會跟集群成員數(shù)量成反比

增加集群成員會顯著且無法預期的增加事務響應時間

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

針對以上問題 Galera Cluster 提出 Certification-based Replication 來解決傳統(tǒng) Synchronous Replication 中遇到的問題，實現(xiàn)如下：Deferred Update Replication 延遲更新復制

這個流程圖中，有幾個細節(jié)需要分享：將基于 binlog 改為基于 write-set，write-set 中包含修改的數(shù)據(jù)，Global Transaction ID(后面簡稱 GTID)和 Primary Key。

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

94530586304 為 64-bit 有符號整型，用來表示事務在序列中的位置

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

本地階段：樂觀執(zhí)行，在事務 Commit 前，假設該 Transcation 在集群中復制時不會產生沖突。

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

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

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

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

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

IDC 和數(shù)據(jù)庫節(jié)點的拓撲架構，以保證在 1 個 IDC 出問題的情況，集群可以持續(xù)提供服務。

首先 IDC(物理或邏輯)最少需要3個，再看看數(shù)據(jù)庫節(jié)點數(shù)量分別為 3、4、5、6、7 的拓撲關系 :3 數(shù)據(jù)庫節(jié)點：4 數(shù)據(jù)庫節(jié)點：設置權重避免”split-brain” (? + ? ) + ? + ?5 數(shù)據(jù)庫節(jié)點：6 數(shù)據(jù)庫節(jié)點：7 數(shù)據(jù)庫節(jié)點 : 可支持兩種拓撲關系

同時，還有 MySQL Group Replication(簡稱 MGR)[1]，類似 Galera Cluster：基于Corosync實現(xiàn)(Totem協(xié)議)，插件式安裝，MySQL 官方原生插件。

集群架構，支持多寫(建議單寫)

允許少數(shù)節(jié)點故障，同步延遲較小，保證強一致，數(shù)據(jù)零丟失

單位時間的交易量受 flow control 影響。

這里還需要提一下 Vitess：該項目由 Youtube 開源，從文檔看功能極為強大，高度產品化。

作為第二個存儲類項目(第一個是 Rook，有意思是存儲類而不是數(shù)據(jù)庫類)加入 CNCF，目前還處于孵化階段(incubation-level)。

筆者沒有使用經(jīng)驗，也不知道國內有哪些用戶，不做評論。

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

| 性能對比

在數(shù)據(jù)零丟失的前提下，看看這幾種架構在性能上的對比：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

本地存儲 / 計算存儲分離

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

測試背景描述：MGR 5.7.17 對比 PXC 5.7.14-26.17(基于 Galera 3實現(xiàn))

負載模型：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]

測試結果：

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

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

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

測試背景描述：增加了 MariaDB 參與對比

PXC 升級到 5.7.17-29.20，該版本改進了MySQL write-set 復制層性能[3]。

負載模型：依然使用 OLTP Read/Write (RW)

durability：sync_binlog=1

non-durability：sync_binlog=0

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

測試結果：

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

性能對比3：本地存儲 / 計算存儲分離

為了對比本地存儲和計算存儲分離，專門使用 MGR + 本地存儲架構和 基于分布式存儲的計算存儲分離架構做性能對比。

測試結果：

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

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

Docker + Kubernetes + MGR / Galera Cluster

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

我們已有計劃實現(xiàn)滿足生產環(huán)境的：Docker + Kubernetes + PXC

Docker + Kubernetes + MGC

Docker + Kubernetes + MGR

并集成到 QFusion 來支持計算存儲分離架構和本地存儲架構混合部署，架構示意圖如下：

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

Docker + Kubernetes + Vitess

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

性能只是選型需要考量的一部分，要使用到生產環(huán)境或者產品化，實際要考量的因素更多：運維：部署、備份

彈性：計算存儲擴容，集群擴容

高可用：比如 “failover” 的細微差別對業(yè)務的影響

容錯：比如網(wǎng)絡對集群的影響，尤其是在網(wǎng)絡抖動或有明顯延時的情況下

社區(qū)活躍度

……

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

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

《人月神話》中提到“No Silver Bullet”，原意是用來論述軟件工程領域的生產力問題。

由于軟件的復雜性本質，使得真正的銀彈并不存在，沒有任何一項技術或方法可使軟件工程的生產力在十年內提高十倍。

相關鏈接：

| 作者簡介

熊中哲，沃趣科技聯(lián)合創(chuàng)始人/產品研發(fā)中心總監(jiān)

原阿里巴巴高級數(shù)據(jù)庫專家，多年大型制造業(yè)及電子商務數(shù)據(jù)庫運維經(jīng)驗，曾參與阿里云RDS運維自動化研發(fā)。

總結

以上是生活随笔為你收集整理的mysql docker还是rds_容器化RDS：计算存储分离还是本地存储？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。