udp重發

最近在處理框架通信方面的問題，經過積累的開發經驗，其實在不少狀況（尤爲是實時大數據量），udp是佔有不少優點的；不須要鏈接，只管發送，理論上要快不少;

另外在穿牆上佔有很大優點；

可是最大的一個問題就是丟包；

不少時候咱們會結合咱們的業務來進行發送與回執，這樣的方式應該是最好的；可是也意味着每次都得重來一次；所以花費了一些時間來寫這個重發邏輯；固然目前僅是測試；

封裝了一個udp重發；其實組播也能夠直接使用，只是我尚未完成封裝，原理同樣，只不過組播封裝重發，會浪費網絡資源，只要一個節點（把一個接收位置看做一個節點）沒有收到其中一個包，就須要發送端發送，全部節點都會接收（並不影響數據完整，在接收端已經封裝了接收方式，不會形成數據重複）；不說組播了，回到udp重發；

大致結構：

1.每一次發送都視爲session；

1》judpclient爲封裝的發送端，發送數據時，會自動分包，按照udp65535大小（能夠設置）；每次發送分配一個發送端session(同時產生id),每次發送分包時，都會依次產生

一個初始化序列號，按照初始序列號，每包設置一個id,按照此發送打包數據發送

2》同時會發送一個ack發送確認包，防止數據包只有一個被丟包；

3》發送後等待數據返回

4》judpclient關閉只是邏輯關閉

2.接收端

 接收端按照來源IP,端口產生一個接收端session，而後接收數據，組織數據，檢查丟包，發送丟包ack;

接收端設計了serversession及buffer,因此不用擔憂數據重發形成數據重複的問題，該結構讀取方式已經直接避免了

3.輔助應用

由於是輔助，沒法判斷judpclient使用狀況，因此利用java特色，在回收對象時設置邏輯關閉；同時控制時間，來判斷通信真實關閉（由於發送端還要監聽等待重發）

4.共享session

最開始的設計是不共享的，可是在測試時發現，在極端時候，由於發送端佔有端口監聽須要時間，從新初始化judpclient對象，會致使端口占用完，沒法再分配；因此

最後採用了共享的方式，讓多個judpclient實際使用一個真正的udp底層通信；每一個judpclient產生一個id,來判斷數據接收時往哪裏發送，觸發哪一個對象的方法；

5.緩存問題解決方式

數據重發就意味着發送的數據須要緩存下來，準備從新發送；這樣若是發送大量數據，發送端就可能「爆滿」，因此要減小內存使用；

處理方式：作一個簡單的數據量統計（不精確，也不須要精確），當這個量達到必定值後，就把數據由內存轉移到磁盤中；

                 我本身設計了一個文件保存方式（作了一個文件持久化層），來按照必定方式保存，也實現了文件刪除，修改（修改沒有必要）；

                裏面主要是有個索引維護；同時使用了內存數據庫表（若是不實現文件修改是沒有必要的，經過異步方式保證文件索引準確，又不影響使用效率）

               最開始我沒有使用文件，而是查找了數據庫（paldb,fastdb,mapdb等等），可是效果不盡人意，經過磁盤，其實通常磁盤讀取在30M/s,而數據庫是作不到的；所以我直接採用了文件讀取方式；我並非要作一個文件數據庫，因此在實現文件修改時，任然使用了第三方數據庫h2,簡單直接，索引使用足夠了，並且是異步；在數據重發這裏，文件修正是沒有必要的，實現該功能只是想讓模塊更加完整而已；

文件保存，也是經過一個簡單的計數，每次10M左右的數據一塊兒寫入文件；

當接收端數據接收完成後，會回覆一個接收完成ack包，發送端解析信息後，會把接收完成的一次會話數據都刪除掉；

使用數據庫保存的最初代碼我並無刪除，只是沒有使用而已；

6.遺留問題（須要優化）

經過什麼的構造，其實最大問題在於我沒法控制judpclient的使用，這樣會形成不少線程啓動，在監聽數據返回的信息（丟包，完成），這樣形成大量線程存在，雖然應用了線程池

根據如今的測試，發送端cpu 15-35%都是有可能的；阻塞的線程也不少，一旦完全完成發送，同時退出的線程一樣多，可是感受這樣也沒有影響測試使用（多是個人java水平不過關，有的測試結果我感受很怪）；因此須要縮減線程以及阻塞集合；

7.共享session分配

  專門有個管理池分配，其實就是定一個最大個數，使用完了就再產生一個，同時監視是否共享session關閉狀況

8.其它輔助實現

 使用了guava的緩存及eventbus;

數據發送打包與解析配套（接收端也能夠正常使用）

9.源碼

eclipse編譯；如今已經上傳git;

地址：https://github.com/jinyuttt/jyudp.git

我也會上傳到csdn,不過可能超過大小；

10.基本能夠測試使用了，優化後性能好了不少