项目使用RQ队列的思考
碎遮项目的后端异步处理经历了
无处理->多线程/多进程->celery异步队列->RQ队列
的调整和修改，先简单说明一下为什么会存在这样的过程。
在nmap的使用指南中，提到过这样的一段话：
作为一个修车新手，我可能折腾几个小时来摸索怎样把基本工具(锤子，胶带，扳子等) 用于手头的任务。当我惨痛地失败，把我的老爷车拖到一个真正的技师那儿的时候 ，他总是在他的工具箱里翻来翻去，直到拽出一个完美的工具然后似乎不费吹灰之力搞定它。 端口扫描的艺术和这个类似。专家理解成打的扫描技术，选择最适合的一种 (或者组合)来完成给定的 任务。 另一方面，没有经验的用户和刚入门者总是用默认的SYN扫描解决每个问题。 既然Nmap是免费的，掌握端口扫描的唯一障碍就是知识。这当然是汽车世界所不能比的， 在那里，可能需要高超的技巧才能确定您需要一个压杆弹簧压缩机，接着您还得为它付数千美金。
虽然我们暂时没有修改nmap源代码的想法，但是作为一个项目的开发者，开发的熟练和不熟练决定了处理问题时选择相应队列和框架的方案。
因为作者是web应用的不熟练开发人员，所以在开发的过程中难免会踩一些坑。
个人首先感觉是
在不同的需求下选择合适的框架
最开始的时候，还没有对后端进行异步处理，因为当时还只是显示一个界面，对于输入的URL也没有进行相应信息的搜集，只是获取输入，所以能够很快返回给前端。
但是添加了漏扫和信息搜集模块之后，假如一个URL需要扫描2分钟，不可能让使用的用户等待两分钟，前端显示界面一直在转圈刷新，这样的用户体验过于差，所以作者在网上找了找，发现了可以使用多线程或者多进程来进行扫描任务的执行，也就是：输入扫描URL，新开一个线程/进程进行处理，主线程先给用户返回一个正常的前端界面，用户可以继续浏览和点击界面。
作者分别使用了线程和进程来实现后端异步的处理，但是线程无法最大限度地发挥多核CPU的威力，所以最后选择了多进程来进行后端异步的处理。问题也相应出现，在我们的项目反馈群里面，有人提到：1，多输入几次URL之后项目容易卡死；2，不能暂停任务，比如输入了一个大型网站的URL，扫描的时间比较长，我扫到一半不想扫了，不能中止掉。
问题一产生的原因我想是电脑CPU有限，在现有进程已经开满的情况下还想继续新建进程，或许就会导致项目卡住，问题二，对于多进程的终止，目前还没有看到比较好的个人实现的方案。
经反馈群中一位老哥推荐，抛弃Celery队列（而确实，扫描器实际上用不上这么重型的队列），使用更加轻量的队列RQ，(Redis Queue)是一个简单的Python库，用于队列任务并在后台与工人（worker）一起处理它们。它由Redis提供支持，旨在降低入门门槛。它可以轻松集成到您的Web堆栈中。
经过Docker配置的一些坑之后，还是将RQ整合到了项目中，后面或许还会根据不同的情况进行相应的调整，这段时间应该都会使用RQ了。
