當前位置：首頁 > 运维知识 > Nginx >内容正文

Nginx

深入理解Nginx：高顿教育java开发

發布時間：2024/1/8 Nginx 35 豆豆

生活随笔收集整理的這篇文章主要介紹了深入理解Nginx：高顿教育java开发小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

一、分布式架構學習路線圖

據統計，人的閱讀時間在20分鐘以內是能夠達到全身心投入的，顧文章單張篇幅以后會盡量縮短，但更新會盡量相應頻繁一些。

二、計算機軟件發展歷史

首先我們了解下計算機軟件的發展歷史,大概總結概括，分為c/s時代，web1.0時代和web2.0時代。

**c/s時代:**富客戶端方案。賣軟件可賺錢。例如 qq、影音、游戲。

**1.0時代:**主要是單向信息的發布，即信息門戶—廣大瀏覽器客戶端，互聯網內容是由少數編輯人員（或站長）定制的。

表是三大門戶，新浪/網易/搜狐。新浪以新聞+廣告為主，網易拓展游戲為主，搜狐延伸門戶矩陣

**2.0時代:**注重用戶的交互。每個人都是內容的供稿者。?RSS訂閱扮演一個很重要的作用。

例如:博客、播客、維基、P2P下載、社區、分享服務

時至今日，互聯網的形式演變已經變成全員參與，老少皆宜的活動。因此，互聯網相關的技術也是要求越來越高，參與人數的增加也讓系統的負擔越來越大。

三、技術架構演進史

以下為2017年天貓雙11的交易指標。那么大的數據量,那么快的處理請求，顯然單臺機器，單個服務絕對是無法支撐的。

那么怎么辦呢，我們將原本單臺部署，單臺處理的服務，需要進行拆分以及部署到不同的服務器中去，使其用多臺機器去處理，分擔壓力。但是我們又要保證系統的完整性。這就是分布式的設計。接下來我們看下服務架構的演進史。

架構演進一:?早期雛形

特征：應用程序主要做靜態文件讀取，返回內容給瀏覽器。

架構演進二:?數據庫開發（LAMP特長）

特征：應用程序主要主要讀取數據表值，填充html模塊。業務邏輯簡單，寫sql

架構演進三:? javaweb的雛形

特征：tomcat + servlet + jsp + mysql。一個war包打天下

項目結構：ssh/ssm三層結構。

架構演進四:? javaweb的集群發展

特征：硬件機器的橫向復制，對整個項目結構無影響。

架構演進五:? javaweb的分布式發展

特征：將Service層單獨分離出去，成為一個單獨的項目jar。單獨運行。Web服務器通過rpc框架，對分離出去的service進行調用。

架構演進六:? javaweb的微服務發展

特征：從業務角度，細分業務為微服務，每一個微服務是一個完整的服務（從http請求到返回）。在微服務內部，將需要對外提供的接口，包裝成rpc接口，對外部開放。

集群與分布式的區別

我在面試的時候，發現很多同學會把集群和分布式混淆，其實他倆完全是兩個東西

分布式：縱向拆分，一個業務分拆多個子業務，部署在不同的服務器上。主要是業務層面拆分，進行業務解耦，從而提高服務高可用以及高性能。
集群：橫向復制，同一個業務，部署在多個服務器上，前面通過負載均衡，起到分擔壓力的作用。而且這些服務器中，即使有一兩個宕機也不會影響到整體業務。

本章主要講了一下高性能架構的學習路線，以及技術演進史。接下來聊聊Alibaba百萬年薪架構師必備技能——高性能架構學習路線（筆記）：中間件、Nginx、緩存、ZK等等…看下方高性能架構進階技能圖…

說明：以下全部所說的架構師必備技能之高性能架構學習路線及相關筆記：中間件、Nginx、緩存、ZK等等等，篇幅有限，很多都是截圖展示，但是圖片都是很高清的，可以清晰的看見其中的內容。

一、Zookeeper分布式環境指揮官

1.1 zookeeper基礎

ZooKeeper是一種分布式協調服務，用于管理大型主機。在分布式環境中協調和管理服務是一個復雜的過程。ZooKeeper通過其簡單的架構和API解決了這個問題。ZooKeeper允許開發人員專注于核心應用程序邏輯，而不必擔心應用程序的分布式特性。

1.2 分布式應用的優點

（1）可靠性 - 單個或幾個系統的故障不會使整個系統出現故障。
（2）可擴展性 - 可以在需要時增加性能，通過添加更多機器，在應用程序配置中進行微小的更改，而不會有停機時間。
（3）透明性 - 隱藏系統的復雜性，并將其顯示為單個實體/應用程序。

