你開發(fā)的系統(tǒng)到底可以支撐多少并發(fā)訪問？100萬？10萬？1萬？1千？500？為什么能支撐，又為什么不能支撐？這是個直擊心靈的問題，能否準(zhǔn)確回答這個問題是程序員的一個分水嶺，也是一個能否持續(xù)做技術(shù)的門檻，能夠準(zhǔn)確回答的人，可以不看這篇文章了，如果仔細(xì)思考過這個問題但是卻沒有思路去回答這個問題的人，建議讀下去。

微服務(wù)不等于高并發(fā)，集群也不等于高并發(fā)，k8s更不等于高并發(fā)，一提性能優(yōu)化就想到壓測，連壓測結(jié)果是否合理可能都不知道，如何去優(yōu)化呢？就是用explain去看看sql么？

所謂的高并發(fā)是針對某些大用戶量同時訪問系統(tǒng)的場景抽象而出的一個模糊的概念，高并發(fā)只是所有那些場景的統(tǒng)稱，所以不存在高并發(fā)的通用解決方案，只存在某些特定場景的解決方案。經(jīng)過多年N多個高并發(fā)場景的不斷積累，目前針對特定的高并發(fā)場景均有相對成熟的解決方案，但僅僅是解決方案，對于具體業(yè)務(wù)還需要具體分析。

講個故事

針對一個簡單場景分析，開發(fā)了一個系統(tǒng)，若干個功能，會存在問題么？如果只是幾百個活躍用戶，談不上什么并發(fā)，那么很簡單，只需一個應(yīng)用集群和一個數(shù)據(jù)庫主備即可，基本上80%的中小型公司開發(fā)的系統(tǒng)都是這樣部署的，一個Tomcat集群，一個主備MySQL數(shù)據(jù)庫，有錢的客戶來個主備的oracle就行了。此時無所謂什么性能優(yōu)化，如下圖：

但是，此時，如果發(fā)現(xiàn)活躍用戶數(shù)到了幾千上萬，突然有一天客戶跟你說，系統(tǒng)崩了，無法訪問或者特別慢，此時到服務(wù)器上一看，進(jìn)程還在啊，CPU也算正常啊，數(shù)據(jù)庫也還好啊，然后看日志，沒什么報錯啊，頂多是sql超時了，很可能會說，系統(tǒng)正常運行著，怎么訪問不了了呢，重啟下吧，重啟之后一切正常，客戶讓你寫故障報告，你憋了半天來了句可能是網(wǎng)絡(luò)問題，或者實話實說系統(tǒng)沒發(fā)現(xiàn)什么異常，不知道為何重啟就好了，這個事兒可能就過去了。之后很可能每隔一段時間來一次重啟，如果一直沒解決，也許客戶失去信心，也就不用這個系統(tǒng)了。這是一個比較常見的場景，我遇到過很多客戶的軟件開發(fā)商都是這樣處理問題的，這也是市面上大多數(shù)開發(fā)人員想要高并發(fā)經(jīng)驗但是又沒有高并發(fā)經(jīng)驗的原因。很多時候不是沒場景，而是即使遇到問題也沒思路解決。

故事的第一階段完了，現(xiàn)在需要針對第一階段來分析分析，如何解決這次的宕機(jī)問題。當(dāng)系統(tǒng)的用戶數(shù)從幾百逐漸增加到幾萬的時候，如果預(yù)先沒有針對高并發(fā)場景進(jìn)行特殊設(shè)計，那么當(dāng)高并發(fā)或頻繁訪問某個功能的時候就會出現(xiàn)此類問題，要么是數(shù)據(jù)庫崩了一堆網(wǎng)絡(luò)請求異常，要么是系統(tǒng)特別慢一個接口執(zhí)行個幾十秒，要么是系統(tǒng)內(nèi)存溢出了。為何會出現(xiàn)這個問題？80%的原因都是數(shù)據(jù)庫查詢太慢了，這就是最常見的瓶頸點——數(shù)據(jù)庫慢查詢。

