當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

从C10K到C10M高性能网络的探索与实践

發(fā)布時(shí)間：2024/4/11 编程问答 52 豆豆

生活随笔收集整理的這篇文章主要介紹了从C10K到C10M高性能网络的探索与实践小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

原文：https://blog.qiniu.com/archives/4941

優(yōu)化整理：極客重生

hi，大家好，今天是大年初一，先祝大家新年快樂(lè)！今天依然是干貨，性能優(yōu)化大局觀(guān)，高端食材，值得品嘗。

在高性能網(wǎng)絡(luò)的場(chǎng)景下，C10K是一個(gè)具有里程碑意義的場(chǎng)景，15年前它給互聯(lián)網(wǎng)領(lǐng)域帶來(lái)了很大的挑戰(zhàn)。發(fā)展至今，我們已經(jīng)進(jìn)入C10M的場(chǎng)景進(jìn)行網(wǎng)絡(luò)性能優(yōu)化。這期間有怎樣的發(fā)展和趨勢(shì)？圍繞著各類(lèi)指標(biāo)分別有哪些探索和實(shí)踐？12月20日在北京舉辦的“七牛架構(gòu)師實(shí)踐日”沙龍中，來(lái)自京東的資深架構(gòu)師閆國(guó)旗為大家做了題為“從C10K到C10M高性能網(wǎng)絡(luò)的探索與實(shí)踐”的分享，更多網(wǎng)絡(luò)分享參考：五個(gè)半小時(shí)。

以下是對(duì)他演講內(nèi)容的文字實(shí)錄。

C10K時(shí)代的問(wèn)題與優(yōu)化手段

首先帶大家回顧一下當(dāng)年C10K場(chǎng)景中遇到的問(wèn)題以及為了解決我們單機(jī)下高并發(fā)的承載能力所做的改進(jìn)。在當(dāng)時(shí)的年代，國(guó)內(nèi)互聯(lián)網(wǎng)的普及程度相對(duì)較低，C10K并沒(méi)有給當(dāng)時(shí)中國(guó)的互聯(lián)網(wǎng)環(huán)境帶來(lái)太大沖擊，但是在全球互聯(lián)網(wǎng)環(huán)境下大家開(kāi)始意識(shí)到這個(gè)問(wèn)題。為了解決該問(wèn)題，首先的研究方向就是IO模型的優(yōu)化，逐漸解決了C10K的問(wèn)題。

epoll、kqueue、iocp，io_ring就是IO模型優(yōu)化的一些最佳實(shí)踐，這幾種技術(shù)實(shí)現(xiàn)分別對(duì)應(yīng)于不同的系統(tǒng)平臺(tái)。以epoll為例，在它的基礎(chǔ)上抽象了一些開(kāi)發(fā)框架和庫(kù)，為廣大軟件開(kāi)發(fā)者在軟件開(kāi)發(fā)帶來(lái)了便利，比如libevent、libev等。隨著當(dāng)年在IO模型上的革命，衍生出了很多至今為止我們都在大量使用的優(yōu)秀開(kāi)源軟件，比如nginx、haproxy、squid等，通過(guò)大量的創(chuàng)新、實(shí)踐和優(yōu)化，使我們?cè)诮裉炷軌蚝茌p易地解決一個(gè)大并發(fā)壓力場(chǎng)景下的技術(shù)問(wèn)題。

深入理解Linux異步I/O框架 io_uring

這里簡(jiǎn)單列了幾點(diǎn)，較為常用的優(yōu)化技術(shù)手段。

CPU親和性&內(nèi)存局域性

目前我們使用的服務(wù)器主要是多路、多核心的x86平臺(tái)。用于運(yùn)行我們的軟件代碼，在很多場(chǎng)景的業(yè)務(wù)需求下，都會(huì)涉及一定并發(fā)任務(wù)，無(wú)論是多進(jìn)程模型還是多線(xiàn)程模型，都要把所有的調(diào)度任務(wù)交給操作系統(tǒng)，讓操作系統(tǒng)幫我們分配硬件資源。我們常用的服務(wù)器操作系統(tǒng)都屬于分時(shí)操作系統(tǒng)，調(diào)度模型都盡可能的追求公平，并沒(méi)有為某一類(lèi)任務(wù)做特別的優(yōu)化，如果當(dāng)前系統(tǒng)僅僅運(yùn)行某一特定任務(wù)的時(shí)候，默認(rèn)的調(diào)度策略可能會(huì)導(dǎo)致一定程度上的性能損失。我運(yùn)行一個(gè)A任務(wù)，第一個(gè)調(diào)度周期在0號(hào)核心上運(yùn)行，第二個(gè)調(diào)度周期可能就跑到1號(hào)核心上去了，這樣頻繁的調(diào)度可能會(huì)造成大量的上下文切換，從而影響到一定的性能。

