高效能架構學習路線：zookeeper，Nginx，訊息中介軟體，Redis
（一）Zookeeper分散式環境指揮官
zookeeper基礎
ZooKeeper是一種分散式協調服務，用於管理大型主機。在分散式環境中協調和管理服務是一個複雜的過程。ZooKeeper通過其簡單的架構和API解決了這個問題。ZooKeeper允許開發人員專注於核心應用程式邏輯，而不必擔心應用程式的分散式特性。
分散式應用的優點
（1）可靠性 - 單個或幾個系統的故障不會使整個系統出現故障。
（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。
（四）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，進行測試
（五）Redis高效能快取資料庫
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，自增改為自減。
（六）專案實戰資料
（1）kafka百萬級吞實戰
（2）Memcached進階實戰
（3）高效能快取開發實戰
（4）MongoDB進階實戰
需要專案資料（可私信我免費領取答案）私信【學習資料】即可領取
附加java開發的資料（面試資源與經驗總結，Dubbo、Redis、設計模式、Netty、zookeeper、Spring cloud、分散式、高併發等架構技術視訊教程資料,架構思維導圖，以及面試資料，瞭解最新的學習動態；瞭解最新的阿里、京東招聘資訊）