我们最近推出了一款新产品,今天有用户反馈一款新产品人脸无识别问题。比较奇怪,因为我们很多产品都使用了人脸识别技术,此前从未出过类似问题。

比较巧合的是这款新产品所在服务器没有挂载物理磁盘,而是采用我们自研的云磁盘技术,将上传图片实时存储到其它节点。

排查代码后确认使用云磁盘技术后,图片不具有本地路径导致识别失败。

下图是我们目前图片识别流程,具体流程口述如下:

  1. 图片本地路径和回调方法首先被包装成识别任务;
  2. 将识别任务发往任务队列;
  3. 识别线程不断从识别任务队列获取新的任务;
  4. 获取到新的任务,读取本地路径对应的文件流并转成 BASE64;
  5. 将 BASE64 发往百度人脸识别接口,获取识别结果;
  6. 调用回调方法。

其实就是生产者(单)和消费者(多)模式,效率比较高,但不支持优先级调整。

detect-flow.png

我和同事各提出一种解决办法,我基于效率考虑提出了第一种解决办法,他出于可扩展性考虑提出第二种方法。

第一种解决方法

本节点将图片缓存到内存,然后才发往远程节点。如果将这片内存包装 Java 的 byte[] 然后包装成识别任务,发往队列。

这样一来,识别程序需要作相应改动,以便支持将 byte[] 数据转成 BASE64。

优点:无需发起网络请求,识别任务周转率高 缺点:识别任务长时间占用内存使得内存利用率低;识别程序与文件类型高度耦合;请求数过多时内存线性增长

第二种解决方法

云磁盘技术采用 FileId 来标识每一个文件(无论是本地还是远程)识别任务包装 FileId,识别程序调用云磁盘接口来获取数据流。 这样一来,通过云磁盘来屏蔽底层文件位置差异,实现识别程序与文件位置解耦。

优点:内存资源利用率高,按需读取;通过 FileId,将文件位置与识别程序解耦,便于后期扩展(将识别程序解构成独立服务)。 缺点:远程文件需要发起网络请求,可能产生延迟影响后续任务周转率

由于出发角度不同,可以看出两种解决方法必须做出相应的权衡取舍,而且巧合是两者恰好是对方的对立面。最终基于扩展性考虑,决定使用第二种解决方法。