數(shù)據(jù)局域性是同樣類(lèi)似的問(wèn)題。當(dāng)前x86服務(wù)器以NUMA架構(gòu)為主，這種平臺(tái)架構(gòu)下，每個(gè)CPU有屬于自己的內(nèi)存，如果當(dāng)前CPU需要的數(shù)據(jù)需要到另外一顆CPU管理的內(nèi)存獲取，必然增加一些延時(shí)。所以我們盡可能的嘗試讓我們的任務(wù)和數(shù)據(jù)在始終在相同的CPU核心和相同的內(nèi)存節(jié)點(diǎn)上，Linux提供了sched_set_affinity函數(shù)，我們可以在代碼中，將我們的任務(wù)綁定在指定的CPU核心上。一些Linux發(fā)行版也在用戶(hù)態(tài)中提供了numactl和taskset工具，通過(guò)它們也很容易讓我們的程序運(yùn)行在指定的節(jié)點(diǎn)上。

RSS、RPS、RFS、XPS

這些技術(shù)都是近些年來(lái)為了優(yōu)化Linux網(wǎng)絡(luò)方面的性能而添加的特性，RPS、RFS、XPS都是Google貢獻(xiàn)給社區(qū)，RSS需要硬件的支持，目前主流的網(wǎng)卡都已支持，即俗稱(chēng)的多隊(duì)列網(wǎng)卡，充分利用多個(gè)CPU核心，讓數(shù)據(jù)處理的壓力分布到多個(gè)CPU核心上去。RPS和RFS在linux2.6.35的版本被加入，一般是成對(duì)使用的，在不支持RSS特性的網(wǎng)卡上，用軟件來(lái)模擬類(lèi)似的功能，并且將相同的數(shù)據(jù)流綁定到指定的核心上，盡可能提升網(wǎng)絡(luò)方面處理的性能。XPS特性在linux2.6.38的版本中被加入，主要針對(duì)多隊(duì)列網(wǎng)卡在發(fā)送數(shù)據(jù)時(shí)的優(yōu)化，當(dāng)你發(fā)送數(shù)據(jù)包時(shí)，可以根據(jù)CPU MAP來(lái)選擇對(duì)應(yīng)的網(wǎng)卡隊(duì)列，低于指定的kernel版本可能無(wú)法使用相關(guān)的特性，但是發(fā)行版已經(jīng)backport這些特性。

詳細(xì)參考：服務(wù)器性能優(yōu)化之網(wǎng)絡(luò)性能優(yōu)化

IRQ 優(yōu)化

關(guān)于IRQ的優(yōu)化，這里主要有兩點(diǎn)，第一點(diǎn)是關(guān)于中斷合并。在比較早期的時(shí)候，網(wǎng)卡每收到一個(gè)數(shù)據(jù)包就會(huì)觸發(fā)一個(gè)中斷，如果小包的數(shù)據(jù)量特別大的時(shí)候，中斷被觸發(fā)的數(shù)量也變的十分可怕。大部分的計(jì)算資源都被用于處理中斷，導(dǎo)致性能下降。后來(lái)引入了NAPI和Newernewer NAPI特性，在系統(tǒng)較為繁忙的時(shí)候，一次中斷觸發(fā)后，接下來(lái)用輪循的方式讀取后續(xù)的數(shù)據(jù)包，以降低中斷產(chǎn)生的數(shù)量，進(jìn)而也提升了處理的效率。第二點(diǎn)是IRQ親和性，和我們前面提到了CPU親和性較為類(lèi)似，是將不同的網(wǎng)卡隊(duì)列中斷處理綁定到指定的CPU核心上去，適用于擁有RSS特性的網(wǎng)卡。

這里再說(shuō)說(shuō)關(guān)于網(wǎng)絡(luò)卸載的優(yōu)化，目前主要有TSO、GSO、LRO、GRO這幾個(gè)特性，先說(shuō)說(shuō)TSO，以太網(wǎng)MTU一般為1500，減掉TCP/IP的包頭，TCP的MaxSegment Size為1460，通常情況下協(xié)議棧會(huì)對(duì)超過(guò)1460的TCP Payload進(jìn)行分段，保證最后生成的IP包不超過(guò)MTU的大小，對(duì)于支持TSO/GSO的網(wǎng)卡來(lái)說(shuō)，協(xié)議棧就不再需要這樣了，可以將更大的TCPPayload發(fā)送給網(wǎng)卡驅(qū)動(dòng)，然后由網(wǎng)卡進(jìn)行封包操作。通過(guò)這個(gè)手段，將需要在CPU上的計(jì)算offload到網(wǎng)卡上，進(jìn)一步提升整體的性能。GSO為T(mén)SO的升級(jí)版，不在局限于TCP協(xié)議。LRO和TSO的工作路徑正好相反，在頻繁收到小包時(shí)，每次一個(gè)小包都要向協(xié)議棧傳遞，對(duì)多個(gè)TCPPayload包進(jìn)行合并，然后再傳遞給協(xié)議棧，以此來(lái)提升協(xié)議棧處理的效率。GRO為L(zhǎng)RO的升級(jí)版本，解決了LRO存在的一些問(wèn)題。這些特性都是在一定的場(chǎng)景下才可以發(fā)揮其性能效率，在不明確自己的需求的時(shí)候，開(kāi)啟這些特性反而可能造成性能下降。

