分布式系統 in 2010s ：存儲之資料庫篇

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

無論哪個時代，存儲都是一個重要的話題，今天先聊聊資料庫。在過去的幾年，資料庫技術上出現了幾個很明顯的趨勢。

存儲和計算進一步分離

我印象中最早的存儲-計算分離的嘗試是 Snowflake，Snowflake 團隊在 2016 年發表的論文《The Snowflake Elastic Data Warehouse》是近幾年我讀過的最好的大資料相關論文之一，尤其推薦閱讀。Snowflake 的架構關鍵點是在無狀态的計算節點 + 中間的緩存層 + S3 上存儲資料，計算并不強耦合緩存層，非常符合雲的思想。從最近 AWS 推出的 RedShift 冷熱分離架構來看，AWS 也承認 Snowflake 這個搞法是先進生産力的發展方向。另外這幾年關注資料庫的朋友不可能不注意到 Aurora。不同于 Snowflake，Aurora 應該是第一個将存儲-計算分離的思想用在 OLTP 資料庫中的産品，并大放異彩。Aurora 的成功在于将資料複制的粒度從 Binlog降低到 Redo Log ，極大地減少複制鍊路上的 IO 放大。而且前端複用了 MySQL，基本做到了 100% 的應用層 MySQL 文法相容，并且托管了運維，同時讓傳統的 MySQL 适用範圍進一步拓展，這在中小型資料量的場景下是一個很省心的方案。

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

我認為 Aurora 是一個很好的迎合 90% 的公有雲網際網路使用者的方案：100% MySQL 相容，對一緻性不太關心，讀遠大于寫，全托管。但同時，Aurora 的架構決定了它放棄了 10% 有極端需求的使用者，如全局的 ACID 事務+ 強一緻，Hyper Scale（百 T 以上，并且業務不友善拆庫），需要實時的複雜 OLAP。這類方案我覺得類似 TiDB 的以 Shared-nothing 為主的設計才是唯一的出路。作為一個分布式系統工程師，我對任何不能水準擴充的架構都會覺得不太優雅。

分布式 SQL 資料庫登上舞台，ACID 全面回歸

回想幾年前 NoSQL 最風光的時候，大家恨不得将一切系統都使用 NoSQL 改造，雖然易用性、擴充性和性能都不錯，但是多數 NoSQL 系統抛棄掉資料庫最重要的一些東西，例如 ACID 限制，SQL 等等。NoSQL 的主要推手是網際網路公司，對于網際網路公司的簡單業務加上超強的工程師團隊來說當然能用這些簡單工具搞定。

但最近幾年大家漸漸發現低垂的果實基本上沒有了，剩下的都是硬骨頭。

最好的例子就是作為 NoSQL 的開山鼻祖，Google 第一個搞了 NewSQL （Spanner 和 F1）。在後移動時代，業務變得越來越複雜，要求越來越實時，同時對于資料的需求也越來越強。尤其對于一些金融機構來說，一方面産品面臨着網際網路化，一方面不管是出于監管的要求還是業務本身的需求，ACID 是很難繞開的。更現實的是，大多數傳統公司并沒有像頂級網際網路公司的人才供給，大量曆史系統基于 SQL 開發，完全遷移到 NoSQL 上肯定不現實。

在這個背景下，分布式關系型資料庫，我認為這是我們這一代人，在開源資料庫這個市場上最後一個 missing part，終于慢慢流行起來。這背後的很多細節由于篇幅的原因我就不介紹，推薦閱讀 PingCAP TiFlash 技術負責人 maxiaoyu 的一篇文章《從大資料到資料庫》，對這個話題有很精彩的闡述。

雲基礎設施和資料庫的進一步整合

在過去的幾十年，資料庫開發者都像是在單打獨鬥，就好像作業系統以下的就完全是黑盒了，這個假設也沒錯，畢竟軟體開發者大多也沒有硬體背景。另外如果一個方案過于綁定硬體和底層基礎設施，必然很難成為事實标準，而且硬體非常不利于調試和更新，成本過高，這也是我一直對定制一體機不是太感興趣的原因。但是雲的出現，将 IaaS 的基礎能力變成了軟體可複用的單元，我可以在雲上按需地租用算力和服務，這會給資料庫開發者在設計系統的時候帶來更多的可能性，舉幾個例子：

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

可以借助 Fargate + EKS 這種輕量級容器 + Managed K8s 的服務，讓我們的資料庫在面臨突發熱點小表讀的場景（這個場景幾乎是 Shared-Nothing 架構的老大難問題），比如在

QQ靓号出售平台

TiDB 中通過 Raft Learner 的方式，配合雲的 Auto Scaler 快速在新的容器中建立隻讀副本，而不是僅僅通過 3 副本提供服務；比如動态起 10 個 pod，給熱點資料建立 Raft 副本（這是我們将 TiKV 的資料分片設計得那麼小的一個重要原因），處理完突發的讀流量後再銷毀這些容器，變成 3 副本。

冷熱資料分離，這個很好了解，将不常用的資料分片，分析型的副本，資料備份放到 S3 上，極大地降低成本。

RDMA/CPU/超算 as a Service，任何雲上的硬體層面的改進，隻要暴露 API，都是可以給軟體開發者帶來新的好處。

例子還有很多，我就不一一列舉了。總之我的觀點是雲服務 API 的能力會像過去的代碼标準庫一樣，是大家可以依賴的東西，雖然現在公有雲的 SLA 仍然不夠理想，但是長遠上看，一定是會越來越完善的。

是以，資料庫的未來在哪裡？是更加的垂直化還是走向統一？對于這個問題，我同意這個世界不存在銀彈，但是我也并不像我的偶像，AWS 的 CTO，Vogels 博士那麼悲觀，相信未來是一個割裂的世界（AWS 恨不得為了每個細分的場景設計一個資料庫）。過度地細分會加大資料在不同系統中流動的成本。解決這個問題有兩個關鍵：

資料産品應該切分到什麼粒度？

使用者可不可以不用知道背後發生了什麼？

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

SQL 是一個非常棒的語言，它隻描述了使用者的意圖，而且完全與實作無關，對于資料庫來說，其實可以在 SQL 層的後面來進行切分，在 TiDB 中，我們引入 TiFlash 就是一個很好的例子。動機很簡單：

使用者其實并不是資料庫專家，你不能指望使用者能 100% 在恰當的時間使用恰當的資料庫，并且用對。

資料之間的同步在一個系統之下才能盡量保持更多的資訊，例如，TiFlash 能保持 TiDB 中事務的 MVCC 版本，TiFlash 的資料同步粒度可以小到 Raft Log 的級别。

另外一些新的功能仍然可以以 SQL 的接口對外提供，例如全文檢索，用 SQL 其實也可以簡潔的表達。這裡我就不一一展開了。

我其實堅信系統一定是朝着更智能、更易用的方向發展的，現在都 21 世紀了，你是希望每天拿着一個 Nokia 再背着一個相機，還是直接一部手機搞定？