如何處理高並發和單點故障

我這么說吧，很簡單，就是因為剛開始系統都是連接數據庫的，但是要知道數據庫支撐到每秒並發兩三千的時候，基本就快完了。所以才有說，很多公司，剛開始干的時候，技術比較low，結果業務發展太快，有的時候系統扛不住壓力就掛了。當然會掛了，憑什么不掛？你數據庫如果瞬間承載每秒5000或8000，甚至上萬的並發，一定會宕機，因為像mysql數據庫壓根兒就扛不住這么高的並發量。所以為啥高並發牛逼？就是因為現在用互聯網的人越來越多，很多app、網站、系統承載的都是高並發請求，可能高峰期每秒並發量幾千，很正常的。就像每年的雙十一，一年比一年的峰值高，每秒並發幾十萬都是灑灑水。

那么我們可以從以下幾個方面來進行考慮：

系統拆分

將一個系統拆分為多個子系統，用dubbo來搞。然后每個系統連一個數據庫，這樣本來就一個庫，現在多個數據庫，這樣就可以抗高並發。

緩存

大部分的高並發場景，都是讀多寫少，那你完全可以在數據庫和緩存里都寫一份，然后讀的時候大量走緩存不就得了。畢竟人家redis輕輕松松單機幾萬的並發啊。沒問題的。所以你可以考的慮考慮你的項目里，那些承載主要請求讀場景，怎么用緩存來抗高並發。

MQ(消息隊列)

可能你還是會出現高並發寫的場景，比如說一個業務操作里要頻繁搞數據庫幾十次，增刪改增刪改，瘋了。那高並發絕對搞掛你的系統，人家是緩存你要是用redis來承載寫那肯定不行，數據隨時就被LRU(淘汰掉最不經常使用的)了，數據格式還無比簡單，沒有事務支持。所以該用mysql還得用mysql啊。那你咋辦？用MQ吧，大量的寫請求灌入MQ里，排隊慢慢玩兒，后邊系統消費后慢慢寫，控制在mysql承載范圍之內。所以你得考慮考慮你的項目里，那些承載復雜寫業務邏輯的場景里，如何用MQ來異步寫，提升並發性。MQ單機抗幾萬並發也是ok的。

分庫分表

可能到了最后數據庫層面還是免不了抗高並發的要求，好吧，那么就將一個數據庫拆分為多個庫，多個庫來抗更高的並發；然后將一個表拆分為多個表，每個表的數據量保持少一點，提高sql跑的性能。

讀寫分離

這個就是說大部分時候數據庫可能也是讀多寫少，沒必要所有請求都集中在一個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫。

Elasticsearch(一個基於Lucene的搜索服務器)

可以考慮用es。es是分布式的，可以隨便擴容，分布式天然就可以支撐高並發，因為動不動就可以擴容加機器來抗更高的並發。那么一些比較簡單的查詢、統計類的操作，可以考慮用es來承載，還有一些全文搜索類的操作，也可以考慮用es來承載。

 

單點故障

大體可以從以下幾個方面來消除單點故障：
一個網站，從基礎的硬件層，到操作系統層，到數據庫層，到應用程序層，再到網絡層，都有可能產生單點故障。如果要有效地消除單點故障，最重要的一點是設計的時候要盡量避免引入單點，隨着架構的變化，定期審查系統潛在的單點也是有必要的。

磁盤鏡像(Disk Mirroring)

為了避免磁盤驅動器發生故障而丟失數據，便增設了磁盤鏡像功能。為實現該功能，須在同一磁盤控制器下，再增設一個完全相同的磁盤驅動器。當采用磁盤鏡像方式時，在每次向主磁盤寫入數據后，都需要將數據再寫到備份磁盤上，使兩個磁盤上具有完全相同的位像圖。把備份磁盤看作是主磁盤的一面鏡子。當主磁盤驅動器發生故障時，由於有備份磁盤的存在，在進行切換后，使主機仍能正常工作。磁盤鏡像雖然實現了容錯功能，卻使磁盤的利用率降至50%，也未能使服務器的磁盤I/O速度得到提高。