哪出的問題

數(shù)據(jù)庫慢查詢的原因?qū)嵲谔啵瑂ql編寫不規(guī)范，沒有遵循ESR原則，業(yè)務(wù)復(fù)雜等等。拋去數(shù)據(jù)庫問題先不談，先說說瓶頸是如何出現(xiàn)的，為何某幾個查詢慢會導(dǎo)致服務(wù)器全面崩潰-雪崩呢，雪崩之后我們應(yīng)該如何分析如何下手呢？看看下圖，一個請求從服務(wù)端接收開始，一直到數(shù)據(jù)庫，然后再返回給前端，大概經(jīng)過這些步驟。這個時候我們就得逼著自己思考幾個問題了，假定100并發(fā)進(jìn)來的時候，哪會存在瓶頸呢？網(wǎng)絡(luò)處理？程序執(zhí)行？數(shù)據(jù)庫查詢？為什么存在或不存在瓶頸將是一個直擊靈魂的問題讓你久久不能寐。

網(wǎng)絡(luò)原因？

首先看第一大類問題，網(wǎng)絡(luò)處理，這涉及到一個網(wǎng)絡(luò)編程的問題，即socket編程。我們開發(fā)的所有web服務(wù)或者說所有跟網(wǎng)絡(luò)有關(guān)的服務(wù)基本上都涉及到這個問題-網(wǎng)絡(luò)編程！

先看一個網(wǎng)絡(luò)請求是如何到了我們的web容器的，一個網(wǎng)絡(luò)請求從客戶端經(jīng)過若干網(wǎng)線傳輸和交換機(jī)路由器的中間轉(zhuǎn)發(fā)，到了我們的網(wǎng)卡的時候，就是一堆的高低電頻信號，網(wǎng)卡在接收到這些信號后，會有個mac+PHY芯片進(jìn)行處理，首先將物理信號轉(zhuǎn)變?yōu)閿?shù)字信號，即01010101這樣一串?dāng)?shù)字，然后進(jìn)行轉(zhuǎn)碼，轉(zhuǎn)變?yōu)閹@就是程序處理網(wǎng)絡(luò)請求的第一個概念，從一個個幀再逐漸轉(zhuǎn)變成包，從IP包再轉(zhuǎn)變成TCP包，最后轉(zhuǎn)變成http包，這就是大學(xué)學(xué)網(wǎng)絡(luò)里面講過的四層協(xié)議或七層協(xié)議。這個過程，有網(wǎng)卡硬件的處理，有CPU和內(nèi)存的交互，還有網(wǎng)卡驅(qū)動和操作系統(tǒng)的程序執(zhí)行。如下圖：

根據(jù)上圖簡單分析下網(wǎng)絡(luò)請求處理過程：

1. 網(wǎng)卡接收高低電頻信號經(jīng)過MAC處理后，將數(shù)據(jù)包先暫存于片內(nèi)FIFO接收隊列。
2. 網(wǎng)卡控制器將FIFO隊列放入內(nèi)存的一個環(huán)形緩沖區(qū)。
3. 網(wǎng)卡控制器將環(huán)形緩沖區(qū)的數(shù)據(jù)放入內(nèi)存，上半部處理完成。
4. 觸發(fā)軟中斷，開始下半部處理。
5. CPU軟中斷，調(diào)用網(wǎng)卡驅(qū)動程序繼續(xù)處理。
6. 網(wǎng)卡驅(qū)動程序通過NAPI開始處理內(nèi)存中的網(wǎng)絡(luò)包。
7. 操作系統(tǒng)內(nèi)核網(wǎng)絡(luò)處理模塊開始介入，執(zhí)行大名鼎鼎的netif_receive_skb函數(shù)，執(zhí)行完成后，網(wǎng)絡(luò)處理第一大部分完成，開始進(jìn)入?yún)f(xié)議處理。
8. linux內(nèi)核的socket模塊開始介入，進(jìn)行tcp或udp協(xié)議處理。

