中文字幕日韩精品一区二区免费_精品一区二区三区国产精品无卡在_国精品无码专区一区二区三区_国产αv三级中文在线

多進程高并發(fā)下,Nginx低時延、高可靠機制應用實例

2021-01-30    分類: 網(wǎng)站建設

開發(fā)背景

現(xiàn)有開源緩存代理中間件有twemproxy、codis等,其中twemproxy為單進程單線程模型,只支持memcache單機版和redis單機版,都不支持集群版功能。

由于twemproxy無法利用多核特性,因此性能低下,短連接QPS大約為3W,長連接QPS大約為13W; codis起幾十個線程,短連接qps不超過10萬;同時某些場景這些開源軟件時延抖動厲害。

為了適應公有云平臺上業(yè)務方的高并發(fā)需求,因此決定借助于twemproxy來做二次開發(fā),把nginx的高性能、高可靠、高并發(fā)機制引入到twemproxy中,通過master+多worker進程來實現(xiàn)七層轉(zhuǎn)發(fā)功能。

Twemproxy

2.1 Twemproxy簡介

Twemproxy 是一個快速的單線程代理程序,支持 Memcached ASCII協(xié)議和更新的Redis協(xié)議。它全部用C寫成,使用Apache 2.0 License授權。支持以下特性:

1)速度快

2)輕量級

3)維護持久的服務器連接

4)啟用請求和響應的管道

5)支持代理到多個后端緩存服務器

6)同時支持多個服務器池

7)多個服務器自動分享數(shù)據(jù)

8)可同時連接后端多個緩存集群

9)實現(xiàn)了完整的 memcached ascii 和 redis 協(xié)議.

10)服務器池配置簡單,通過一個 YAML 文件即可

11)一致性hash

12)詳細的監(jiān)控統(tǒng)計信息

13)支持 Linux, *BSD, OS X and Solaris (SmartOS)

14)支持設置HashTag

15)連接復用,內(nèi)存復用,提高效率

2.2 滴云memcache緩存集群拓撲結構


如上圖所示,實際應用中業(yè)務程序通過輪詢不同的twemproxy來提高qps,同時實現(xiàn)負載均衡。

2.3 推特原生twemproxy瓶頸

如今twemproxy憑借其高性能的優(yōu)勢, 在很多互聯(lián)網(wǎng)公司得到了廣泛的應用,已經(jīng)占據(jù)了其不可動搖的地位, 然而在實際的生產(chǎn)環(huán)境中, 存在以下缺陷,如下:

i)單進程單線程, 無法充分發(fā)揮服務器多核cpu的性能

ii)當twemproxy qps短連接達到8000后,消耗cpu超過70%,時延陡增。

iii)大流量下造成IO阻塞,無法處理更多請求,qps上不去,業(yè)務時延飆升

iiii)維護成本高,如果想要充分發(fā)揮服務器的所有資源包括cpu、 網(wǎng)絡io等,就必須建立多個twemproxy實例,維護成本高

iiiii)擴容、升級不便

原生twemproxy進程呈現(xiàn)了下圖現(xiàn)象:一個人干活,多個人圍觀。多核服務器只有一個cpu在工作,資源沒有得到充分利用。


Nginx

nginx是俄羅斯軟件工程師Igor Sysoev開發(fā)的免費開源web服務器軟件,聚焦于高性能,高并發(fā)和低內(nèi)存消耗問題,因此成為業(yè)界公認的高性能服務器,并逐漸成為業(yè)內(nèi)主流的web服務器。主要特點有:

i)完全借助epoll機制實現(xiàn)異步操作,避免阻塞。

ii)重復利用現(xiàn)有服務器的多核資源。

iii)充分利用CPU 親和性(affinity),把每個進程與固定CPU綁定在一起,給定的CPU 上盡量長時間地運行而不被遷移到其他處理器的傾向性,減少進程調(diào)度開銷。

iiii)請求響應快

iiiii)支持模塊化開發(fā),擴展性好

iiiii)Master+多worker進程方式,確保worker進程可靠工作。當worker進程出錯時,可以快速拉起新的worker子進程來提供服務。

iiiiii)內(nèi)存池、連接池等細節(jié)設計保障低內(nèi)存消耗。

iiiiii)熱部署支持,master與worker進程分離設計模式,使其具有熱部署功能。

iiiiiii)升級方便,升級過程不會對業(yè)務造成任何傷害。

Nginx多進程提供服務過程如下圖所示:


Nginx master+worker多進程機制在twemproxy中的應用

