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

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

二、計算機軟件發(fā)展歷史

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

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

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

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

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

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

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

三、技術架構演進史

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

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

架構演進一:?早期雛形

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

**架構演進二:?**數(shù)據(jù)庫開發(fā)（LAMP特長）

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

架構演進三:? javaweb的雛形

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

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

架構演進四:? javaweb的集群發(fā)展

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

架構演進五:? javaweb的分布式發(fā)展

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

架構演進六:? javaweb的微服務發(fā)展

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

集群與分布式的區(qū)別

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

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

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

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

一、Zookeeper分布式環(huán)境指揮官

1.1 zookeeper基礎

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

1.2 分布式應用的優(yōu)點

• （1）可靠性 - 單個或幾個系統(tǒng)的故障不會使整個系統(tǒng)出現(xiàn)故障。

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

• （3）透明性 - 隱藏系統(tǒng)的復雜性，并將其顯示為單個實體/應用程序。

1.3 分布式應用的挑戰(zhàn)

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

• （2）死鎖 - 兩個或多個操作等待彼此無限期完成。

• （3）不一致 - 數(shù)據(jù)的部分失敗。

1.4 Zookeeper相關筆記

• ZK 手寫筆記（1）：概述+CPA+環(huán)境搭配+一致性協(xié)議+基本使用

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

二、Nginx高并發(fā)分流進階實戰(zhàn)

2.1 nginx如何實現(xiàn)高并發(fā)

• 簡單來講，就是異步，非阻塞，使用了epoll和大量的底層代碼優(yōu)化。

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

2.2 進程模型

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

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

• master進程也要負責監(jiān)控woker的狀態(tài)，保證高可靠性

• woker進程一般設置為跟cpu核心數(shù)一致。nginx的woker進程跟apache不一樣。apche的進程在同一時間只能處理一個請求，所以它會開很多個進程，幾百甚至幾千個。而nginx的woker進程在同一時間可以處理額請求數(shù)只受內存限制，因此可以處理多個請求。

2.3 事件模型

nginx是異步非阻塞的。

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

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

2.4 Nginx相關筆記

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

• 深入剖析Nginx

三、rabbitMQ消息中間件

• （1）Broker：消息中間件實例, 可能是單個節(jié)點也可能是運行在多節(jié)點集群上的邏輯實體

• （2）消息(Message)：消息由消息頭和消息體兩部分組成。消息頭中包括routing-key、priority等標準消息頭以及其它自定義消息頭，用于定義RabbitMQ對消息行為。消息體是字節(jié)流，包含消息內容。

• （3）連接(Connection)：客戶端與 Broker 之間的 TCP連接

• （4）信道(Channel) ：Channel 是建立在 TCP 連接上的邏輯(虛擬)連接。多個 Channel 復用同一個 TCP 連接, 以避免建立 TCP 連接的巨大開銷。 RabbitMQ 官方要求每個線程使用獨立的 Channel, 禁止多個線程共用 Channel。

• （5）生產者(Publisher)：發(fā)送消息的客戶端線程

• （6）消費者(Consumer)：處理消息的客戶端線程

• （7）交換機(Exchange)：交換機負責將消息投遞到相應的隊列

• （8）隊列(Queue)：接收并保存交換機投遞的消息，直至被消費者成功消費。邏輯結構遵循先進先出FIFO。

• （9）綁定(Binding)：將隊列(Queue)注冊到交換機(Exchange)的路由表

• （10）虛擬主機(Vhost)：每個Broker下可建立多個vhost, 每個 vhost 可建立獨立的 Exchange、Queue、綁定及權限系統(tǒng)。同一個 Broker 下的 vhost 共享 Connection、Channel 和 用戶系統(tǒng)，就是說可以使用同一個用戶身份使用同一個 Channel 訪問不同 vhost。

3.1 rabbitMQ消息中間件相關筆記

• RabbitMQ-最完整最全教程

• RabbitMQ實戰(zhàn)指南

