【51CTO.com原創(chuàng)稿件】在互聯(lián)網(wǎng)時(shí)代，高并發(fā)與高可用一樣，已經(jīng)變成系統(tǒng)的標(biāo)配了，如果系統(tǒng)每秒查詢率（QPS）沒有上萬，都不好意思跟人打招呼（雖然實(shí)際每天調(diào)用量不超過100）。尤其在雙十一期間，電商們憑借著藐視全球的流量，熱心地分享自己的技術(shù)架構(gòu)，幾乎千篇一律地用緩存+哈希（HASH），仿佛這就是高并發(fā)的核心技術(shù)了。當(dāng)然，如果你信了，那就離坑不遠(yuǎn)了。

緩存+哈希=高并發(fā)？

所謂知己知彼百戰(zhàn)不殆，先來看看我們經(jīng)?？吹降母卟l(fā)技術(shù)是什么。

資源靜態(tài)化  活動(dòng)秒殺頁面是標(biāo)準(zhǔn)的高并發(fā)場景，活動(dòng)期間單個(gè)頁面流量巨大無比，每秒QPS達(dá)到幾十萬上百萬。系統(tǒng)核心解決方案就是靜態(tài)化，靠機(jī)器和帶寬支撐。如果沒有部署CDN，所有流量都落到同一個(gè)IP，解決辦法就是用Nginx的文件靜態(tài)化，單機(jī)的承受能力主要取決于帶寬和單機(jī)的性能。如果流量再多，那就采用LVS(或者F5)+集群了。就中后臺而言，Nginx可以搞定大部分應(yīng)用，核心還是使用了緩存技術(shù)。

現(xiàn)在各種緩存的工具如memcache,redis之類的KV數(shù)據(jù)庫作為緩存已經(jīng)非常成熟，而且基本上都可以集群化部署，操作起來也很簡單，簡直成為高并發(fā)的代言詞。

讀寫分離和分庫分表  讀寫分離也是大家經(jīng)?？吹降母卟l(fā)的架構(gòu)，因?yàn)橐话闱闆r下讀比寫要多得多，所以數(shù)據(jù)庫的主庫寫，從庫們提供讀操作，一下就把數(shù)據(jù)庫的并發(fā)性能提高了。如果還不夠，那么分庫分表把，把數(shù)據(jù)分到各個(gè)數(shù)據(jù)庫的各個(gè)機(jī)器上，進(jìn)一步的減少單臺機(jī)器的壓力，從而達(dá)到高并發(fā)的目的。

如果是分庫分表，有時(shí)候使用的就是哈希技術(shù)了，以某個(gè)字段哈希一下然后來分庫分表，讀寫分離的讀操作，基本也是通過哈希技術(shù)把讀落到不同的機(jī)器上去減輕單機(jī)壓力。但凡大數(shù)據(jù)處理，高并發(fā)系統(tǒng)，必言哈希，隨機(jī)插入，時(shí)間復(fù)雜度O(1)，隨便查詢，時(shí)間復(fù)雜度O(1)，除了耗費(fèi)點(diǎn)空間以外，幾乎零缺點(diǎn)，在現(xiàn)在這個(gè)內(nèi)存廉價(jià)的時(shí)代，哈希表變成了一個(gè)高并發(fā)系統(tǒng)的標(biāo)配。

當(dāng)電商促銷活動(dòng)時(shí)，幾千萬人同時(shí)訪問網(wǎng)站還沒有掛，讓很多人覺得高并發(fā)應(yīng)該就是這樣子。這樣的場景再擴(kuò)展一點(diǎn)，就是凡是能提前提供數(shù)據(jù)的并發(fā)訪問，就可以用緩存+哈希來搞定并發(fā)。而像12306網(wǎng)站這樣，不能提前提供數(shù)據(jù)的，可以通過緩存+哈希來提高用戶體驗(yàn)，然后通過異步方式來提供服務(wù)（被吐槽的驗(yàn)證碼其實(shí)就是異步的排隊(duì)方式）。

實(shí)際上是不是這樣呢？顯然沒那么簡單。讓我們來看看一個(gè)高并發(fā)的系統(tǒng)真正需要考慮的元素。

合理的數(shù)據(jù)結(jié)構(gòu)

搜索提示功能大家都非常熟悉，如果是google,baidu這種大型搜索系統(tǒng)，或者京東淘寶這種電商系統(tǒng)，搜索提示的調(diào)用量是搜索服務(wù)本身調(diào)用量的好幾倍，因?yàn)槟忝枯斎胍粋€(gè)鍵盤，就要調(diào)用一次搜索提示服務(wù)，這算得上是個(gè)標(biāo)準(zhǔn)的高并發(fā)系統(tǒng)吧？那么它是怎么實(shí)現(xiàn)的呢？

可能很多人腦子里立刻出現(xiàn)了緩存+哈希的系統(tǒng)，把搜索的搜索提示詞存在redis集群中，每次來了請求直接redis集群中查找key，然后返回相應(yīng)的value值就行了。雖然耗費(fèi)點(diǎn)內(nèi)存，但是空間換時(shí)間嘛，也能接受。然而事實(shí)上沒有人會(huì)這么做。

