如何設(shè)計一個高并發(fā)系統(tǒng)？
如果你確實有真才實學(xué)柱嫌，在互聯(lián)網(wǎng)公司里锋恬，干過高并發(fā)系統(tǒng)，那你拿Offer编丘，基本如探囊取物一樣簡單与学。
但你要真干過高并發(fā)系統(tǒng)，面試官絕對不會問這個問題嘉抓，否則他就不太明智了索守。
因為真正干過高并發(fā)的人一定知道，脫離了業(yè)務(wù)的系統(tǒng)架構(gòu)抑片，都是紙上談兵卵佛。
真正在復(fù)雜業(yè)務(wù)場景、而且還高并發(fā)的時候敞斋，這個系統(tǒng)架構(gòu)一定很難搞截汪。
要理解高并發(fā)，就得從高并發(fā)的根源出發(fā)——為什么會有高并發(fā)植捎？為什么高并發(fā)就很牛X衙解？
因為剛開始，系統(tǒng)都是連接數(shù)據(jù)庫的焰枢，但是數(shù)據(jù)庫支撐到每秒并發(fā)兩三千的時候蚓峦，基本就快完了舌剂。
數(shù)據(jù)庫如果瞬間承載每秒5000、8000暑椰、甚至上萬的并發(fā)霍转，一定會宕機，因為比如MySQL就壓根兒扛不住這么高的并發(fā)量一汽。
所以為什么高并發(fā)牛X避消？
因為現(xiàn)在網(wǎng)民越來越多，很多App角虫、網(wǎng)站沾谓、系統(tǒng)承載的都是高并發(fā)請求，高峰期每秒并發(fā)量幾千都很正常戳鹅。就像每年的雙十一，一年比一年的峰值高昏兆，每秒并發(fā)幾十萬枫虏，都是灑灑水。
那么爬虱，我們可以從以下幾個方面隶债，來進行考慮：
1、系統(tǒng)拆分跑筝。將一個系統(tǒng)拆分為多個子系統(tǒng)死讹，用Dubbo來搞。然后每個系統(tǒng)連一個數(shù)據(jù)庫曲梗，這樣本來就一個庫赞警，現(xiàn)在多個數(shù)據(jù)庫，就可以抗高并發(fā)了虏两。
2愧旦、緩存。必須得用緩存定罢。大部分的高并發(fā)場景笤虫，都是讀多寫少。你完全可以在數(shù)據(jù)庫和緩存里都寫一份祖凫，然后讀的時候琼蚯，大量走緩存就行了。
3惠况、MQ遭庶。必須得用MQ。
可能你還是會出現(xiàn)高并發(fā)寫的場景售滤，比如說一個業(yè)務(wù)操作里罚拟，要頻繁搞數(shù)據(jù)庫幾十次台诗，增刪改增刪改，瘋了赐俗。
那你咋辦拉队？用MQ吧，大量寫請求灌入MQ里阻逮，排隊慢慢玩兒粱快，后邊系統(tǒng)消費后慢慢寫，控制在MySQL承載范圍之內(nèi)叔扼。
4事哭、分庫分表」细唬可能到了最后鳍咱，數(shù)據(jù)庫層面還是免不了抗高并發(fā)的要求，好吧与柑，那么就將一個數(shù)據(jù)庫谤辜，拆分為多個庫，多個庫來抗更高的并發(fā)价捧。
然后將一個表丑念，拆分為多個表，每個表的數(shù)據(jù)量结蟋，保持少一點脯倚，提高SQL跑的性能。
5嵌屎、讀寫分離推正。多數(shù)時候，數(shù)據(jù)庫可能也是讀多寫少编整，沒必要所有請求舔稀，都集中在一個庫上。
可以搞個主從架構(gòu)掌测，主庫寫入内贮，從庫讀取，搞一個讀寫分離汞斧。讀流量太多的時候夜郁，還可以加更多的從庫。
6粘勒、Elasticsearch竞端，可以考慮用ES。ES是分布式的庙睡，可以隨便擴容事富，分布式天然就可以支撐高并發(fā)技俐，因為動不動就可以擴容加機器，來抗更高的并發(fā)统台。
如何解決單點故障雕擂？
一個網(wǎng)站，從基礎(chǔ)的硬件層贱勃、到操作系統(tǒng)層井赌、到數(shù)據(jù)庫層、到應(yīng)用程序?qū)庸笕拧⒃俚骄W(wǎng)絡(luò)層仇穗，都有可能產(chǎn)生單點故障。
如果要有效地消除單點故障戚绕，最重要的一點纹坐，是設(shè)計的時候，要盡量避免引入單點舞丛，隨著架構(gòu)的變化恰画，定期審查系統(tǒng)潛在的單點，也是有必要的瓷马。
大體可以從以下幾個方面，來消除單點故障：
增加硬盤跨晴，做鏡像欧聘。讓出錯的概率降低。
網(wǎng)卡與網(wǎng)線的單點問題端盆。系統(tǒng)里面最容易物理損壞的就是網(wǎng)線怀骤，網(wǎng)卡綁定（NIC bonding）是一個很簡單、很通用的辦法焕妙，建議你配置多個網(wǎng)卡蒋伦。
SSH服務(wù)器和Telnet服務(wù)器共存。畢竟SSH和Telnet焚鹊，都不是百分之百靠譜的事痕届；
IDC機房的單點。由于中國特色的“南北互通”末患，所以選擇IDC機房的時候研叫，一定要有冗余。
靠譜的DNS解析璧针。
原文https://csdn-app.csdn.net/csdn.apk
