高性能和高并發(fā)，聽著就有點(diǎn)類似，并且他們還經(jīng)常一起提及，比如提高我們的并發(fā)性能，顯然，高性能可以提高我們的并發(fā)，但是細(xì)化來看，他們是有區(qū)別的，他們的考量點(diǎn)的維度不同。高性能需要我們從單機(jī)維度到整體維度去考慮，更多的是先從編碼角度、架構(gòu)使用角度去讓我們的單機(jī)（單實(shí)例）有更好的性能，然后再從整個(gè)系統(tǒng)層面來擁有更好的性能；高并發(fā)則直接是全局角度來讓我們的系統(tǒng)在全鏈路下都能夠抗住更多的并發(fā)請(qǐng)求。

一、高性能架構(gòu)和系統(tǒng)設(shè)計(jì)的幾個(gè)層面

高性能架構(gòu)設(shè)計(jì)主要集中在單機(jī)優(yōu)化、服務(wù)集群優(yōu)化、編碼優(yōu)化三方面。但架構(gòu)層面的設(shè)計(jì)是高性能的基礎(chǔ)，如果架構(gòu)層面的設(shè)計(jì)沒有做到高性能，僅依靠優(yōu)化編碼，對(duì)整體系統(tǒng)的提升是有限的。我們從一個(gè)全局角度來看高性能的系統(tǒng)設(shè)計(jì)，需要整體考慮的包括如下幾個(gè)層面：

• 前端層面。后端優(yōu)化的再好，如果前端（客戶端）的性能不 ok，那么對(duì)用戶而言，他們的體感還是很差的，因此前端層也是有必要考慮的，只是不在我們本文的設(shè)計(jì)范圍之內(nèi)，在實(shí)際工作中是需要進(jìn)行探討的。
• 編碼實(shí)現(xiàn)層面：代碼邏輯的分層、分模塊、協(xié)程、資源復(fù)用（對(duì)象池，線程池等）、異步、IO 多路復(fù)用（異步非阻塞）、并發(fā)、無鎖設(shè)計(jì)、設(shè)計(jì)模式等。
• 單機(jī)架構(gòu)設(shè)計(jì)層面：IO 多路復(fù)用、Reactor 和 Proactor 架構(gòu)模式
• 系統(tǒng)架構(gòu)設(shè)計(jì)層面：架構(gòu)分層、業(yè)務(wù)分模塊、集群（集中式、分布式）、緩存（多級(jí)緩存、本地緩存）、消息隊(duì)列（異步、削峰）
• 基礎(chǔ)建設(shè)層面：機(jī)房、機(jī)器、資源分配
• 運(yùn)維部署層面：容器化部署、彈性伸縮
• 性能測試優(yōu)化層面：性能壓測、性能分析、性能優(yōu)化

二、前端層面

后端優(yōu)化的再好，如果前端（客戶端）的性能不 ok，那么對(duì)用戶而言，他們的體感還是很差的，因此前端層也是有必要考慮的，只是不在我們本文的設(shè)計(jì)范圍之內(nèi)，在實(shí)際工作中是需要進(jìn)行探討的。

這里簡單說明下，從我個(gè)人工作的經(jīng)歷來看，前端（客戶端）這里可以優(yōu)化的點(diǎn)包括但不限于：數(shù)據(jù)預(yù)加載、數(shù)據(jù)本地緩存、業(yè)務(wù)邏輯前置處理、CDN 加速、請(qǐng)求壓縮、異步處理、合并請(qǐng)求、長連接、靜態(tài)資源等

三、編碼實(shí)現(xiàn)層面

編碼實(shí)現(xiàn)層面：代碼邏輯的分層、分模塊、協(xié)程、資源復(fù)用（對(duì)象池，線程池等）、異步、IO 多路復(fù)用（異步非阻塞）、并發(fā)、無鎖設(shè)計(jì)、設(shè)計(jì)模式等。

多線程、多協(xié)程

大多數(shù)情況下，多進(jìn)程、多線程、多協(xié)程都可以大大提高我們的并發(fā)性能，尤其是是多協(xié)程。

在網(wǎng)絡(luò)框架層面，現(xiàn)在一般成熟的后端系統(tǒng)框架（服務(wù)化框架）都是支持多線程、多協(xié)程的，因此對(duì)于網(wǎng)絡(luò)框架這點(diǎn)，我們只要是引用相對(duì)成熟的服務(wù)化框架來實(shí)現(xiàn)我們的業(yè)務(wù)，基本上可以不用過多考慮和設(shè)計(jì)。

在業(yè)務(wù)層面，如果是 Go 語言，天然支持大量并發(fā)，并且創(chuàng)建 Go 的協(xié)程非常容易，一個(gè) go 關(guān)鍵字就搞定，因此多協(xié)程那就非常容易了，Go 里面可以創(chuàng)建大量協(xié)程來提高我們的并發(fā)性能。如果是其他語言，我們盡可能的使用多協(xié)程、多線程去執(zhí)行我們的業(yè)務(wù)邏輯。

