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

無論哪個時代，存儲都是一個重要的話題，今天先聊聊數(shù)據(jù)庫。在過去的幾年，數(shù)據(jù)庫技術(shù)上出現(xiàn)了幾個很明顯的趨勢。

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

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

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

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

分布式 SQL 數(shù)據(jù)庫登上舞臺，ACID 全面回歸

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

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

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

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

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

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

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

3、冷熱數(shù)據(jù)分離，這個很好理解，將不常用的數(shù)據(jù)分片，分析型的副本，數(shù)據(jù)備份放到 S3 上，極大地降低成本。

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

例子還有很多，我就不一一列舉了?？傊业挠^點是云服務(wù) API 的能力會像過去的代碼標(biāo)準(zhǔn)庫一樣，是大家可以依賴的東西，雖然現(xiàn)在公有云的 SLA 仍然不夠理想，但是長遠(yuǎn)上看，一定是會越來越完善的。

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

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

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

第一個問題并沒有一個明確的答案，但是我覺得肯定不是越細(xì)越好的，而且這個和 Workload 有關(guān)，比如如果沒有那么大量的數(shù)據(jù)，直接在 MySQL 或者 PostgreSQL 上跑分析查詢其實一點問題也沒有，沒有必要非去用 Redshift。雖然沒有直接的答案，但是我隱約覺得第一個問題和第二個問題是息息相關(guān)的，畢竟沒有銀彈，就像 OLAP 跑在列存儲引擎上一定比行存引擎快，但是對用戶來說其實可以都是 SQL 的接口。

SQL 是一個非常棒的語言，它只描述了用戶的意圖，而且完全與實現(xiàn)無關(guān)，對于數(shù)據(jù)庫來說，其實可以在 SQL 層的后面來進(jìn)行切分，在 TiDB 中，我們引入 TiFlash 就是一個很好的例子。動機(jī)很簡單：

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

2、數(shù)據(jù)之間的同步在一個系統(tǒng)之下才能盡量保持更多的信息，例如，TiFlash 能保持 TiDB 中事務(wù)的 MVCC 版本，TiFlash 的數(shù)據(jù)同步粒度可以小到 Raft Log 的級別。另外一些新的功能仍然可以以 SQL 的接口對外提供，例如全文檢索，用 SQL 其實也可以簡潔的表達(dá)。這里我就不一一展開了。

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

責(zé)任編輯：ct