阿里P8四面-如何設計一個高併發系統?

1 為什麼面試官愛問這種面試題？

因為招聘中大家都有這個要求。

技術強的人，在網際網路公司肯定負責過高併發模組，那奪取offer太簡單了。可惜大部分初級工程師甚至高併發程式碼都沒想過怎麼寫！ 不是說只要用個redis快取，用個mq非同步削峰就搞定了！真實的要複雜很多倍。

面試官問你如何設計一個高併發系統，其實多半是因為知道你沒幹過高併發。看你簡歷也沒啥特別的，所以就問問你，如何設計。就是想考察你是否有技術儲備。

最好是招聘個真正有高併發經驗的，但眾所周知國內缺乏這種中高階開發。所以退而求其次，招個至少研究過的，也比招個啥想法也沒有的好。

話不多說，開始乾貨輸出，來看如何回答該問題！

2 服務拆分

將一個服務拆為多個服務。每個服務單獨連一個數據庫，這樣原本只有一個庫的，現在有多個數據庫，最容易做到的抗高併發。即微服務架構。

3 快取

高併發場景，大多

讀多寫少

，可以在資料庫和快取裡都寫一份，然後讀時大量走快取。

而Redis輕輕鬆鬆單機幾萬併發，所有系統都有快取中介軟體。所以考慮在你的專案中，讓承載主要請求的讀場景，使用快取來抗吧。

4 訊息佇列

可能還是會出現高併發寫場景（秒殺場景）。那絕對搞掛你的系統，11。11都得卡，你要是用Redis承載寫肯定不行，它是快取，資料隨時被LRU，資料格式還簡單，沒有事務支援。 所以該用MySQL還得用MySQL。咋辦？

用MQ！大量的寫請求灌入MQ，排隊一個個慢慢來，後邊系統消費後慢慢寫，控制在MySQL的承載範圍。 所以考慮你的專案裡，那些寫場景，用MQ非同步寫，提升併發性。MQ單機抗幾萬併發也ok。

5 分庫分表

可能到最後的資料庫層，還是免不了抗高併發。 那麼就將一個數據庫拆為多個庫，多個庫來抗更高併發。 將一個表拆分為多個表，每個表的資料量保持少一點，提高SQL效能。

6 讀寫分離

資料庫層的承載可能也大多是讀多寫少，那就沒必要所有請求都集中在一個庫。 可以設計主從架構，主庫寫，從庫讀，實現讀寫分離。如果讀流量太多，再加從庫。

7 Elasticsearch

分散式，可擴容。一些較簡單的查詢、統計類的、全文搜尋類的操作，可考慮使用ES承載。

8 總結

其實設計遠不止說的這麼簡單，很多細節需要考慮： 哪些才需要分庫分表，單庫單表跟分庫分表如何join，哪些資料才放進快取…… 一旦做過一次，做好一次，以後都會非常吃香。