回看這幾年幅虑，分布式系統(tǒng)領(lǐng)域出現(xiàn)了很多新東西丰滑，特別是云和 AI 的崛起，讓這個(gè)過(guò)去其實(shí)不太 sexy 的領(lǐng)域一下到了風(fēng)口浪尖倒庵，在這期間誕生了很多新技術(shù)褒墨、新思想，讓這個(gè)古老的領(lǐng)域重新煥發(fā)生機(jī)擎宝。站在 2010s 的尾巴上郁妈，我想跟大家一起聊聊分布式系統(tǒng)令人振奮的進(jìn)化路程，以及談一些對(duì) 2020s 的大膽猜想绍申。

無(wú)論哪個(gè)時(shí)代噩咪，存儲(chǔ)都是一個(gè)重要的話題，今天先聊聊數(shù)據(jù)庫(kù)失晴。在過(guò)去的幾年剧腻，數(shù)據(jù)庫(kù)技術(shù)上出現(xiàn)了幾個(gè)很明顯的趨勢(shì)拘央。

?存儲(chǔ)和計(jì)算進(jìn)一步分離

我印象中最早的存儲(chǔ) - 計(jì)算分離的嘗試是 Snowflake涂屁，Snowflake 團(tuán)隊(duì)在 2016 年發(fā)表的論文《 The Snowflake Elastic Data Warehouse 》是近幾年我讀過(guò)的最好的大數(shù)據(jù)相關(guān)論文之一，尤其推薦閱讀灰伟。Snowflake 的架構(gòu)關(guān)鍵點(diǎn)是在無(wú)狀態(tài)的計(jì)算節(jié)點(diǎn) + 中間的緩存層 + S3 上存儲(chǔ)數(shù)據(jù)拆又，計(jì)算并不強(qiáng)耦合緩存層，非常符合云的思想栏账。從最近 AWS 推出的 RedShift 冷熱分離架構(gòu)來(lái)看帖族，AWS 也承認(rèn) Snowflake 這個(gè)搞法是先進(jìn)生產(chǎn)力的發(fā)展方向。另外這幾年關(guān)注數(shù)據(jù)庫(kù)的朋友不可能不注意到 Aurora挡爵。不同于 Snowflake竖般，Aurora 應(yīng)該是第一個(gè)將存儲(chǔ) - 計(jì)算分離的思想用在 OLTP 數(shù)據(jù)庫(kù)中的產(chǎn)品，并大放異彩茶鹃。Aurora 的成功在于將數(shù)據(jù)復(fù)制的粒度從 Binlog 降低到 Redo Log 涣雕，極大地減少?gòu)?fù)制鏈路上的 IO 放大。而且前端復(fù)用了 MySQL闭翩，基本做到了 100% 的應(yīng)用層 MySQL 語(yǔ)法兼容挣郭，并且托管了運(yùn)維，同時(shí)讓傳統(tǒng)的 MySQL 適用范圍進(jìn)一步拓展疗韵，這在中小型數(shù)據(jù)量的場(chǎng)景下是一個(gè)很省心的方案兑障。

雖然 Aurora 獲得了商業(yè)上的成功，但是從技術(shù)上，我并不覺(jué)得有很大的創(chuàng)新流译。熟悉 Oracle 的朋友第一次見(jiàn) Aurora 的架構(gòu)可能會(huì)覺(jué)得和 RAC 似曾相識(shí)逞怨。Oracle 大概在十幾年前就用了類似的方案，甚至很完美的解決了 Cache Coherence 的問(wèn)題福澡。另外骇钦，Aurora 的 Multi-Master 還有很長(zhǎng)的路要走，從最近在 ReInvent 上的說(shuō)法來(lái)看竞漾，目前 Aurora 的 Multi-Master 的主要場(chǎng)景還是作為 Single Writer 的高可用方案眯搭，本質(zhì)的原因應(yīng)該是目前 Multi-Writer 采用樂(lè)觀沖突檢測(cè)，沖突檢測(cè)的粒度是 Page业岁，在沖突率高的場(chǎng)合會(huì)帶來(lái)很大的性能下降鳞仙。

