今天無意間在極客時間上看到了這個標題，看完後有所收穫，分享給你，以下是原文精簡版：
分佈式數據庫的應用場景主要特徵是海量併發，所以理論上說，業務規模越大，使用分佈式數據庫的需求也就越迫切。
工行的選擇
圖中的 DBLE 是企業級開源分佈式中間件，江湖人送外號 “MyCat Plus”；以其簡單穩定，持續維護，良好的社區環境和廣大的羣衆基礎得到了社區的大力支持
工行只所以沒有選擇真正的分佈式數據庫，而是採用 DBLE + MySQL 的形式，有三個原因，一是當時新的分佈式數據庫還沒有普及，爲了系統的穩定性，不亦採用未被充分實踐的產品；第二，選擇 MySQL 是因爲它的普及程度足夠高；第三，選擇 DBLE 則因爲它是在 MyCat 的基礎上研發，號稱是“增強版 MyCat”，由於 MyCat 已經有較多的應用案例，所以這一點給 DBLE 帶來不少加分。
郵蓄銀行的選擇
郵儲銀行的零售用戶在 2019 年已經超過 6 億。這個龐大的用戶基數使得郵儲銀行也早早地就開始探討分佈式數據庫的使用。
那他們採用了什麼方案呢？可能又讓你失望了，他們也沒有選擇分佈式數據庫。郵儲的核心業務系統改造方案更接近於單元化架構，所以連分佈式中間件都沒使用。它的設計思路就是將原來商業數據庫拆分成若干個小的單體數據庫，分別設置對應的應用實例。郵儲在單體數據庫上選擇了 PostgreSQL，這個在銀行業中是相對較少使用的。
通過分庫分表和讀寫分離實現分佈式數據訪問功能；基於可靠消息的最終一致性和基於衝正模型的反向處理實現分佈式事務功能，弱化了分佈式數據庫的作用，更加強調整體架構改造，在應用系統層面做了更多的工作。
北京銀行（NewSQL）
北京銀行是城市商業銀行中的佼佼者，但相對於前幾家銀行，在資產規模和用戶數量上有較大的差距。北京銀行從 2018 年開始，先後在網聯支付系統和網貸系統中應用了 TiDB。事實上，很多比北京銀行規模更小的城市商業銀行，比如南京銀行（OceanBase）、張家港銀行（TDSQL）都已經上線了分佈式數據庫。
表面上，我們似乎很難捕捉到他們替換數據庫的動因。從業務壓力的角度，業務量通常沒有達到海量併發級別；同時城商行通常也不涉及“主機下移”帶來可用性下降問題。那麼，他們爲什麼要做出這個選擇呢？
我覺得主要有三點原因。國產化的訴求由於各種原因，繼續依賴 Oracle 這樣的國外商業產品，很可能讓銀行將面臨更大的風險。而對於小型銀行來說，使用開源數據庫還是分佈式數據庫，在成本上可能差異並不大。隨着國內廠商加大技術投入，隱約有一種趨勢，就是分佈式數據庫正在逐步成爲國產數據庫的代名詞。那些原本深耕單體數據庫技術的廠商，比如達夢、人大金倉，也在朝着分佈式架構轉型。所以，選擇分佈式數據庫也就滿足了國產化的訴求。實際收益由於小型銀行的數據量並不大，上線分佈式數據庫後集羣的節點規模沒有大幅增長，對運維的衝擊也相對小些。此外，利用分佈式數據庫的多租戶特性，轉變成類似 Aurora 使用方式，還能降低數據庫實例管理的複雜度。所以，使用分佈式數據庫也是有一些實際收益的。技術潮流這也是我在開篇詞中說的，一旦技術的趨勢形成，就會在無形中影響人們的選擇。就像時尚潮流那樣，在同等價位下，大家當然更願意選那些流行款式。今天，分佈式架構轉型就是這樣的潮流，微服務架構、分佈式數據庫甚至容器雲都是這個大潮下的浪花。在風險可控的前提下，受到技術潮流的影響，我覺得可能還會有更多的小型銀行會選擇分佈式數據庫。