一）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進階實戰
需要項目資料可以關注我的公衆號：【風平浪靜如碼】點資料領取即可獲取！
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！