Kernel 優(yōu)化

關(guān)于Kernel的網(wǎng)絡(luò)相關(guān)優(yōu)化我們就不過(guò)多的介紹了，主要的內(nèi)核網(wǎng)絡(luò)參數(shù)的調(diào)整在以下兩處：net.ipv4.*參數(shù)和net.core.*參數(shù)。主要用于調(diào)節(jié)一些超時(shí)控制及緩存等，通過(guò)搜索引擎我們能很容易找到關(guān)于這些參數(shù)調(diào)優(yōu)的文章，但是修改這些參數(shù)是否能帶來(lái)性能的提升，或者會(huì)有什么弊端，建議詳細(xì)的閱讀kernel文檔，并且多做一些測(cè)試來(lái)驗(yàn)證。

更深入的探索和實(shí)踐

接下來(lái)，我們著重了解如何去更進(jìn)一步提升我們單機(jī)網(wǎng)絡(luò)吞吐以及網(wǎng)絡(luò)處理性能的技術(shù)和手段。計(jì)算機(jī)硬件做為當(dāng)前IT發(fā)展的重要組成部分。作為軟件開(kāi)發(fā)者，我們更應(yīng)該掌握這部分的內(nèi)容，學(xué)習(xí)了解我們的軟件如何在操作系統(tǒng)中運(yùn)行，操作系統(tǒng)又怎樣分配我們的硬件資源。

硬件

CPU

CPU是計(jì)算機(jī)系統(tǒng)中最核心、最關(guān)鍵的部件。在當(dāng)前的x86服務(wù)器領(lǐng)域我們接觸到主要還是Intel的芯片。索性我們就以IntelXeon 2600系列舉例。

Intel Xeon 2600系列的CPU已經(jīng)發(fā)布了3代，第4代產(chǎn)品2016年Q1也即將面市，圖例中均選取了4代產(chǎn)品最高端的型號(hào)。圖一為該系列CPU的核心數(shù)量統(tǒng)計(jì)，從第一代的8核心發(fā)展到即將上市的22核心，若干年前，這是很可怕的事情。裝配該型號(hào)CPU的雙路服務(wù)器，再開(kāi)啟超線(xiàn)程，輕而易舉達(dá)到80多個(gè)核心。就多核處理器的發(fā)展歷程來(lái)講，核心數(shù)量逐年提升，主頻基本穩(wěn)定在一定的范圍內(nèi)，不是說(shuō)單核主頻不再重要，而是說(shuō)在當(dāng)前的需求場(chǎng)景下，多核心才是更符合我們需求的處理器。

圖1

不僅僅是核心數(shù)量，像LLC緩存的容量、內(nèi)存帶寬都有很大的提升，分別達(dá)到了55MB和76.8GB/s。

內(nèi)存

關(guān)于內(nèi)存，可能它的發(fā)展歷程并沒(méi)有像CPU或者其他硬件這樣耀眼奪目。可能大家更關(guān)心的就是價(jià)格吧。目前在服務(wù)器領(lǐng)域，DDR3內(nèi)存仍是主流，DDR4內(nèi)存因?yàn)槌杀镜葐?wèn)題并沒(méi)有大面積普及。這里列舉了IDF15的一些數(shù)據(jù)，從Intel的銷(xiāo)售市場(chǎng)調(diào)研報(bào)告來(lái)看，在明年Q2左右會(huì)看到更多的服務(wù)器CPU支持DDR4，但是PC機(jī)的普及可能還需要一段過(guò)渡時(shí)間。

網(wǎng)絡(luò)

