记一次人脸服务端的极致优化

         随着用户量的增加，以及更复杂的场景要求，公司原来的人脸服务已无法满足需求, 频频卡死,效率和准确率都达不到新要求，受限于颜值，这个任务自然落到我身上，首先是对人脸服务源码进行解读.  这里介绍一下，人脸底层基于CPU处理的 V1.5版本免费的虹软人脸识别技术，当有新生录入，或者原来的师生照片需要更换时，其人脸特征会对应的进行更换，为了达到实时性的目的，旧源码采用了5分钟轮询一次人员特征表的线程任务方法，作为比对的人脸库 ，结合移动端刷脸验证，大致流程如下.

                                                                                                             

可以看到，确实存在有部分优化的空间

①没必要每5分钟查询特征库，耗时，耗内存，毕竟每个人脸特征值都很大

②没必要全部特征一起遍历，可以拆分成教师，学生，家长三块, 三种身份入口不同

③没必要频繁从数据库读取人脸特征，毕竟取 IO数据，相对耗时，次数越少越好

④ V1.5人脸版本老旧，效率和准确率有待提高

针对，这里源码提出的三部分优化方向，再结合虹软人脸识别服务的新版本 ，当时是V2.2，后来出了 V3.0，疫情之后还出了一个效率尚可行的口罩版本（收费），当然这些升级都是基于底层人脸引擎的参数优化，对识别效率和准确率有一定的提升.当然，针对升级过程中带来的各种没来由的问题，升级虹软人脸识别遇到的坑 ，这篇笔记有过总结，这里就不做进一步说明, 结合新业务场景和旧版本的不足,  优化后流程如下                 

                                      

 说了这么多, 总要拉出来溜溜，其实最关心的就是升级之后识别效率没有提升，实时性如何？压测如何？

1. 识别效率， 在升级之后，经过测试部十几轮持续性的测试，加上针对性的功能调整，满足平均 2s 内识别(大部分1s内)的要求

2. 实时性， 升级之后，由于业务的调整，没有5分钟的漫长等待，采用1分钟定时Task扫描任务表后(安全队列, 线程A生产入队, 线程B消费出队) ,这里前端更换完照片后，1~2分钟能安排上最新的人脸

3. 压力测试，升级之后，10台设备同时识别10分钟，6000人左右的库(0.8G) , 后来内存最高仅飙升至 0.8~1.5G, 这里需要注意的是，当识别人与人脸库进行比对后，需要将已比对的人员特征进行手动回收，避免内存回收不及时以至于大量内存泄漏带来计算机卡死

 

写到这里并没有结束,  细想之后, 仍存在明显的优化地方, 比如 之前每5分钟查询特征表(数据量大) 调整为 每1分钟扫描 任务表(数据量小), 虽然优化了更新实时性, 但仍需频繁扫表

1. 需要额外维护任务表, 新增任务表,用来web端和人脸服务端交互

2. 频繁扫表浪费内存, 人员变更多集中在固定时期,如新学年录入新生, 其余时间调整照片不是很集中, 每隔1分钟去扫表不妥

既然Task扫表之后,采用了安全队列来更新Cache, 为什么不直接采用采用消息队列来操作呢?  试想, 当Web端收到人脸变更时, 发出消息,  人脸服务端取到变更指令后, 去特征表捞取此人最新特征值, 然后更新对应的Cache, 逻辑上可行

                                                                             

 

采用消息队列优点, 主要来自于扫表的缺点

1. 实时性更高, 服务端第一时间去更新Cache

2. 无需额外维护任务表

3. 人脸服务端而言无需频繁扫表

4. Web端而言, 无需每次成功变更特征值后去写表

一读多写之间,提高了性能, 当然采用消息队列, 也有需要注意的地方 , 怎么保证数据在传输之间不会丢失, 安全的被消费掉,  数据丢失主要来源三方面

1. 生产者

2. 队列本身

3. 消费者

这里需要结合业务本身所在的场景选择合理的处理方式就好