我们最近推出了一款新产品，今天有用户反馈一款新产品人脸无识别问题。比较奇怪，因为我们很多产品都使用了人脸识别技术，此前从未出过类似问题。
比较巧合的是这款新产品所在服务器没有挂载物理磁盘，而是采用我们自研的云磁盘技术，将上传图片实时存储到其它节点。
排查代码后确认使用云磁盘技术后，图片不具有本地路径导致识别失败。
下图是我们目前图片识别流程，具体流程口述如下：
- 图片本地路径和回调方法首先被包装成识别任务；
- 将识别任务发往任务队列；
- 识别线程不断从识别任务队列获取新的任务；
- 获取到新的任务，读取本地路径对应的文件流并转成 BASE64；
- 将 BASE64 发往百度人脸识别接口，获取识别结果；
- 调用回调方法。
其实就是生产者（单）和消费者（多）模式，效率比较高，但不支持优先级调整。
我和同事各提出一种解决办法，我基于效率考虑提出了第一种解决办法，他出于可扩展性考虑提出第二种方法。
第一种解决方法
本节点将图片缓存到内存，然后才发往远程节点。如果将这片内存包装 Java 的 byte[] 然后包装成识别任务，发往队列。
这样一来，识别程序需要作相应改动，以便支持将 byte[] 数据转成 BASE64。
优点：无需发起网络请求，识别任务周转率高
缺点：识别任务长时间占用内存使得内存利用率低；识别程序与文件类型高度耦合；请求数过多时内存线性增长
第二种解决方法
云磁盘技术采用 FileId 来标识每一个文件（无论是本地还是远程）识别任务包装 FileId，识别程序调用云磁盘接口来获取数据流。
这样一来，通过云磁盘来屏蔽底层文件位置差异，实现识别程序与文件位置解耦。
优点：内存资源利用率高，按需读取；通过 FileId，将文件位置与识别程序解耦，便于后期扩展（将识别程序解构成独立服务）。
缺点：远程文件需要发起网络请求，可能产生延迟影响后续任务周转率
由于出发角度不同，可以看出两种解决方法必须做出相应的权衡取舍，而且巧合是两者恰好是对方的对立面。最终基于扩展性考虑，决定使用第二种解决方法。