無鎖設(shè)計(jì)（lock free）

在多線程、多協(xié)程的框架下，如果我們并發(fā)的線程（協(xié)程）之間訪問共享資源，那么需要特別注意，要么通過加鎖、要么通過無鎖化設(shè)計(jì)，否則沒有任何處理的訪問共享資源會(huì)產(chǎn)生意想不到的結(jié)果。而加鎖的設(shè)計(jì)，在并發(fā)較大的時(shí)候，如果鎖的力度不合適，或者頻繁的加鎖解鎖，又會(huì)使我們的性能嚴(yán)重下降。

為此，在追求高性能的時(shí)候，大家就比較推崇無鎖化的設(shè)計(jì)。目前很多后臺(tái)底層設(shè)計(jì)，為了避免共享資源的競爭，都采用了無鎖化設(shè)計(jì)，特別是在底層框架上。無鎖化主要有兩種實(shí)現(xiàn)，無鎖隊(duì)列和原子操作。

• 無鎖隊(duì)列。可以通過 鏈表或者 RingBuffer（循環(huán)數(shù)組）來實(shí)現(xiàn)無鎖隊(duì)列。
• 原子操作。利用硬件同步原語 CAS 來實(shí)現(xiàn)各種無鎖的數(shù)據(jù)結(jié)構(gòu)。比如 Go 語言中的 atomic 包、C++11 語言中的 atomic 庫。

數(shù)據(jù)序列化

為什么要說 數(shù)據(jù)序列化協(xié)議？因?yàn)槲覀兊南到y(tǒng)，要么就是各個(gè)后端微服務(wù)之間通過 RPC 做交互，要么就是通過 HTTP/TCP 協(xié)議和前端(終端)做交互，因此不可避免的需要我們進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸。而數(shù)據(jù)，只有序列化后，才方便進(jìn)行網(wǎng)絡(luò)傳輸。

序列化就是將數(shù)據(jù)結(jié)構(gòu)或?qū)ο筠D(zhuǎn)換成二進(jìn)制串的過程，也就是編碼的過程，序列化后，會(huì)把數(shù)據(jù)轉(zhuǎn)換為二進(jìn)制串，然后可以進(jìn)行網(wǎng)絡(luò)傳輸；反序列化就是在序列化過程中所生成的二進(jìn)制串轉(zhuǎn)換成數(shù)據(jù)結(jié)構(gòu)或者對(duì)象的過程，將二進(jìn)制轉(zhuǎn)換為對(duì)象后業(yè)務(wù)才好進(jìn)行后續(xù)的邏輯處理。

常見的序列化協(xié)議如下

• Protocol Buffer（PB）
• JSON
• XML
• 內(nèi)置類型（如 java 語言就有 java.io.Serializable）

常見的序列化協(xié)議的對(duì)比在網(wǎng)上有各種性能的對(duì)比，這里就不在貼相關(guān)截圖了，只說結(jié)論：從性能上和使用廣泛度上來看，后端服務(wù)之間現(xiàn)在一般推薦使用 PB。如果和前端交互，由于 HTTP 協(xié)議只能支持 JSON，因此一般只能 JSON。

池化技術(shù)（資源復(fù)用）

池化技術(shù)是非常常見的一個(gè)提高性能的技術(shù)，池化的核心思想就是對(duì)資源進(jìn)行復(fù)用，減少重復(fù)創(chuàng)建銷毀所帶來的開銷。復(fù)用就是創(chuàng)建一個(gè)池子，然后再在這個(gè)池子里面對(duì)各種資源進(jìn)行統(tǒng)一分配和調(diào)度，不是創(chuàng)建后就釋放，而是統(tǒng)一放到池子里面來復(fù)用，這樣可以減少重復(fù)創(chuàng)建和銷毀，從而提高性能。而這個(gè)資源就包括我們編程中常見到如 線程資源、網(wǎng)絡(luò)連接資源、內(nèi)存資源，具體到對(duì)應(yīng)的池化技術(shù)層面就是 線程池（協(xié)程池）、連接池、內(nèi)存池等。

• 線程池（協(xié)程池）。本質(zhì)都是進(jìn)程、線程、協(xié)程這些維度的一個(gè)池子，先創(chuàng)建合適數(shù)量的線程（協(xié)程）并且初始處于休眠狀態(tài)，然后當(dāng)需要用到的時(shí)候，從池子里面喚醒一個(gè)，然后執(zhí)行業(yè)務(wù)邏輯，處理完業(yè)務(wù)邏輯后，資源并不釋放，而是直接放回池子里面休眠，等待后續(xù)的請(qǐng)求被喚醒，這樣重復(fù)利用。

創(chuàng)建線程的開銷是很大的，因此如果來一個(gè)請(qǐng)求就頻創(chuàng)建一個(gè)線程、進(jìn)程，那么請(qǐng)求的性能肯定不會(huì)太高。

