Nginx多进程高并发、低时延、高可靠机制在缓存(redis、memcache)twemproxy代理中的应用...
1. 開發背景
? ? ?現有開源緩存代理中間件有twemproxy、codis等，其中twemproxy為單進程單線程模型，只支持memcache單機版和redis單機版，都不支持集群版功能。
? ? ?由于twemproxy無法利用多核特性，因此性能低下，短連接QPS大約為3W，長連接QPS大約為13W，同時某些場景時延抖動厲害。
? ? ??為了適應公有云平臺上業務方的高并發需求，因此決定借助于twemproxy來做二次開發，把nginx的高性能、高可靠、高并發機制引入到twemproxy中，通過master+多worker進程來實現七層轉發功能。
2? ??Twemproxy
2.1??Twemproxy簡介
Twemproxy?是一個快速的單線程代理程序，支持?Memcached?ASCII協議和更新的Redis協議。它全部用C寫成，使用Apache 2.0 License授權。支持以下特性：
i)速度快
ii)輕量級
iii)維護持久的服務器連接
iiii)啟用請求和響應的管道
iiiii)支持代理到多個后端緩存服務器
iiiii)同時支持多個服務器池
iiiiii)多個服務器自動分享數據
iiiiiii)可同時連接后端多個緩存集群
iiiiiiii)實現了完整的?memcached ascii?和?redis?協議.
iiiiiiiii)服務器池配置簡單，通過一個?YAML?文件即可
iiiiiiiiii)一致性hash
iiiiiiiiii)詳細的監控統計信息
iiiiiiiiiii)支持?Linux, *BSD, OS X and Solaris (SmartOS)
iiiiiiiiiiii)支持設置HashTag
iiiiiiiiiiiiiii)連接復用，內存復用，提高效率
2.2?memcache緩存集群拓撲結構
圖1 twemproxy緩存集群拓撲圖
如上圖所示，實際應用中業務程序通過輪詢不同的twemproxy來提高qps，同時實現負載均衡。
說明:官方memcache沒有集群版和持久化功能，集群版和持久化功能由我們自己內部開發完成。
2.3 推特原生twemproxy瓶頸
如今twemproxy憑借其高性能的優勢,?在很多互聯網公司得到了廣泛的應用，已經占據了其不可動搖的地位,?然而在實際的生產環境中,?存在以下缺陷，如下：
i)單進程單線程,?無法充分發揮服務器多核cpu的性能
ii)當twemproxy qps短連接達到8000后，消耗cpu超過70%，時延陡增。
iii)大流量下造成IO阻塞，無法處理更多請求，qps上不去，業務時延飆升
iiii)維護成本高，如果想要充分發揮服務器的所有資源包括cpu、?網絡io等，就必須建立多個twemproxy實例，維護成本高
iiiii)擴容、升級不便
原生twemproxy進程呈現了下圖現象：一個人干活，多個人圍觀。多核服務器只有一個cpu在工作，資源沒有得到充分利用。
3. Nginx
nginx是俄羅斯軟件工程師Igor Sysoev開發的免費開源web服務器軟件，聚焦于高性能，高并發和低內存消耗問題，因此成為業界公認的高性能服務器，并逐漸成為業內主流的web服務器。主要特點有：
i)完全借助epoll機制實現異步操作，避免阻塞。
ii)重復利用現有服務器的多核資源。
iii)充分利用CPU?親和性（affinity），把每個進程與固定CPU綁定在一起，給定的?CPU?上盡量長時間地運行而不被遷移到其他處理器的傾向性，減少進程調度開銷。
iiii)請求響應快
iiiii)支持模塊化開發，擴展性好
iiiii)Master+多worker進程方式，確保worker進程可靠工作。當worker進程出錯時，可以快速拉起新的worker子進程來提供服務。
iiiiii)內存池、連接池等細節設計保障低內存消耗。
iiiiii)熱部署支持，master與worker進程分離設計模式，使其具有熱部署功能。
iiiiiii)升級方便，升級過程不會對業務造成任何傷害。
Nginx多進程提供服務過程如下圖所示：
4? ? Nginx?master+worker多進程機制在twemproxy中的應用
4.1? 為什么選擇nginx多進程機制做為參考？
Twemproxy和nginx都屬于網絡io密集型應用，都屬于七層轉發應用，時延要求較高，應用場景基本相同。
Nginx充分利用了多核cpu資源，性能好，時延低。
4.2? Master-worker多進程機制原理
Master-worker進程機制采用一個master進程來管理多個worker進程。每一個worker進程都是繁忙的，它們在真正地提供服務，master進程則很“清閑”，只負責監控管理worker進程, 包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程。
worker進程負責處理客戶端的網絡請求，多個worker進程同時處理來自客戶端的不同請求，worker進程數可配置。
4.3?多進程關鍵性能問題點
master-worker多進程模式需要解決的問題主要有：
i)linux內核低版本(2.6以下版本), “驚群”問題
ii) linux內核低版本(2.6以下版本),負載均衡問題
iii)linux內核高版本(3.9以上版本)新特性如何利用
iii)如何確保進程見高可靠通信
iiii)如何減少worker進程在不同cpu切換的開銷
iiiii)master進程如何匯總各個工作進程的監控數據
iiiiii)worker進程異常，如何快速恢復
?4.3.1??linux內核低版本關鍵技術問題
由于linux低內核版本缺陷，因此存在”驚群”、負載不均問題，解決辦法完全依賴應用層代碼保障。
?4.3.1.1?如何解決“驚群”問題
當客戶端發起連接后，由于所有的worker子進程都監聽著同一個端口，內核協議棧在檢測到客戶端連接后，會激活所有休眠的worker子進程，最終只會有一個子進程成功建立新連接，其他子進程都會accept失敗。
Accept失敗的子進程是不應該被內核喚醒的，因為它們被喚醒的操作是多余的，占用本不應該被占用的系統資源，引起不必要的進程上下文切換，增加了系統開銷，同時也影響了客戶端連接的時延。
“驚群”問題是多個子進程同時監聽同一個端口引起的，因此解決的方法是同一時刻只讓一個子進程監聽服務器端口，這樣新連接事件只會喚醒唯一正在監聽端口的子進程。
因此“驚群”問題通過非阻塞的accept鎖來實現進程互斥accept()，其原理是：在worker進程主循環中非阻塞trylock獲取accept鎖，如果trylock成功，則此進程把監聽端口對應的fd通過epoll_ctl()加入到本進程自由的epoll事件集；如果trylock失敗，則把監聽fd從本進程對應的epoll事件集中清除。
Nginx實現了兩套互斥鎖：基于原子操作和信號量實現的互斥鎖、基于文件鎖封裝的互斥鎖。考慮到鎖的平臺可移植性和通用性，改造twemproxy選擇時，選擇文件鎖實現。
如果獲取accept鎖成功的進程占用鎖時間過長，那么其他空閑進程在這段時間內無法獲取到鎖，從而無法接受新的連接。最終造成客戶端連接相應時間變長，qps低，同時引起負載嚴重不均衡。為了解決該問題，選擇通過post事件隊列方式來提高性能，trylock獲取到accept鎖成功的進程，其工作流程如下：
1.trylock獲取accept鎖成功
2.通過epoll_wait獲取所有的事件信息，把監聽到的所有accept事件信息加入accept_post列表，把已有連接觸發的讀寫事件信息加入read_write_post列表。
3.執行accept_post列表中的所有事件
4.Unlock鎖
5.執行read_write_post列表中的事件。
Worker進程主循環工作流程圖如下：
從上圖可以看出，worker進程借助epoll來實現網絡異步收發，客戶端連接twemproxy的時候，worker進程循環檢測客戶端的各種網絡事件和后端memcached的網絡事件，并進行相應的處理。
twemproxy各個進程整體網絡i/o處理過程圖如下：
4.3.1.2???? 如何解決“負載均衡“問題
在多個子進程爭搶處理同一個新連接事件時，一定只有一個worker子進程最終會成功建立連接，隨后，它會一直處理這個連接直到連接關閉。這樣，如果有的子進程“運氣”很好，它們搶著建立并處理了大部分連接，其他子進程就只能處理少量連接，這對多核cpu架構下的應用很不利。理想情況下，每個子進程應該是平等的，每個worker子進程應該大致平均的處理客戶端連接請求。如果worker子進程負載不均衡，必然影響整體服務的性能。
nginx通過連接閾值機制來實現負載均衡，其原理如下：每個進程都有各自的最大連接數閾值max_threshold和當前連接閾值數local_threshold，和當前連接數閾值，進程每接收一個新的連接，local_threshold增一，連接斷開后，local_threashold減一。如果local_threshold超過max_threshold，則不去獲取accept鎖，把accept機會留給其他進程，同時把local_threshold減1，這樣下次就有機會獲取accept鎖，接收客戶端連接了。
在實際業務應用中，有的業務采用長連接和twemproxy建立連接，連接數最大可能就幾百連接，如果設置max_threshold閾值過大，多個連接如果同時壓到twemproxy，則很容易引起所有連接被同一個進程獲取從而造成不均衡。
為了盡量減少負載不均衡，在實際應用中，新增了epoll_wait超時時間配置選項，把該超時時間設短，這樣減少空閑進程在epoll_wait上的等待事件，從而可以更快相應客戶端連接，并有效避免負載不均衡。
4.3.2 Linux內核高版本TCP REUSEPORT特性如何利用
4.3.2.1 什么是reuseport？
reuseport是一種套接字復用機制，它允許你將多個套接字bind在同一個IP地址/端口對上，這樣一來，就可以建立多個服務來接受到同一個端口的連接。
4.3.2.2 支持reuseport和不支持reuseport的區別
如果linux內核版本小于3.9，則不支持reuseport(注:部分centos發行版在低版本中已經打了reuseport patch,所以部分linux低版本發行版本也支持該特性)。
不支持該特性的內核，一個ip+port組合，只能被監聽bind一次。這樣在多核環境下，往往只能有一個線程（或者進程）是listener，也就是同一時刻只能由一個進程或者線程做accept處理，在高并發情況下，往往這就是性能瓶頸。其網絡模型如下:
在Linux kernel 3.9帶來了reuseport特性，它可以解決上面的問題，其網絡模型如下:
reuseport是支持多個進程或者線程綁定到同一端口，提高服務器程序的吞吐性能，其優點體現在如下幾個方面:
i)允許多個套接字 bind()/listen() 同一個TCP/UDP端口
ii)每一個線程擁有自己的服務器套接字
iii)在服務器套接字上沒有了鎖的競爭，因為每個進程一個服務器套接字
iiii)內核層面實現負載均衡
iiiii)安全層面，監聽同一個端口的套接字只能位于同一個用戶下面
4.3.3 Master進程和worker進程如何通信？
由于master進程需要實時獲取worker進程的工作狀態，并實時匯總worker進程的各種統計信息，所以選擇一種可靠的進程間通信方式必不可少。
在twemproxy改造過程中，直接參考nginx的信號量機制和channel機制(依靠socketpair)來實現父子進程見通信。Master進程通過信號量機制來檢測子進程是否異常，從而快速直接的反應出來；此外，借助socketpair，封裝出channel接口來完成父子進程見異步通信，master進程依靠該機制來統計子進程的各種統計信息并匯總，通過獲取來自master的匯總信息來判斷整個twemproxy中間件的穩定性、可靠性。
配置下發過程：主進程接收實時配置信息，然后通過channel機制發送給所有的worker進程，各個worker進程收到配置信息后應答給工作進程。流程如下:
獲取監控信息流程和配置下發流程基本相同，master進程收到各個工作進程的應答后，由master進程做統一匯總，然后發送給客戶端。
4.3.4 如何減少worker進程在不同cpu切換的開銷
CPU 親和性（affinity）?就是進程要在某個給定的 CPU 上盡量長時間地運行而不被遷移到其他處理器的傾向性。
Linux 內核進程調度器天生就具有被稱為?軟 CPU 親和性（affinity）?的特性，這意味著進程通常不會在處理器之間頻繁遷移。這種狀態正是我們希望的，因為進程遷移的頻率小就意味著產生的負載小。具體參考sched_setaffinity函數。
4.3.5?worker進程異常如何減少對業務的影響？
在實際線上環境中，經常出現這樣的情況:某個多線程服務跑幾個月后，因為未知原因進程掛了，最終造成整個服務都會不可用。
這時候，master+多worker的多進程模型就體現了它的優勢，如果代碼有隱藏的并且不容易觸發的bug，某個時候如果某個請求觸發了這個bug，則處理這個請求的worker進程會段錯誤退出。但是其他worker進程不會收到任何的影響，也就是說如果一個改造后的twemproxy起了20個worker進程，某個時候一個隱藏bug被某個請求觸發，則只有處理該請求的進程段錯誤異常，其他19個進程不會受到任何影響，該隱藏bug觸發后影響面僅為5%。如果是多線程模型，則影響面會是100%。
如果某個worker進程掛了，master父進程會感知到這個信號，然后重新拉起一個worker進程，實現瞬間無感知”拉起”恢復。以下為模擬觸發異常段錯誤流程：
如上圖所示，殺掉31420 worker進程后，master進程會立馬在拉起一個31451工作進程，實現了快速恢復。
多進程異常，自動”拉起”功能源碼，可以參考如下demo：
https://github.com/y123456yz/reading-code-of-nginx-1.9.2/blob/master/nginx-1.9.2/src/demo.c
5? ? 網絡優化
5.1?網卡多隊列
在實際上線后，發現軟中斷過高，幾乎大部分都集中在一個或者幾個CPU上，嚴重影響客戶端連接和數據轉發，qps上不去，時延抖動厲害。
RSS（Receive Side Scaling）是網卡的硬件特性，實現了多隊列，可以將不同的流分發到不同的CPU上。支持RSS的網卡，通過多隊列技術，每個隊列對應一個中斷號，通過對每個中斷的綁定，可以實現網卡中斷在cpu多核上的分配，最終達到負載均衡的作用。
5.2 可怕的40ms
原生twemproxy在線上跑得過程中，發現時延波動很大，抓包發現其中部分數據包應答出現了40ms左右的時延，拉高了整體時延抓包如下(借助tcprstat工具)：
解決辦法如下：在recv系統調用后，調用一次setsockopt函數，設置TCP_QUICKACK。代碼修改如下：
6? ?Twemproxy改造前后性能對比? ?(時延、qps對比)
6.1? 線上真實流量時延對比
6.1.1? 改造前線上twemproxy集群時延
線上集群完全采用開源twemproxy做代理，架構如下：
未改造前線上twemproxy+memcache集群，qps=5000~6000，長連接，客戶端時延分布如下圖所示：
在twemproxy機器上使用tcprstat監控到的網卡時延如下:
從上面兩個圖可以看出，采用原生twemproxy,時延高，同時抖動厲害。
6.1.2 參照nginx改造后的twemproxy時延
線上集群一個twemproxy采用官方原生twemproxy，另一個為改造后的twemproxy，其中改造后的twemproxy配置worker進程數為1，保持和原生開源twemproxy進程數一致，架構如下：
替換線上集群兩個代理中的一個后(影響50%流量)，長連接，qps=5000~6000，客戶端埋點監控時延分布如下:
替換兩個proxy中的一個后，使用tcprstat在代理集群上面查看兩個代理的時延分布如下:
原生twemproxy節點機器上的時延分布:
另一個改造后的twemproxy節點機器上的時延分布：
總結：替換線上兩個proxy中的一個后，客戶端時間降低了一倍，如果線上集群兩個代理都替換為改造后的twemproxy，客戶端監控時延預計會再降低一倍，總體時延降低3倍左右。
此外，從監控可以看出，改造后的twemproxy時延更低，更加穩定，無任何波動。
6.2?參考nginx多進程改造后的twemproxy線下壓測結果(開啟reuseport功能)
監聽同一個端口，數據長度100字節，壓測結果如下：
? ?linux內核版本:linux-3.10
? ?物理機機型： M10(48 cpu)
多進程監聽同一個端口，數據長度150字節，壓測結果如下：
? ?linux內核版本:linux-3.10
? ?物理機機型： TS60 (24 cpu)
7? ?總結
7.1 多進程、多線程機制選擇
選擇參照nginx多進程機制，而不選擇多線程實現原因主要有:
1) 多進程機制無鎖操作，實現更容易
2) 多進程的代理，整個worker進程無任何鎖操作，性能更好
3) 如果是多線程方式，如果代碼出現bug段錯誤，則整個進程掛掉，整個服務不可用。而如果是多進程方式，因為bug觸發某個worker進程段錯誤異常，其他工作進程不會受到如何影響，20個worker進程，如果觸發異常，同一時刻只有有1/20的流量受到影響。而如果是多線程模式，則100%的流量會受到影響。
4) worker進程異常退出后，master進程立馬感知拉起一個新進程提供服務，可靠性更高。
5) ?配置熱加載、程序熱升級功能實現更加容易
7.2 參照nginx改造后的twemproxy特性
支持nginx幾乎所有的優秀特性，同時也根據自己實際情況新增加了自有特性:
1) ?master+多worker進程機制
2) 適配所有linux內核版本，內核低版本驚群問題避免支持
3) quic_ack支持
4) reuser_port適配支持
5) worker進程異常，master進程自動拉起功能支持
6) 90%、95%、98%、100%平均時延統計功能支持
7) memcache單機版、集群版支持
8) redis單機版、集群版支持
9) 二進制協議、文本協議同時支持
10) redis、memcache集群在線擴容、縮容、數據遷移支持，擴縮容、數據遷移過程對業務無任何影響。
11) 多租戶支持，一個代理可以接多個memcache、redis集群，并支持混部。
12) mget、gets、sets等批量處理命令優化處理
13) 慢響應日志記錄功能支持
14) 內存參數實時修改支持
15) 詳細的集群監控統計功能
16) CPU親緣性自添加
17)內存配置動態實時修改
var result = new HttpRequester("https://weihanli.xyz") // 使用 GET 方式請求 https://weihanli.xyz
.Execute(www.sanxingyLzc.com); // 返回 responseText
System.Console.WriteLine(result);
// 使用 POST 方法請求 https://accounting.weihanli.xyz/Account/LogOn
var loginResult = new HttpRequester(www.suoLaieyuLe.com"https://accounting.weihanli.xyz/Account/LogOn", HttpMethod.Post)
.WithHeaders(new Dictionary<string, string>()
{
{ "X-Requested-With", "XMLHttpRequest" },
}) // 設置請求頭
// .AjaxRequest(true)
// 設置 Referer，在做爬蟲時會比較有用，還可以通過 WithProxy("proxyUrl") 設置代理
.WithReferer("https://www.bsylept.com accounting.weihanli.xyz/Account/Login?ReturnUrl=%2F")
// 手動設置 UserAgent，默認會隨機設置一個 UA
.WithUserAgent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36")
.WithFormParameters(new Dictionary<string, string>()
{
{"Username","liweihan" },
{"Password", "112233" },
{"RememberMe","false" }
}) // 設置 post 的 form 參數
// 獲取返回的 responseText，并 json 反序列化為一個強類型的Model
.Execute<WeihanLi.Common.Models.JsonResultModel<bool>>();
System.Console.WriteLine(loginResult.ToJson());
// 上傳文件示例
var uploadFileResponse = new HttpRequester(www.baishenyvip.com"https://www.meiwanyule.cn graph.baidu.com/upload", HttpMethod.Post)
.WithFile($@"{System.Environment.GetEnvironmentVariable(www.yongshi123.cn"USERPROFILE")}\Pictures\4e6ab53e383863ed4d15252039f70423.jpg", "image", new Dictionary<string, string>()
{
{ "tn","pc" },
{ "from","pc" },
{ "image_source","PC_UPLOAD_SEARCH_FILE" },
{ "range","{\"page_from\": \"searchIndex\"}" },
}) // 設置上傳文件，并設置其它 form 參數信息
.WithReferer("https://www.michenggw.com baidu.com/"www.jrgjze.com/) // 設置 referer
.WithUserAgent("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36")
.ExecuteForResponse(); // 獲取一個 HttpWebResponse 對象，可以使用 StatusCode/ ResponseHeader 等信息
System.Console.WriteLine($"Response status:{uploadFileResponse.StatusCode}, result:{uploadFileResponse.ReadToEnd()}");
7.3后期計劃
? ?添加如下功能:
? ? ?i) 配置文件熱加載支持。
? ? ?ii) 代碼熱升級功能支持。
7.4? 長遠規劃展望
抽象出一款類似nginx的高性能代理軟件，nginx支持http協議，我們的支持tcp協議代理，覆蓋nginx所有功能，包括前面提到的所有功能，同時支持模塊化開發。這樣，很多的tcp協議代理就無需關心網絡架構底層實現，只需要根據需要開發對應的協議解析模塊，和自己關心的統計、審計等功能功能，降低開發成本。現有開源的中間件，很大一部分都是tcp的，有自己的私有tcp協議，把這個抽象出來，開發成本會更低
?
轉載于:https://www.cnblogs.com/qwangxiao/p/10545957.html
總結
以上是生活随笔為你收集整理的Nginx多进程高并发、低时延、高可靠机制在缓存(redis、memcache)twemproxy代理中的应用...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php 赋值 递增,PHP 基础（赋值
- 下一篇： Nginx----进阶