這種搜索提示的功能一般用trie樹來做，耗費(fèi)的內(nèi)存不多，查找速度為O(k)，其中k為字符串的長度，雖然看上去沒有哈希表的O(1)好，但是少了網(wǎng)絡(luò)開銷，節(jié)約了很多內(nèi)存，并且實(shí)際查找時(shí)間還要不比緩存+哈希慢多少，一種合適當(dāng)前場景的核心數(shù)據(jù)結(jié)構(gòu)才是高并發(fā)系統(tǒng)的關(guān)鍵，緩存+哈希如果也看成一種數(shù)據(jù)結(jié)構(gòu)，但這種數(shù)據(jù)結(jié)構(gòu)并不適用于所有的高并發(fā)場景，所以高并發(fā)系統(tǒng)的設(shè)計(jì)，關(guān)鍵在合理的數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)，而不在架構(gòu)的套用。

不斷優(yōu)化代碼性能

有了上面的數(shù)據(jù)結(jié)構(gòu)，并且設(shè)計(jì)出了系統(tǒng)了，拿到線上一跑，效果還行，但感覺沒達(dá)到極限，這時(shí)候可千萬不能就直接上外部工具（比如緩存）提升性能，需要做的是不斷的代碼性能的優(yōu)化，簡單的說，就是不斷的重申你的代碼，不斷找出可以優(yōu)化的性能點(diǎn)，然后進(jìn)行優(yōu)化，因?yàn)橹霸O(shè)計(jì)的時(shí)候就已經(jīng)通過理論大概能算出來這個(gè)系統(tǒng)的并發(fā)量了，比如上面那個(gè)搜索提示，如果我們假定平均每個(gè)搜索詞6個(gè)字符，檢索一次大約需要查詢6次，需要2-3毫秒，這樣的話，如果8核的機(jī)器，多線程編程方式，一秒鐘最多能接受3200次請求（1000ms/2.5ms*8），如果沒達(dá)到這個(gè)量級，那么肯定是代碼有問題。

這個(gè)階段可能需要借助一些個(gè)工具了，Golang自帶的go tool pprof就能很好的進(jìn)行性能優(yōu)化。

或者把各個(gè)模塊的時(shí)間打印出來，壓測一遍，看看哪個(gè)模塊耗時(shí)，然后再去仔細(xì)檢查那個(gè)模塊的代碼，進(jìn)行算法和數(shù)據(jù)結(jié)構(gòu)的優(yōu)化。

這個(gè)過程是一個(gè)長期的過程，也是《重構(gòu)：改善代碼的既有設(shè)計(jì)》中提到的，一個(gè)優(yōu)秀的系統(tǒng)需要不斷的進(jìn)行代碼級別的優(yōu)化和重構(gòu)，所以高并發(fā)系統(tǒng)的實(shí)現(xiàn)，就是不斷的優(yōu)化代碼的性能，不斷逼近設(shè)計(jì)時(shí)的理論值。

***考慮外部通用方法

如果以上兩個(gè)都完成了，并發(fā)量也基本達(dá)到理論值了，但是還有提升的需求，這時(shí)候再來考慮外部的通用方法，比如加一個(gè)LRU緩存，把熱詞的查詢時(shí)間變成O(1)，進(jìn)一步提高性能。在沒把系統(tǒng)的性能壓榨完全之前，不要使用外部的通用方法，因?yàn)槭褂昧艘院缶蜎]有太多進(jìn)一步優(yōu)化空間了。

此外還需要再考慮運(yùn)維的技術(shù)，如常規(guī)的加負(fù)載均衡，部署成集群，通過運(yùn)維和部署的方法提高服務(wù)的并發(fā)性。

51CTO觀點(diǎn)

其實(shí)代碼才是高可用的關(guān)鍵，代碼的健壯性決定了高可用。除此之外，還需要看重?cái)?shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)和代碼的調(diào)優(yōu)能力。很多人對數(shù)據(jù)結(jié)構(gòu)嗤之以鼻，覺得對于現(xiàn)有的開發(fā)來說，數(shù)據(jù)結(jié)構(gòu)沒那么重要，但對于后端開發(fā)來說，數(shù)據(jù)結(jié)構(gòu)是很重要的技能。

找準(zhǔn)合適的數(shù)據(jù)結(jié)構(gòu)，不斷的優(yōu)化代碼，這樣來提升系統(tǒng)性能才是可控的，才有不斷優(yōu)化的空間，更好的高并發(fā)，如果一開始就上外部的緩存技術(shù)，很可能如果性能達(dá)不到要求，就沒有優(yōu)化空間了，因?yàn)橐薷耐獠康南到y(tǒng)還很困難。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

【編輯推薦】

  為什么使用GPL協(xié)議的開源項(xiàng)目越來越少？

  硅材料要哭了！新寵GaN讓數(shù)據(jù)中心能源效率翻倍，成本還打5折

  暗網(wǎng)也被“黑吃黑” 匿名黑客21個(gè)步驟拿下20%暗網(wǎng)