在实际的应用开发中经常都会碰到碰到一些相对比较耗时的任务需要处理,而用户也不能等到这些耗时的任务结束后才收到响应,这个时候异步任务就派上用场了。这篇文章主要介绍实时异步任务和定时异步任务的具体实现。这些实现都是基于我们现有平台业务做出的选择,不一定是最优的实现,但是可以作为学习和参考。
实时的异步任务
大部分平台都会有发送短信,发送邮件,发送微信通知的业务(经常还有批量发送),这类业务因为是走网络接口,耗时是非常不确定的,而且这类业务不是一定要同步去完成,通过异步去完成然后设置成功标识,通知前端任务已经完成就可以了。
之前做了一些微博类的产品,碰到大V发微博,这时可以通过异步任务将这条微博逐步发送给所有的粉丝。
定时的异步任务
主要就是统计类的任务,比如一些数据报表生成,阶段性运营数据报表生成。
我们平台提现业务,我们也是定时获取一下提现的数据然后给相应的客户做提现操作。
实时的异步任务的实现
我们的短信发送使用的基于Redis的php-resqueue,主要是考虑Redis用得比较多,而且php-resqueue相对比较简单,比较容易部署运用。
将相应的配置和类库移植到平台的框架中,方便调用
通过supervisor进行守护,同时通过配置"numprocs"开启多进程。
[program:queue]
command=/usr/local/php/bin/php -f /var/www/html/Service/Crontab/startQueue.php
autostart=true
autorestart=true
startsecs=3
redirect_stderr=true
stdout_logfile=/alidata/log/supervisor/queue.log
numprocs=10
process_name=%(program_name)s_%(process_num)02d
还有一些平台上面的核销后续处理业务是通过swoole的task来实现的,用起来也是比较方便的。主要考虑到我们核销的tcp部分的业务是通过swoole的worker来实现的,然后后续的异步任务就通过task来实现了。
TCP服务器有通过crontab的脚本进行每分钟的健康检测,如果发现进程挂了会进行重启。
其中有一个坑就是 "task操作的次数必须小于onTask处理速度,如果投递容量超过处理能力,task会塞满缓存区,导致worker进程发生阻塞。worker进程将无法接收新的请求"(官方文档的说明),实际测试是开启两个task进程,当积压的任务达到1000多的时候,worker进程就发生阻塞了。
定时的异步任务的实现
这部分任务基本就是通过Linux下面的Crontab来实现的,通过Crontab比较简单和文档,但是其中也存在一些问题:配置散落到各个服务器的crontab配置文件中,对于团队的项目来说管理起来比较麻烦;对于具体的任务进程不能进行管理。
如果没有要求秒级定时器,使用的是jobby,整体来说还是不错的。
如果任务执行失败,会发送邮件提醒
有对配置做了一些修改,添加了ip的配置,这样任务可以指定哪台服务器执行
如果是要求秒级定时器,我们使用的是基于swoole定时器实现的swoole-crontab