• 連接池。這個(gè)是最常用的，一般我們都要操作 MySQL、Redis 等存儲(chǔ)資源，同樣的，我們并不是每次請(qǐng)求 MySQL、Redis 等存儲(chǔ)的時(shí)候就新創(chuàng)建一個(gè)連接去訪問數(shù)據(jù)，而是初始化的時(shí)候就創(chuàng)建合適數(shù)量的連接放到池子里面，當(dāng)需要連接去訪問數(shù)據(jù)的時(shí)候，從池子里面獲取一個(gè)空閑的連接去訪問數(shù)據(jù)，訪問完了之后不釋放連接，而是放回池子里面。

連接池需要保證連接的可用性，就是這個(gè)連接和 MySQL、Redis 等存儲(chǔ)是必須要定期發(fā)送數(shù)據(jù)來保證連接的，要不然會(huì)被斷開。同時(shí)我們要針對(duì)已經(jīng)失效（斷開）的連接進(jìn)行檢測和摘除。

• 內(nèi)存池。常規(guī)的情況下，我們都是直接調(diào)用 new、malloc 等 Linux 操作系統(tǒng)的 API 來申請(qǐng)分配內(nèi)存，而每次申請(qǐng)的內(nèi)存塊的大小不定，所以，當(dāng)我們頻繁 分配內(nèi)存、回收內(nèi)存的時(shí)候，會(huì)造成大量的內(nèi)存碎片，同時(shí)每次使用內(nèi)存都要重新分配也會(huì)降低性能。內(nèi)存池就是先預(yù)先分配足夠大的一塊內(nèi)存，當(dāng)做我們的內(nèi)存池，然后每次用戶請(qǐng)求分配內(nèi)存的時(shí)候，就會(huì)返回內(nèi)存池中的一塊空閑的內(nèi)存，并將這塊內(nèi)存的標(biāo)志置為已使用，當(dāng)內(nèi)存使用完畢釋放內(nèi)存的時(shí)候，也不是真正地調(diào)用 free 或 delete 來釋放內(nèi)存，而是把這塊內(nèi)存直接放回內(nèi)存池內(nèi)并且同時(shí)把標(biāo)志置為空閑。一般業(yè)內(nèi)都有相關(guān)的套件來幫我們來做這個(gè)事情，比如在 C/C++ 語言里面，都有相關(guān)庫去封裝原生的 malloc，glibc 實(shí)現(xiàn)了一個(gè) ptmalloc 庫，Google 實(shí)現(xiàn)了一個(gè) tcmalloc 庫。
• 對(duì)象池。其實(shí)前面幾種類型的池化技術(shù)，其實(shí)都可以作為對(duì)象池的各種應(yīng)用，因?yàn)楦鞣N資源都可以當(dāng)做一個(gè)對(duì)象。對(duì)象池就是避免大量創(chuàng)建同一個(gè)類型的對(duì)象，從而進(jìn)行池化，保證對(duì)象的可復(fù)用性。

異步IO 和 異步流程

異步有兩個(gè)層面的意思：

• IO 層面的異步調(diào)用
• 業(yè)務(wù)邏輯層面的異步流程

異步是相對(duì)同步而言的，同步就是要等待前面一個(gè)事情執(zhí)行完畢才能繼續(xù)執(zhí)行，異步就是可以不用等待，可想而知，異步的性能要比同步好很多。

IO 層面的異步調(diào)用

針對(duì) IO 層面的異步調(diào)用，就是我們常說的 I/O 模型，有 阻塞、非阻塞、同步、異步這幾種類型。在 Linux 操作系統(tǒng)內(nèi)核中，內(nèi)置了 5 種不同的 IO 交互模式，分別是阻塞 IO、非阻塞 IO、多路復(fù)用 IO、信號(hào)驅(qū)動(dòng) IO、異步 IO。

針對(duì)網(wǎng)絡(luò) IO 模型而言，Linux 下，使用最多性能較好的是同步非阻塞模型，具體代表是 AIO，而 Windows 下的代表作 IOCP 則實(shí)現(xiàn)了真正的異步非阻塞 I/O。

業(yè)務(wù)邏輯層面的異步流程

業(yè)務(wù)邏輯層面的異步流程，就是指讓我們的應(yīng)用程序在業(yè)務(wù)邏輯上可以異步的執(zhí)行。通常比較復(fù)雜的業(yè)務(wù)，都會(huì)有很多步驟流程，如果所有步驟都是同步的話，那么當(dāng)這些步驟中有一步卡住，那么整個(gè)流程都會(huì)卡住，這樣的流程顯然性能不會(huì)很高。為此，在業(yè)內(nèi)，我們?nèi)绻胍岣咝阅埽岣卟l(fā)，那么基本上都會(huì)采用異步流程的方式。