根據(jù)上圖分析，我們普通的服務(wù)器在處理網(wǎng)絡(luò)請求時，一般有三個瓶頸點，帶寬、網(wǎng)卡速率和協(xié)議處理。帶寬基本上是客戶花錢買的，一般幾十上百兆，1G也正常。網(wǎng)卡速率取決于硬件設(shè)備了，現(xiàn)在的千兆網(wǎng)卡和萬兆網(wǎng)卡比較主流；協(xié)議處理算是一個比較重要的瓶頸，目前面試寶典中的epoll技術(shù)就是協(xié)議處理所使用的最重要的一種技術(shù)，協(xié)議處理技術(shù)的變革直接導(dǎo)致了網(wǎng)絡(luò)并發(fā)請求和在線連接數(shù)從原來的幾百到了現(xiàn)在的幾十上百萬。

在這些軟硬件相互交互的過程中，大量前輩針對中斷、數(shù)據(jù)包處理，協(xié)議處理等做過大量優(yōu)化，有軟硬中斷、上半部下半部分離處理、NAPI、DMA、Epoll等等，這些技術(shù)很好的解決了網(wǎng)絡(luò)請求處理過程中的各種瓶頸，發(fā)展到目前，出現(xiàn)了100Gb的網(wǎng)卡，阿里巴巴六年前就開始研究單機(jī)千萬連接，即解決C10M的問題，目前在網(wǎng)絡(luò)處理層面，基本上一臺物理機(jī)可以滿足我們正常的十萬連接并發(fā)處理了。關(guān)于網(wǎng)絡(luò)編程內(nèi)容也不是一句兩句能說透的，此處暫且分析到只要使用了正常的一個服務(wù)器，并且使用epoll技術(shù)，適當(dāng)?shù)墓浪阆虏l(fā)量和帶寬，網(wǎng)絡(luò)處理這塊兒不太容易成為瓶頸。下面我們重點說說epoll和應(yīng)用層的網(wǎng)絡(luò)請求處理。

首先我們可以做個基準(zhǔn)測試，先隨意找一臺虛擬機(jī)服務(wù)器，然后部署個Nginx，直接用wrk來試試基準(zhǔn)測試的結(jié)果，可以看到nginx在一臺很普通的服務(wù)器上可以支撐8萬并發(fā)。如果在這臺服務(wù)器多跑幾個nginx，基本上可以把網(wǎng)卡打滿，并發(fā)也可以上到十幾二十萬，這就跟本身服務(wù)器性能有關(guān)了，如果是個物理機(jī)，性能會更高。nginx只是測試了一個http請求的處理并發(fā)，nginx基準(zhǔn)測試完成后，可以進(jìn)一步進(jìn)行tomcat的基準(zhǔn)測試和springboot的基準(zhǔn)測試，最后使用公司內(nèi)部的框架做一個網(wǎng)絡(luò)處理的基準(zhǔn)測試，得到一個相對合理的極限值。我們做的結(jié)果是nginx單機(jī)雙實例占用4核可以到15萬，tomcat可以到10萬，springboot和內(nèi)部封裝后的框架可以到9萬。由此看來web容器和spring框架多多少少會損耗一些性能。此時的瓶頸為CPU，因為一直在處理網(wǎng)絡(luò)請求的收發(fā)，與預(yù)期相符，在網(wǎng)絡(luò)處理層面，CPU、網(wǎng)卡和帶寬絕對是瓶頸。下圖是nginx的壓測結(jié)果。

如果這篇文章說不清epoll的本質(zhì)，那就過來掐死我吧！

這篇文章把epoll的原理講得比較透，nginx、tomcat、redis、kafka等等所有高性能的中間件的底層都是使用epoll。