當(dāng)年我們可能僅僅使用一臺(tái)服務(wù)器就能滿(mǎn)足我們的業(yè)務(wù)需求，但是隨著業(yè)務(wù)規(guī)模的擴(kuò)大，單臺(tái)服務(wù)器的能力已經(jīng)遠(yuǎn)不能支撐現(xiàn)在的業(yè)務(wù)，所謂的分布式擴(kuò)展，便被大家推了上現(xiàn)，所以現(xiàn)在的業(yè)務(wù)對(duì)網(wǎng)絡(luò)的依賴(lài)越來(lái)越高。關(guān)于網(wǎng)絡(luò)硬件，我們也以Inter系列的網(wǎng)卡來(lái)舉例，總結(jié)一下目前比較成熟的特性，像RSS特性，前面也提到了，這個(gè)特性是需要硬件支持的，目前大部分中小企業(yè)可能還是千兆網(wǎng)絡(luò)為主，像82559這類(lèi)的網(wǎng)卡，都已經(jīng)支持了比較多的隊(duì)列。今年新出的X710芯片也是正對(duì)應(yīng)著云計(jì)算或者虛擬化的需求，提供更多相關(guān)的特性，如virtualfunction，SR-IOV，tunnel protocol offload等等。隨著云計(jì)算的發(fā)展，未來(lái)包含這些特性的網(wǎng)卡將會(huì)成為主流。

如何更好的利用硬件特性

現(xiàn)在主流的硬件性能已經(jīng)很強(qiáng)大了，但是我們的應(yīng)用軟件，真的能夠充分利用這些硬件嗎？如何更進(jìn)一步把這些硬件特性利用起來(lái)，我們摸索出一系列的技術(shù)的段，先聊聊比較關(guān)鍵的三點(diǎn)：數(shù)據(jù)包處理、任務(wù)調(diào)度和數(shù)據(jù)存儲(chǔ)。

首先就是如何處理我們的數(shù)據(jù)包，使其速度更快，效率更高。其次讓我們的任務(wù)按業(yè)務(wù)邏輯進(jìn)行調(diào)度，而不僅僅是我起個(gè)并發(fā)模型，讓操作系統(tǒng)幫我們調(diào)度。第三是關(guān)于數(shù)據(jù)訪(fǎng)問(wèn)，也就是和內(nèi)存交互的一些技巧。

內(nèi)核協(xié)議棧問(wèn)題

在2013年在Shmoocon會(huì)議上，Robert提出”kernel不是一個(gè)萬(wàn)能的解決方案，它正是一個(gè)問(wèn)題所在。”這樣一個(gè)命題。隨著互聯(lián)網(wǎng)的發(fā)展，Linux已經(jīng)成為服務(wù)器領(lǐng)域上不可或缺的角色。但是它的初衷并不是?針對(duì)某一類(lèi)應(yīng)用場(chǎng)景進(jìn)行特殊的優(yōu)化和適配，本質(zhì)上來(lái)說(shuō)還是一個(gè)分時(shí)系統(tǒng)，希望更公平地服務(wù)眾多的用戶(hù)以和任務(wù)。但正是因?yàn)樗脑O(shè)計(jì)目標(biāo)是如此，所以在過(guò)去的發(fā)展中也主要是解決這些問(wèn)題。進(jìn)而所造成的一個(gè)問(wèn)題就是系統(tǒng)越來(lái)越龐大，功能越來(lái)越多，邏輯越來(lái)越臃腫，雖然通過(guò)一些手段有的優(yōu)化，但是整體的架構(gòu)對(duì)于我們上層的軟件開(kāi)發(fā)者來(lái)說(shuō)還是比較復(fù)雜的。

圖2是從linux foundation的一篇文章kernel_flow中截取的，我們可以看到在用戶(hù)態(tài)中，從調(diào)用write()等API到將數(shù)據(jù)發(fā)送到網(wǎng)卡上經(jīng)過(guò)了相當(dāng)多的邏輯處理，在很多需求場(chǎng)景中，可以省略一定的邏輯上整個(gè)的東西，復(fù)雜的實(shí)現(xiàn)，一定程度上對(duì)軟件開(kāi)發(fā)者的理解造成了障礙。

圖2

這里重點(diǎn)講兩個(gè)瓶頸點(diǎn)，第一個(gè)就是全局的隊(duì)列，在我們?cè)趯?xiě)用戶(hù)態(tài)網(wǎng)絡(luò)程序中，對(duì)同一個(gè)網(wǎng)絡(luò)端口，僅允許一個(gè)監(jiān)聽(tīng)實(shí)例，接收的數(shù)據(jù)包由一個(gè)隊(duì)列來(lái)維護(hù)，并發(fā)的短連接請(qǐng)求較大時(shí)，會(huì)對(duì)這個(gè)隊(duì)列造成較大的競(jìng)爭(zhēng)壓力，成為一個(gè)很大瓶頸點(diǎn)，至少在linuxkernel 3.9版本之前是這樣，在3.9的版本合并了一個(gè)很關(guān)鍵的特性SO_REUSEPORT，支持多個(gè)進(jìn)程或線(xiàn)程監(jiān)聽(tīng)相同的端口，每個(gè)實(shí)例分配一個(gè)獨(dú)立的隊(duì)列，一定程度上緩解這個(gè)問(wèn)題。用更容易理解的角度來(lái)描述，就是支持了我們?cè)谟脩?hù)態(tài)上對(duì)一個(gè)網(wǎng)絡(luò)端口，可以有多個(gè)進(jìn)程或線(xiàn)程去監(jiān)聽(tīng)它。正是因?yàn)橛羞@樣一個(gè)特性，我們可以根據(jù)CPU的核心數(shù)量來(lái)進(jìn)行端口監(jiān)聽(tīng)實(shí)例的選擇，進(jìn)一步優(yōu)化網(wǎng)絡(luò)連接處理的性能。

