多進(jìn)程高并發(fā)下，Nginx低時(shí)延、高可靠機(jī)制應(yīng)用實(shí)例

開發(fā)背景

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

由于twemproxy無法利用多核特性，因此性能低下，短連接QPS大約為3W，長(zhǎng)連接QPS大約為13W; codis起幾十個(gè)線程，短連接qps不超過10萬；同時(shí)某些場(chǎng)景這些開源軟件時(shí)延抖動(dòng)厲害。

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

Twemproxy

2.1 Twemproxy簡(jiǎn)介

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

1)速度快

2)輕量級(jí)

3)維護(hù)持久的服務(wù)器連接

4)啟用請(qǐng)求和響應(yīng)的管道

5)支持代理到多個(gè)后端緩存服務(wù)器

6)同時(shí)支持多個(gè)服務(wù)器池

7)多個(gè)服務(wù)器自動(dòng)分享數(shù)據(jù)

8)可同時(shí)連接后端多個(gè)緩存集群

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

10)服務(wù)器池配置簡(jiǎn)單，通過一個(gè) YAML 文件即可

11)一致性hash

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

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

14)支持設(shè)置HashTag

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

2.2 滴云memcache緩存集群拓?fù)浣Y(jié)構(gòu)

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

2.3 推特原生twemproxy瓶頸

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

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

ii)當(dāng)twemproxy qps短連接達(dá)到8000后，消耗cpu超過70%，時(shí)延陡增。

iii)大流量下造成IO阻塞，無法處理更多請(qǐng)求，qps上不去，業(yè)務(wù)時(shí)延飆升

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

iiiii)擴(kuò)容、升級(jí)不便

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

Nginx

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

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

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

iii)充分利用CPU 親和性（affinity），把每個(gè)進(jìn)程與固定CPU綁定在一起，給定的CPU 上盡量長(zhǎng)時(shí)間地運(yùn)行而不被遷移到其他處理器的傾向性，減少進(jìn)程調(diào)度開銷。

iiii)請(qǐng)求響應(yīng)快

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

iiiii)Master+多worker進(jìn)程方式，確保worker進(jìn)程可靠工作。當(dāng)worker進(jìn)程出錯(cuò)時(shí)，可以快速拉起新的worker子進(jìn)程來提供服務(wù)。

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

iiiiii)熱部署支持，master與worker進(jìn)程分離設(shè)計(jì)模式，使其具有熱部署功能。

iiiiiii)升級(jí)方便，升級(jí)過程不會(huì)對(duì)業(yè)務(wù)造成任何傷害。

Nginx多進(jìn)程提供服務(wù)過程如下圖所示：

Nginx master+worker多進(jìn)程機(jī)制在twemproxy中的應(yīng)用

4.1 為什么選擇nginx多進(jìn)程機(jī)制做為參考？

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

Nginx充分利用了多核cpu資源，性能好，時(shí)延低。

4.2 Master-worker多進(jìn)程機(jī)制原理

Master-worker進(jìn)程機(jī)制采用一個(gè)master進(jìn)程來管理多個(gè)worker進(jìn)程。每一個(gè)worker進(jìn)程都是繁忙的，它們?cè)谡嬲靥峁┓?wù)，master進(jìn)程則很“清閑”，只負(fù)責(zé)監(jiān)控管理worker進(jìn)程, 包含：接收來自外界的信號(hào)，向各worker進(jìn)程發(fā)送信號(hào)，監(jiān)控worker進(jìn)程的運(yùn)行狀態(tài)，當(dāng)worker進(jìn)程退出后(異常情況下)，會(huì)自動(dòng)重新啟動(dòng)新的worker進(jìn)程。

worker進(jìn)程負(fù)責(zé)處理客戶端的網(wǎng)絡(luò)請(qǐng)求，多個(gè)worker進(jìn)程同時(shí)處理來自客戶端的不同請(qǐng)求，worker進(jìn)程數(shù)可配置。

4.3 多進(jìn)程關(guān)鍵性能問題點(diǎn)

master-worker多進(jìn)程模式需要解決的問題主要有：

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

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

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

iii)如何確保進(jìn)程見高可靠通信

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

iiiii)master進(jìn)程如何匯總各個(gè)工作進(jìn)程的監(jiān)控?cái)?shù)據(jù)

iiiiii)worker進(jìn)程異常，如何快速恢復(fù)

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

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

4.3.1.1 如何解決“驚群”問題

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

