故事篇：數據庫架構演變之路

故事的開頭總是這樣，適逢其會、猝不及防。今天我哼着 “也是黃昏的沙灘上，有着腳印兩對半......” 在海邊散步，迎面走來了一位身穿黃金甲的男子，來海邊還穿這麼花哨，真是個傻 X。定睛一看，這不是嘉文嗎？

❝

背景介紹：嘉文四世，德瑪西亞皇子，是有名的高富帥。與蓋倫、菊花信並稱草叢三劍客，整天嚷嚷着 “犯我德邦者，雖遠必誅”。

❞

「嘉文：」 我在老爸的支持下自己開了家銀行，最近有一個問題一直困擾着我：不知道怎樣才能使我的銀行業務處理起來又快又穩呢？

「阿 Q：」 內心 OS：我靠，土豪就是土豪呀，都開銀行了。（假裝淡定）你現在的模式是怎樣的呢？能不能簡單說一下你模式的轉變過程呢？

單機 MySQL 的美好年代

「嘉文：」 我首先把銀行定在了一個極具發展潛力的城郊上。從目前發展來看，我都佩服我自己。前期這邊人不是很多，所以我就僱傭了一個櫃員來處理存錢取錢的簡單業務。

「旁白:」 看到這種**「單機模式」**，相信大家都倍感親切吧，曾幾何時，大家都是從這種單機項目起步的。那時候項目比較小，而且業務邏輯也比較簡單，大家爲了能夠儘快地實現業務系統，驗證市場，會將所有的業務數據都存放在同一個數據庫中。

單機 + 緩存

「阿 Q：」 那你這一天也處理不了幾個人的業務呀，這要是趕上週末來幾十個人你就接待不了了呀。

「旁白：」 隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。

「嘉文：」 對呀，所以我就去別家銀行看了看，幾乎每家銀行都有一個漂亮的小姐姐在那裏接客。呸呸呸，是幫客戶辦理業務，所以我就又請了個大堂經理來負責辦理那些小額又簡單的業務。

「旁白：」 爲了儘快緩解用戶訪問的壓力，一般在優化數據庫的結構和索引的基礎上，會在應用服務器和數據庫服務器中間加一個緩存層來抵消掉一部分的數據庫查詢操作。

主從複製：讀寫分離

「阿 Q：」 嗯嗯，這樣確實解決了一部分問題。哎，我聽說去年你們那邊通地鐵了吧？這樣人流豈不是增加了，這樣一來，加上大堂經理應該也不夠用吧。

「旁白：」 增加數據庫緩存層只能緩解數據庫讀取壓力，攔截部分數據庫訪問請求。但是隨着用戶訪問量的進一步增長，讀寫集中在一個數據庫上讓數據庫不堪重負，數據庫訪問的瓶頸進一步凸顯出來。這個時候，就不得不對數據層的架構進行改造。

「嘉文：」 誰說不是呢，還好我機智，我又招了兩個人，把窗口進行了優化：A 專門負責存款業務，BC 窗口負責取款業務。這樣一來，存取款業務就分離了，處理效率也就增加了。

「旁白：」 我們會啓用多個數據庫實例，把數據庫劃分爲主庫和從庫：主庫負責寫入數據，又被稱爲寫庫；從庫負責讀取數據，又被稱爲讀庫，其中讀庫可以有多個。

❝

主從庫之間通過同步機制把主庫的數據同步到從庫，對於需要查詢最新寫入數據的場景，可以在緩存中多寫一份，通過緩存獲得最新數據。

❞

「主、從庫可以部署到同一臺服務器上，但是爲了提高性能，在資源充足情況下，最好部署到不同的服務器上。」

垂直拆分業務數據

「阿 Q：」 不錯不錯，沒想到你還有這招，讓我刮目相看呀。那你這邊除了存取款業務，就沒有其他的業務了嗎？

