最近在处理框架通讯方面的问题，通过积累的开发经验，其实在很多情况（尤其是实时大数据量），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.基本可以测试使用了，优化后性能好了很多