舉個(gè)實(shí)際的應(yīng)用案例，針對(duì) IM 系統(tǒng)的發(fā)送消息的這個(gè)場景，比如微信發(fā)送消息，那么當(dāng)客戶端發(fā)送的消息，服務(wù)端收到后，這個(gè)消息肯定要落地存儲(chǔ)，這個(gè)發(fā)送的流程才能算完畢，但是，如果每條消息，服務(wù)端都真正存儲(chǔ)到 DB 后再返回給客戶端說已經(jīng)正確收到，那么這個(gè)性能顯然會(huì)很低，因?yàn)槲覀冎溃瑢?DB 的性能是很低的，尤其是像微信這種每天有大量消息的 APP。那么這個(gè)流程就可以異步化，服務(wù)端收到消息后，先把消息寫入消息隊(duì)列，寫入隊(duì)列成功就返回給客戶端，然后異步流程去從消息隊(duì)列里面消費(fèi)數(shù)據(jù)然后落地存儲(chǔ)到 DB 里面，這樣性能就非常高了，因?yàn)橄㈥?duì)列的性能會(huì)很高。而比較低性能的操作都是異步處理。

并發(fā)流程

并發(fā)流程，同樣是針對(duì)我們上層的應(yīng)用程序而言的，我們?cè)谔幚順I(yè)務(wù)邏輯的時(shí)候，尤其是相對(duì)負(fù)責(zé)的業(yè)務(wù)邏輯，一般下游都可能會(huì)有多個(gè)請(qǐng)求，或者說多個(gè)流程，如果依賴的下游多個(gè)請(qǐng)求之間沒有強(qiáng)依賴關(guān)系，那么我們可以將這些請(qǐng)求的流程并發(fā)處理，這個(gè)是后端系統(tǒng)設(shè)計(jì)里面非常常見的優(yōu)化手段。

通過并發(fā)的處理流程，可以將串行的疊加處理耗時(shí)優(yōu)化為單個(gè)處理耗時(shí)，這樣就大大的降低了整體耗時(shí)，舉個(gè)例子，一個(gè)商品活動(dòng)頁面，渲染的數(shù)據(jù)包括 用戶基本信息、用戶活動(dòng)積分、用戶推薦商品列表。那么當(dāng)收到這個(gè)用戶的請(qǐng)求的時(shí)候，我們需要 查詢用戶的基本信息、用戶的活動(dòng)積分，還有用戶的商品推薦，而這 3 個(gè)步驟完全是沒有相互依賴關(guān)系的，因此，我們可以并發(fā)去分別查詢，這樣可以極大的減少耗時(shí)，從而提高我們的性能。

四、單機(jī)架構(gòu)設(shè)計(jì)層面

單機(jī)優(yōu)化的關(guān)鍵點(diǎn)

單機(jī)優(yōu)化層面就是要盡量提升單機(jī)的性能，將單機(jī)的性能發(fā)揮到極致的其中一個(gè)關(guān)鍵點(diǎn)就是我們服務(wù)器采取的并發(fā)模型，然后在這個(gè)模型下，去設(shè)計(jì)好我們的服務(wù)器對(duì)連接的管理、對(duì)請(qǐng)求的處理流程。而這些就涉及到我們的多協(xié)程、多線程的進(jìn)程模型和異步非阻塞、同步非阻塞的 IO 模型。

在具體實(shí)現(xiàn)細(xì)節(jié)上，針對(duì)連接的管理，要想提高性能，那么就要采用 IO 多路復(fù)用技術(shù)，可以參考I/O Multiplexing查看，I/O 多路復(fù)用技術(shù)的兩個(gè)關(guān)鍵點(diǎn)在于：

• 當(dāng)多條連接共用一個(gè)阻塞對(duì)象后，進(jìn)程只需要在一個(gè)阻塞對(duì)象上等待，而無須再輪詢所有連接，常見的實(shí)現(xiàn)方式有 select、epoll、kqueue 等。
• 當(dāng)某條連接有新的數(shù)據(jù)可以處理時(shí)，操作系統(tǒng)會(huì)通知進(jìn)程，進(jìn)程從阻塞狀態(tài)返回，開始進(jìn)行業(yè)務(wù)處理。

IO 多路復(fù)用（epoll 模型）

基本上來說，異步 I/O 模型的發(fā)展技術(shù)是：select -> poll -> epoll -> aio -> libevent -> libuv。

而且現(xiàn)在大家比較熟悉和使用的最多的恐怕就是 epoll 和 aio ，尤其是 epoll 模型，基本是 Linux 后端系統(tǒng)下的大部分框架和軟件都是采用 epoll 模型。

但是，需要特別強(qiáng)調(diào)的是，僅僅依靠 epoll 不是萬能的，連接數(shù)太多的時(shí)候單進(jìn)程的 epoll 也是不行的。

Reactor 和 Proactor 架構(gòu)模式

epoll 只是一個(gè) IO 多路復(fù)用的模型，在后端系統(tǒng)設(shè)計(jì)里面，要想實(shí)現(xiàn)單機(jī)的高性能，那在 IO 多路復(fù)用基礎(chǔ)之上，我們的整個(gè)網(wǎng)絡(luò)框架，還需要配合池化技術(shù)來提高我們的性能。因此，業(yè)界一般都是采用 I/O 多路復(fù)用 + 線程池（協(xié)程池、進(jìn)程池）的方式來提高性能。與之對(duì)應(yīng)的，在業(yè)界常用的兩個(gè)單機(jī)高性能的架構(gòu)模式就是Reactor 和 Proactor 模式。Reactor 模式屬于非阻塞同步網(wǎng)絡(luò)模型，Proactor 模式屬于非阻塞異步網(wǎng)絡(luò)模型。

