架構師必備之高性能架構學習路線：消息中間件，Nginx，Redis等！

時間 2020-02-22

標籤架構師必備高性能架構學習路線消息中間件 nginx redis 欄目系統架構简体版

原文原文鏈接

一）Zookeeper分佈式環境指揮官

zookeeper基礎nginx

ZooKeeper是一種分佈式協調服務，用於管理大型主機。在分佈式環境中協調和管理服務是一個複雜的過程。ZooKeeper經過其簡單的架構和API解決了這個問題。ZooKeeper容許開發人員專一於核心應用程序邏輯，而沒必要擔憂應用程序的分佈式特性。web

分佈式應用的優勢數據庫

（1）可靠性 - 單個或幾個系統的故障不會使整個系統出現故障。apache

（2）可擴展性 - 能夠在須要時增長性能，經過添加更多機器，在應用程序配置中進行微小的更改，而不會有停機時間。後端

（3）透明性 - 隱藏系統的複雜性，並將其顯示爲單個實體/應用程序。緩存

分佈式應用的挑戰服務器

（1）競爭條件 - 兩個或多個機器嘗試執行特定任務，實際上只需在任意給定時間由單個機器完成。例如，共享資源只能在任意給定時間由單個機器修改。網絡

（2）死鎖 - 兩個或多個操做等待彼此無限期完成。數據結構

（3）不一致 - 數據的部分失敗。架構

二）Nginx高併發分流進階實戰

nginx如何實現高併發

簡單來說，就是異步，非阻塞，使用了epoll和大量的底層代碼優化。

稍微詳細一點展開的話，就是nginx的特殊進程模型和事件模型的設計。

進程模型

nginx採用一個master進程，多個woker進程的模式。

master進程主要負責收集、分發請求。當一個請求過來時，master拉起一個worker進程負責處理這個請求。

master進程也要負責監控woker的狀態，保證高可靠性

woker進程通常設置爲跟cpu核心數一致。nginx的woker進程跟apache不同。apche的進程在同一時間只能處理一個請求，因此它會開不少個進程，幾百甚至幾千個。而nginx的woker進程在同一時間能夠處理額請求數只受內存限制，所以能夠處理多個請求。

事件模型

nginx是異步非阻塞的。

每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什麼程度呢？處理到可能發生阻塞的地方，好比向上遊（後端）服務器轉發request，並等待請求返回。那麼，這個處理的worker不會這麼傻等着，他會在發送完請求後，註冊一個事件：「若是upstream返回了，告訴我一聲，我再接着幹」。因而他就休息去了。此時，若是再有request 進來，他就能夠很快再按這種方式處理。而一旦上游服務器返回了，就會觸發這個事件，worker纔會來接手，這個request纔會接着往下走。

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

三）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。