WmDog文件处理流程

最近开了一个新坑,需要做一个把美团外卖订单数据解析成单个菜品数据的工具。暂定名称WmDog。源起是一个朋友的实际需求。仔细想想,自从业以来,对于web上相关的文件系统处理仅止步于上传、保存,而这一次还需要后续的处理和下载。而且整个流程设计有一个明显的渐进过程,于是想要记录一下。

第一版的按照所需的功能进行了最简单的设计。

这样的设计符合最初的直觉,但根据经验,像解析数据这样的工作一般是不会直接放在api接口中进行的,更何况美团的外卖数据可能是以十万甚至数十万记录的量级。在用户端看起来很可是假死甚至超时了。

所以解析的过程需要放到任务队列中异步处理。

第二版设计中加入任务队列。

异步处理加入之后,前端可以通过查询任务处理状态持续给予用户反馈;只要保存好job_id可以做到稍后再看的能力。但是这一版设计中依然存在一些问题。文件的上传和下载都是通过web服务器进行,用户文件和解析结果文件也存储在web服务器。我们先不说如果web服务器崩溃导致文件丢失,单单是上传下载的带宽占用就是极大的浪费。web 就该好好干web的事,把文件处理交给专业的来做。谁最专业?自然是各个oss。

第三版设计中把文件存储交给oss。

这样修改之后还有一个好处:可扩展性。web服务器和文件存储、文件解析都分离了,哪里压力大,就可以可以只加那一部分的资源。比如任务队列消费不过来了,只要加一些worker进程即可。从某种程度上说,这样的设计也是一种微服务化的体现。

一个简单的例子。核心的思想是两个:

  1. 耗时任务放到异步队列中执行,既缓解服务器压力,又可以给用户更好的体验
  2. 切分任务,增加可扩展性。

水一文留着给自己看,没有多少干货。最后记录两个好用的程序。

  1. python下的一个轻量级任务队列RQ
  2. 像写代码一样画时序图工具websequencediagrams

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据