4.1 為什么選擇nginx多進程機制做為參考?

Twemproxy和nginx都屬于網(wǎng)絡io密集型應用,都屬于七層轉(zhuǎn)發(fā)應用,時延要求較高,應用場景基本相同。

Nginx充分利用了多核cpu資源,性能好,時延低。

4.2 Master-worker多進程機制原理

Master-worker進程機制采用一個master進程來管理多個worker進程。每一個worker進程都是繁忙的,它們在真正地提供服務,master進程則很“清閑”,只負責監(jiān)控管理worker進程, 包含:接收來自外界的信號,向各worker進程發(fā)送信號,監(jiān)控worker進程的運行狀態(tài),當worker進程退出后(異常情況下),會自動重新啟動新的worker進程。

worker進程負責處理客戶端的網(wǎng)絡請求,多個worker進程同時處理來自客戶端的不同請求,worker進程數(shù)可配置。

4.3 多進程關鍵性能問題點

master-worker多進程模式需要解決的問題主要有:

i)linux內(nèi)核低版本(2.6以下版本), “驚群”問題

ii) linux內(nèi)核低版本(2.6以下版本),負載均衡問題

iii)linux內(nèi)核高版本(3.9以上版本)新特性如何利用

iii)如何確保進程見高可靠通信

iiii)如何減少worker進程在不同cpu切換的開銷

iiiii)master進程如何匯總各個工作進程的監(jiān)控數(shù)據(jù)

iiiiii)worker進程異常,如何快速恢復

4.3.1 linux內(nèi)核低版本關鍵技術問題

由于linux低內(nèi)核版本缺陷,因此存在”驚群”、負載不均問題,解決辦法完全依賴應用層代碼保障。

4.3.1.1 如何解決“驚群”問題

當客戶端發(fā)起連接后,由于所有的worker子進程都監(jiān)聽著同一個端口,內(nèi)核協(xié)議棧在檢測到客戶端連接后,會激活所有休眠的worker子進程,最終只會有一個子進程成功建立新連接,其他子進程都會accept失敗。

Accept失敗的子進程是不應該被內(nèi)核喚醒的,因為它們被喚醒的操作是多余的,占用本不應該被占用的系統(tǒng)資源,引起不必要的進程上下文切換,增加了系統(tǒng)開銷,同時也影響了客戶端連接的時延。

“驚群”問題是多個子進程同時監(jiān)聽同一個端口引起的,因此解決的方法是同一時刻只讓一個子進程監(jiān)聽服務器端口,這樣新連接事件只會喚醒唯一正在監(jiān)聽端口的子進程。

因此“驚群”問題通過非阻塞的accept鎖來實現(xiàn)進程互斥accept(),其原理是:在worker進程主循環(huán)中非阻塞trylock獲取accept鎖,如果trylock成功,則此進程把監(jiān)聽端口對應的fd通過epoll_ctl()加入到本進程自由的epoll事件集;如果trylock失敗,則把監(jiān)聽fd從本進程對應的epoll事件集中清除。

Nginx實現(xiàn)了兩套互斥鎖:基于原子操作和信號量實現(xiàn)的互斥鎖、基于文件鎖封裝的互斥鎖。考慮到鎖的平臺可移植性和通用性,改造twemproxy選擇時,選擇文件鎖實現(xiàn)。

如果獲取accept鎖成功的進程占用鎖時間過長,那么其他空閑進程在這段時間內(nèi)無法獲取到鎖,從而無法接受新的連接。最終造成客戶端連接相應時間變長,qps低,同時引起負載嚴重不均衡。為了解決該問題,選擇通過post事件隊列方式來提高性能,trylock獲取到accept鎖成功的進程,其工作流程如下:

1.trylock獲取accept鎖成功

2.通過epoll_wait獲取所有的事件信息,把監(jiān)聽到的所有accept事件信息加入accept_post列表,把已有連接觸發(fā)的讀寫事件信息加入read_write_post列表。

3.執(zhí)行accept_post列表中的所有事件

4.Unlock鎖

5.執(zhí)行read_write_post列表中的事件。

Worker進程主循環(huán)工作流程圖如下:


從上圖可以看出,worker進程借助epoll來實現(xiàn)網(wǎng)絡異步收發(fā),客戶端連接twemproxy的時候,worker進程循環(huán)檢測客戶端的各種網(wǎng)絡事件和后端memcached的網(wǎng)絡事件,并進行相應的處理。

twemproxy各個進程整體網(wǎng)絡i/o處理過程圖如下:


4.3.1.2 如何解決“負載均衡“問題

