Nginx再次回顧
也許你已經忘記了Nginx是做什麼的？我來再次給你夯實一下概念。
多協定反向代理
Nginx是個高性能的Web和反向代理伺服器及HTTP伺服器，它能反向代理HTTP，HTTPS和郵件相關(SMTP，POP3，IMAP)的協定連結，還可以提供了負載均衡以及HTTP緩存。
它的功能特點
- 功能豐富：優秀的反向代理功能和靈活的負載均衡政策
- 異步事件模型：削減上下文排程的開銷，提高伺服器并發能力，官方資料每秒支援 5 萬并發。
- 子產品化：具有良好的擴充性，可以通過子產品方式進行功能擴充。
- 高可靠性：主要程序和 worker 是同步實作的，一個 worker 出現問題，會立刻啟動另一個 worker。
- 記憶體低損耗：10000個keep-alive長連接配接，大緻會消耗3MB左右的記憶體。
Ngnix高可用服務架構
分布式系統中，應用隻部署一台伺服器會存在單點故障，負載均衡同樣有類似的問題。一般可采用主備或負載均衡裝置叢集的方式節約單點故障或高并發請求分流。
Ngnix 高可用，至少包含兩個 Ngnix 伺服器，一台主伺服器，一台備伺服器，之間使用 Keepalived 做健康監控和故障檢測。開放 VIP 端口，通過防火牆進行外部映射。
主從模式
大多數場景下，Nginx采用一主多從的主從架構，如下圖所示。
Nginx服務節點
Master節點負責範圍
- Master節點主要負責的作用隻是啟動worker，加載配置檔案，負責系統的平滑更新。
- Master節點不負責具體的工作，而是調用 worker 工作，他隻是負責讀取配置檔案，是以當一個子產品修改或者配置檔案發生變化，是由 master 進行讀取，是以此時不會影響到 worker 工作。
Worker節點負責範圍
- Worker節點被啟動之後，負責一些Web最簡單的工作，而其他的工作都是有worker 中調用的子產品來實作的。子產品之間是以流水線的方式實作功能的。
- Master節點進行讀取配置檔案之後，不會立即的把修改的配置檔案告知Worker。而是讓被修改的Worker繼續使用老的配置檔案工作，當Worker工作完畢之後，直接當掉這個子程序，更換新的子程序，使用新的規則。
流水線，指的是一個使用者請求，由多個子產品組合各自的功能依次實作完成的。比如：第一個子產品隻負責分析請求首部，第二個子產品隻負責查找資料，第三個子產品隻負責壓縮資料，依次完成各自工作。來實作整個工作的完成。
更多C++背景開發技術點知識内容包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，MongoDB，ZK，流媒體，音視訊開發，Linux核心，TCP/IP，協程，DPDK多個進階知識點。
C/C++Linux伺服器開發進階架構師/C++背景開發架構師免費學習位址
【文章福利】另外還整理一些C++背景開發架構師 相關學習資料，面試題，教學視訊，以及學習路線圖，免費分享有需要的可以點選領取
Nginx 通信模型采用 I/O 複用機制
- 開發模型：epoll和kqueue。
- 事件機制：kqueue、epoll、rt signals、/dev/poll 、event ports、select 以及 poll。
事件模型
Nginx支援如下處理連接配接的方法（I/O複用方法），這些方法可以通過use指令指定。
- select - 标準方法。 如果目前平台沒有更有效的方法，它是編譯時預設的方法。你可以使用配置參數 —with-select_module 和 —without-select_module 來啟用或禁用這個子產品。
- poll - 标準方法。 如果目前平台沒有更有效的方法，它是編譯時預設的方法。你可以使用配置參數 —with-poll_module 和 —without-poll_module 來啟用或禁用這個子產品。
- kqueue - 高效的方法，使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用雙處理器的MacOS X系統使用kqueue可能會造成核心崩潰。
- epoll - 高效的方法，使用于Linux核心2.6版本及以後的系統。在某些發行版本中，如SuSE 8.2, 有讓2.4版本的核心支援epoll的更新檔。
支援的kqueue特性包括 EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用資料的數量，錯誤代碼.
支援sendfile、sendfile64 和 sendfilev檔案AIO；DIRECTIO，支援Accept-filters 和 TCP_DEFER_ACCEP.
Nginx支援sendfile機制
一般情況下的資料處理模型和流程，如下所示。
- 使用者将請求發給核心。
- 核心根據使用者的請求調用相應使用者程序，使用者程序在處理時需要申請對應的資源。
- 使用者程序需要把請求再次發給核心（程序沒有直接IO的能力），由核心加載資料。
- 核心查找到資料之後，會把資料複制給使用者程序，由使用者程序對資料進行封裝，交給核心。
- 核心在進行 tcp/ip 首部的封裝，最後再發給用戶端。
這個功能使用者程序隻是發生了一個封裝封包的過程，卻要繞一大圈， 是以有了Sendfile，它的總體工作流程，如下所示。
是以，Nginx引入了sendfile 機制，使得核心在接受到資料之後，不再依靠使用者程序給予封裝，而是自己查找自己封裝，減少了一個很長一段時間的浪費，這是一個提升性能的核心點。
目前高并發的處理，一般都采用 sendfile 模式。通過直接操作核心層資料，減少應用與核心層資料傳遞。
Nginx 場景
Ngnix 一般作為入口負載均衡或内部負載均衡，結合反向代理伺服器使用。
入口負載均衡架構
Ngnix 伺服器在使用者通路的最前端。根據使用者請求再轉發到具體的應用伺服器或二級負載均衡伺服器（LVS）。
内部負載均衡架構
LVS 作為入口負載均衡，将請求轉發到二級 Ngnix 伺服器，Ngnix 再根據請求轉發到具體的應用伺服器。
原文連結：深入淺出學習透析Nginx伺服器的架構分析及原理分析「底層技術原理+運作架構機制」 - 掘金