轉載：http://blog.itpub.net/70000181/viewspace-2776766/
面試題剖析
爲什麼要分庫分表？（設計高併發系統的時候，數據庫層面該如何設計？）
說白了，分庫分表是兩回事兒，大家可別搞混了，可能是光分庫不分表，也可能是光分表不分庫，都有可能。我先給大家拋出來一個場景：
假如我們現在是一個小創業公司(或者是一個BAT公司剛興起的一個新部門)，現在註冊用戶就20萬，每天活躍用戶就1萬，每天單表數據量就1000，然後高峯期每秒鐘併發請求最多就10。天，就這種系統，隨便找一個有幾年工作經驗的，然後帶幾個剛培訓出來的，隨便幹什麼都可以。
結果沒想到我們運氣居然這麼好，碰上個CEO帶着我們走上了康莊大道，業務發展迅猛，過了幾個月，註冊用戶數達到了2000萬！每天活躍用戶數100萬！每天單表數據量10萬條!高峯期每秒最大請求達到1000！同時公司還順帶着融資了兩輪，進賬了幾個億人民幣啊!公司估值達到了驚人的幾億美金！這是小獨角獸的節奏！
好吧，沒事，現在大家感覺壓力已經有點大了，爲啥呢?因爲每天多10萬條數據，一個月就多300萬條數據，現在咱們單表已經幾百萬數據了，馬上就破千萬了。但是勉強還能撐着。高峯期請求現在是1000，咱們線上部署了幾臺機器，負載均衡搞了一下，數據庫撐1000QPS也還湊合。但是大家現在開始感覺有點擔心了，接下來咋整呢..... .
在接下來幾個月，我的天，CEO 太牛逼了，公司用戶數已經達到1億，公司繼續融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成爲了國內今年最牛逼的明星創業公司!天，我們太幸運了。
但是我們同時也是不幸的，因爲此時每天活躍用戶數上千萬，每天單表新增數據多達 50萬，目前一個表總數據量都已經達到了兩三千萬了!扛不住啊!數據庫磁盤容量不斷消耗掉!高峯期併發達到驚人的
5000~8000!別開玩笑了，哥。我跟你保證，你的系統支撐不到現在，已經掛掉了！
好吧，所以你看到這裏差不多就理解分庫分表是怎麼回事兒了，實際上這是跟着你的公司業務發展走的，你公司業務發展越好，用戶就越多，數據量越大，請求量越大，那你單個數據庫一定扛不住。
分表
比如你單表都幾千萬數據了，你確定你能扛住麼？絕對不行，單表數據量太大，會極大影響你的 sql 執行的性能，到了後面你的 sql可能就跑得很慢了。一般來說，就以我的經驗來看，單表到幾百萬的時候，性能就會相對差一些了，你就得分表了。
分表是啥意思？就是把一個表的數據放到多個表中，然後查詢的時候再查一個表。比如按照用戶id來分表，將一個用戶的數據就放在一個表中。然後操作的時候你對一個用戶就操作那個表就好了。這樣可以控制每個表的數據量在可控的範圍內，比如每個表就固定在 200萬以內。
分庫
分庫是啥意思？就是你一個庫一般我們經驗而言，最多支撐到併發2000，一定要擴容了，而且一個健康的單庫併發值你最好保持在每秒1000 左右，不要太大。那麼你可以將一個庫的數據拆分到多個庫中，訪問的時候就訪問一個庫好了。
這就是所謂的分庫分表，爲啥要分庫分表？你明白了吧。
你們具體是如何對數據庫如何進行垂直拆分或水平拆分的？
水平拆分的意思，就是把一個表的數據給弄到多個庫的多個表裏去，但是每個庫的表結構都一樣，只不過每個庫表放的數據是不同的，所有庫表的數據加起來就是全部數據。水平拆分的意義，就是將數據均勻放在更多的庫裏，然後用多個庫來扛更高的併發，還有就是用多個庫的存儲容量來進行擴容。
垂直拆分的意思，就是把一個有很多字段的表給拆分成多個表，或者是多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到一個表裏去，然後將較多的訪問頻率很低的字段放到另外一個表裏去。因爲數據庫是有緩存的，你訪問頻率高的行字段越少，就可以在緩存裏緩存更多的行，性能就越好。這個一般在表層面上做得較多一些。
還有表層面的拆分，就是分表，將一個表變成N個表，就是讓每個表的數據量控制在一定範圍內，保證SQL 的性能。否則單表數據量越大，SQL性能就越差。一般是200萬行左右，不要太多，但是也得看具體你怎麼操作，也可能是500萬，或者是100萬。你的SQL越複雜，就最好讓單錶行數越少。
涉及高併發系統，我該怎麼辦？
如果不想只是單純地做個底層CRUD的搬磚程序員，那麼對於高併發系統設計這一類的問題，你必須得掌握！不用慌，小編整理了46問，貫穿整個高併發系統設計的問題，涉及： 基礎、數據庫、緩存、消息隊列、分佈式、維護、實戰操練等7個部分的內容（並將每一問的答案解析整理完整）。
- 爲什麼要學習高併發系統設計？
- 高併發系統：它的通用設計方法是什麼
- 架構分層：我們爲什麼一定要這麼做
- 系統設計目標（一）：如何提升系統性能
- 系統設計目標（二）：系統怎樣做到高可用
- 系統設計目標（三）：如何讓系統易於擴展
- 面試現場第一期：當問到組件實現原理時，面試官是在***難你嗎？
- 池化技術：如何減少頻繁創建數據庫連接的性能損耗？
- 數據庫優化方案（一）：查詢請求增加時，如何做主從分離
- 數據庫優化方案（二）：寫入數據量增加時，如何實現分庫分表
- 發號器：如何保證分庫分表後ID的全局唯─性？
- NoSQL：在高併發場景下，數據庫和 NoSQL 如何做到互補？
- 緩存：數據庫成爲瓶頸後，動態數據的查詢要如何加速？
- 緩存的使用姿勢（一）：如何選擇緩存的讀寫策略？
- 緩存的使用姿勢（二）：緩存如何做到高可用？
- 緩存的使用姿勢（三）：緩存穿透了怎麼辦？
- CDN：靜態資源如何加速？
- 數據的遷移應該如何做？
- 消息隊列：秒殺時如何處理每秒上萬次的下單請求？
- 消息投遞：如何保證消息僅僅被消費一次？
- 消息隊列：如何降低消息隊列系統中消息的延遲？
- 面試現場第二期：當問到項目經驗時，面試官究竟想要了解什麼
- 從“心”出發，我還有無數個可能
- 高併發系統設計期中測試題目解析
- 系統架構：每秒1萬次請求的系統要做服務化拆分嗎？
- 微服務架構：微服務化後系統架構要如何改造？
- RPC框架：10萬 Q P S 下如何實現毫秒級的服務調用？
- 註冊中心：分佈式系統如何尋址？
- 分佈式Trace :橫跨幾十個分佈式組件的慢請求要如何排查？
- 負載均衡：怎樣提升系統的橫向擴展能力？
- A P I 網關：系統的門面要如何做呢？
- 多機房部署：跨地域的分佈式系統如何做？
- Service Mesh：如何屏蔽服務化系統的服務治理細節？
- 給系統加上眼睛：服務端監控要怎麼做？
- 應用性能管理：用戶的使用體驗應該如何監控？
- 壓力測試：怎樣設計全鏈路壓力測試平臺？
- 配置管理：成千上萬的配置項要如何管理？
- 降級熔斷：如何屏蔽非核心繫統故障的影響？
- 流量控制：高併發系統中我們如何操縱流量？
- 面試現場第三期：你要如何準備—場技術面試呢？
- 計數系統設計（一）：面對海量數據的計數器要如何做
- 計數系統設計（二）：50萬 Q PS下如何設計未讀數系統
- 信息流設計（一）：通用信息流系統的推理模式要如何做
- 信息流設計（二）：通用信息流系統的拉模式要如何做
- 高併發下如何發現和排查問題？
- 我們如何準備抵抗流量峯值？
答案解析原件（如下圖，內容過多近400頁的 高併發系統設計文檔，無法一一將答案上傳）
|
1
|
原件獲取；找微u；mf97532 |
此外，怎麼肝下MySQL？
想肝MySQL說難也還行吧，不說別的，我準備了 167道超高頻的MySQL面試問題（附解析，包含從基礎-索引-鎖-日誌-調優等內容），想做Java高級程序員乃至Java架構師，想拿阿里P7-P8的offer，先將下面這些內容裝進腦子裏吧！
答案解析原件（如下圖，內容過多64頁的 167道超高頻的MySQL面試文檔，無法一一將答案上傳，但已整理如下的文檔）