第二點(diǎn)也是一個(gè)比較大的問(wèn)題，在linuxkernel中有一個(gè)全局的連接表，用于維護(hù)TCP連接狀態(tài)，這個(gè)表在維護(hù)大量的TCP連接時(shí)，會(huì)造成相當(dāng)嚴(yán)重的資源競(jìng)爭(zhēng)。總的來(lái)說(shuō)，有鎖的地方，有資源占用的地方都可能會(huì)成為瓶頸點(diǎn)。

高性能網(wǎng)絡(luò)

對(duì)于前面提到的問(wèn)題，是我們?yōu)榱藢?shí)現(xiàn)高性能網(wǎng)絡(luò)優(yōu)先要解決的。目前，在業(yè)界來(lái)說(shuō)解決這些問(wèn)題主要有以下兩套方案。第一套方案就是說(shuō)更進(jìn)一步在linuxkernel中優(yōu)化網(wǎng)絡(luò)協(xié)議棧處理的業(yè)務(wù)邏輯和結(jié)構(gòu)，但是這里會(huì)有一個(gè)問(wèn)題，前提你要有一個(gè)相對(duì)有一定kerne經(jīng)驗(yàn)的團(tuán)隊(duì)做這件事情，而且對(duì)它足夠了解，但是對(duì)于大部分企業(yè)來(lái)說(shuō)是很難具備這樣的一個(gè)團(tuán)隊(duì)的。另外一個(gè)解決方案，讓你的數(shù)據(jù)包接近用戶(hù)態(tài)，盡可能的和kernel少做交互，目前我們選擇的是第二種方式，盡可能不讓kernel做太多事情，至少在網(wǎng)絡(luò)數(shù)據(jù)包處理這塊。

關(guān)于網(wǎng)絡(luò)數(shù)據(jù)包處理這塊，如何讓它更接近用戶(hù)態(tài)，主要有兩點(diǎn)。第一點(diǎn)，在收到數(shù)據(jù)包之后不進(jìn)協(xié)議棧，把數(shù)據(jù)包的內(nèi)存直接映射到用戶(hù)態(tài)，讓我們的程序在用戶(hù)態(tài)直接可以看到這些數(shù)據(jù)。這樣就繞過(guò)了kernel的處理。第二個(gè)其這間利用了linuxUIO，這個(gè)特性叫UIO，比如當(dāng)前流行的DPDK，通過(guò)這個(gè)模塊框架我們可以在驅(qū)動(dòng)程序收到數(shù)據(jù)包之后，直接放到用戶(hù)態(tài)的內(nèi)存空間中，也同樣達(dá)到了繞過(guò)協(xié)議棧的目的。

高性能網(wǎng)絡(luò)的問(wèn)題

大家也可能想到一個(gè)問(wèn)題，我雖然繞過(guò)了Linux協(xié)議棧，數(shù)據(jù)包直接達(dá)到用戶(hù)態(tài)，對(duì)于大部分比較業(yè)務(wù)應(yīng)用來(lái)說(shuō)，沒(méi)有太大的意義，為什么？因?yàn)榇藭r(shí)應(yīng)用程序看到的數(shù)據(jù)包僅僅是內(nèi)存中的一段二進(jìn)制，獲取IP等信息，不知如何獲取，和原有的socket編程方式完全不兼容。在一些特殊專(zhuān)用領(lǐng)域的，它們可能會(huì)有一些特有的流程來(lái)處理這些數(shù)據(jù)，而且不需要協(xié)議棧的支持，例如IDS這類(lèi)功能。所以我們需要這樣一個(gè)協(xié)議棧，并且支持傳統(tǒng)的Socket框架，避免帶來(lái)應(yīng)用程序修改成本。我們知道協(xié)議棧從BSD等系統(tǒng)最初的實(shí)現(xiàn)，發(fā)展到現(xiàn)在，經(jīng)歷了幾十個(gè)年頭，功能越來(lái)越復(fù)雜，規(guī)模越來(lái)越龐大。像前面提到采用繞過(guò)kernel默認(rèn)協(xié)議棧的方案的話(huà)，協(xié)議棧是永遠(yuǎn)不可避免的。無(wú)論是購(gòu)買(mǎi)一個(gè)商業(yè)的協(xié)議棧，移植開(kāi)源協(xié)議棧，或者自己重新實(shí)現(xiàn)。

