Java學習總結 1-2-2 Netty框架源碼學習

netty線程模型
    Netty是一個高性能、高可擴展性異步事件驅動的網絡應用程序框架,它極大簡化了TCP和UDP客戶端和服務器開發等網絡編程
    
    結構:
    
    Netty四個重要內容:
        1、Reactor線程模型:一種高性能的多線程程序設計思路
        2、Netty中自己定義的Channel概念:增強版的通道概念
        3、ChannelPipeline職責聯設計模式:時間處理機制
        4、內存管理:增強的ByteBuf緩衝區
    
    Tony源碼中文分析註釋:https://github.com/crazyFeng/netty/tree/netty-4.1.32.final-remark
    優秀博客:https://www.cnblogs.com/lighten/p/8909254.html
    
    
整體結構  三大塊
    1、支持Socket等多種傳輸方式
    2、提供了多種協議的編碼實現
    3、核心設計包含:
            事件處理模型
            API的使用
            ByteBuffer的增強
    
    
netty線程模型
    1、Resources資源(請求/任務)
    2、Synchronius Event Demultiplexer同步事件複用器
    3、Dispatch分配器
    4、Request Handler請求處理器
    
    EvenLoopGroup初始化過程
        構造函數 -> 確定線程數量(默認cpus的兩倍)-> new Executor構建線程執行器 -> for--newChild()構建ExentLoop -> new EventExecutorChooser
        EventLoopGroup:
            Main EventLoopGroup:輪詢通過事件分配執行任務(任務隊列、事件選擇器)
            sub EventLoopGroup:處理請求(IO)
    
    netty中ServerSocketChannel用的是NioMessageUnsafe,socketChannel用的是NioByteUnsafe
    

責任鏈模式 chins
    爲請求創建了一個處理對象的鏈。發起請求個具體處理請求的過程進行解耦:責任鏈上的處理者扶着處理請求,客戶只需要將請求發送到
    職責鏈上即可,無須關心請求的處理細節和請求的傳遞
    
    4個要素:
        處理器抽象類、具體處理器實現類、保存處理器信息、處理執行
    
    
零拷貝複製機制  https://blog.csdn.net/linsongbin1/article/details/77650105
    傳統讀操作:
        當應用發起一個從磁盤讀取文件的操作時,請求會先經過內核,由內核與磁盤進行交互。數據會從磁盤拷貝到內核的緩存區中。
            這個copy動作由DMA(硬件和軟件的信息傳輸、直接存儲器訪問)完成,整個過程中基本上不消耗CPU。如果應用想拿到信息,
            還得從內核緩衝區獲取,這裏又存在一個cpu copy的動作,將數據從內核緩衝區中拷貝到應用緩衝區中。這個copy動作是需要消耗CPU的。
            所以應用想拿到數據需要2次copy動作。
        傳統讀操作流程:
    
    傳統寫操作:
            應用想將數據傳遞給客戶端,必須經過內核,將數據先從應用緩衝區中copy(cpu copy)到內核的緩衝區中,對於寫操作而言,通常這個內核緩
            衝區叫kernel socket buffer,接着DMA會從kernel socket buffer中將數據拷貝(DMA copy)到protocol engine,最終將數據發送給客戶端。
            這裏又發生2次copy動作,一次是cpu copy,另外一次是DMA copy。
        傳統寫操作流程:
        
        
    ByteBuf:
        JDK ByteBuffer的缺點:
            無法動態擴容:
                JDK的ByteBuffer長單獨是固定的,不能動態擴展和收縮,當數據大於ByteBuffer容量時,會發生索引越界異常
            API使用複雜:
                讀寫時需手動調用flip()和rewind()等方法,需謹慎使用這些API,容易出現錯誤
        
        ByteBuf做了增強:
            1、API操作便捷性
            2、動態擴容
            3、多種ByteBuf實現
            4、零拷貝機制
            
        屬性:
            1、capacity     容量
            2、readerIndex  讀取位置
            3、writerIndex  寫入位置
            
        
網絡編程(推送)
    短鏈接:請求/響應之後,關閉已建立的TCP鏈接,下次請求重新建立請求
    長鏈接:請求/響應之後,不關閉TCP鏈接,多次請求,複用同一個鏈接
    
    粘包:Nagle算法-客戶端累積一定量或者緩衝一段時間緊再傳輸。服務端緩衝區堆積,導致多個請求粘貼在一起
    拆包:發送的數據大於發送緩衝區,及逆行分片 傳輸。服務端緩衝區堆積,導致服務端讀取的數據不完整
    
    TCP鏈接四元組:
        服務器IP+服務器PORT+客戶端IP+客戶端PORT


郵箱
    海量用戶的情況如下:
        1、知道哪些接受者需要接受這條消息
        2、確定哪些服務器需要接受推送這個消息
        4、消息存到MQ
        

代更新。。
        

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章