1.3 分布式應用的挑戰

（1）競爭條件 - 兩個或多個機器嘗試執行特定任務，實際上只需在任意給定時間由單個機器完成。例如，共享資源只能在任意給定時間由單個機器修改。
（2）死鎖 - 兩個或多個操作等待彼此無限期完成。
（3）不一致 - 數據的部分失敗。

1.4 Zookeeper相關筆記

ZK 手寫筆記（1）：概述+CPA+環境搭配+一致性協議+基本使用

ZK 手寫筆記（2）：源碼解析+應用場景

二、Nginx高并發分流進階實戰

2.1 nginx如何實現高并發

簡單來講，就是異步，非阻塞，使用了epoll和大量的底層代碼優化。
稍微詳細一點展開的話，就是nginx的特殊進程模型和事件模型的設計。

2.2 進程模型

nginx采用一個master進程，多個woker進程的模式。
master進程主要負責收集、分發請求。當一個請求過來時，master拉起一個worker進程負責處理這個請求。
master進程也要負責監控woker的狀態，保證高可靠性
woker進程一般設置為跟cpu核心數一致。nginx的woker進程跟apache不一樣。apche的進程在同一時間只能處理一個請求，所以它會開很多個進程，幾百甚至幾千個。而nginx的woker進程在同一時間可以處理額請求數只受內存限制，因此可以處理多個請求。

2.3 事件模型

nginx是異步非阻塞的。

每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發生阻塞的地方，比如向上游（后端）服務器轉發request，并等待請求返回。那么，這個處理的worker不會這么傻等著，他會在發送完請求后，注冊一個事件：“如果upstream返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時，如果再有request 進來，他就可以很快再按這種方式處理。而一旦上游服務器返回了，就會觸發這個事件，worker才會來接手，這個request才會接著往下走。

web server的工作性質決定了每個request的大部份生命都是在網絡傳輸中，實際上花費在server機器上的時間片不多。這是幾個進程就解決高并發的秘密所在。

2.4 Nginx相關筆記

Nginx 常見應用技術指南[Nginx Tips]

深入剖析Nginx

三、rabbitMQ消息中間件

（1）Broker：消息中間件實例, 可能是單個節點也可能是運行在多節點集群上的邏輯實體
（2）消息(Message)：消息由消息頭和消息體兩部分組成。消息頭中包括routing-key、priority等標準消息頭以及其它自定義消息頭，用于定義RabbitMQ對消息行為。消息體是字節流，包含消息內容。
（3）連接(Connection)：客戶端與 Broker 之間的 TCP連接
（4）信道(Channel) ：Channel 是建立在 TCP 連接上的邏輯(虛擬)連接。多個 Channel 復用同一個 TCP 連接, 以避免建立 TCP 連接的巨大開銷。 RabbitMQ 官方要求每個線程使用獨立的 Channel, 禁止多個線程共用 Channel。
（5）生產者(Publisher)：發送消息的客戶端線程
（6）消費者(Consumer)：處理消息的客戶端線程
（7）交換機(Exchange)：交換機負責將消息投遞到相應的隊列
（8）隊列(Queue)：接收并保存交換機投遞的消息，直至被消費者成功消費。邏輯結構遵循先進先出FIFO。
（9）綁定(Binding)：將隊列(Queue)注冊到交換機(Exchange)的路由表
（10）虛擬主機(Vhost)：每個Broker下可建立多個vhost, 每個 vhost 可建立獨立的 Exchange、Queue、綁定及權限系統。同一個 Broker 下的 vhost 共享 Connection、Channel 和用戶系統，就是說可以使用同一個用戶身份使用同一個 Channel 訪問不同 vhost。

3.1 rabbitMQ消息中間件相關筆記

RabbitMQ-最完整最全教程

RabbitMQ實戰指南

四、ActiveMQ消息中間件

（1）多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
（2）完全支持JMS1.1和J2EE 1.4規范 (持久化，XA消息，事務)
（3）對Spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統里面去，而且也支持Spring2.0的特性
（4）通過了常見J2EE服務器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業服務器上
（5）支持多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
（6）支持通過JDBC和journal提供高速的消息持久化
（7）從設計上保證了高性能的集群，客戶端-服務器，點對點
（8）支持Ajax
（9）支持與Axis的整合
（10）可以很容易的調用內嵌JMS provider，進行測試

五、Kafka百萬級吞吐實戰