獨立磁盤冗余陣列（RAID，redundant array of independent disks）

是把相同的數據存儲在多個硬盤的不同的地方（因此，冗余地）的方法。通過把數據放在多個硬盤上，輸入輸出操作能以平衡的方式交疊，改良性能。因為多個硬盤增加了平均故障間隔時間（MTBF），儲存冗余數據也增加了容錯。

磁盤陣列其樣式有三種，一是外接式 磁盤陣列櫃、二是內接式 磁盤陣列卡，三是利用軟件來仿真。

• 外接式磁盤陣列櫃最常被使用大型服務器上，具可熱交換（Hot Swap）的特性，不過這類產品的價格都很貴。
• 內接式磁盤陣列卡，因為價格便宜，但需要較高的安裝技術，適合技術人員使用操作。硬件陣列能夠提供在線擴容、動態修改陣列級別、自動數據恢復、驅動器漫游、超高速緩沖等功能。它能提供性能、數據保護、可靠性、可用性和可管理性的解決方案。陣列卡專用的處理單元來進行操作。
• 利用軟件仿真的方式，是指通過網絡操作系統自身提供的磁盤管理功能將連接的普通SCSI卡上的多塊硬盤配置成邏輯盤，組成陣列。軟件陣列可以提供數據冗余功能，但是磁盤子系統的性能會有所降低，有的降低幅度還比較大，達30%左右。因此會拖累機器的速度，不適合大數據流量的服務器。 

雙機熱備份

主從備份模式

即目前通常所說的active/standby 方式，active服務器處於工作狀態；而standby 服務器處於監控准備狀態，服務器數據包括數據庫數據同時往兩台或多台服務器寫入（通常各服務器采用RAID磁盤陣列卡），保證數據的即時同步。當active服務器出現故障的時候，通過軟件診測或手工方式將standby機器激活，保證應用在短時間內完全恢復正常使用。典型應用在證券資金服務器或行情服務器。這是目前采用較多的一種模式，但由於另外一台服務器長期處於后備的狀態，從計算資源方面考量，就存在一定的浪費。

雙機互備模式

是兩個相對獨立的應用在兩台機器同時運行，但彼此均設為備機，當某一台服務器出現故障時，另一台服務器可以在短時間內將故障服務器的應用接管過來，從而保證了應用的持續性，但對服務器的性能要求比較高。配置相對要好。

雙機雙工模式

是目前cluster（群集:群集包括兩種，一種是 網絡負載平衡，另一種是 服務器群集。這里的雙機雙工模式是屬於網絡負載平衡群集。）的一種形式，兩台服務器均為活動，同時運行相同的應用，保證整體的性能，也實現了負載均衡和互為備份，實現該類方案的典型產品包括國外廠商 Oracle的 RAC，國內廠商格瑞趨勢的 Moebius for SQL Server。需要利用磁盤櫃存儲技術（最好采用San方式）。WEB服務器或FTP服務器等用此種方式比較多

 

網卡與網線的單點問題。系統里面最容易物理損壞的就是網線。網卡綁定(NIC bonding)一個很簡單很通用的辦法。配置多個網卡，一個網卡壞了並不會影響服務器的正常運行。
SSH 服務器和Telnet 服務器共存。畢竟 SSH 和 Telnet 都不是百分之百靠譜的事。
IDC 機房的單點。由於中國特色的“南北互通”，所以選擇IDC機房的時候，一定要有冗余。
靠譜的DNS解析
以上幾點，是一些比較常見的解決方法。我們一個常見的應用架構，在服務器上安裝了MySQL作為作為應用數據庫，為了提高性能，在服務器和數據庫之間加上了Redis緩存服務器，那么Redis緩存服務器和MySQL數據庫都是一個單點故障的隱患，此時，我們就可以考慮主從備份的設計。

 

參考地址：

如何處理高並發和單點故障「ALLENsakaru」 ：https://blog.csdn.net/ALLENsakaru/article/details/85952942