事情的起因是這樣的：
從9月1號開始，成都市政府宣布了為期四天的全員核酸檢測。昨天下午，我們小區(qū)物業(yè)通知了預計14:00-17:00會進行檢測，告訴我們會挨個樓棟通知下去檢測。
結果一直拖到晚上也沒收到通知，我一直忙別的也沒留意，結果上網(wǎng)一看，關于成都核酸系統(tǒng)崩潰的各種段子已經(jīng)滿天飛了。
是的，成都核酸檢測系統(tǒng)，又崩潰了！
辛苦的大白們沒有辦法，都用上了這種古老的方式來尋找“信號”。
因為這個系統(tǒng)出了問題，導致核酸檢測工作非常緩慢，大量的市民排隊等待，平常排隊半小時能完成的，昨晚都要排隊好幾個小時。
到晚上23點半，物業(yè)直接通知只給部分人做，其他人可以洗洗睡了。好家伙，不知道有多少人白排了幾個小時隊。
這好好的系統(tǒng)它咋就崩潰了呢？
有網(wǎng)友挖出了一個中標公告，說這套系統(tǒng)背后使用的是浪潮的服務器：
一千多萬的項目，結果就這？
但隨后，有疑似浪潮的人出來回復：
人家說的很清楚，上面中標的只是基礎運維，這套軟件系統(tǒng)的設計另有其人。
隨后有人又開噴健康碼，噴鵝廠。
但實際上，崩的不是健康碼，而是大白使用的核酸采集錄入系統(tǒng)，這是兩套獨立的系統(tǒng)。
再接著，有人爆出這套軟件是東軟公司做的。
于是一時間，所有人把怒火對準了東軟，很快就把東軟這個詞條送上了微博熱搜榜第一的位置。
關于崩潰的原因，也有各種說法在朋友圈、微信群里流傳，一時難辨真假。
有說是這套系統(tǒng)背后使用的MySQL使用了超寬的大表：
有說是MySQL單表容量太大，造成性能下降：
還有的說是因為負載均衡不行，沒法支撐高并發(fā)。
總結起來基本上就兩個原因：
1、數(shù)據(jù)庫的問題，數(shù)據(jù)量大后，查詢檢索效率低下。
成都全市人口超過2000萬，每天一次核酸，那就是單日新增兩千萬條記錄，最近幾天一直在做，數(shù)據(jù)容量很快就是幾億的規(guī)模，如果后端用MySQL還不分表，那確實夠嗆。
2、高并發(fā)的問題，同一時間大量請求，服務器扛不住。
一般情況下，使用nginx負載均衡，單機能做到幾萬的并發(fā)量。但成都2000W+的人口規(guī)模，全面做核酸的情況下，幾萬的并發(fā)肯定是不夠用的。
倘若這套系統(tǒng)背后真的就是一個nginx+mysql(不分表)，那昨晚的情況也就不足為奇了。
好了，吃瓜歸吃瓜，我們還是要來點干貨，作為一個程序員，要在吃瓜中學會成長。
高并發(fā)之路
這篇文章，我們來回答一個問題：到底該怎么做高并發(fā)？
讓我們從零開始。
1、單機時代
一開始的時候，用戶量很少，一天就幾百上千個請求，一臺服務器就完全足夠。
我們用Java、Python、PHP或者其他后端語言開發(fā)一個Web后端服務，再用一個MySQL來存儲業(yè)務數(shù)據(jù)，它倆攜手工作，運行在同一臺服務器上，對外提供服務。
2、應用與數(shù)據(jù)庫分離
慢慢的，用戶量開始多了起來，一臺服務器有點夠嗆，把它們拆開成兩臺服務器，一臺專門運行Web服務，一臺專門用來運行數(shù)據(jù)庫，這樣它們就能獨享服務器上的CPU和內(nèi)存資源，不用互搶了。
3、緩存系統(tǒng)
后來，用戶量進一步增加，每一次都要去數(shù)據(jù)庫里查，有點費時間，引入一個緩存系統(tǒng)，可以有效縮短服務的響應時間。
4、軟件負載均衡
用戶量還在增加，一個Web服務的吞吐量開始達到了上限，系統(tǒng)開始出現(xiàn)卡頓。這時候，可以復制多個Web服務出來，再用一個nginx來進行負載均衡，將請求分攤到所有Web服務器上，提高并發(fā)量。
5、數(shù)據(jù)讀寫分離
隨著系統(tǒng)的運行和用戶的增長，數(shù)據(jù)量越來越多，數(shù)據(jù)庫的瓶頸開始顯現(xiàn)，讀寫明顯變慢。這時候，可以增加新的數(shù)據(jù)庫服務器，將讀寫進行分離，二者做好數(shù)據(jù)同步，提高數(shù)據(jù)庫服務的整體I/O性能。
6、數(shù)據(jù)庫分庫分表
系統(tǒng)中的數(shù)據(jù)越來越多，即便是讀寫分離了，但一張表中的記錄越來越多，從幾百萬到幾千萬，甚至要過億了。把它們?nèi)咳谕粡埍砝?，檢索查詢耗時費力，是時候進行分庫分表，把數(shù)據(jù)拆分一下，提高數(shù)據(jù)查詢效率。
7、硬件負載均衡
再后來，業(yè)務發(fā)展很不錯，用戶量激增，以至于強勁的Nginx也扛不住了。
一臺不夠，那就多整幾臺，再引入一個硬件負載均衡的服務器，比如F5，將網(wǎng)絡流量分發(fā)到不同的Nginx服務器上，再一次提高性能。
8、DNS負載均衡
再再后來，用戶量還在蹭蹭蹭的增長，強悍如F5這樣的硬件負載均衡服務器也扛不住這樣的高并發(fā)。
老辦法，一個不夠那就多整幾個。這一次，咱們在域名解析上下功夫，不同地區(qū)的用戶，在訪問同一個域名時，解析到不同的IP地址，以此來將流量進一步拆分。
上面就是從最簡單的單機到復雜集群的高并發(fā)演進之路。
高并發(fā)是一個很大的話題，它所涵蓋的東西其實遠遠不止上面這些內(nèi)容。除了這些之外，像是消息隊列、數(shù)據(jù)庫選型、CDN、編程語言中的協(xié)程等等技術都能為提高并發(fā)助力。
回到這次崩潰事件上，我想著經(jīng)過一夜的折騰，今天總該好點了吧，結果下午一開始，又繼續(xù)擺爛了：
在我寫這篇文章的時候，當事公司已經(jīng)發(fā)布了說明：
下載文檔