在多個子進程爭搶處理同一個新連接事件時,一定只有一個worker子進程最終會成功建立連接,隨后,它會一直處理這個連接直到連接關閉。這樣,如果有的子進程“運氣”很好,它們搶著建立并處理了大部分連接,其他子進程就只能處理少量連接,這對多核cpu架構下的應用很不利。理想情況下,每個子進程應該是平等的,每個worker子進程應該大致平均的處理客戶端連接請求。如果worker子進程負載不均衡,必然影響整體服務的性能。

nginx通過連接閾值機制來實現(xiàn)負載均衡,其原理如下:每個進程都有各自的大連接數(shù)閾值max_threshold和當前連接閾值數(shù)local_threshold,和當前連接數(shù)閾值,進程每接收一個新的連接,local_threshold增一,連接斷開后,local_threashold減一。如果local_threshold超過max_threshold,則不去獲取accept鎖,把accept機會留給其他進程,同時把local_threshold減1,這樣下次就有機會獲取accept鎖,接收客戶端連接了。

在實際業(yè)務應用中,有的業(yè)務采用長連接和twemproxy建立連接,連接數(shù)大可能就幾百連接,如果設置max_threshold閾值過大,多個連接如果同時壓到twemproxy,則很容易引起所有連接被同一個進程獲取從而造成不均衡。

為了盡量減少負載不均衡,在實際應用中,新增了epoll_wait超時時間配置選項,把該超時時間設短,這樣減少空閑進程在epoll_wait上的等待事件,從而可以更快相應客戶端連接,并有效避免負載不均衡。

4.3.2 Linux內(nèi)核高版本TCP REUSEPORT特性如何利用

4.3.2.1 什么是reuseport?

reuseport是一種套接字復用機制,它允許你將多個套接字bind在同一個IP地址/端口對上,這樣一來,就可以建立多個服務來接受到同一個端口的連接。

4.3.2.2 支持reuseport和不支持reuseport的區(qū)別

如果linux內(nèi)核版本小于3.9,則不支持reuseport(注:部分centos發(fā)行版在低版本中已經(jīng)打了reuseport patch,所以部分linux低版本發(fā)行版本也支持該特性)。

不支持該特性的內(nèi)核,一個ip+port組合,只能被監(jiān)聽bind一次。這樣在多核環(huán)境下,往往只能有一個線程(或者進程)是listener,也就是同一時刻只能由一個進程或者線程做accept處理,在高并發(fā)情況下,往往這就是性能瓶頸。其網(wǎng)絡模型如下:


在Linux kernel 3.9帶來了reuseport特性,它可以解決上面的問題,其網(wǎng)絡模型如下:


reuseport是支持多個進程或者線程綁定到同一端口,提高服務器程序的吞吐性能,其優(yōu)點體現(xiàn)在如下幾個方面:

i)允許多個套接字 bind()/listen() 同一個TCP/UDP端口

ii)每一個線程擁有自己的服務器套接字

iii)在服務器套接字上沒有了鎖的競爭,因為每個進程一個服務器套接字

iiii)內(nèi)核層面實現(xiàn)負載均衡

iiiii)安全層面,監(jiān)聽同一個端口的套接字只能位于同一個用戶下面

4.3.3 Master進程和worker進程如何通信?

由于master進程需要實時獲取worker進程的工作狀態(tài),并實時匯總worker進程的各種統(tǒng)計信息,所以選擇一種可靠的進程間通信方式必不可少。

在twemproxy改造過程中,直接參考nginx的信號量機制和channel機制(依靠socketpair)來實現(xiàn)父子進程見通信。Master進程通過信號量機制來檢測子進程是否異常,從而快速直接的反應出來;此外,借助socketpair,封裝出channel接口來完成父子進程見異步通信,master進程依靠該機制來統(tǒng)計子進程的各種統(tǒng)計信息并匯總,通過獲取來自master的匯總信息來判斷整個twemproxy中間件的穩(wěn)定性、可靠性。

配置下發(fā)過程:主進程接收實時配置信息,然后通過channel機制發(fā)送給所有的worker進程,各個worker進程收到配置信息后應答給工作進程。流程如下:


獲取監(jiān)控信息流程和配置下發(fā)流程基本相同,master進程收到各個工作進程的應答后,由master進程做統(tǒng)一匯總,然后發(fā)送給客戶端。

4.3.4 如何減少worker進程在不同cpu切換的開銷

CPU 親和性(affinity) 就是進程要在某個給定的 CPU 上盡量長時間地運行而不被遷移到其他處理器的傾向性。

