项目使用RQ队列的思考

Posted 2020-12-17 cl0ud

碎遮项目的后端异步处理经历了

无处理->多线程/多进程->celery异步队列->RQ队列

的调整和修改，先简单说明一下为什么会存在这样的过程。

在nmap的使用指南中，提到过这样的一段话：

作为一个修车新手，我可能折腾几个小时来摸索怎样把基本工具(锤子，胶带，扳子等) 用于手头的任务。当我惨痛地失败，把我的老爷车拖到一个真正的技师那儿的时候 ，他总是在他的工具箱里翻来翻去，直到拽出一个完美的工具然后似乎不费吹灰之力搞定它。 端口扫描的艺术和这个类似。专家理解成打的扫描技术，选择最适合的一种 (或者组合)来完成给定的 任务。 另一方面，没有经验的用户和刚入门者总是用默认的SYN扫描解决每个问题。 既然Nmap是免费的，掌握端口扫描的唯一障碍就是知识。这当然是汽车世界所不能比的， 在那里，可能需要高超的技巧才能确定您需要一个压杆弹簧压缩机，接着您还得为它付数千美金。

虽然我们暂时没有修改nmap源代码的想法，但是作为一个项目的开发者，开发的熟练和不熟练决定了处理问题时选择相应队列和框架的方案。

因为作者是web应用的不熟练开发人员，所以在开发的过程中难免会踩一些坑。

个人首先感觉是

在不同的需求下选择合适的框架

最开始的时候，还没有对后端进行异步处理，因为当时还只是显示一个界面，对于输入的URL也没有进行相应信息的搜集，只是获取输入，所以能够很快返回给前端。

但是添加了漏扫和信息搜集模块之后，假如一个URL需要扫描2分钟，不可能让使用的用户等待两分钟，前端显示界面一直在转圈刷新，这样的用户体验过于差，所以作者在网上找了找，发现了可以使用多线程或者多进程来进行扫描任务的执行，也就是：输入扫描URL，新开一个线程/进程进行处理，主线程先给用户返回一个正常的前端界面，用户可以继续浏览和点击界面。

作者分别使用了线程和进程来实现后端异步的处理，但是线程无法最大限度地发挥多核CPU的威力，所以最后选择了多进程来进行后端异步的处理。问题也相应出现，在我们的项目反馈群里面，有人提到：1，多输入几次URL之后项目容易卡死；2，不能暂停任务，比如输入了一个大型网站的URL，扫描的时间比较长，我扫到一半不想扫了，不能中止掉。

问题一产生的原因我想是电脑CPU有限，在现有进程已经开满的情况下还想继续新建进程，或许就会导致项目卡住，问题二，对于多进程的终止，目前还没有看到比较好的个人实现的方案。

于是只好使用Python Flask支持的异步队列，来实现后端异步的功能，起初选择了Celery框架，在一台云服务器上能够成功进行多任务的执行，同时能够扫描10个URL，本以为异步处理的问题已经告一段落，作者准备完善终止任务功能：获取Celery任务的ID显示在前端，可以通过用户的点击来进行取消。没想到先出现的问题是，部分服务器运行扫描器的时候，输入一个URL扫描一个上午，很明显这是后端卡住了。我在另一台学生机上进行实验，发现单个URL会在进行内置POC扫描的时候卡住，原因应该是：内置POC扫描开了多线程，Celery本身框架比较重，性能不太好的服务器可能就带不动，最终导致卡住。

经反馈群中一位老哥推荐，抛弃Celery队列（而确实，扫描器实际上用不上这么重型的队列），使用更加轻量的队列RQ，(Redis Queue)是一个简单的Python库，用于队列任务并在后台与工人（worker）一起处理它们。它由Redis提供支持，旨在降低入门门槛。它可以轻松集成到您的Web堆栈中。

经过Docker配置的一些坑之后，还是将RQ整合到了项目中，后面或许还会根据不同的情况进行相应的调整，这段时间应该都会使用RQ了。

轻装上阵，继续努力