四、ActiveMQ消息中間件

• （1）多種語言和協(xié)議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協(xié)議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP

• （2）完全支持JMS1.1和J2EE 1.4規(guī)范 (持久化，XA消息，事務)

• （3） 對Spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性

• （4） 通過了常見J2EE服務器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務器上

• （5） 支持多種傳送協(xié)議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

• （6）支持通過JDBC和journal提供高速的消息持久化

• （7）從設計上保證了高性能的集群，客戶端-服務器，點對點

• （8） 支持Ajax

• （9）支持與Axis的整合

• （10）可以很容易的調用內嵌JMS provider，進行測試

五、Kafka百萬級吞吐實戰(zhàn)

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

Kafka外在表現(xiàn)很像消息系統(tǒng)，允許發(fā)布和訂閱消息流，但是它和傳統(tǒng)的消息系統(tǒng)有很大的差異，

• 首先，Kafka是個現(xiàn)代分布式系統(tǒng)，以集群的方式運行，可以自由伸縮。

• 其次，Kafka可以按照要求存儲數(shù)據(jù)，保存多久都可以。

• 第三，流式處理將數(shù)據(jù)處理的層次提示到了新高度，消息系統(tǒng)只會傳遞數(shù)據(jù)，Kafka 的流式處理能力可以讓我們用很少的代碼就能動態(tài)地處理派生流和數(shù)據(jù)集。所以 Kafka 不僅僅是個消息中間件

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

5.1 Kafka百萬級吞吐實戰(zhàn)相關筆記

• 手寫“Kafka筆記”

• Kafka源碼解析與實戰(zhàn)

六、Redis高性能緩存數(shù)據(jù)庫

6.1 Redis的數(shù)據(jù)結構和相關常用命令

• Key：Redis采用Key-Value型的基本數(shù)據(jù)結構，任何二進制序列都可以作為Redis的Key使用（例如普通的字符串或一張JPEG圖片）

• String：String是Redis的基礎數(shù)據(jù)類型，Redis沒有Int、Float、Boolean等數(shù)據(jù)類型的概念，所有的基本類型在Redis中都以String體現(xiàn)。

• SET：為一個key設置value，可以配合EX/PX參數(shù)指定key的有效期，通過NX/XX參數(shù)針對key是否存在的情況進行區(qū)別操作，時間復雜度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數(shù)據(jù)起作用。時間復雜度O(1)

• INCRBY：將key對應的value值自增指定的整型數(shù)值，并返回自增后的值。只對可以轉換為整型的String數(shù)據(jù)起作用。時間復雜度O(1)

• DECR/DECRBY：同INCR/INCRBY，自增改為自減。

6.2 Redis高性能緩存數(shù)據(jù)庫相關筆記

• Redis高性能緩存

• Redis實戰(zhàn)

• Redis設計與實現(xiàn)

六、分布式系統(tǒng)常用技術及案例分析（PDF）

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

• 第一部分主要介紹分布式系統(tǒng)基礎理論知識，總結一些在設計分布式系統(tǒng)時需要考慮的范式、知識點以及可能會面臨的問題，其中包括線程、通信、一致性、容錯性、CAP理論、安全性和并發(fā)等相關內容;同時講述分布式系統(tǒng)的常見架構體系，其中也包括最近比較火的RESTful風格架構、微服務、容器技術等

• 第二部分主要列舉了在分布式系統(tǒng)應用中經常用到的一些主流技術，并介紹這些技術的作用和用法;這些技術涵蓋了分布式消息服務、分布式計算、分布式存儲、分布式監(jiān)控系統(tǒng)、分布式版本控制、RESTful、微服務、容器等領域的內容。

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

最后

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

、分布式監(jiān)控系統(tǒng)、分布式版本控制、RESTful、微服務、容器等領域的內容。

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

最后

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

[外鏈圖片轉存中…(img-xeTcWlZV-1627038765265)]

總結

以上是生活随笔為你收集整理的深入理解Nginx：高顿教育java开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。