kafka 最初是 LinkedIn 的一個內部基礎設施系統。最初開發的起因是，LinkedIn 雖然有了數據庫和其他系統可以用來存儲數據，但是缺乏一個可以幫助處理持續數據流的組件。所以在設計理念上，開發者不想只是開發一個能夠存儲數據的系統，如關系數據庫、Nosql 數據庫、搜索引擎等等，更希望把數據看成一個持續變化和不斷增長的流，并基于這樣的想法構建出一個數據系統，一個數據架構。

Kafka外在表現很像消息系統，允許發布和訂閱消息流，但是它和傳統的消息系統有很大的差異，

首先，Kafka是個現代分布式系統，以集群的方式運行，可以自由伸縮。
其次，Kafka可以按照要求存儲數據，保存多久都可以。
第三，流式處理將數據處理的層次提示到了新高度，消息系統只會傳遞數據，Kafka 的流式處理能力可以讓我們用很少的代碼就能動態地處理派生流和數據集。所以 Kafka 不僅僅是個消息中間件

Kafka 不僅僅是一個消息中間件，同時它是一個流平臺，這個平臺上可以發布和訂閱數據流（Kafka 的流，有一個單獨的包 Stream 的處理），并把它們保存起來，進行處理，這個是 Kafka 作者的設計理念。

5.1 Kafka百萬級吞吐實戰相關筆記

手寫“Kafka筆記”

Kafka源碼解析與實戰

六、Redis高性能緩存數據庫

6.1 Redis的數據結構和相關常用命令

Key：Redis采用Key-Value型的基本數據結構，任何二進制序列都可以作為Redis的Key使用（例如普通的字符串或一張JPEG圖片）
String：String是Redis的基礎數據類型，Redis沒有Int、Float、Boolean等數據類型的概念，所有的基本類型在Redis中都以String體現。
SET：為一個key設置value，可以配合EX/PX參數指定key的有效期，通過NX/XX參數針對key是否存在的情況進行區別操作，時間復雜度O(1)
GET：獲取某個key對應的value，時間復雜度O(1)
GETSET：為一個key設置value，并返回該key的原value，時間復雜度O(1)
MSET：為多個key設置value，時間復雜度O(N)
MSETNX：同MSET，如果指定的key中有任意一個已存在，則不進行任何操作，時間復雜度O(N)
MGET：獲取多個key對應的value，時間復雜度O(N)
INCR：將key對應的value值自增1，并返回自增后的值。只對可以轉換為整型的String數據起作用。時間復雜度O(1)
INCRBY：將key對應的value值自增指定的整型數值，并返回自增后的值。只對可以轉換為整型的String數據起作用。時間復雜度O(1)
DECR/DECRBY：同INCR/INCRBY，自增改為自減。

6.2 Redis高性能緩存數據庫相關筆記

Redis高性能緩存

Redis實戰

Redis設計與實現

六、分布式系統常用技術及案例分析（PDF）

本PDF分為三大部分，即分布式系統基礎理論、分布式系統常用技術以及經典的分布式系統案例分析。

第一部分主要介紹分布式系統基礎理論知識，總結一些在設計分布式系統時需要考慮的范式、知識點以及可能會面臨的問題，其中包括線程、通信、一致性、容錯性、CAP理論、安全性和并發等相關內容;同時講述分布式系統的常見架構體系，其中也包括最近比較火的RESTful風格架構、微服務、容器技術等
第二部分主要列舉了在分布式系統應用中經常用到的一些主流技術，并介紹這些技術的作用和用法;這些技術涵蓋了分布式消息服務、分布式計算、分布式存儲、分布式監控系統、分布式版本控制、RESTful、微服務、容器等領域的內容。
第三部分選取了以淘寶網和Twitter為代表的國內外知名互聯網企業的大型分布式系統案例，分析其架構設計以及演變過程;這部分相當于是對第二部分零散的技術點做一個“串燒”，讓讀者可以結合技術的理論，看到實戰的效果。

最后

手繪了下圖所示的kafka知識大綱流程圖（xmind文件不能上傳，導出圖片展現），但都都可提供源文件給每位愛學習的朋友，獲取鏈接：戳這里免費下載

、分布式監控系統、分布式版本控制、RESTful、微服務、容器等領域的內容。

第三部分選取了以淘寶網和Twitter為代表的國內外知名互聯網企業的大型分布式系統案例，分析其架構設計以及演變過程;這部分相當于是對第二部分零散的技術點做一個“串燒”，讓讀者可以結合技術的理論，看到實戰的效果。

最后