我認(rèn)為 Aurora 是一個(gè)很好的迎合 90% 的公有云互聯(lián)網(wǎng)用戶的方案：100% MySQL 兼容，對(duì)一致性不太關(guān)心笔时，讀遠(yuǎn)大于寫棍好，全托管。但同時(shí)允耿，Aurora 的架構(gòu)決定了它放棄了 10% 有極端需求的用戶借笙，如全局的 ACID 事務(wù) + 強(qiáng)一致，Hyper Scale（百 T 以上较锡，并且業(yè)務(wù)不方便拆庫(kù)）业稼，需要實(shí)時(shí)的復(fù)雜 OLAP。這類方案我覺(jué)得類似 TiDB 的以 Shared-nothing 為主的設(shè)計(jì)才是唯一的出路蚂蕴。作為一個(gè)分布式系統(tǒng)工程師低散，我對(duì)任何不能水平擴(kuò)展的架構(gòu)都會(huì)覺(jué)得不太優(yōu)雅。

?分布式 SQL 數(shù)據(jù)庫(kù)登上舞臺(tái)骡楼，ACID 全面回歸

回想幾年前 NoSQL 最風(fēng)光的時(shí)候熔号，大家恨不得將一切系統(tǒng)都使用 NoSQL 改造，雖然易用性鸟整、擴(kuò)展性和性能都不錯(cuò)引镊，但是多數(shù) NoSQL 系統(tǒng)都拋棄掉了數(shù)據(jù)庫(kù)最重要的一些東西，例如 ACID 約束篮条，SQL 等等弟头。NoSQL 的主要推手是互聯(lián)網(wǎng)公司，互聯(lián)網(wǎng)公司的簡(jiǎn)單業(yè)務(wù)加上超強(qiáng)的工程師團(tuán)隊(duì)兑燥，NoSQL 丟掉的東西當(dāng)然能用某些工具簡(jiǎn)單搞定亮瓷。但最近幾年大家漸漸發(fā)現(xiàn)低垂的果實(shí)基本上沒(méi)有了，剩下的都是硬骨頭降瞳。

最好的例子就是作為 NoSQL 的開(kāi)山鼻祖嘱支，Google 第一個(gè)搞了 NewSQL （Spanner 和 F1）蚓胸。在后移動(dòng)時(shí)代，業(yè)務(wù)變得越來(lái)越復(fù)雜除师，要求越來(lái)越實(shí)時(shí)沛膳，同時(shí)對(duì)于數(shù)據(jù)的需求也越來(lái)越強(qiáng)。尤其對(duì)于一些金融機(jī)構(gòu)來(lái)說(shuō)汛聚，一方面產(chǎn)品面臨著互聯(lián)網(wǎng)化锹安，一方面不管是出于監(jiān)管的要求還是業(yè)務(wù)本身的需求，ACID 是很難繞開(kāi)的倚舀。更現(xiàn)實(shí)的是叹哭，大多數(shù)傳統(tǒng)公司并沒(méi)有像頂級(jí)互聯(lián)網(wǎng)公司的人才供給，大量歷史系統(tǒng)基于 SQL 開(kāi)發(fā)痕貌，完全遷移到 NoSQL 上肯定不現(xiàn)實(shí)风罩。

在這個(gè)背景下，分布式關(guān)系型數(shù)據(jù)庫(kù)舵稠，我認(rèn)為這是我們這一代人超升，在開(kāi)源數(shù)據(jù)庫(kù)這個(gè)市場(chǎng)上最后一個(gè) missing part，終于慢慢流行起來(lái)哺徊。這背后的很多細(xì)節(jié)由于篇幅的原因我就不介紹室琢，推薦閱讀 PingCAP TiFlash 技術(shù)負(fù)責(zé)人 maxiaoyu 的一篇文章《從大數(shù)據(jù)到數(shù)據(jù)庫(kù)》，對(duì)這個(gè)話題有很精彩的闡述落追。

?云基礎(chǔ)設(shè)施和數(shù)據(jù)庫(kù)的進(jìn)一步整合

在過(guò)去的幾十年盈滴，數(shù)據(jù)庫(kù)開(kāi)發(fā)者都像是在單打獨(dú)斗，就好像操作系統(tǒng)以下的就完全是黑盒了淋硝，這個(gè)假設(shè)也沒(méi)錯(cuò)雹熬，畢竟軟件開(kāi)發(fā)者大多也沒(méi)有硬件背景宽菜。另外如果一個(gè)方案過(guò)于綁定硬件和底層基礎(chǔ)設(shè)施谣膳，必然很難成為事實(shí)標(biāo)準(zhǔn)，而且硬件非常不利于調(diào)試和更新铅乡，成本過(guò)高继谚，這也是我一直對(duì)定制一體機(jī)不是太感興趣的原因。但是云的出現(xiàn)阵幸，將 IaaS 的基礎(chǔ)能力變成了軟件可復(fù)用的單元花履，我可以在云上按需租用算力和服務(wù)，這會(huì)給數(shù)據(jù)庫(kù)開(kāi)發(fā)者在設(shè)計(jì)系統(tǒng)的時(shí)候帶來(lái)更多的可能性挚赊，舉幾個(gè)例子：

