springBoot监听redis队列获取数据

项目本身有一个批处理模块，使用了springBatch作为数据同步框架，目前2.0版本因为需要对接redis队列，并且数据必须是实时采集并统计显示的（允许一小段的时间差）,觉得实时的数据处理使用batch不太合适，所以自行封装实现了对redis队列的数据接收，采用和sringbatch相似的开发模式，降低开发成本，也统一代码风格。

抽取后的结构大致如下

RedisQueueListener 队列监听 提供redis队列监听功能 AbstractRedisJob 解析队列数据后依次调用Reader,Processor,Write三个接口,抽象类,需要业务子类去继承实现. QueueItemReader 数据读取，获取队列数据并补充完整 QueueItemProcessor 数据处理，获取读取完整的数据并进行数据清洗 QueueItemWrite 数据入库，将处理结束的数据进行持久化 AbstractTransactionRedisJob 事务处理 集成自AbstractRedisJob,在父级的基础上增加了数据库事务 QueueJobListener 事件监听 任务处理过程中的各种事件(开始结束错误)的回调 以Order开头的为具体的业务实现类，基本上能和原来的业务处理保持一致的代码风格。 最终的结构如下：

项目源码： https://gitee.com/nanfree/springboot_code_set

运行之后可通过结合nginx接口接收数据:

curl -X POST -i 'http://***.com/lua' --data '{"orderSource":-535303285,"orderId":"547d4ddf1e4244d5b6fb2bba40c98eb9","payTime":1540304054197,"payMode":2086852026,"errMsg":"01dd65904acf4d9e8a27b11244d0dd8d","pushPoint":716988819,"isOnlineOrder":-1824400530,"submitTime":1540304054197,"orderAmount":150532537,"payAmount":2042040188,"createTime":1540304054197,"masterUid":-363942776,"tradeId":"f1db0f0d560f4ee587d366ea94fc8ea7","userUid":-883316814,"arriveBank":1715104638}'

在这次的过程中遇到的收获不算多，却多了些许不解。目前经验太少，只是按着单一职责和代码习惯去编写，这次在整合之前代码的时候，发现之前同个业务几个类之前的调用关系是，父类实现回调接口再提供一个抽象方法交由子类去继承，整个流程是由组件调用父类，父类再一步步调用子类，由上至下。这次调整去掉了多出来的父类抽象方法，直接子类实现了接口方法(父类或也实现),再由子类去主动调用父类的方法，关系变成由下至上。后者调用关系更清晰(减少了几个抽象方法)，但前者可以在父类对所有子类的调用路径做路由处理。我把第一层继承关系使用第一种方法，后面的层次则采用第二种方法。由此而来，忽然感慨： 写完代码还是得总结思考(代码一早写好，可写到这里时我又多明白了这些～)，代码也有直觉，也有后觉，一开始写的时候结合业务有点绕，但最后还是调整好了，现在回想，那时并没有现在如此透彻(也是因为现在脱离了业务的原因吧～) 近一年来，感觉自身其实技术增长实在缓慢，好在业务接触得多了，能更好的将技术服务于业务。而成为小leader后又更加发现短板太多…路越走越长也越走越远～