此處的基準(zhǔn)測試是個很重要的環(huán)節(jié)，我們網(wǎng)上能夠看到的很多文章所謂的高并發(fā)高性能，都是一些理論值，或者說是推測出來的一個量級，實際值跟網(wǎng)絡(luò)情況服務(wù)器情況的不同會有較大的差別，做好基準(zhǔn)測試是我們做性能優(yōu)化非常重要的一環(huán)，而基準(zhǔn)測試的核心就是在一個簡單的配置環(huán)境下發(fā)現(xiàn)核心性能點的瓶頸，例如如果一臺服務(wù)器裝了個nginx，發(fā)現(xiàn)壓測結(jié)果是并發(fā)1萬，那就是由于某些原因完全沒測出來瓶頸，需要從CPU、網(wǎng)絡(luò)等角度來排查哪一環(huán)出現(xiàn)了問題。很多時候我們可以使用壓測工具得到一個數(shù)值，這不是關(guān)鍵點，關(guān)鍵點在于這個值對不對，到底瓶頸在哪，是CPU還是網(wǎng)絡(luò)，是內(nèi)存還是硬盤。

應(yīng)用問題？

確認(rèn)了網(wǎng)絡(luò)編程在epoll配置下普通服務(wù)器都可以達(dá)到10萬并發(fā)級別，現(xiàn)在來看看十萬并發(fā)的請求到了應(yīng)用代碼執(zhí)行層面會不會出現(xiàn)問題。如果拋去數(shù)據(jù)庫的查詢速度，單純在代碼執(zhí)行和內(nèi)存訪問，基本都是在納秒級別，下圖可以看到各硬件訪問的速度，單純執(zhí)行1000行代碼還是處于微妙級別，訪問1000次內(nèi)存，也只是100微秒即0.1毫秒，所以如果沒有高并發(fā)下的鎖競爭，僅是代碼執(zhí)行也很少會出現(xiàn)高CPU的情況，除非是遞歸調(diào)用等特殊場景。

數(shù)據(jù)庫問題？

分析了網(wǎng)絡(luò)層瓶頸在單機(jī)十萬，應(yīng)用層基本不會存在瓶頸，那么下一層就是數(shù)據(jù)庫查詢了，也就是說，當(dāng)十萬并發(fā)請求進(jìn)來的時候，基本上在網(wǎng)絡(luò)處理和程序執(zhí)行上不會存在多少損耗，會直接將流量打到數(shù)據(jù)庫上，那么此時就需要了解數(shù)據(jù)庫的瓶頸點和極限值了。數(shù)據(jù)庫的知識點就比較多了，因為經(jīng)過這么多年的發(fā)展，數(shù)據(jù)庫做了N多優(yōu)化，而且存儲也是一個系統(tǒng)的重中之重，基本上所有的優(yōu)化都是從數(shù)據(jù)庫開始的。可以先從數(shù)據(jù)庫的簡單原理了解下數(shù)據(jù)庫的性能到底怎么樣。

上圖以mysql為例列出了請求從網(wǎng)絡(luò)到執(zhí)行再到持久化四個大過程的基本實現(xiàn)原理。第一步是connection pool來處理連接，認(rèn)證等工作；第二步是解析sql、優(yōu)化sql和查詢mysql庫級別緩存；第三步進(jìn)入存儲引擎處理，mysql目前默認(rèn)的存儲引擎是innodb；第四步就是磁盤訪問了。根據(jù)上述的網(wǎng)絡(luò)處理分析，第一步基本不會存在瓶頸。第二步都是代碼執(zhí)行的內(nèi)存訪問，也不太會成為瓶頸。第三步是引擎執(zhí)行，innodb支持三種行鎖，但是查詢時mvcc不加鎖，并且當(dāng)數(shù)據(jù)庫記錄數(shù)量不是特別大（百萬或千萬級）時，數(shù)據(jù)的定為都是基于內(nèi)存中的page進(jìn)行的，一般情況下也不會存在瓶頸，只有第四步的磁盤訪問會成為瓶頸。