Linux 內(nèi)核進程調(diào)度器天生就具有被稱為 軟 CPU 親和性(affinity) 的特性,這意味著進程通常不會在處理器之間頻繁遷移。這種狀態(tài)正是我們希望的,因為進程遷移的頻率小就意味著產(chǎn)生的負載小。具體參考sched_setaffinity函數(shù)。

4.3.5 worker進程異常如何減少對業(yè)務的影響?

在實際線上環(huán)境中,經(jīng)常出現(xiàn)這樣的情況:某個多線程服務跑幾個月后,因為未知原因進程掛了,最終造成整個服務都會不可用。

這時候,master+多worker的多進程模型就體現(xiàn)了它的優(yōu)勢,如果代碼有隱藏的并且不容易觸發(fā)的bug,某個時候如果某個請求觸發(fā)了這個bug,則處理這個請求的worker進程會段錯誤退出。但是其他worker進程不會收到任何的影響,也就是說如果一個改造后的twemproxy起了20個worker進程,某個時候一個隱藏bug被某個請求觸發(fā),則只有處理該請求的進程段錯誤異常,其他19個進程不會受到任何影響,該隱藏bug觸發(fā)后影響面僅為5%。如果是多線程模型,則影響面會是100%。

如果某個worker進程掛了,master父進程會感知到這個信號,然后重新拉起一個worker進程,實現(xiàn)瞬間無感知”拉起”恢復。以下為模擬觸發(fā)異常段錯誤流程:


如上圖所示,殺掉31420 worker進程后,master進程會立馬在拉起一個31451工作進程,實現(xiàn)了快速恢復。

多進程異常,自動”拉起”功能源碼,可以參考如下demo:

https://github.com/y123456yz/reading-code-of-nginx-1.9.2/blob/master/nginx-1.9.2/src/demo.c

網(wǎng)絡優(yōu)化

5.1 網(wǎng)卡多隊列

在實際上線后,發(fā)現(xiàn)軟中斷過高,幾乎大部分都集中在一個或者幾個CPU上,嚴重影響客戶端連接和數(shù)據(jù)轉(zhuǎn)發(fā),qps上不去,時延抖動厲害。

RSS(Receive Side Scaling)是網(wǎng)卡的硬件特性,實現(xiàn)了多隊列,可以將不同的流分發(fā)到不同的CPU上。支持RSS的網(wǎng)卡,通過多隊列技術,每個隊列對應一個中斷號,通過對每個中斷的綁定,可以實現(xiàn)網(wǎng)卡中斷在cpu多核上的分配,最終達到負載均衡的作用。

5.2 可怕的40ms

原生twemproxy在線上跑得過程中,發(fā)現(xiàn)時延波動很大,抓包發(fā)現(xiàn)其中部分數(shù)據(jù)包應答出現(xiàn)了40ms左右的時延,拉高了整體時延抓包如下(借助tcprstat工具):

解決辦法如下:在recv系統(tǒng)調(diào)用后,調(diào)用一次setsockopt函數(shù),設置TCP_QUICKACK。代碼修改如下:

Twemproxy改造前后性能對比 (時延、qps對比)

6.1 線上真實流量時延對比

6.1.1 改造前線上twemproxy集群時延

線上集群完全采用開源twemproxy做代理,架構如下:


未改造前線上twemproxy+memcache集群,qps=5000~6000,長連接,客戶端時延分布如下圖所示:


在twemproxy機器上使用tcprstat監(jiān)控到的網(wǎng)卡時延如下:


從上面兩個圖可以看出,采用原生twemproxy,時延高,同時抖動厲害。

6.1.2 參照nginx改造后的twemproxy時延

線上集群一個twemproxy采用官方原生twemproxy,另一個為改造后的twemproxy,其中改造后的twemproxy配置worker進程數(shù)為1,保持和原生開源twemproxy進程數(shù)一致,架構如下:


替換線上集群兩個代理中的一個后(影響50%流量),長連接,qps=5000~6000,客戶端埋點監(jiān)控時延分布如下:



替換兩個proxy中的一個后,使用tcprstat在代理集群上面查看兩個代理的時延分布如下:

原生twemproxy節(jié)點機器上的時延分布:


另一個改造后的twemproxy節(jié)點機器上的時延分布:


總結:替換線上兩個proxy中的一個后,客戶端時間降低了一倍,如果線上集群兩個代理都替換為改造后的twemproxy,客戶端監(jiān)控時延預計會再降低一倍,總體時延降低3倍左右。