在業(yè)內(nèi)開源軟件里面，Redis 采用的是 單 Reactor 單進(jìn)程的方式，Memcache 采用的是 多 Reactor 多線程的方式，Nginx 采用的是多 Reactor 多進(jìn)程的方式。關(guān)于 的詳細(xì)介紹，可以查看The Design and Implementation of the Reactor。

Redis 可以用單進(jìn)程 Reactor 模式的是因?yàn)?Redis 的應(yīng)用場景是內(nèi)部訪問，并發(fā)數(shù)一般不會(huì)超過 1w，而 Nginx 必須用多進(jìn)程 Reactor 模式是因?yàn)?Nginx 是外網(wǎng)訪問，并發(fā)數(shù)很容易超過 1w，因此我們的網(wǎng)絡(luò)架構(gòu)模式，必須要通過 I/O 多路復(fù)用 + 線程池（協(xié)程池、進(jìn)程池）來配合。

可以看到，單機(jī)優(yōu)化層面其實(shí)和編碼層面上的多協(xié)程、異步 IO、 池化技術(shù)都是有強(qiáng)關(guān)聯(lián)的。這里也是一個(gè)知識(shí)相通的典型，我們所學(xué)的一些基礎(chǔ)層面的知識(shí)點(diǎn)，在架構(gòu)層面、模型層面都是有用武之地的。

五、系統(tǒng)架構(gòu)設(shè)計(jì)層面

架構(gòu)設(shè)計(jì)層面：架構(gòu)分層、業(yè)務(wù)分模塊、集群（集中式、分布式）、緩存（多級(jí)緩存、本地緩存）、消息隊(duì)列（異步、削峰）

架構(gòu)和模塊劃分的設(shè)計(jì)

整個(gè)系統(tǒng)想要有一個(gè)高性能，那么首先就需要有個(gè)合理的架構(gòu)設(shè)計(jì)，這里需要根據(jù)一些架構(gòu)設(shè)計(jì)原則，比如高內(nèi)聚低耦合，職責(zé)單一等來去構(gòu)建我們的架構(gòu)。最有效的方式包括架構(gòu)分層設(shè)計(jì)、業(yè)務(wù)分模塊設(shè)計(jì)。

這么設(shè)計(jì)之后，在整體的系統(tǒng)性能優(yōu)化上，后面就會(huì)有比較大的優(yōu)化空間，從而不至于后面想要優(yōu)化就根本無從下手，只能重構(gòu)系統(tǒng)。

服務(wù)化框架的設(shè)計(jì)

目前的互聯(lián)網(wǎng)時(shí)代，我們基本上都是采用微服務(wù)來搭建我們的系統(tǒng)，而微服務(wù)化的必要條件就是要有一套服務(wù)化框架，這個(gè)服務(wù)化框架最核心的功能包括 RPC 請(qǐng)求和最基礎(chǔ)的服務(wù)治理策略（服務(wù)注冊(cè)和發(fā)現(xiàn)、負(fù)載均衡等）。

為此，這里服務(wù)化框架的性能就尤為重要，這里主要包括這個(gè)服務(wù)化框架里面實(shí)現(xiàn)：

• 數(shù)據(jù)處理。

數(shù)據(jù)序列化協(xié)議，一般有些采用 PB 協(xié)議，不管是從性能還是維護(hù)都是最優(yōu)的。

數(shù)據(jù)壓縮，一般采用 gzip 壓縮，壓縮后可以減少網(wǎng)絡(luò)上的數(shù)據(jù)傳輸。

• 網(wǎng)絡(luò)模型。

同步還是異步流程，如果是 Go 語言，那么可以來一個(gè)請(qǐng)求 go 一個(gè)協(xié)程來處理。

是否有相關(guān)連接池的能力。

其他的一些優(yōu)化。

負(fù)載均衡

負(fù)載均衡系統(tǒng)是水平擴(kuò)展的關(guān)鍵技術(shù)，通過負(fù)載均衡，相當(dāng)于可以把流量分散到不同的機(jī)器的不同的服務(wù)實(shí)例里面，這樣每個(gè)服務(wù)實(shí)例都可以承擔(dān)一部分請(qǐng)求，從而可以提高我們的整體系統(tǒng)的性能。

對(duì)于負(fù)載均衡的方式，大都是在客戶端發(fā)現(xiàn)模式(client-side) 來實(shí)現(xiàn)服務(wù)路和負(fù)載均衡，一般也都會(huì)支持常見的負(fù)載均衡策略，如隨機(jī)，輪訓(xùn)，hash，權(quán)重，連接數(shù)【連接數(shù)越少，優(yōu)先級(jí)越高】。

合理采用各種隊(duì)列