1诡壁、 Spanner 原生的 TrueTime API 依賴原子鐘和 GPS 時(shí)鐘，如果純軟件實(shí)現(xiàn)的話荠割，需要犧牲的東西很多（例如 CockroachDB 的 HLC 和 TiDB 的改進(jìn)版 Percolator 模型妹卿，都是基于軟件時(shí)鐘的事務(wù)模型）旺矾。但是長(zhǎng)期來(lái)看，不管是 AWS 還是 GCP 都會(huì)提供類似 TrueTime 的高精度時(shí)鐘服務(wù)夺克，這樣一來(lái)我們就能更好的實(shí)現(xiàn)低延遲長(zhǎng)距離分布式事務(wù)箕宙。

2、 可以借助 Fargate + EKS 輕量級(jí)容器 + Managed K8s 的服務(wù)铺纽，讓數(shù)據(jù)庫(kù)應(yīng)對(duì)突發(fā)熱點(diǎn)小表讀的場(chǎng)景（這個(gè)場(chǎng)景幾乎是 Shared-Nothing 架構(gòu)的老大難問(wèn)題）柬帕，比如在 TiDB 中通過(guò) Raft Learner 的方式，配合云的 Auto Scaler 快速在新的容器中創(chuàng)建只讀副本狡门，而不是僅僅通過(guò) 3 副本提供服務(wù)陷寝；比如動(dòng)態(tài)起 10 個(gè) pod，給熱點(diǎn)數(shù)據(jù)創(chuàng)建 Raft 副本（這是我們將 TiKV 的數(shù)據(jù)分片設(shè)計(jì)得那么小的一個(gè)重要原因）其馏，處理完突發(fā)的讀流量后再銷毀這些容器盼铁，變成 3 副本。

3尝偎、冷熱數(shù)據(jù)分離饶火，這個(gè)很好理解，將不常用的數(shù)據(jù)分片致扯，分析型的副本肤寝，數(shù)據(jù)備份放到 S3 上，極大地降低成本抖僵。

4鲤看、 RDMA/CPU/ 超算 as a Service，任何云上的硬件層面的改進(jìn)耍群，只要暴露 API义桂，都是可以給軟件開(kāi)發(fā)者帶來(lái)新的好處。

例子還有很多蹈垢，我就不一一列舉了慷吊。總之我的觀點(diǎn)是云服務(wù) API 的能力會(huì)像過(guò)去的代碼標(biāo)準(zhǔn)庫(kù)一樣曹抬，是大家可以依賴的東西溉瓶，雖然現(xiàn)在公有云的 SLA 仍然不夠理想，但是長(zhǎng)遠(yuǎn)上看谤民，一定是會(huì)越來(lái)越完善的堰酿。

所以，數(shù)據(jù)庫(kù)的未來(lái)在哪里张足？是更加的垂直化還是走向統(tǒng)一触创？對(duì)于這個(gè)問(wèn)題，我同意這個(gè)世界不存在銀彈为牍，但是我也并不像我的偶像哼绑，AWS CTO Vogels 博士那么悲觀顺饮，相信未來(lái)是一個(gè)割裂的世界（AWS 恨不得為了每個(gè)細(xì)分的場(chǎng)景設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)）。過(guò)度地細(xì)分會(huì)加大數(shù)據(jù)在不同系統(tǒng)中流動(dòng)的成本凌那。解決這個(gè)問(wèn)題有兩個(gè)關(guān)鍵：

數(shù)據(jù)產(chǎn)品應(yīng)該切分到什么粒度兼雄？

用戶可不可以不用知道背后發(fā)生了什么？

第一個(gè)問(wèn)題并沒(méi)有一個(gè)明確的答案帽蝶，但是我覺(jué)得肯定不是越細(xì)越好的赦肋，而且這個(gè)和 Workload 有關(guān)，比如如果沒(méi)有那么大量的數(shù)據(jù)励稳，直接在 MySQL 或者 PostgreSQL 上跑分析查詢其實(shí)一點(diǎn)問(wèn)題也沒(méi)有佃乘，沒(méi)有必要非去用 Redshift。雖然沒(méi)有直接的答案驹尼，但是我隱約覺(jué)得第一個(gè)問(wèn)題和第二個(gè)問(wèn)題是息息相關(guān)的趣避，畢竟沒(méi)有銀彈，就像 OLAP 跑在列存儲(chǔ)引擎上一定比行存引擎快新翎，但是對(duì)用戶來(lái)說(shuō)其實(shí)可以都是 SQL 的接口程帕。