Accept失敗的子進(jìn)程是不應(yīng)該被內(nèi)核喚醒的，因?yàn)樗鼈儽粏拘训牟僮魇嵌嘤嗟模加帽静粦?yīng)該被占用的系統(tǒng)資源，引起不必要的進(jìn)程上下文切換，增加了系統(tǒng)開銷，同時(shí)也影響了客戶端連接的時(shí)延。

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

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

Nginx實(shí)現(xiàn)了兩套互斥鎖：基于原子操作和信號(hào)量實(shí)現(xiàn)的互斥鎖、基于文件鎖封裝的互斥鎖?？紤]到鎖的平臺(tái)可移植性和通用性，改造twemproxy選擇時(shí)，選擇文件鎖實(shí)現(xiàn)。

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

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進(jìn)程主循環(huán)工作流程圖如下：

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

twemproxy各個(gè)進(jìn)程整體網(wǎng)絡(luò)i/o處理過程圖如下：

4.3.1.2 如何解決“負(fù)載均衡“問題

在多個(gè)子進(jìn)程爭(zhēng)搶處理同一個(gè)新連接事件時(shí)，一定只有一個(gè)worker子進(jìn)程最終會(huì)成功建立連接，隨后，它會(huì)一直處理這個(gè)連接直到連接關(guān)閉。這樣，如果有的子進(jìn)程“運(yùn)氣”很好，它們搶著建立并處理了大部分連接，其他子進(jìn)程就只能處理少量連接，這對(duì)多核cpu架構(gòu)下的應(yīng)用很不利。理想情況下，每個(gè)子進(jìn)程應(yīng)該是平等的，每個(gè)worker子進(jìn)程應(yīng)該大致平均的處理客戶端連接請(qǐng)求。如果worker子進(jìn)程負(fù)載不均衡，必然影響整體服務(wù)的性能。

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

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

為了盡量減少負(fù)載不均衡，在實(shí)際應(yīng)用中，新增了epoll_wait超時(shí)時(shí)間配置選項(xiàng)，把該超時(shí)時(shí)間設(shè)短，這樣減少空閑進(jìn)程在epoll_wait上的等待事件，從而可以更快相應(yīng)客戶端連接，并有效避免負(fù)載不均衡。

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

4.3.2.1 什么是reuseport？

reuseport是一種套接字復(fù)用機(jī)制，它允許你將多個(gè)套接字bind在同一個(gè)IP地址/端口對(duì)上，這樣一來，就可以建立多個(gè)服務(wù)來接受到同一個(gè)端口的連接。

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

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

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

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

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

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

ii)每一個(gè)線程擁有自己的服務(wù)器套接字

iii)在服務(wù)器套接字上沒有了鎖的競(jìng)爭(zhēng)，因?yàn)槊總€(gè)進(jìn)程一個(gè)服務(wù)器套接字

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

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

4.3.3 Master進(jìn)程和worker進(jìn)程如何通信？

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

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

配置下發(fā)過程：主進(jìn)程接收實(shí)時(shí)配置信息，然后通過channel機(jī)制發(fā)送給所有的worker進(jìn)程，各個(gè)worker進(jìn)程收到配置信息后應(yīng)答給工作進(jìn)程。流程如下:

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

4.3.4 如何減少worker進(jìn)程在不同cpu切換的開銷

CPU 親和性（affinity） 就是進(jìn)程要在某個(gè)給定的 CPU 上盡量長(zhǎng)時(shí)間地運(yùn)行而不被遷移到其他處理器的傾向性。

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

4.3.5 worker進(jìn)程異常如何減少對(duì)業(yè)務(wù)的影響？

在實(shí)際線上環(huán)境中，經(jīng)常出現(xiàn)這樣的情況:某個(gè)多線程服務(wù)跑幾個(gè)月后，因?yàn)槲粗蜻M(jìn)程掛了，最終造成整個(gè)服務(wù)都會(huì)不可用。

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

如果某個(gè)worker進(jìn)程掛了，master父進(jìn)程會(huì)感知到這個(gè)信號(hào)，然后重新拉起一個(gè)worker進(jìn)程，實(shí)現(xiàn)瞬間無感知”拉起”恢復(fù)。以下為模擬觸發(fā)異常段錯(cuò)誤流程：

如上圖所示，殺掉31420 worker進(jìn)程后，master進(jìn)程會(huì)立馬在拉起一個(gè)31451工作進(jìn)程，實(shí)現(xiàn)了快速恢復(fù)。

多進(jìn)程異常，自動(dòng)”拉起”功能源碼，可以參考如下demo：

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

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

5.1 網(wǎng)卡多隊(duì)列

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

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

5.2 可怕的40ms

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

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

