设备通信存在以下特性：
1、单线程，同时只支持一个socket通信
2、采用一问一答（连续发送的指令时，需要前一条指令响应回来，才能发第二条），有一种特殊情况设备随时从udp通道会给我发来告警的信息，如设备上一些异常操作，这个不需要发送指令的
3、现在与设备通信指令有四十种左右，可以理解成api，只不过是异步的
4、每个指令的格式大体相同 ，请求的数据体有区别，响应也是一样。针对不同的响应我们实现了不同的响应处理类。主要是对响应的十六进制的数据进行解析成我们认识的java封装的对象。
下面是楼主面临的问题：
场景：通过各种指令的组合，去完成一个业务工单，比如拆纤的业务工单，在页面发起一个拆纤动作，设备上会以慢闪提示（发了两条慢闪的指令），然后现场操作人员会将慢闪的端口的纤拔了，此时那个端口会有拔出的告警。根据告警会再次发送
灭灯指令，当需要拔的端口都操作完了，这个拆纤业务也就结束了。
楼主的方案：
第一阶段：整个方案没有第三方框架的介入，所有逻辑是自己设计的。首先发送指令和接收指令的核心代码用数据库表设计的队列，启动收发两个线程，发送线程每50毫秒去扫描发送队列表，有数据就进行发送。收线程不停接收，将接收的数据拼成一个完整的响应后分发给不同响应的处理类。
第一阶段的问题很多，主要有：
1、首先用数据库实现队列，50ms去扫描，增加数据库的压力，同时效率不能满足
2、发送和接收核心代码实现了很好封装，但是响应处理类跟业务耦合性太高，而且响应处理类需要根据不同的业务类型做不同的业务，也就是响应处理类后期代码分之会非常多，不便维护
第二阶段：重新选择了方案：用redis内存数据库代替了db数据库，同时引入了activiti流程的概念，收发核心代码跟方案一类似，lz很快实现了。但是activiti是我另一个同事在研究（我们项目大都是一到两年工作经验，lz三年了算是最老了，但是技术还是菜），本来打算用流程来解决不同的工单，但是在尝试过程中结合到实际的业务还是不能很好的满足。而且把流程搞得变味了，工单业务也复杂多了
小弟在这里先谢谢大家，能耐心的看完我对目前工作的理解。有些地方描述的不好，各位多多包涵，希望大神们指导一下，给出一些建议或者技术选型。再次谢谢
更多 0