為了保證數(shù)據(jù)穩(wěn)定持久化，一定是要將數(shù)據(jù)存儲在磁盤上的，因為計算機(jī)一共就有兩類存儲，磁盤和內(nèi)存，內(nèi)存是基于電容的，原理就是通電后通過01信號來表示數(shù)據(jù)，而磁盤是通過磁極變化來記錄表示01數(shù)據(jù)，通電改變磁場寫入數(shù)據(jù)，斷電后不會發(fā)生改變。所以要想讓數(shù)據(jù)持久保留，必須用磁盤。當(dāng)然磁盤有很多種，普通的機(jī)械硬盤，SSD硬盤，磁帶等等。因為內(nèi)存是靠電來表示數(shù)據(jù)，所以足夠快，但是磁盤中，當(dāng)磁頭掃過盤面，通過感應(yīng)電流就可以識別出不同狀態(tài)，即讀取數(shù)據(jù)；增強(qiáng)磁頭的磁性，可以改變盤面記錄單元的狀態(tài)，實現(xiàn)寫入數(shù)據(jù)。此時帶著磁頭的機(jī)械臂擺動就會成為訪問瓶頸，由此可見，數(shù)據(jù)庫的第一大瓶頸就是磁盤的寫入和讀取。

根據(jù)上面列出的硬件訪問速度，磁盤訪問在10ms左右，因為機(jī)械臂的移動速度在7ms左右。如果每次數(shù)據(jù)庫查詢都需要10ms，那么此時我們就可以算算，數(shù)據(jù)庫CPU此時除了網(wǎng)絡(luò)處理和數(shù)據(jù)查找（定位磁盤位置）以外，剩余的執(zhí)行時間都是等待磁盤IO，可以適當(dāng)增加線程數(shù)并行執(zhí)行網(wǎng)絡(luò)處理和數(shù)據(jù)查找，并行等待磁盤IO，即提高數(shù)據(jù)庫連接數(shù)，傳導(dǎo)到應(yīng)用層面即為增加請求的連接數(shù)。此時通過增加應(yīng)用連接數(shù)來提高并發(fā)能力，可以快速將數(shù)據(jù)庫的瓶頸突破到磁盤瓶頸，按照正常物理機(jī)的固態(tài)硬盤的速度，每秒可以處理116k次16KB數(shù)據(jù)的隨機(jī)讀，即11萬并發(fā)，當(dāng)然此時數(shù)據(jù)庫基本處于滿負(fù)荷狀態(tài)，崩潰邊緣，正常支撐6萬以下并發(fā)處于合理范圍，如果將數(shù)據(jù)庫部署到虛擬機(jī)上或者低配機(jī)上，那么并發(fā)量會直線下滑，我們內(nèi)部的一個虛擬機(jī)作為數(shù)據(jù)庫服務(wù)器的基準(zhǔn)測試結(jié)果慘不忍睹，16k隨機(jī)讀的IOPS僅為600，即當(dāng)有600查詢請求進(jìn)來時，磁盤IO為100%了。以上數(shù)據(jù)均屬于內(nèi)部基準(zhǔn)測試得出的結(jié)果，實際生產(chǎn)環(huán)境或其他環(huán)境需要根據(jù)基準(zhǔn)測試和全流程壓測的實際值為準(zhǔn)。

