故事的開頭總是這樣，適逢其會、猝不及防。今天我哼著“也是黃昏的沙灘上，有著腳印兩對半......”在海邊散步，迎面走來了一位身穿黃金甲的男子，來海邊還穿這麼花哨，真是個傻X。定睛一看，這不是嘉文嗎？
> 背景介紹：嘉文四世，德瑪西亞皇子，是有名的高富帥。與蓋倫、菊花信並稱草叢三劍客，整天嚷嚷著“犯我德邦者，雖遠必誅”。
嘉文： 我在老爸的支援下自己開了家銀行，最近有一個問題一直困擾著我：不知道怎樣才能使我的銀行業務處理起來又快又穩呢？
阿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：可以關注gzh“阿Q說程式碼”，也可以加阿Q好友qingqing-4132，阿Q期待你的到來！