「嘉文：」 那肯定得有呀，我可不能讓他們老閒着聊天呀。我去年年底又增加了基金的業務，想着培養這批年輕人樹立理財的意識，我是不是太無私了。但是自從加了這些業務，人手又不夠了。哎！

「旁白：」 當我們使用了主從數據庫架構之後，我們會發現我們能支撐更多的用戶訪問和請求了。但隨着業務的進一步發展，如電商系統中增加了商品庫存系統，此時就會與原有的訂單系統搶佔數據庫資源，相互影響性能，導致數據庫的壓力進一步增大。

「阿 Q：」 聽說你去年沒少掙呀，那你是怎麼解決的呢？

「嘉文：」 （顯示出得意的表情）我直接從外邊挖來一個高管，讓他和他的團隊只負責基金等理財業務，我現有的團隊還在傳統的業務上。這樣他倆相互工作，互不影響。

「旁白：」 爲了緩解業務擴張導致的數據庫壓力問題，我們可以按照業務將數據庫進行垂直拆分：將訂單系統和商品庫存系統的數據庫分離開來，降低業務之間的資源競爭，使用獨有的數據庫進行存儲。

水平分表

「阿 Q：」 現在大家都全面實現小康社會了，人們手裏都有錢了，是不是現在存錢的人變多了呀。

「嘉文：」 昂，這不是前幾個月我又招了幾個大學生，擴展了一下櫃檯，專門用來負責存款業務嘛。

「旁白：」 以電商爲例，隨着用戶交易量的增多，單張訂單表已經無法滿足存儲的要求。此時我們可以將一張表拆成多張表來存儲，採用一定的策略進行水平擴展，將請求儘可能的均勻的分發到服務器的各個小表中，併發量也進一步得到提升。

集羣部署

「阿 Q：」 我聽蓋倫說你們那邊小區入駐率很高呀，人流變大了，業務也突飛猛進吧。

「嘉文：」 哈哈，這就是我最自豪的事了，我又開了一家銀行。照搬原來的模式，又搞了一套，這樣東邊和西邊各有一個就不用擔心忙不過來了。

「旁白：」 隨着數據量的持續猛增，我們可以採用集羣的方式來減輕訪問的壓力。但是集羣的性能並不能很好的滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。

NoSQL 數據庫和搜索引擎

「阿 Q：」 我去，太牛了老鐵，那你還愁眉苦臉的幹啥，聽你這麼一說，該愁眉苦臉的是我呀。

「嘉文：」 你有所不知，前幾天這邊的商場開業了，輻射了周邊，把周邊的好多人都吸引來了。存取款的人一多，忙不過來了，總不能再開一家吧，再開一家的成本和收益比太低了，不值當的。

「阿 Q：」 奧奧，原來如此。我覺得你可以這樣規劃：在東西兩家銀行裏都放幾臺 ATM 取款機，這樣他們就不會去櫃檯辦理存取款的小額任務了；再在新開的商場旁邊租個門店，扔幾臺 ATM 取款機，減少了人工成本，這樣你不就滿足逛商場的人的需求了？

「旁白：」 當我們數據庫中的數據數量和多樣性達到一定規模後，僅僅使用 MySQL 已經無法滿足我們的需求了，因此引進了其它的數據存儲方式。拿電商爲例，我們可以對其中的信息大致分類：

「嘉文：」 有道理呀，術業有專攻，這樣我晚上就可以睡個好覺了。走，帶你出去嗨去！

「阿 Q：」 走着！

❝

以上故事純屬虛構，只爲給大家演示一下數據庫架構的演變歷程。真實的銀行系統及業務如何辦理，阿 Q 沒有特別深入的研究，只是劇情需要杜撰了一下，僅爲了增加大家的理解。

❞

公衆號

如果你有不同的意見或者更好的idea，歡迎聯繫阿 Q：關注公衆號 “阿 Q 說代碼”，也可以加阿 Q 好友qingqing-4132，阿 Q 期待你的到來！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/U-6LHdb3yoE-JSBP5o-WCA

猜你喜歡