同步转换为异步思考

同步转换为异步思考.

我之前项目经验.有一个工行充值的东西.

之前的同步调用模型是这样的..

1 通过前端界面进行充值操作----> 调用工行充值接口---->等待工行充值接口返回充值成功参数--->充值结果返回,处理内部的

  充值操作逻辑.

这一系列的操作都是同步的,这个方案存在着一个问题,就是调用接口的超时问题.用户操作的体验相当不好.

而且如果说,同一个时间段操作的人比较多的话,同时对充值服务器发起充值请求.对服务器是一个很大的压力.(工行充值的服务器,需要加密解密,token认证获取等等,虽然这块压力不是很大,但是经常会阻塞,原因查了很久没找到)

后来我们经过改造,改成了异步的方式

方案为 

1 通过前端界面进行充值操作,数据进入异步任务表中,状态为待处理,前端操作暂时结束

2 异步任务调度处理器(tbschedule),从任务表中取待处理的数据(抓取的量,和频率我们可以配置,这样就保证了我们向下游服务发送请求的频率,避免压垮下游服务器),向工行发送请求.同时将任务状态修改为充值中.

  不等候工行的返回结果.(避免调用超时)

3 从任务池中取处理中状态的任务数据,然后调用工行查询充值状态(其实也就是转账)的服务,如果成功就执行充值成功的逻辑,如果失败执行失败的逻辑,下游服务基本不用修改.

对于你当前的这个任务我认为也可以参考相应的解决方案.

a 设计一张通用的任务表.common_task

  id: 任务id

  status: 当前任务状态

  exe_count:任务执行次数(这个可以允许一个任务重试)

  task_data:任务数据,往往是任务的参数,一个json,这样就跟具体的业务逻辑无关了,具备通用性.

  对于具体的使用方来说,只需要关系,json数据的解析和封装的实现,以及具体业务逻辑的处理而已.这种方式相对灵活.能实现天然的业务模块之间的解耦.

b tbschedule(淘宝分布式任务调度服务),搭建相应框架.因为我们的业务应用基于他,这个是一个多实例,多线程的任务调度器,经过测算,数据处理速度能达到, 30W/h(oracle,当然跟具体的业务逻辑相关,只要不是很复杂,处理速度还是可以的),可以动态添加,减少机器. 

c 调用下游服务

具体来说,就,servlet接受到调用请求,将任务参数插入到任务表中.

用tbschedule 装配任务执行,调用下游的dubbo服务,根据对应的任务调用状态,更新对应的任务执行状态和次数.