經常思考乙個問題，為什麼我們需要分布式？很大程度或許是不得已而為之。如果摩爾定律不會失效，如果通過低成本的硬體就能解決網際網路日益增長的計算儲存需求，是不是我們也就不需要分布式了。
過去的二三十年，是一場軟體工程師們自我拯救的，浩浩蕩蕩的革命。分布式技術的發展，深刻地改變了我們程式設計的模式，改變了我們思考軟體的模式。通過隨處可見的 x86 或者 arm 機器，構建出乙個無限擴充套件的計算以及儲存能力，這是軟體工程師最浪漫的自我救贖。
值 2019 年末，pingcap 聯合 infoq 共同策劃出品「分布式系統前沿技術」專題， 邀請轉轉、pulsar、微眾銀行、ucloud、知乎、貝殼金服等技術團隊共同參與，從資料庫、硬體、測試、運維等角度，共同探索這個古老領域的新生機。
系列一：儲存之資料庫篇
回看這幾年，分布式系統領域出現了很多新東西，特別是雲和 ai 的崛起，讓這個過去其實不太 ***y 的領域一下到了風口浪尖，在這期間誕生了很多新技術、新思想，讓這個古老的領域重新煥發生機。站在 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丟掉的東西當然能用某些工具簡單搞定。
但最近幾年大家漸漸發現低垂的果實基本上沒有了，剩下的都是硬骨頭。
最好的例子就是作為 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 架構的老大難問題），比如在 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 就是乙個很好的例子。動機很簡單：
1.使用者其實並不是資料庫專家，你不能指望使用者能 100% 在恰當的時間使用恰當的資料庫，並且用對。
2.資料之間的同步在乙個系統之下才能盡量保持更多的資訊，例如，tiflash 能保持 tidb 中事務的 mvcc 版本，tiflash 的資料同步粒度可以小到 raft log 的級別。
另外一些新的功能仍然可以以 sql 的介面對外提供，例如全文檢索，用 sql 其實也可以簡潔的表達。這裡我就不一一展開了。
我其實堅信系統一定是朝著更智慧型、更易用的方向發展的，現在都 21 世紀了，你是希望每天拿著乙個 nokia 再揹著乙個相機，還是直接一部手機搞定。
分布式儲存技術
分布式儲存技術 分布式儲存概念 與目前常見的集中式儲存技術不同，分布式儲存技術並不是將資料儲存在某個或多個特定的節點上，而是通過網路使用企業中的每台機器上的磁碟空間，並將這些分散的儲存資源構成乙個虛擬的儲存裝置，資料分散的儲存在企業的各個角落。結構化資料的儲存及應用所謂結構化資料是一種使用者定義的資...
分布式文件儲存資料庫 MongoDB
mongodb是乙個介於關聯式資料庫和非關聯式資料庫之間的產品，是非關聯式資料庫當中功能最豐富，最像關聯式資料庫的。他支援的資料結構非常鬆散，是類似json的bjson格式，因此可以儲存比較複雜的資料型別。mongo最大的特點是他支援的查詢語言非常強大，其語法有點類似於物件導向的查詢語言，幾乎可以實...
python分布式儲存系統 分布式系統
danger 什麼是分布式系統 分布式系統是由一組通過網路進行通訊 為了完成共同的任務而協調工作的計算機節點組成的系統。分布式系統的出現是為了用廉價的 普通的機器完成單個計算機無法完成的計算 儲存任務。其目的是利用更多的機器，處理更多的資料。首先需要明確的是，只有當單個節點的處理能力無法滿足日益增長...