在后端系統(tǒng)設(shè)計(jì)里面，很多流程和請(qǐng)求并不要求實(shí)時(shí)處理，更不需要做到強(qiáng)一致，大部分情況下，我們只需要實(shí)現(xiàn)最終一致性就可以了。故而，我們通過隊(duì)列，就可以使我們的系統(tǒng)能夠?qū)崿F(xiàn)異步處理邏輯、流程削峰、業(yè)務(wù)模塊解耦、柔性事務(wù)等多種效果，從而可以完成最終一致性，并且能夠極大的提高我們系統(tǒng)的性能。

我們常見的隊(duì)列包括

• 消息隊(duì)列：使用的最為廣泛的隊(duì)列之一，代表作有 RabbitMQ、RocketMQ、Kafka 等。可以用來實(shí)現(xiàn)異步邏輯、削峰、解耦等多種效果。從而可以極大的提高我們的性能
• 延遲隊(duì)列：延時(shí)隊(duì)列相比于普通隊(duì)列最大的區(qū)別就體現(xiàn)在其延時(shí)的屬性上，普通隊(duì)列的元素是先進(jìn)先出，按入隊(duì)順序進(jìn)行處理，而延時(shí)隊(duì)列中的元素在入隊(duì)時(shí)會(huì)指定一個(gè)延遲時(shí)間，表示其希望能夠在經(jīng)過該指定時(shí)間后處理。延遲隊(duì)列的目的是為了異步處理。延遲隊(duì)列的應(yīng)用場景其實(shí)也非常的廣泛，比如說以下的場景：

到期后自動(dòng)執(zhí)行指定操作。

在指定時(shí)間之前自動(dòng)執(zhí)行某些動(dòng)作

查詢某個(gè)任務(wù)是否完成，未完成等待一定時(shí)間再次查詢

回調(diào)通知，當(dāng)回調(diào)失敗時(shí)，等待后重試

• 任務(wù)隊(duì)列：將任務(wù)提交到隊(duì)列中異步執(zhí)行，最常見的就是線程池的任務(wù)隊(duì)列。

各級(jí)緩存的設(shè)計(jì)

分布式緩存

分布式緩存的代表作有 Redis、Memcache。通過分布式緩存，我們可以不直接讀數(shù)據(jù)庫，而是讀取緩存來獲取數(shù)據(jù)，可以極大的提高我們讀數(shù)據(jù)的性能。而一般的業(yè)務(wù)都是讀多寫少，因此，對(duì)我們的整體性能的提高是非常有效的手段，而且是必須的手段。

本地緩存

本地緩存可以從幾個(gè)維度來看：

• 客戶端的本地緩存：針對(duì)一些不常改變的數(shù)據(jù)，客戶端也可以緩存，這樣就可以避免請(qǐng)求后端，從而可以改善性能
• 后端服務(wù)的本地緩存：后端服務(wù)中，一般都會(huì)采用分布式緩存，但是，有些場景下，如果我們的數(shù)據(jù)量比較小，那么可以直接將這些數(shù)據(jù)緩存到進(jìn)程里面，這樣直接通過內(nèi)存讀取，而不用網(wǎng)絡(luò)耗時(shí)，性能會(huì)更高。但是本地緩存一般只會(huì)緩存少量數(shù)據(jù)。數(shù)據(jù)量太大就不合適。

多級(jí)緩存

多級(jí)緩存是一個(gè)更為高級(jí)的緩存架構(gòu)設(shè)計(jì)，比如最簡單的模式可以是 本地緩存 + 分布式緩存這樣形成一個(gè)多級(jí)緩存架構(gòu)。

我們把全量要緩存的數(shù)據(jù)都放到分布式緩存里面，然后把一些熱點(diǎn)的少量緩存放到本地緩存里面，這樣大部分熱點(diǎn)數(shù)據(jù)都能夠從本地直接讀取，而其他非熱點(diǎn)的數(shù)據(jù)還是通過分布式緩存讀取，這樣可以極大的提高我們的性能，提高并發(fā)能力。

舉個(gè)例子，電商系統(tǒng)里面，我們做一個(gè)活動(dòng)頁，活動(dòng)頁的前面 10 個(gè)商品是特賣商品，然后后面的其他商品就是常規(guī)商品，因?yàn)槭腔顒?dòng)頁面，那么這個(gè)頁面的訪問肯定就會(huì)非常大。而活動(dòng)頁面的前 10 個(gè)商品，必然是用戶首先進(jìn)來頁面就一定會(huì)看到的，而用戶想要繼續(xù)看其他商品，那么就需要在手機(jī)上手動(dòng)上滑刷新一下。這個(gè)場景下，前面 10 個(gè)商品的訪問量無疑是最大的，而用戶手動(dòng)上滑刷新后的請(qǐng)求就會(huì)少很多。為此，我們可以把全量商品都緩存在分布式緩存如 redis 里面，然后再在這個(gè)基礎(chǔ)之上，把前面 10 個(gè)商品的信息緩存到本地，這樣，當(dāng)活動(dòng)開始后，拉取的第一頁 10 個(gè)商品數(shù)據(jù)，都是從本地緩存拉取的，本地讀取性能會(huì)非常高，因?yàn)閮?nèi)存讀取就行，完全不需要網(wǎng)絡(luò)交互。