用戶(hù)態(tài)協(xié)議棧

現(xiàn)在一些大公司都已經(jīng)進(jìn)行了相關(guān)的嘗試，并且?guī)У搅松a(chǎn)環(huán)境中。對(duì)于協(xié)議棧，還是有一些優(yōu)化的空間，就TCP協(xié)議來(lái)說(shuō)，它的場(chǎng)景其實(shí)是針對(duì)不可控的互聯(lián)網(wǎng)而產(chǎn)生的，它所面臨的問(wèn)題也主要是延時(shí)不同，距離不同等等廣域網(wǎng)的場(chǎng)景，比如滑動(dòng)窗口，TCP擁塞算法等等。對(duì)于現(xiàn)在的互聯(lián)網(wǎng)業(yè)務(wù)而言，每套業(yè)務(wù)系統(tǒng)都有很多的業(yè)務(wù)層次，除了接入層需要直接面向互聯(lián)網(wǎng)和用戶(hù)打交道，其余大量的數(shù)據(jù)交互都發(fā)生在機(jī)房?jī)?nèi)部或機(jī)房之間，就算跨兩個(gè)異地的機(jī)房，之間的網(wǎng)絡(luò)延時(shí)也不過(guò)幾毫秒，并不像互聯(lián)網(wǎng)的環(huán)境那樣的復(fù)雜，也正因如此，很多特性在這些場(chǎng)景中看來(lái)有些“多余”。也正是因?yàn)檫@些特性，對(duì)于網(wǎng)絡(luò)性能而言也是有一定的損耗，也給我們更多的空間，根據(jù)我們自己的業(yè)務(wù)對(duì)其進(jìn)行定制和優(yōu)化。

擴(kuò)展性

這個(gè)也是大家都面臨的一個(gè)問(wèn)題。例如，數(shù)據(jù)流量進(jìn)來(lái)，需要對(duì)它進(jìn)行采樣統(tǒng)計(jì)分析，或者做一些更精細(xì)化的流量調(diào)度，如此眾多的業(yè)務(wù)需求，如果像前面提到的在linuxkernel內(nèi)部做優(yōu)化，做擴(kuò)展的話(huà)，挑戰(zhàn)還是蠻大的。正是因?yàn)槲覀冇腥绱硕嗟臉I(yè)務(wù)需求，所以我們選擇了在kernel之外做這樣的事情。

我們的服務(wù)器經(jīng)常會(huì)有一種現(xiàn)象，CPU0 使用率很高，但大部分的CPU核心很空閑，我們?cè)诰幊痰臅r(shí)候，多進(jìn)程模型或多線(xiàn)程模型，只是描述程序的并發(fā)模型，和系統(tǒng)的多核調(diào)度并沒(méi)有太多直接的聯(lián)系。這些調(diào)度模型是否能夠充分利用多核，就像前面提到的CPU親和性，將某個(gè)進(jìn)程或線(xiàn)程綁定在指定的CPU核心，充分利用CPU核心的緩存，減少在上下文切換等。這里產(chǎn)生了另外一個(gè)問(wèn)題，雖然這種方式是能解決對(duì)于CPU多核利用率不佳的問(wèn)題，但這種硬性關(guān)聯(lián)無(wú)法解決我們業(yè)務(wù)上的需求，也就是說(shuō)結(jié)合業(yè)務(wù)，我們更了解應(yīng)該怎樣調(diào)度我們計(jì)算資源和數(shù)據(jù)。

剛剛提到了多進(jìn)程和多線(xiàn)程，有些同學(xué)說(shuō)用協(xié)程的模型也可以來(lái)解決這個(gè)問(wèn)題吧？但協(xié)程只是讓開(kāi)發(fā)者更容易使用的一種封裝，在進(jìn)程內(nèi)模擬并發(fā)，并自行管理上下文，比系統(tǒng)提供的要輕一些，但最終還是落在現(xiàn)在的調(diào)度模型上。這里有一個(gè)比較有爭(zhēng)議的建議，不見(jiàn)得在任何場(chǎng)景中都適用。

cache優(yōu)化

前面已經(jīng)提到過(guò)，對(duì)于在一條網(wǎng)絡(luò)連接上的數(shù)據(jù)處理，盡可能保持在一個(gè)CPU核心上，以此換取CPUCache的利用率。網(wǎng)絡(luò)連接流保持在一個(gè)核心上，可以降低在網(wǎng)絡(luò)連接流上處理的優(yōu)化成本，如果背道而馳的話(huà)，可能我接收數(shù)據(jù)包的是CPU0核心，發(fā)送數(shù)據(jù)包的是CPU1核心，這樣可能會(huì)引入業(yè)務(wù)處理上的復(fù)雜度。