此外,從監(jiān)控可以看出,改造后的twemproxy時延更低,更加穩(wěn)定,無任何波動。

6.2 參考nginx多進程改造后的twemproxy線下壓測結果(開啟reuseport功能)

監(jiān)聽同一個端口,數(shù)據(jù)長度100字節(jié),壓測結果如下:

linux內(nèi)核版本:linux-3.10

物理機機型: M10(48 cpu)


多進程監(jiān)聽同一個端口,數(shù)據(jù)長度150字節(jié),壓測結果如下:

linux內(nèi)核版本:linux-3.10

物理機機型: TS60 (24 cpu)


總結

7.1 多進程、多線程機制選擇

選擇參照nginx多進程機制,而不選擇多線程實現(xiàn)原因主要有:

1) 多進程機制無鎖操作,實現(xiàn)更容易

2) 多進程的代理,整個worker進程無任何鎖操作,性能更好

3) 如果是多線程方式,如果代碼出現(xiàn)bug段錯誤,則整個進程掛掉,整個服務不可用。而如果是多進程方式,因為bug觸發(fā)某個worker進程段錯誤異常,其他工作進程不會受到如何影響,20個worker進程,如果觸發(fā)異常,同一時刻只有有1/20的流量受到影響。而如果是多線程模式,則100%的流量會受到影響。

4) worker進程異常退出后,master進程立馬感知拉起一個新進程提供服務,可靠性更高。

5) 配置熱加載、程序熱升級功能實現(xiàn)更加容易

7.2 參照nginx改造后的twemproxy特性

支持nginx幾乎所有的優(yōu)秀特性,同時也根據(jù)自己實際情況新增加了自有特性:

1) master+多worker進程機制

2) 適配所有l(wèi)inux內(nèi)核版本,內(nèi)核低版本驚群問題避免支持

3) quic_ack支持

4) reuser_port適配支持

5) worker進程異常,master進程自動拉起功能支持

6) 90%、95%、98%、100%平均時延統(tǒng)計功能支持

7) memcache單機版、集群版支持

8) redis單機版、集群版支持

9) 二進制協(xié)議、文本協(xié)議同時支持

10) redis、memcache集群在線擴容、縮容、數(shù)據(jù)遷移支持,擴縮容、數(shù)據(jù)遷移過程對業(yè)務無任何影響。

11) 多租戶支持,一個代理可以接多個memcache、redis集群,并支持混部。

12) mget、gets、sets等批量處理命令優(yōu)化處理

13) 慢響應日志記錄功能支持

14) 內(nèi)存參數(shù)實時修改支持

15) 詳細的集群監(jiān)控統(tǒng)計功能

16) CPU親緣性自添加

17)內(nèi)存配置動態(tài)實時修改

7.3后期計劃

添加如下功能:

i) 配置文件熱加載支持。

ii) 代碼熱升級功能支持。

7.4 長遠規(guī)劃展望

抽象出一款類似nginx的高性能代理軟件,nginx支持http協(xié)議,我們的支持tcp協(xié)議代理,覆蓋nginx所有功能,包括前面提到的所有功能,同時支持模塊化開發(fā)。這樣,很多的tcp協(xié)議代理就無需關心網(wǎng)絡架構底層實現(xiàn),只需要根據(jù)需要開發(fā)對應的協(xié)議解析模塊,和自己關心的統(tǒng)計、審計等功能功能,降低開發(fā)成本。現(xiàn)有開源的中間件,很大一部分都是tcp的,有自己的私有tcp協(xié)議,把這個抽象出來,開發(fā)成本會更低。

網(wǎng)站標題:多進程高并發(fā)下,Nginx低時延、高可靠機制應用實例
當前地址:http://m.rwnh.cn/news/98236.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、搜索引擎優(yōu)化品牌網(wǎng)站制作、服務器托管、云服務器、外貿(mào)建站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

營銷型網(wǎng)站建設
响水县| 锡林郭勒盟| 东山县| 五河县| 诸城市| 织金县| 洮南市| 安陆市| 开鲁县| 抚州市| 乡城县| 惠水县| 河间市| 延安市| 雅江县| 黄平县| 宁南县| 福鼎市| 九寨沟县| 汝州市| 清镇市| 察雅县| 青田县| 霍州市| 吴忠市| 九江县| 绵阳市| 鄱阳县| 尖扎县| 高雄市| 沙坪坝区| 长葛市| 贵溪市| 牙克石市| 徐闻县| 龙海市| 徐水县| 邓州市| 磐石市| 四子王旗| 武威市|