其他的模式，可以 本地緩存 + 二級(jí)分布式緩存 + 一級(jí)分布式緩存，也就是針對(duì)分布式緩存再做一層分級(jí)，這樣每一級(jí)的緩存都能抗一部分的量，因此整體來看，能夠?qū)ν馓峁┑男阅芫妥銐蚋摺?/p>

緩存預(yù)熱

通過異步任務(wù)提前將接下來要大量訪問的數(shù)據(jù)預(yù)熱到我們緩存里面。這樣當(dāng)有請(qǐng)求的突峰的時(shí)候，可以從容應(yīng)對(duì)。

其他高性能的 NoSQL

除了 Redis、本地緩存這些，其他的一些 NoSQL 中，MongoDB、Elasticserach 也是常見的性能很高的組件，我們可以根據(jù)適用場景，合理選用。

比如我們?cè)陔娚滔到y(tǒng)里面，我們針對(duì)商品的搜索、推薦都是采用 Elasticserach 來實(shí)現(xiàn)。

存儲(chǔ)的設(shè)計(jì)

數(shù)據(jù)分區(qū)

數(shù)據(jù)分區(qū)是把數(shù)據(jù)按一定的方式分成多個(gè)區(qū)（比如通過地理位置），不同的數(shù)據(jù)區(qū)來分擔(dān)不同區(qū)的流量，這需要一個(gè)數(shù)據(jù)路由的中間件，但會(huì)導(dǎo)致跨庫的 Join 和跨庫的事務(wù)非常復(fù)雜。

將數(shù)據(jù)分布到多個(gè)分區(qū)有兩種比較典型的方案：

• 根據(jù)鍵做哈希，根據(jù)哈希值選擇對(duì)應(yīng)的數(shù)據(jù)節(jié)點(diǎn)。
• 根據(jù)范圍分區(qū)，某一段連續(xù)的鍵都保存在一個(gè)數(shù)據(jù)節(jié)點(diǎn)上。

分庫分表

一般來說，影響數(shù)據(jù)庫最大的性能問題有兩個(gè)，一個(gè)是對(duì)數(shù)據(jù)庫的操作，一個(gè)是數(shù)據(jù)庫中數(shù)據(jù)的大小。對(duì)于前者，我們需要從業(yè)務(wù)上來優(yōu)化。一方面，簡化業(yè)務(wù)，不要在數(shù)據(jù)庫上做太多的關(guān)聯(lián)查詢，而對(duì)于一些更為復(fù)雜的用于做報(bào)表或是搜索的數(shù)據(jù)庫操作，應(yīng)該把其移到更適合的地方。比如，用 ElasticSearch 來做查詢，用 Hadoop 或別的數(shù)據(jù)分析軟件來做報(bào)表分析。對(duì)于后者，一般就是拆分。分庫分表技術(shù)，有些地方也稱為 Sharding、分片，通過分庫分表可以提高我們的讀寫性能，

分庫分表有垂直切分和水平切分兩種：

• 垂直切分（分庫），一般按照業(yè)務(wù)功能模塊來劃分，分庫后分表部署到不同的庫上。分庫是為了提高并發(fā)能力，比如讀寫請(qǐng)求量大就需要分庫。
• 水平切分（分表），當(dāng)一個(gè)表中的數(shù)據(jù)量過大時(shí)，我們可以把該表的數(shù)據(jù)通過各種 ID 的 hash 散列來劃分，比如 用戶 ID、訂單 ID 的 hash。分表更多的是應(yīng)對(duì)性能問題，比如查詢慢的問題。單表一般情況下，千萬級(jí)別后各種性能就開始下降了，就要考慮開始分表了。

分表包括垂直切分和水平切分，而分區(qū)只能起到水平切分的作用。

讀寫分離

互聯(lián)網(wǎng)系統(tǒng)大多數(shù)都是讀多寫少，因此讀寫分離可以幫助主庫抗量，讀寫分離就是將讀的請(qǐng)求量改為從庫承擔(dān)，寫還是主庫來承擔(dān)。一般我們都是一主多從的架構(gòu)，既可以抗量，又可以保證數(shù)據(jù)不丟。

冷熱分離

針對(duì)業(yè)務(wù)場景而言，如果數(shù)據(jù)有冷熱之分的話，可以將歷史冷數(shù)據(jù)與當(dāng)前熱數(shù)據(jù)分開存儲(chǔ)，這樣可以減輕當(dāng)前熱數(shù)據(jù)的存儲(chǔ)量，可以提高性能。

我們常見的存儲(chǔ)系統(tǒng)比如 MySQL、Elasticserach 等都可以支持。

分布式數(shù)據(jù)庫