Twemproxy改造前后性能對(duì)比 (時(shí)延、qps對(duì)比)

6.1 線上真實(shí)流量時(shí)延對(duì)比

6.1.1 改造前線上twemproxy集群時(shí)延

線上集群完全采用開源twemproxy做代理，架構(gòu)如下：

未改造前線上twemproxy+memcache集群，qps=5000~6000，長(zhǎng)連接，客戶端時(shí)延分布如下圖所示：

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

從上面兩個(gè)圖可以看出，采用原生twemproxy,時(shí)延高，同時(shí)抖動(dòng)厲害。

6.1.2 參照nginx改造后的twemproxy時(shí)延

線上集群一個(gè)twemproxy采用官方原生twemproxy，另一個(gè)為改造后的twemproxy，其中改造后的twemproxy配置worker進(jìn)程數(shù)為1，保持和原生開源twemproxy進(jìn)程數(shù)一致，架構(gòu)如下：

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

替換兩個(gè)proxy中的一個(gè)后，使用tcprstat在代理集群上面查看兩個(gè)代理的時(shí)延分布如下:

原生twemproxy節(jié)點(diǎn)機(jī)器上的時(shí)延分布:

另一個(gè)改造后的twemproxy節(jié)點(diǎn)機(jī)器上的時(shí)延分布：

總結(jié)：替換線上兩個(gè)proxy中的一個(gè)后，客戶端時(shí)間降低了一倍，如果線上集群兩個(gè)代理都替換為改造后的twemproxy，客戶端監(jiān)控時(shí)延預(yù)計(jì)會(huì)再降低一倍，總體時(shí)延降低3倍左右。

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

6.2 參考nginx多進(jìn)程改造后的twemproxy線下壓測(cè)結(jié)果(開啟reuseport功能)

監(jiān)聽同一個(gè)端口，數(shù)據(jù)長(zhǎng)度100字節(jié)，壓測(cè)結(jié)果如下：

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

物理機(jī)機(jī)型： M10(48 cpu)

多進(jìn)程監(jiān)聽同一個(gè)端口，數(shù)據(jù)長(zhǎng)度150字節(jié)，壓測(cè)結(jié)果如下：

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

物理機(jī)機(jī)型： TS60 (24 cpu)

總結(jié)

7.1 多進(jìn)程、多線程機(jī)制選擇

選擇參照nginx多進(jìn)程機(jī)制，而不選擇多線程實(shí)現(xiàn)原因主要有:

1) 多進(jìn)程機(jī)制無鎖操作，實(shí)現(xiàn)更容易

2) 多進(jìn)程的代理，整個(gè)worker進(jìn)程無任何鎖操作，性能更好

3) 如果是多線程方式，如果代碼出現(xiàn)bug段錯(cuò)誤，則整個(gè)進(jìn)程掛掉，整個(gè)服務(wù)不可用。而如果是多進(jìn)程方式，因?yàn)閎ug觸發(fā)某個(gè)worker進(jìn)程段錯(cuò)誤異常，其他工作進(jìn)程不會(huì)受到如何影響，20個(gè)worker進(jìn)程，如果觸發(fā)異常，同一時(shí)刻只有有1/20的流量受到影響。而如果是多線程模式，則100%的流量會(huì)受到影響。

4) worker進(jìn)程異常退出后，master進(jìn)程立馬感知拉起一個(gè)新進(jìn)程提供服務(wù)，可靠性更高。

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

7.2 參照nginx改造后的twemproxy特性

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

1) master+多worker進(jìn)程機(jī)制

2) 適配所有l(wèi)inux內(nèi)核版本，內(nèi)核低版本驚群?jiǎn)栴}避免支持

3) quic_ack支持

4) reuser_port適配支持

5) worker進(jìn)程異常，master進(jìn)程自動(dòng)拉起功能支持

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

7) memcache單機(jī)版、集群版支持

8) redis單機(jī)版、集群版支持

9) 二進(jìn)制協(xié)議、文本協(xié)議同時(shí)支持

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

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

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

13) 慢響應(yīng)日志記錄功能支持

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

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

16) CPU親緣性自添加

17)內(nèi)存配置動(dòng)態(tài)實(shí)時(shí)修改

7.3后期計(jì)劃

添加如下功能:

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

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

7.4 長(zhǎng)遠(yuǎn)規(guī)劃展望

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

網(wǎng)站標(biāo)題：多進(jìn)程高并發(fā)下，Nginx低時(shí)延、高可靠機(jī)制應(yīng)用實(shí)例
當(dāng)前地址：http://www.bm7419.com/news/98236.html

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

廣告

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