近年來，隨着國內互聯網行業的加速發展，以及摩爾定律的實效，千億數據的潘多拉魔盒早已打開，傳統的開源/商業關係數據庫早已遇到了容量的瓶頸。而容量告警則不僅意味着業務發展收到影響，同時對現有系統的穩定性和可用性、可維護性，也帶來極大的挑戰。
從十年前起，淘寶等公司就遇到這類制約業務發展的技術問題，進而有了 TDDL 框架，2016 年噹噹網也發起了 Sharding-JDBC 項目，通過包裝 JDBC，來屏蔽 MySQL 分庫分表的邏輯，讓業務系統想使用單機數據庫一樣方便。
後來，JDBC 封裝框架逐漸演變到中間件，在 TDDL 的基礎上，淘寶逐漸發展出來了 DRDS，在 Sharding-JDBC 轉移到 Apache 和京東數科以後又孵化出來了 Sharding-Proxy，都是以一個虛擬的 MySQL Server 提供更透明和無侵入的客戶端接入服務。其他的中間件，像 MyCat 和 DBLE 也方興未艾。
另一方面，隨着 Google 的 Spanner，阿里的 OceanBase 和 PolarDB，AWS 的 Aurora，PingCAP 的 TiDB，Cockroachlabs 的 CockroachDB 等商業或開源的技術作爲代表，分佈式數據庫開始大規模興起。這些技術試圖通過一個直接的數據庫來解決上述問題，而不僅僅是類庫或中間件，這種增強 MySQL/PGSQL 的間接方式。當然，分佈式數據庫本身的複雜度，是另外一個話題。
以上種種對於企業來說，都是試圖通過採用類似 Apache ShardingSphere 這種分佈式的數據庫中間件、或者 CockroachDB 這種分佈式數據庫作爲整體解決方案，增強數據庫的吞吐能力，保證高可用和實時強一致性的同時，實現線性的水平擴展能力，在一定規模上提升企業信息系統的數據管理上限。本文將從這個整體的發展過程談起，詳細介紹每一個階段技術的特點、解決的問題，適用的場景，帶領大家瞭解千億數據的祕密。
計劃寫作大綱：
-
從單機數據庫講起
-
MySQL 的高可用與短板
-
-
分庫分表的優勢與陷阱
-
哪些場景下我們需要用分庫分表
-
-
數據庫中間件的技術選型
-
什麼時候引入數據庫中間件
-
-
NoSQL 與 NewSQL
-
當我們談分佈式數據庫的時候，我們在談什麼典型的
-
幾個分佈式數據庫
-
第一時間圍觀地址：https://gitbook.cn/gitchat/activity/5eb2e609edf3136c22fcffd2