無(wú)鎖數(shù)據(jù)結(jié)構(gòu)，其是更多的都是編程上的一些技巧，雖然我們用的是多核平臺(tái)，盡可能讓每個(gè)核心做自己的事情，但是不可避免在業(yè)務(wù)的需求上還是有跨CPU核心或?qū)嵗耐ㄐ胚^(guò)程，這類(lèi)通信是無(wú)法避免的，我們只有盡可能保證不要有鎖的出現(xiàn)，不是用鎖解決資源問(wèn)題不好，而是這種上下文中，解決數(shù)據(jù)一致性可能成本會(huì)頗高，得不償失，特別是在本文提到的需求場(chǎng)景下。

保證你的數(shù)據(jù)結(jié)構(gòu)盡可能在相同的CPU核心上進(jìn)行處理，對(duì)于一個(gè)數(shù)據(jù)包相關(guān)的數(shù)據(jù)結(jié)構(gòu)或者哈希表，在相同的類(lèi)型實(shí)例上都保存一份，雖然增加了一些內(nèi)存占用，但降低了資源沖突的概率。

圖3是一些常見(jiàn)的延時(shí)，其中一部分的數(shù)據(jù)是在我的laptop上測(cè)試得出的，另外一部分是引用JeffDean。我們可以看到對(duì)于一個(gè)CPU寄存器或緩沖的訪(fǎng)問(wèn)，基本都在1個(gè)時(shí)鐘周期內(nèi)就可以完成了，延時(shí)是很低的，對(duì)于L1緩存來(lái)說(shuō)至少需要4個(gè)時(shí)鐘周期，LLC至少要26個(gè)時(shí)鐘周期，到我們內(nèi)存訪(fǎng)問(wèn)的話(huà)就是更是拉開(kāi)相當(dāng)大的數(shù)量級(jí)。也是說(shuō)明前面為什么多次提到盡可能充分利用CPU的緩存，而不是說(shuō)盡可能把數(shù)據(jù)放在內(nèi)存里，因?yàn)閮?nèi)存訪(fǎng)問(wèn)的代價(jià)，在這里看來(lái)有些昂貴的，的確是這樣的。但是說(shuō)對(duì)于IO設(shè)備，之間的差距則變得更大了。

圖3

內(nèi)存優(yōu)化

前面提到的都是關(guān)于任務(wù)調(diào)度以及關(guān)于對(duì)數(shù)據(jù)包處理上的優(yōu)化的關(guān)鍵點(diǎn)，最后這一點(diǎn)主要關(guān)于內(nèi)存的技巧。第一個(gè)是盡可能的不要使用多級(jí)的指針嵌套，怎么理解呢？在我們傳統(tǒng)中實(shí)現(xiàn)，都會(huì)抽象很多結(jié)構(gòu)體，通過(guò)我們的業(yè)務(wù)抽象出很多層次，然后通過(guò)指針一級(jí)級(jí)關(guān)聯(lián)下去，從這個(gè)角度看沒(méi)有什么問(wèn)題，通過(guò)指針可以很方便對(duì)數(shù)據(jù)進(jìn)行索引和處理，避免數(shù)據(jù)處理的拷貝。但最大的問(wèn)題也是發(fā)生在這里，多級(jí)的指針檢索，有很大的機(jī)率觸發(fā)你的CacheMiss。對(duì)于網(wǎng)絡(luò)數(shù)據(jù)處理，盡可能將你的數(shù)據(jù)結(jié)構(gòu)以及數(shù)據(jù)業(yè)務(wù)層面盡可能抽象更加扁平化一些，這是一個(gè)取舍的問(wèn)題，也是在高性能面前尋求一個(gè)平衡點(diǎn)。

Hugepage主要解決的問(wèn)題就是TLB Miss的問(wèn)題。TLB是需要靠硬件實(shí)現(xiàn)的，因?yàn)槌杀竞芨?#xff0c;所以它的容量沒(méi)有像其他的存儲(chǔ)呈指數(shù)級(jí)的增長(zhǎng)。但是我們的內(nèi)存幾十G，上百G都已經(jīng)是常態(tài)了。這種不對(duì)稱(chēng)的存在，造成了大內(nèi)存在4k頁(yè)面的時(shí)候產(chǎn)生了大量的TLB Miss。目前解決的手段就是使用更大的內(nèi)存頁(yè)，也就是hugepage，雖然可以換來(lái)性能提升，但是也引入了另外一個(gè)問(wèn)題，就是內(nèi)存利用率的問(wèn)題，同時(shí)要求你對(duì)大頁(yè)內(nèi)存的使用進(jìn)行數(shù)據(jù)結(jié)構(gòu)上的優(yōu)化。