由此可見，即使我們使用高性能數(shù)據(jù)庫服務(wù)器，安全運行的并發(fā)能力也只是6萬的QPS，TPS可能還要低很多。如果一個高并發(fā)的業(yè)務(wù)接口需要訪問5次數(shù)據(jù)庫，那么最高能支撐1.2萬的接口并發(fā)。如果前端業(yè)務(wù)功能每次點擊需要走三四個接口，如果這三四個接口有查詢有更新插入，也許連并發(fā)2000都撐不到。而這都是基于單次查詢只有一次磁盤IO的情況，如果單次查詢數(shù)據(jù)量大于1頁，或者查詢內(nèi)容需要跨頁訪問，那就會產(chǎn)生多次IO，那性能就更低了，也許連四五百都撐不住，甚至于一個沒有太高并發(fā)的業(yè)務(wù)，但是查詢語句非常復(fù)雜，可能直接導(dǎo)致并發(fā)能力在幾十甚至個位數(shù)。而數(shù)據(jù)庫又因為ACID的原因，基本只能實現(xiàn)多讀無法實現(xiàn)多寫，分布式事務(wù)到現(xiàn)在也是難以突破的一個技術(shù)鴻溝，要實現(xiàn)需要付出巨大成本。

怎么優(yōu)化

分析到此，就找到了幾千用戶訪問時無論怎么加應(yīng)用服務(wù)器，最后還會雪崩的原因了，根兒就不在應(yīng)用層面，加再多的服務(wù)器都沒有用。那么數(shù)據(jù)庫的問題僅僅靠優(yōu)化sql解決么？sql從慢到快，只是一個表象，系統(tǒng)宕機(jī)的根本原因在于數(shù)據(jù)庫服務(wù)器達(dá)到了瓶頸，資源不足導(dǎo)致的，我們應(yīng)該先分析什么問題導(dǎo)致了資源瓶頸，然后對癥下藥的分析。也許只需在某幾個點加個緩存，也許見個合理的索引，也許是變動下只查id不查內(nèi)容避免回表，都可以一針見血的解決掉性能問題。現(xiàn)在特別流行使用的nosql可以支持分布式存儲，性能也可以隨著節(jié)點數(shù)增多而線性遞增，是不是換成分布式存儲就可以支撐高并發(fā)了呢？也不是，僅僅支撐幾萬并發(fā)，使用數(shù)據(jù)庫+緩存還是可以的，傳統(tǒng)數(shù)據(jù)庫的ACID、使用簡單、技術(shù)成熟穩(wěn)定是我們必須要考慮的，也是我們首次開發(fā)一個項目的首選存儲。這也是為何很多大的金融機(jī)構(gòu)還在使用IOE（IBM+ORACLE+EMC）的原因。

現(xiàn)在我們經(jīng)過上述一系列分析，知道了系統(tǒng)真正的瓶頸點了，網(wǎng)絡(luò)上只有流量會成為瓶頸，應(yīng)用上只有鎖、線程切換、遞歸調(diào)用和大數(shù)據(jù)量處理會成為運算和內(nèi)存瓶頸，數(shù)據(jù)庫因為ACID是單點，所以此處的性能是最難擴(kuò)展的。面對大流量，核心目標(biāo)就是盡量讓高并發(fā)接口可以支持橫向擴(kuò)展。最開始的性能優(yōu)化基本都是圍繞著數(shù)據(jù)庫的瓶頸而進(jìn)行的，一般有如下幾個階段：

第一階段：緩存熱數(shù)據(jù)

有些熱點數(shù)據(jù)如果需要多次查詢，而且查多改少，那么一般是可以放到redis緩存中的，利用內(nèi)存訪問來替代磁盤訪問，可以明顯提升效率。同時，針對數(shù)據(jù)庫的回表問題，也可以在mysql中只查id，根據(jù)id在redis中查詢數(shù)據(jù)內(nèi)容。這種緩存只適用于大多數(shù)人查詢的內(nèi)容都相同的情況，緩存只需要存一份，更新緩存相對容易。

第二階段：擴(kuò)散寫

有些查詢根據(jù)每個人會得到不同結(jié)果，那么每個人來訪問系統(tǒng)都需要查詢一次數(shù)據(jù)庫，并發(fā)量上來后很可能會把數(shù)據(jù)庫壓到瓶頸，所以需要預(yù)先算出每個人的查詢結(jié)果并緩存，這就是倒排索引，也就是擴(kuò)散寫的思路。此時為了降低數(shù)據(jù)庫壓力提高查詢效率，需要為每個人冗余一份數(shù)據(jù)，更新會比較復(fù)雜，因為需要重新計算每個人的數(shù)據(jù)。但是查詢會非常快，而且未來也可以針對查詢做各種擴(kuò)展。

