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.基本能够测试使用了，优化后性能好了不少