最后一個(gè)內(nèi)存預(yù)分配的問(wèn)題，其實(shí)在一些軟件中可以看到它的影子，像一些數(shù)據(jù)庫(kù)的實(shí)現(xiàn)，我們可以看到預(yù)分配內(nèi)存的場(chǎng)景，它的引入解決的問(wèn)題是什么呢？如果需要內(nèi)存，進(jìn)行數(shù)據(jù)存儲(chǔ)的時(shí)候，頻繁去申請(qǐng)釋放內(nèi)存，在內(nèi)存管理就會(huì)把整體的性能拉下來(lái)，提前進(jìn)行內(nèi)存預(yù)分配，可以一定程度上降低這方面的開(kāi)銷(xiāo)。還是說(shuō)要對(duì)內(nèi)存進(jìn)行更精細(xì)化的管理，避免在內(nèi)存分配上引入一些性能損失或容量損失等等。

總結(jié)

前面提到了這些都是我們?cè)谧龈咝阅芫W(wǎng)絡(luò)框架這個(gè)項(xiàng)目中遇到的一些問(wèn)題，在業(yè)內(nèi)交流汲取的經(jīng)驗(yàn)，以及我們?cè)趯?shí)踐上所帶來(lái)的一些積累。就目前整體的IT產(chǎn)業(yè)的發(fā)展，無(wú)論軟件還是硬件來(lái)說(shuō)，它的發(fā)展在向一個(gè)目標(biāo)前進(jìn)，軟件開(kāi)發(fā)人員需要了解硬件的工作原理，硬件接觸較多的同學(xué)比如運(yùn)維也要更了解你的業(yè)務(wù)是怎樣的實(shí)現(xiàn)，軟硬結(jié)合會(huì)是未來(lái)持續(xù)方向之一。雖然說(shuō)在當(dāng)前這個(gè)云計(jì)算大潮下，很多軟件人員只需要把代碼寫(xiě)好，直接發(fā)布出去了，這樣對(duì)你的開(kāi)發(fā)是帶來(lái)一定便利性。但也逃避不了這樣的一個(gè)角色，幫助你讓你的軟件更好的運(yùn)行在底層平臺(tái)上。

8086剛問(wèn)世的那個(gè)時(shí)代，主CPU是沒(méi)有浮點(diǎn)運(yùn)算的，要用攜處理器來(lái)支持。隨著歷史發(fā)展，所有功能都在向CPU內(nèi)遷移，就像FSB，逐漸取消了，內(nèi)存管理功能移到了CPU內(nèi)部，這是CPU整個(gè)處理器產(chǎn)業(yè)的發(fā)展。當(dāng)然對(duì)我們來(lái)說(shuō)是很好的，我們可以使用更大的帶寬在CPU和內(nèi)存之間進(jìn)行交互。我國(guó)近幾年對(duì)于網(wǎng)絡(luò)安全的發(fā)展尤其看重，比如全站HTTPS，我們知道這種場(chǎng)景的話(huà)需要很大計(jì)算資源進(jìn)行加密解密，但是這部分的運(yùn)算讓通用CPU來(lái)做的話(huà)，性能并不是特別理想，所以又引入了的協(xié)處理器的概念，當(dāng)然已經(jīng)不是當(dāng)年的那個(gè)協(xié)處理器，而用一塊輔助的硬件加速卡幫我們做SSL Offload的事情。使用GPU進(jìn)行加速處理，這個(gè)也是我們調(diào)研的方向，就是我們希望用GPU這樣一個(gè)比較優(yōu)秀的并行架構(gòu)能夠幫助我們?cè)诰W(wǎng)絡(luò)處理上，可能達(dá)到更好的效果，另外提到關(guān)于英特爾的phi卡，天河2號(hào)，連續(xù)幾年拿到超算排名，不可否認(rèn)有一部分是由phi卡帶來(lái)的。

作為軟件開(kāi)發(fā)人員不僅僅代碼寫(xiě)的漂亮，質(zhì)量高，一定要對(duì)硬件有一定的了解，做運(yùn)維的同學(xué)不僅需要對(duì)硬件，對(duì)中間件，對(duì)服務(wù)器了解的同時(shí)，也同時(shí)多看看業(yè)務(wù)方有怎樣的需求，怎么樣把資源和業(yè)務(wù)結(jié)合的更好，更好的為我們的用戶(hù)提供更好的服務(wù)。

- END -

看完一鍵三連在看，轉(zhuǎn)發(fā)，點(diǎn)贊

是對(duì)文章最大的贊賞，極客重生感謝你

總結(jié)

以上是生活随笔為你收集整理的从C10K到C10M高性能网络的探索与实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。