聊一聊yii2-queue你可能不知道的事

业务描述

在聊yii2-queue之前，先来了解下最近使用queue的业务场景。公司最近需要开发游戏app热更新的后台功能，热更新的差异包在后台计算生成，所谓差异包就是用新版本的包对比旧版本的包并把有修改或新增的文件重新组成一个新包。这是个很耗时、很占cpu和内存(zip压缩包对比)的操作，所以放到队列慢慢处理。版本包比较大(大约400MB/个)，所以考虑存放在第三方服务，每次计算都从第三方下载回来，生成后重新上传到第三方服务器

问题

上面业务会引发以下问题：

• 文件上传或下载到第三方服务器不完整
• yii2-queue运行超时，进程自杀

版本

• yii2-queue: 2.0 , 队列驱动用的是redis
• redis ：测试2.6，生产4.0
• php : 7.1

定位、解决问题过程

在开发调试时，用的都是小包(一般不超过5M)的包进行测试，所以不会出现上面的问题。但是，到对接的时候用大包和计算多个版本的差异包时，耗时长还引发一系列其它问题。因为前期开发偷懒，没有对程序的每一步做日志追踪，后期排查不到问题。首先出现的、最头痛的问题是包计算到一半就停了，并且没有任何错误日志，慌得一匹。

我的第一个反应就是：可能服务器内存或cpu崩了，导致进程被杀。查看服务器后，发现确实占得很高，但不会把程序杀死。排查了很久，决定重新追踪程序日志并且从让程序断掉的包入手(因为程序每次计算这个包时断掉)，所以就出现了以上的第一个问题：文件上传或下载到第三方服务器不完整，导致zip受损，解压出错。这个问题不是今天主要聊的，只简单总结下，每次上传或下载完后md5_file和第三方提供的md5对比即可保证文件的完整性。

解决完文件完整性问题后，发现程序被杀的问题还没解决。正头疼时，之前追踪的日志成功捕获到有用信息