nginx+lua+redis实现高并发接口(二)

/ 浏览:90 次

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后又更加发现短板太多...路越走越长也越走越远~

如果你想转载,请注明来源或者出处