Netty、Redis、Zookeeper高併發實戰

從這本書中更多的是學習了一下netty。認識了下zookeeper。然後裏面的im，想去實現，但是確實沒有那個精力了。提供的代碼保存了下來，以後可以用來抄襲。我的極客精神不見了。

講的通俗易懂，不過內容偏基礎，另外zookeeper跟redis章節感覺是爲了書名寫的，不比網上內容優質吧

第二章 對於io模型講解🉐很透徹了

前面的netty部分非常不錯，最後幾個章節只是粗略介紹了一下API。整體感覺挺不錯的。

本書最主要的還是介紹netty，netty部分內容，示例工程im也讓這一部分更有質感，脫離理論陷阱，是很不錯的netty學習和實戰文章，但後面高併發部分不及netty部分豐富，也未涉及原理，權當開拓眼界，查漏補缺，整一個高併發的im工程還沒來得及細看，相信看完能有所獲。

在實際生產環境中，不同的技術框架是一起使用的，在集羣中各司其責，這本書分析了現在流行框架Netty、Redis、Zookeeper的技術原理，以及如何將他們運用到實戰之中，重要的部分都有涉及，簡單易懂，可以快速地掌握他們的精髓，最後一章的IM系統是這些技術的綜合應用，幫助你理解他們在集羣中扮演的角色，如何構建一個負載均衡的高性能分佈式系統。 Netty：異步的，事件驅動的網絡通信框架，基於反應器模式，高性能高併發。 Redis：分佈式緩存數據庫。 Zookeeper：分佈式集羣協調服務，通過在內存中構建目錄樹來存儲集羣中的資源（節點）信息，可以提供動態節點的命名服務，可以實現分佈式鎖，可以統計整個集羣的在線用戶數等等。 第二章的高併發IO底層原理、第四章的Reactor反應器模式，是互聯網架構技術的重點內容。 IO讀寫的基礎原理： 調用操作系統的read，是把數據從內核緩衝區複製到進程緩衝區；而write系統調用，是把數據從進程緩衝區複製到內核緩衝區。 書中對同步與異步、阻塞與阻塞的解釋是不清楚的，更準確的解釋是： 1、同步與異步 同步和異步關注的是消息通信機制。 所謂同步，就是在發出一個調用時，在沒有得到結果之前，該調用就不返回。但是一旦調用返回，就得到返回值了。也就是說，調用者主動等待這個調用的結果。 異步則是相反，調用在發出之後，這個調用就直接返回了，所以沒有返回結果。換句話說，當一個異步過程調用發出後，調用者不會立刻得到結果。而是在調用發出後，被調用者通過狀態、通知來通知調用者，或通過回調函數處理這個調用。 2、阻塞與非阻塞 阻塞和非阻塞關注的是程序在等待調用結果（消息，返回值）時的狀態。 阻塞調用是指調用結果返回之前，當前線程會被掛起。調用線程只有在得到結果之後纔會返回。 非阻塞調用指在不能立刻得到結果之前，該調用不會阻塞當前線程。 NIO三大組件： 1、Bytebuff 緩衝區 2、Channel 通道 3、Selector 選擇器 NIO與BIO的區別在於讀寫是否阻塞的，NiO需要輪詢IO事件的就緒狀態。 while(true){ ByteBuffer buffer=ByteBuffer.allocate(1024); int r=0; if((r=channel.read(buffer))!=0){ //處理數據 } } 通過選擇器Selector，一個線程可以查詢多個通道的IO事件的就緒狀態，比如服務器監聽通道有新連接、傳輸通道連接成功、傳輸通道可讀、傳輸通道可寫等等。 實現IO多路複用，首先把通道註冊到選擇器中，然後通過選擇器內部的機制，可以查詢（select）這些註冊的通道是否有已經就緒的IO事件。 Selector的最大優勢是，可以用一個線程去監控多個通道，與傳統BIO相比，減少了多線程上下文切換的開銷。 Nginx、Redis、Netty等中間件技術都是使用反應器技術。 傳統BIO模式： 對於每一個新的網絡連接都分配給一個線程。每個線程都獨自處理自己負責的輸入和輸出，即Connection Per Thread模式。 缺點是，對應於大量的連接，需要耗費大量的線程資源，對線程資源要求太高。 如何解決Connection Per Thread模式的巨大缺陷呢？使用Reactor反應器模式。用反應器模式對線程的數量進行控制，做到一個線程處理大量的連接。 在反應器模式中，有Reactor反應器和Handler處理器兩個重要的組件： （1）Reactor反應器：負責查詢IO事件，當檢測到一個IO事件，將其發送給相應的Handler處理器去處理。這裏的IO事件，對應NIO中選擇器監控的通道IO事件。 （2）Handler處理器：與IO事件綁定，負責IO事件的處理。完成真正的連接建立、通道的讀取、處理業務邏輯、負責將結果寫出到通道等。

一直想搞明白Netty也嘗試去看過NIO，Netty相關的書籍，都沒堅持下來比較枯燥，作者用通俗易懂的方式幫助讀者如何讀懂Netty，我認爲是最點睛之筆。 1、剛開始從操作系統(內核態)、應用進程（用戶態）之間的IO讀寫，作爲基礎理論幫助讀者認識底層流程是怎麼走的。 2、傳統IO讀寫有那些問題，進化到NIO優化了那些問題，以及講了NIO的核心組件Buffer（緩衝區）、 Channel(管道)、 Selector（選擇器）這章節非常重要！非常重要！非常重要！。 3、講了基於NIO設計出來的Reactor反應堆模式 核心設計思想, 包括單線程與多線程的演進性能方面提升了那些，我感覺Reactor就是Netty的雛形，讀者這章節讀懂了，Netty的核心思想也基本也有了。也爲接下來的章節打下了基礎，所以這段基礎一定要讀懂。非常重要！非常重要！ 4、講了傳統異步回調有什麼樣的問題，google Guava異步回調以及Netty異步回調 之間的對比與優化，這章節也非常重要Netty框架絕大多數場景使用的都是異步回調。 5、講了Netty基本使用方式，比較核心的概念就是Pipeline流水線處理。這個點很像Reactor中的attach/attachment組合升級版(讀到這裏你會發現Netty與Reactor很多共同之處，讀起來也簡單許多)，包括對Nio byteBuf封裝的加強版 也有講到，其他的讀者也可以看看官方案例 API還是講的很細的。 6、粘包、拆包這塊講的比較細，包括解決方案，包括底層什麼原因導致粘包、拆包，理論知識比較值得多讀章節。 7、Zookeeper 基礎理論存儲方式、核心組件大概有講到包括包括Watcher監聽通知，InterProcessMutex重入鎖實現分佈式鎖。Cutator主流客戶端。 8、Redis版本就講的比較基礎適合入門使用吧。 9、這本結合所有知識點，做了個開發實踐demo，我理解是思路版本的，作者還是很用心幫助大家去深入理解 實戰如何使用這些組件，當然讓我印象最深刻的、學習更多的還是1~5章節，讓我有了基礎框架，更好的理解Netty 。 最後：要是作者能夠在講講select/poll/epoll 之間的缺優點與演進就更好的，因爲 高路複用爲什麼快，還是受限於底層使用什麼模型，以及系統句柄數，內存。如果是selelct相對於epoll就要慢，因爲底層存儲數據結構不一樣。

目標 ZooKeeper 是用來做什麼的？ 之前沒有ZK，爲什麼會誕生 ZK？ 憑直覺: ZooKeeper 是用於簡化分佈式應用開發的，對開發者屏蔽一些分佈式應用開發過程中的底層細節 ZooKeeper 對外暴露簡單的 API，用於支持分佈式應用開發 ZooKeeper 在提供上述功能的同時，其還是一個 高性能、高可用、高可靠的分佈式集羣 上面說這麼多，總結一下，ZK 能解決分佈式應用開發的問題，ZK 能很好的解決問題。到這一步，疑問就更多了： 分佈式應用開發，有哪些常見問題？ZK 是如何屏蔽這些底層細節的？ ZooKeeper 對外暴露了那些 API？這些 API 如何支持分佈式應用開發的？這些 API 還能簡化嗎？API 的語義性怎麼樣？ ZooKeeper 自身是一個高性能、高可用、高可靠的分佈式集羣，那有個簡單的問題： 高性能是指什麼？ZooKeeper 爲了達到高性能，做了哪些工作？ 高可用? 高可靠? 爲什麼有 ZooKeeper 一個應用程序，涉及多個進程協作時，業務邏輯代碼中混雜有大量複雜的進程協作邏輯。 上述多進程協作邏輯，有 2 個特點： 處理複雜 處理邏輯可重用 因此，考慮將多進程協作的共性問題拎出，作爲基礎設施，讓 RD 更加專注業務邏輯開發，即： ZooKeeper 就是上述多進程協作基礎服務的一種。 ZooKeeper 的特點 ZooKeeper 有幾個簡單特點： ZooKeeper 的 API：從 文件系統 API 得到的啓發，提供簡單的 API ZooKeeper 運行在專用服務器上，跟業務邏輯分離，保證了高容錯性和可擴展性 ZooKeeper 是存儲設施，但特別注意 ZK上存儲的數據聚焦爲：協作數據（元數據），而不是應用數據，應用數據有自己的存儲方案，例如 HDFS 等 ZK 本質上，可以看作一種特殊的 FS 特別說明： 應用數據和元數據，由於使用場景不同，對一致性和持久性的要求有差異， 因此，架構設計、數據治理過程中，應將 2 類數據獨立看待、獨立存儲。 ZooKeeper 的使命 ZK 要解決的核心問題： ZK 目標：簡化分佈式應用開發中，多進程協作問題。爲分佈式應用，提供高效、可靠的分佈式協調服務（基礎服務），例如： 統一的命名服務 分佈式鎖 進程崩潰檢測 Leader 選舉 配置管理：配置變更時，及時下發到各個 Client。 一個簡單的問題：多進程的協作是什麼？尼瑪呀，有完沒完，啥問題你都有，面對這個掉咋天的腦殼，還是回答一下。 多進程協作，整體分爲 2 類： 協作：多進程需要一同處理某些事情，一些進程採取行動是的其他進程能夠正常工作，例如：主從結構，M 向 S 分配任務，S 纔會執行，否則 S 就保持空閒狀態 競爭：兩個進程不能同時工作，一個進程必須等待另個進程執行完畢，例如：主從結構，M 節點失效後，很多 S 都想成爲 M，這時，就需要互斥鎖，只有第一個獲得鎖的 S 成爲 M 特別說明： 不跨網絡協作：多進程，可以在同一臺物理主機上，同步原語很方便(比如管道、共享內存、消息隊列、信號量) 跨網絡協作：多進程，分佈在不同的物理主機上，ZK 關注這一類 跨網絡多進程協作，進程通信，基本思路有 2 個： 消息機制：通過網絡，直接信息交換，多消息傳遞算法，實現同步原語 共享存儲：利用外部共享存儲，實現多進程協作，要求共享存儲提供有序訪問，ZK 採用這種方式 真實系統中，跨網絡通信，有幾個共性問題： 消息延遲：由於網絡原因，後發送先到達 處理器性能：由於系統調度原因，消息到達後，延遲處理 時鐘偏移：不同物理主機，時鐘發生偏移 ZK 精心設計用於屏蔽上述 3 個共性問題，使得這些問題在應用服務層面完全透明化。 ZooKeeper 特性 ZooKeeper 解決的本質問題 分佈式系統的一致性問題： 消息傳遞：延遲性，先發送的消息，不一定先到達； 消息傳遞：丟失性，發送的消息，可能丟失； 節點崩潰：分佈式系統內，任何一個節點都可能崩潰； 在這種情況下，如何保證數據的一致性？ 提案投票：基於投票策略，2PC 選舉投票：基於投票策略，投出優先級最高的節點（包含最新數據的節點） Paxos 目標：解決分佈式一致性問題，提高分佈式系統容錯性的一致性算法。 Paxos 本質：基於消息傳遞的高度容錯的一致性算法 ZooKeeper 定位 ZooKeeper 是： 分佈式協調服務，高效、可靠，方便應用程序，聚焦業務邏輯開發，而不需要過多關注分佈式進程間協作細節。 ZooKeeper 不直接暴露原語，而是，暴露一部分調用方法組成的 API，類似文件系統的 API，支持應用程序實現自己的原語。 ZooKeeper 特性 ZooKeeper 可以保證如下分佈式一致性特性： 順序一致性：同一個 Client 發起的事務請求，嚴格按照發起順序執行 原子性：事務請求，要麼應用到所有節點，要麼一個節點都沒有應用 單一視圖：Client 無論連接到哪個節點，看到的服務端數據都是一致的（Note：不準確，其實是最終一致性） 可靠性：事務一旦執行成功，狀態永久保留 實時性：事務一旦執行成功，Client 並不能立即看到最新數據，但 ZooKeeper 保證最終一致性 ZooKeeper 設計目標 ZooKeeper 致力於提供高性能、高可用、順序一致性的分佈式協調服務，保證數據最終一致性。 目標一：高性能（簡單的數據模型） 採用樹形結構組織數據節點； 全量數據節點，都存儲在內存中； Follower 和 Observer 直接處理非事務請求； 目標二：高可用（構建集羣） 半數以上機器存活，服務就能正常運行 自動進行 Leader 選舉 目標三：順序一致性（事務操作的順序） 每個事務請求，都會轉發給 Leader 處理 每個事務，會分配全局唯一的遞增id（zxid，64位：epoch + 自增 id） 目標四：最終一致性 通過提議投票方式，保證事務提交的可靠性 提議投票方式，只能保證 Client 收到事務提交成功後，半數以上節點能夠看到最新數據 ZooKeeper 出現之前 ZK 出現之前，分佈式系統常用兩種方式，實現多進程協作： 分佈式鎖管理器 分佈式數據庫 ZK 更專注於進程協作，而不提供任何鎖接口和通用的存儲數據接口。 應用服務器，常見的 2 種需求： Master-Slave Leader 選舉：要求提供Master節點選舉功能 進程響應跟蹤 崩潰檢測：要求提供進程存活狀態的跟蹤 分佈式鎖：互斥排它鎖 ZK 爲上述 2 種策略提供了基礎 API。 ZooKeeper 不適用的場景： 海量數據存儲：ZK 本質是特殊的 FS，但 ZK 用於存儲元數據，需要單獨存儲應用數據

書的內容比較豐富，第九章和十二章的確描述的過於簡單，另外十二章只是講了個思路，沒有具體項目的部署信息，如果能夠有部署的信息，那這本書的價值就會更高，不過還是要感謝作者的辛苦努力！

在微信讀書讀的第一本技術書籍。重點看了Netty部分因爲之前沒有接觸過，感覺很不錯。比網上的博客和買的某某學院的視頻講的更清晰且容易理解。