資料庫的工程架構設計必須考慮的內容：
前面的七篇文章，從思路和方**的角度介紹了微服務中的粒度、高可用、高併發、負載均衡以及微服務的重要元件連線池的一些基本問題。
在系統架構中，最容易先成為瓶頸的往往是持久層，後續的文章將會對如何進行資料庫的架構進行思路上的梳理。
本篇的內容主要是資料庫讀效能的提公升和引出資料庫設計要考慮哪些問題。
資料庫如何設計
沈老師常說的一句話：「任何脫離業務的架構，都是耍流氓」。
資料庫的設計主要就是兩個方面：庫表設計、索引設計，而它們的設計指導：
根據「業務模式」，設計庫表結構
根據「訪問模式」，設計索引結構
讀效能如何提公升
提公升讀效能，最先想到的就是建立索引，但它也有潛在的問題:
寫效能降低，每多建立乙個索引，就會多一棵b+樹，那麼寫操作的時候，就會涉及到更多的b+樹，物理層面就是更多的資料頁
索引占用記憶體大（如果建立了過多的索引，有些還是不常用的），buffer命中率降低，讀效能降低
為不同例項，建立不同的索引
如圖就是，主庫只負責寫入，所以不需要索引，對線上提供服務的索引，建立了uid的索引，為線下操作（比如簡單的統計分析，後台訪問等）提供服務的還要建立一些其它的索引。
當然，這會造成運維上的成本，不同的例項不同的索引設計需要額外的管理成本。
增加從庫
這是首先很容易想到的方式，讀寫分離的主從架構的目的就是為了擴充套件讀效能，這一方案已經在前面的文章多有提及，這裡就不再重複了。需要明確的就是對於乙個問題的解決方案要追問：它解決什麼問題、它沒有解決什麼問題，它帶來了什麼新問題。對於主從架構而言：
解決什麼問題：讀效能水平擴充套件的問題、讀庫高可用
沒有解決什麼問題：寫高可用、寫擴充套件
帶來了什麼新問題：主從一致性問題
增加快取
快取是提公升效能萬金油的方法，但是引入快取也會帶來一系列的新問題，這會在後續快取的章節裡再詳細說明，這裡先簡單的講一下帶快取的持久層的讀流程：
上游先訪問快取，如果快取裡面有資料，則取得資料後直接返回
如果快取裡沒有資料則訪問資料庫
再把取到的資料放入快取
至於快取的不一致性問題後續再討論。
快取的設計我們要考慮的是不「雪崩」，不雪崩可以做快取高可用，也可以做快取分片，分片的粒度就是某一分片不可用的時候不至於就打崩資料庫。
資料庫的工程架構設計必須考慮的內容：
讀效能提公升
高可用一致性保障
擴充套件性垂直拆分
這五個方面也是後續資料庫章節的主要內容了。
微服務合集：
【成為架構師3-1】服務化：微服務架構，究竟解決什麼問題
【成為架構師3-2】服務化：微服務的粒度，究竟要細到什麼程度
【成為架構師3-3】服務化：必須保證高可用
【成為架構師3-4】服務化：必須支援高併發
【成為架構師3-5】服務化：必須搞定負載均衡
【成為架構師3-6】服務化：連線池，微服務的基礎元件
【成為架構師3-7】服務化：連線池，高可用、可擴充套件、負載均衡都離不開它
如何成為真正的資料架構師
下面是內容概要 1 為什麼需要構建資料結構？1 資料標準不一致 2 資料模型管理混亂 3 深入的效能的問題無法解決 4 sql語句編寫水平不高導致出現嚴重效能問題 5 開發人員對執行計畫收悉 6 上線前缺乏審計 7 相對複雜的資料處理能力欠缺 8 資料質量差需要執行資料質量管理 2 資料管理組織角色...
如何成為架構師系列 前言
很多it新人都對架構感興趣，我的團隊裡打算往架構方向發展的同事也不少 我在乙個二十人左右的軟體團隊裡任部門經理 他們會問我要往哪個方向去努力，看什麼書啊，積累什麼技能啊，但怎麼說呢，或許是我的見識有限，我覺得很難用幾句話說清這件事情。上網搜尋 如何成為架構師 大部分人都說得靠經驗 得積累等等。去買架...
如何成為專業大資料架構師？
架構師按照專注領域不同，可分為企業架構師 基礎結構架構師 特定技術架構和解決方案架構師等，專職架構師往往偏向基礎結構架構師和特定技術架構師，專職架構師不負責具體的業務系統，而又對所有的系統負責，很少直接負責專案，但對專案要有提前把控，面對的是更大的團隊和更大的問題域。想要成為專職架構師，就要明確專職...