分布式數(shù)據(jù)庫的基本思想是將原來集中式數(shù)據(jù)庫中的數(shù)據(jù)分散存儲(chǔ)到多個(gè)通過網(wǎng)絡(luò)連接的數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)上，以獲取更大的存儲(chǔ)容量和更高的并發(fā)訪問量，從而提高我們的性能。現(xiàn)在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)開始從集中式模型向分布式架構(gòu)發(fā)展了。一般云服務(wù)廠商，都會(huì)提供分布式數(shù)據(jù)庫的解決方案，比如騰訊云的 TDSQL MySQL 版，TDSQL for MySQL 是騰訊打造的一款分布式數(shù)據(jù)庫產(chǎn)品，具備強(qiáng)一致高可用、全球部署架構(gòu)、分布式水平擴(kuò)展、高性能、企業(yè)級(jí)安全等特性，同時(shí)提供智能 DBA、自動(dòng)化運(yùn)營、監(jiān)控告警等配套設(shè)施，為客戶提供完整的分布式數(shù)據(jù)庫解決方案。

六、基礎(chǔ)建設(shè)層面

基礎(chǔ)建設(shè)層面，大體分為 3 大塊：

• 機(jī)房層面，主要關(guān)注機(jī)房的網(wǎng)絡(luò)出口帶寬、入口帶寬。一般這個(gè)對(duì)我們業(yè)務(wù)開發(fā)來說，都接觸不到，但是這里還是需要注意，如果機(jī)房帶寬不夠，那么我們的服務(wù)就支撐不了大的并發(fā)，從而也沒法讓我們的系統(tǒng)有一個(gè)好的性能。
• 機(jī)器配置層面，服務(wù)器本身的性能要足夠好，包括 CPU、內(nèi)存、磁盤（SSD）等資源。同理，一般這個(gè)對(duì)我們業(yè)務(wù)開發(fā)來說，都接觸不到，但是如果機(jī)器配置較差，那么我們的服務(wù)部署在這樣的機(jī)器上面，也無法充分發(fā)揮，從而使得我們的業(yè)系統(tǒng)也無法擁有一個(gè)好的性能。
• 資源使用層面，我們要合理的分配 CPU 和內(nèi)存等相關(guān)資源，一般 CPU 的使用率不要超過 70%-80%，超過這個(gè)閾值后，我們服務(wù)的性能就會(huì)開始下降，因此一般我們?cè)?70% 的時(shí)候就要開始執(zhí)行擴(kuò)容。如果是 K8s 容器部署的話，我們可以設(shè)置 CPU 使用率超過指定閾值后就自動(dòng)擴(kuò)容。當(dāng)然，如果是物理機(jī)部署，或者其他方式，可以同樣的進(jìn)行監(jiān)控和及時(shí)擴(kuò)容。也就是說，要保證我們所需的各種資源（CPU、內(nèi)存、磁盤、帶寬）都在一個(gè)合理的范圍。

七、運(yùn)維部署層面

在運(yùn)維部署層面做好相關(guān)建設(shè)，是有助于提高我們系統(tǒng)的整體性能的。比如，我們可以通過容器化部署做到彈性伸縮，通過彈性伸縮的能力，可以使得我們的服務(wù)，在資源分配使用上，一直保持合理的 CPU、內(nèi)存等資源的使用率。

八、性能測試優(yōu)化層面

我們從架構(gòu)設(shè)計(jì)層面、編碼實(shí)現(xiàn)層面按照高性能的解決方案和思路實(shí)現(xiàn)了我們系統(tǒng)之后，理論上，我們的系統(tǒng)性能不會(huì)太差，但是，具體我們的系統(tǒng)性能如何？是否存在可優(yōu)化點(diǎn)？代碼的實(shí)現(xiàn)是否有性能問題？我們的依賴服務(wù)是否存在性能問題？等等，這些對(duì)我們大部分人來說，如果沒有一個(gè)合理的性能壓測和分析，那么可能還是黑盒的。

因此，針對(duì)我們研發(fā)人員而言，在高性能架構(gòu)設(shè)計(jì)方面的最后一個(gè)環(huán)節(jié)，就是進(jìn)行性能測試優(yōu)化，具體包括三個(gè)環(huán)節(jié)：

• 性能壓測。針對(duì)系統(tǒng)的各個(gè)環(huán)節(jié)先分別做壓測，然后有條件的情況下，最好能夠做全鏈路壓測。
• 性能分析。壓測后，最優(yōu)的分析方式是結(jié)合火焰圖去分析，看看性能最差的是哪里，是否有可優(yōu)化的點(diǎn)。一定是先找到性能最差的進(jìn)行優(yōu)化，這樣事半功倍。
• 性能優(yōu)化。找到可優(yōu)化點(diǎn)后，進(jìn)行優(yōu)化。然后反復(fù)這三個(gè)步驟，直到你認(rèn)為性能已經(jīng)完全符合預(yù)期。

本文轉(zhuǎn)載自微信公眾號(hào)「 后端系統(tǒng)和架構(gòu)」，作者「 AllenWu」，可以通過以下二維碼關(guān)注。

轉(zhuǎn)載本文請(qǐng)聯(lián)系「后端系統(tǒng)和架構(gòu)」公眾號(hào)。