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

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

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

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

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

單機MySQL的美好年代

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

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

單機+緩存

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

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

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

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

主從復制：讀寫分離

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

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

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

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

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

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

垂直拆分業務數據

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

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

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

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

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

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

水平分表

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

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

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

集群部署

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

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

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

NoSQL數據庫和搜索引擎

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

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

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

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

商品的基本信息存到MySQL、Oracle等關系型數據庫中；

商品的描述、詳情、評價等信息可以采用MongDB等文檔數據庫來存儲，可以提高IO讀寫性能；

商品的圖片采用分布式的文件系統HDFS；

商品的關鍵字可以使用搜索引擎ES、Solr；

商品的波段性熱點高頻信息可以使用內存型數據庫Redis、Tair；

商品的交易、價格計算、積分積累等可以使用第三方接口或者支付系統。

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

阿Q： 走著！

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

如果你有不同的意見或者更好的idea，歡迎聯系阿Q：可以關注“阿Q說代碼”，阿Q期待你的到來！

MySQL SQL 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。