第三階段：異步處理

有些業(yè)務(wù)場景是需要高并發(fā)插入更新的，此時數(shù)據(jù)庫也容易成為瓶頸。為了保證系統(tǒng)可以正常使用，只能延遲返回插入更新的結(jié)果，放入隊列，慢慢消費，也算是削峰的一種。

第四階段：讀寫分離

上面三個階段都處于單機(jī)狀態(tài)，但是熱點數(shù)據(jù)的緩存有很多場景還是先查庫后緩存，也容易把數(shù)據(jù)庫壓崩，所以此時需要橫向擴(kuò)展，通過讀寫分離，擴(kuò)展讀的mysql服務(wù)器，但此時就會存在讀寫服務(wù)器的數(shù)據(jù)同步延時問題需要考慮和解決。

第五階段：分庫分表

第四階段的讀寫分離，但是一寫多讀，當(dāng)寫的單機(jī)成為瓶頸時，就只能橫向或者眾向分表了，我們一般說得分庫分表都是眾向分表，即選擇一個合理的分表策略，一般是根據(jù)高并發(fā)的查詢條件設(shè)置，因為要防止跨表查詢，同時還得考慮分布式事務(wù)的問題。一個事務(wù)里涉及到的表盡量在一個庫中。

第六階段：NoSQL

有些復(fù)雜查詢和聚合查詢，真的不適合使用mysql這種關(guān)系型數(shù)據(jù)庫來支撐，就需要使用es這類倒排索引的存儲引擎或者一些列式存儲的mapreduce的來解決，此時就需要考慮使用NoSQL來冗余數(shù)據(jù)存儲，以解決這類特殊場景的業(yè)務(wù)查詢。

總結(jié)

在性能優(yōu)化過程中，加機(jī)器是最容易實現(xiàn)的。所以針對應(yīng)用層的CPU算力問題是最容易解決的，網(wǎng)絡(luò)層的帶寬只要預(yù)先算好，客戶也能欣然接受。而針對存儲層的各種優(yōu)化都是極為復(fù)雜的，單機(jī)的維護(hù)比多機(jī)簡單的多，單寫比多寫簡單的多，一個存儲的維護(hù)也要比多個存儲的維護(hù)簡單的多，每一個階段的優(yōu)化都意味著更高的維護(hù)成本，所以優(yōu)化是根據(jù)業(yè)務(wù)需求被動提出的而不是過度設(shè)計出來的。說白了我們都想舒舒服服地坐在這喝茶看著系統(tǒng)穩(wěn)定運行，不要自己給自己加碼提高維護(hù)成本。

提到并發(fā)大家就會想到秒殺，就會想到紅包、春節(jié)活動、雙十一、12306等等。他們確實是極為典型的高并發(fā)大流量，他們的接口qps甚至可以達(dá)到幾十萬上百萬，他們的存儲可能需要支撐幾千萬上億的qps。他們在解決這個問題上使用了各種各樣高大上的技術(shù)，限流熔斷，分布式存儲，隊列，緩存，調(diào)用鏈跟蹤，全鏈路監(jiān)控等等等等。

對于軟件開發(fā)人員來說，性能優(yōu)化的根本就是在協(xié)調(diào)CPU、內(nèi)存、磁盤和網(wǎng)絡(luò)等硬件設(shè)備的性能瓶頸，把單機(jī)性能優(yōu)化到極致，然后優(yōu)化為可以支持多機(jī)擴(kuò)展。不能隨心所欲地使用一些流行技術(shù)堆積出一個系統(tǒng)，解鈴還須系鈴人，找到性能瓶頸的本質(zhì)才是最關(guān)鍵的。