SQL 是一個(gè)非常棒的語(yǔ)言，它只描述了用戶的意圖地啰，而且完全與實(shí)現(xiàn)無(wú)關(guān)愁拭，對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，其實(shí)可以在 SQL 層的后面來(lái)進(jìn)行切分亏吝，在 TiDB 中岭埠，我們引入 TiFlash 就是一個(gè)很好的例子。動(dòng)機(jī)很簡(jiǎn)單：

1蔚鸥、用戶其實(shí)并不是數(shù)據(jù)庫(kù)專家惜论，你不能指望用戶能 100% 在恰當(dāng)?shù)臅r(shí)間使用恰當(dāng)?shù)臄?shù)據(jù)庫(kù)，并且用對(duì)止喷。

2馆类、數(shù)據(jù)之間的同步在一個(gè)系統(tǒng)之下才能盡量保持更多的信息，例如启盛，TiFlash 能保持 TiDB 中事務(wù)的 MVCC 版本蹦掐，TiFlash 的數(shù)據(jù)同步粒度可以小到 Raft Log 的級(jí)別。另外一些新的功能仍然可以以 SQL 的接口對(duì)外提供僵闯，例如全文檢索，用 SQL 其實(shí)也可以簡(jiǎn)潔的表達(dá)藤滥。這里我就不一一展開(kāi)了鳖粟。

我其實(shí)堅(jiān)信系統(tǒng)一定是朝著更智能、更易用的方向發(fā)展的拙绊，現(xiàn)在都 21 世紀(jì)了向图，你是希望每天拿著一個(gè) Nokia 再背著一個(gè)相機(jī)泳秀，還是直接一部手機(jī)搞定？

?作者介紹

黃東旭榄攀，分布式系統(tǒng)專家嗜傅，架構(gòu)師，開(kāi)源軟件作者檩赢。PingCAP 聯(lián)合創(chuàng)始人兼 CTO吕嘀，知名開(kāi)源項(xiàng)目 Codis / TiDB / TiKV 主要作者，曾就職于微軟亞洲研究院贞瞒，網(wǎng)易有道及豌豆莢偶房。2015 年創(chuàng)業(yè)，成立 PingCAP军浆，致力于下一代開(kāi)源分布式數(shù)據(jù)庫(kù)的研發(fā)工作棕洋，擅長(zhǎng)分布式存儲(chǔ)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)，高并發(fā)后端架構(gòu)設(shè)計(jì)乒融。

?推薦閱讀

經(jīng)常思考一個(gè)問(wèn)題掰盘，為什么我們需要分布式？很大程度或許是不得已而為之赞季。如果摩爾定律不會(huì)失效庆杜，如果通過(guò)低成本的硬件就能解決互聯(lián)網(wǎng)日益增長(zhǎng)的計(jì)算存儲(chǔ)需求，是不是我們也就不需要分布式了碟摆。

過(guò)去的二三十年晃财，是一場(chǎng)軟件工程師們自我拯救的，浩浩蕩蕩的革命典蜕。分布式技術(shù)的發(fā)展断盛，深刻地改變了我們編程的模式，改變了我們思考軟件的模式愉舔。通過(guò)隨處可見(jiàn)的 X86 或者 Arm 機(jī)器钢猛，構(gòu)建出一個(gè)無(wú)限擴(kuò)展的計(jì)算以及存儲(chǔ)能力，這是軟件工程師最浪漫的自我救贖轩缤。

PingCAP 聯(lián)合 InfoQ 共同策劃出品“分布式系統(tǒng)前沿技術(shù)”專題命迈， 邀請(qǐng)轉(zhuǎn)轉(zhuǎn)、Pulsar火的、微眾銀行壶愤、UCloud、知乎馏鹤、貝殼金服等技術(shù)團(tuán)隊(duì)共同參與征椒，從數(shù)據(jù)庫(kù)、硬件湃累、測(cè)試勃救、運(yùn)維等角度碍讨，共同探索這個(gè)古老領(lǐng)域的新生機(jī)。