最近在折腾一个多设备人脸门禁同步的活简单说就是把后端人员库里的人脸底库稳定且高效地下发到一批大华摄像头设备上人脸门禁一体机、人脸抓拍机、人脸通道闸机都有。最开始做法很粗暴——遍历人员列表一个一个调设备接口结果一个300人库同步到单台设备要将近一个小时中途还经常超时、丢任务。这篇文章把这次优化的完整思路、踩坑过程、实测数据都记录下来给对接过大华设备、被同步慢、对不上账折磨过的同学一个参考。先说清楚我这里说的人脸同步不是指设备抓拍后把抓拍图传回服务器做人脸比对而是指把授权人员的人脸底库照片、姓名、权限组等下发、更新、删除到设备端。这两件事经常被混在一起但优化思路完全不一样别搞混。1. 最初的人脸同步逻辑慢在哪一次请求的账单1.1 老方案的实现方式最初的同步服务是个单机定时任务逻辑非常简单从数据库查出所有需要下发的人员然后循环调用大华设备的人脸注册接口把照片以base64形式上传到设备里。# 最初的同步逻辑示意 for person in person_list: resp dahua_device.add_face( face_idperson.id, face_imageperson.base64_img, person_nameperson.name ) if not resp.ok: count_fail 1 time.sleep(3)乍一看没毛病逻辑直白排错也容易。但放到真实环境里问题瞬间暴露300人的底库单台设备同步一次接近一个小时。设备数量一多整个任务基本跑不完永远有设备处于上次还没同步完、下次又要开始同步的状态。1.2 慢的核心单张照片一次完整HTTP往返很多人以为慢是照片大小的问题其实大头在请求往返和设备端处理本身。大华人脸设备收到一张底库照片后要做的事情包括写入本地存储、做人脸检测、扣取人脸框、提取特征值、做质量校验然后才返回成功。这一套流程在设备端跑完通常需要3到10秒性能差一点的设备能到15秒。再加上HTTP/TCP连接的建立开销每次调用如果都新建连接握手就要额外花时间。如果照片本身是2MB左右的原图base64编码后接近2.7MB上传传输时间也直接翻倍。我把当时的真实耗时拉了一下大概是这样环节单张耗时TCP HTTP握手0.2 ~ 0.5秒图片传输base64约2.7MB1 ~ 3秒设备端建模与特征提取3 ~ 10秒响应返回0.1 ~ 0.2秒合计5 ~ 15秒均约12秒300人 × 12秒 ≈ 3600秒这就是一个小时的由来。如果中间某几张照片质量不合格或者设备处理超时重试一次又是十几秒总时长直接奔着70分钟去了。所以第一步不是谈优化而是把一次同步的真实成本算清楚——算完之后你会发现任何减少请求次数、压缩传输体积的手段都值得做。1.3 另一个隐形问题全量覆盖式的同步方式老方案还有一个致命设计每次都是全量下发。也就是说设备上已有的、没变化的人脸也会被重新注册一遍。有些设备对重复的face_id会直接覆盖有些会报冲突错误还有的会累积出脏数据。设备端本来容量就有限全量覆盖不仅慢还会让设备数据库反复写擦容易老化。而且全量下发导致对账无从谈起——并发到哪了哪些成功哪些失败完全靠日志去翻中间断了就只能从头再跑。这些痛点凑在一起逼着我把整套同步方案推倒重做。2. 把优化目标拆成四个可落地的方向2.1 方向一降低单次请求的成本这个最直观两个抓手压缩图片、复用连接。大华人脸底库照片根本不是越清晰越好设备端建模时会统一缩放。我拿一批原图做了对照测试原图1.8MB的人脸压到640×480、质量85%的JPEG约80~100KB设备端返回成功率没有下降但上传时间从2秒以上降到了200毫秒以内。连接方面确保HTTP客户端使用连接池开启Keep-Alive避免每次请求都重新握手。用Java的同学注意HttpClient连接复用用Python的话用requests.Session或者httpx的client来复用连接。实测仅连接复用图片压缩两项单张耗时从平均12秒降到了5秒左右。2.2 方向二把全量同步改成增量同步增量同步的核心是回答三个问题设备上现在有哪些face_id本地底库里期望有哪些face_id两者差集是什么所以本地必须维护一张人员-设备-人脸的映射表记录每个人员下发给每台设备的face_id、照片哈希、同步状态、同步时间。每次同步不再全量扫描人员表而是扫描这张映射表里状态异常或者哈希有变化的记录只处理真正的差异。设备端也尽量提供一个查询全部人脸列表的接口同步前拉取一次快照和本地映射表做比对就能自动发现设备多出来的、缺失的、过期的记录。这个对比逻辑不复杂但一定要用批量方式查别写成N1的SQL——人脸数据量上来以后慢SQL同样能把任务拖死。2.3 方向三异步化和队列化改造老方案是同步定时任务串行执行失败了只能整段重跑。新方案必须把同步流程切成三段任务生成、任务执行、结果核对。任务生成监听到人员新增、照片更换、离职删除时往任务表里插入一条待同步记录。任务执行独立的Worker从任务表里取数据调设备接口更新同步状态。结果核对定时或触发式的对账任务把设备端实际人脸列表拉回来和本地映射表比对反向修正状态。任务表用MySQL或者Redis队列都行关键是任务要有状态机PENDING - PROCESSING - SUCCESS / FAILED失败任务要有重试次数和下一次执行时间这样才能做到断了能续、失败了能重试、不会重复下发。2.4 方向四控制并发但别把设备压垮大华不同型号、不同固件的设备接口并发能力差别很大。有的设备同一个时间只能处理一个HTTP请求开3个并发就开始拒绝连接有的设备能扛5~10个并发。这个没有统一的参数表必须实测。我的建议是多个设备之间可以并行处理单台设备内部尽量串行最多小并发2~3并且要给每台设备单独做一个信号量。宁可同步慢一点也不要让设备端服务挂掉或者内存被打满设备一旦异常重启底库损坏的风险很大。3. 最终落地的同步方案增量差量 任务队列 可控并发3.1 整体流程骨架新方案跑起来以后链路大概是这样的业务系统人员变更入职、换照片、删除时写一条变更事件到任务表。同步Worker按设备维度拉取待处理任务。执行前先拉取设备当前人脸列表快照可缓存30~60秒与本地映射表做diff生成具体的新增/删除/更新指令。单设备按指令串行执行多设备并行跑。每成功执行一条更新本地映射表的同步状态和照片哈希。周期性的对账任务重新拉取设备列表对本地状态做二次校正。伪代码大致长这样def sync_device(device): local_mapping get_local_mapping(device) device_snapshot get_device_face_list(device) to_add, to_update, to_delete diff(local_mapping, device_snapshot, device) for face_id in to_delete: device.delete_face(face_id) for face_id in to_update: device.delete_face(face_id) # 先删旧 device.add_face(...) # 再传新照片 for face_id in to_add: device.add_face(...) update_local_status(device, to_add, to_update, to_delete)3.2 diff的核心逻辑照片哈希与face_id映射diff判断照片是否变化的关键是哈希。本地存储每个人脸底图的SHA256值设备返回的人脸列表一般会带face_id和注册时间但不会带哈希。所以更新判断只能靠本地本地映射表里某个人脸的哈希和当前人员照片的哈希不一致就认为需要更新。更新操作我建议先删除、再新增不要依赖设备提供覆盖更新接口。原因有两个一是很多设备没有真正的更新接口注册相同face_id时行为不一致二是先删后增能保证设备端不会短暂出现两张旧特征图同时存着的中间状态。face_id的映射也要注意不建议直接用业务人员ID作face_id因为大华设备端对face_id的字符长度、类型有限制而且人员删除后ID可能被复用容易串数据。我用的是一张独立映射表内部自增ID或者UUID作为face_id同时记录对应的业务人员ID双向可查。3.3 重试、熔断与幂等设备接口调用不可能永远是稳稳的重试策略必须设计好。我采用的策略是网络错误、超时指数退避重试间隔1秒、2秒、4秒、8秒最多重试5次。业务错误比如照片质量不合格、人脸数量超限直接放弃这条任务记录错误原因不重试。连续重试达到上限整个设备标记为暂停同步不再接收新任务避免无效请求继续压设备等人工介入或下一轮对账任务再恢复。幂等性靠face_id保证设备端同一个face_id重复调用add_face要么被幂等忽略要么覆盖删除操作重复执行也安全。所以即使Worker意外重启导致任务重复执行也不会把数据搞乱。3.4 执行状态怎么维护本地映射表字段大致这样设计字段说明id主键device_sn设备序列号person_id业务人员IDface_id设备端使用的人脸IDface_hash照片SHA256sync_statusPENDING / SUCCESS / FAILEDretry_count已重试次数next_retry_time下次重试时间last_sync_time最后同步时间每次任务执行完就更新状态对账任务专门扫描sync_status为FAILED或者retry_count超限的记录。这张表一定要加联合索引device_sn, sync_status对账SQL才不会拖慢主流程。4. 实测数据与跳过的坑4.1 优化前后对比拿一台常见的大华人脸门禁一体机做实测300人底库包含开通权限、下发照片结果如下指标优化前优化后单台全量同步耗时约58分钟约4分钟新增10人增量同步耗时约5分钟约15秒同步失败率每次固定超时2~3个百次调用几乎为0任务中断恢复需人工重跑全量断点续跑自动补差设备并发连接报错偶尔出现基本不再出现耗时能压缩到原来的1/15左右主要贡献是图片压缩、连接复用、增量同步三个点叠加的结果。注意那4分钟不是极限如果设备并发能力允许开到2~3个并发还能再缩短到2分半但我没继续压——没必要为了几十秒的提速去冒设备异常的风险。4.2 坑一并发一开设备直接拒绝连接我一开始图快单台设备开了10个线程并发提交结果测了5分钟设备日志里全是连接重置部分人脸底库还出现了写入不完整的情况。后来查资料加实测发现这台设备在并发HTTP请求超过3个时就开始丢请求了。解决方式很简单用信号量把单设备并发限制在2优先保证稳定。这里也提醒一下不要拿PC服务器的并发思维套在嵌入式设备上人脸设备处理器和内存都很有限容不下高并发。4.3 坑二base64上传体积限制有段时间同步频繁失败返回的错误码查手册也语焉不详。后来我用大华的网页插件抓设备侧日志才发现是上传的base64字符串超过设备单请求体上限。设备大多对HTTP请求大小有限制有些是2MB有些是1MB。原图2MB的照片经base64编码后早已超限。压缩到100KB以内之后这个问题彻底消失。建议所有底库照片统一走一条压缩管道裁剪到640×480、转JPEG、质量85%、去除EXIF信息既减小体积也防止隐私信息外泄。4.4 坑三face_id冲突导致误删早期直接用业务人员ID当face_id后面删除一个人员、再用相同ID新建另一个人员时设备端出现了旧人脸覆盖新照片的情况甚至出现过A的照片同步到B的名字下。排查到头发现是业务ID复用导致的。换成自增内部ID作为face_id并且在映射表里保存person_id的归属之后问题不再出现。这里强烈建议设备端ID和业务ID要做隔离别偷这个懒。4.5 坑四注册成功后立刻查询查不到误判失败人脸设备注册接口返回成功不代表设备端已经完成建模。设备内部经常是异步处理先收图入库再后台提取特征值。上传完成后马上调用查询接口很可能返回查无此人被程序误判为失败然后重试重复写入。我的处理方式注册成功的任务标记为等待确认延迟10~15秒后再查询一次设备端人脸列表确认face_id确实存在才把映射表状态置为SUCCESS。对账任务也专门处理这种本地状态成功但设备无此人或者反过来的情况。4.6 坑五设备时间不准日志对不上账排查一个莫名其妙的同步成功但抓拍不生效问题时发现设备系统时间比服务器慢了40多分钟。设备时间不准会影响日志排序、特征生效判断甚至部分设备对证书有效期判断也会出问题。同步流程最前面加了一步NTP校准用服务器时间主动同步设备时间。这个动作成本极低建议所有设备对接方案都加上。5. 这套方案还能往哪些方向继续演进5.1 从照片下发到特征向量同步如果底库规模继续上涨比如几千上万人的集团级场景设备端本地存储和算力会成为瓶颈。一个可以考虑的演进方向是把同步链路的末端从下发照片变成下发特征向量或者同时维护本地特征库。具体做法是服务端在做底库管理时先通过算法提取人脸特征向量然后同步到设备端。特征向量体积远小于照片通常几百个浮点数传输快、建模快。底库大之后还可以引入向量检索来做预筛再结合设备端精排这个就是我们常说的向量库集成的场景了。不过这个改造涉及设备接口能力不是所有大华设备都开放向量级接口选型前要跟设备SDK文档核对清楚。5.2 多设备分组的滚动同步设备多了以后同一时间一起同步会撞上网络带宽和平台侧服务压力。可以把设备按区域、按分组划分设置不同批次和周期比如凌晨2点到6点滚动执行。任务表里加一个batch_id或者scheduled_time字段调度器按时分批拉取避免一批拉出来几百台设备同时开工。5.3 监控与对账自动化最后强烈建议把对账做成周期性的不要只在同步时对一次。人脸设备日常使用中可能出现底库被人工操作清空、SD卡故障导致数据丢失等问题这些都是同步流程外的事件。定时对账任务每天跑一次发现设备端数量和本地映射表不一致就自动补差并告警能兜住大部分看不见的意外。我个人在实际操作中最深的体会是人脸同步这种活慢还不是最可怕的最可怕的是设备端和数据源之间看起来对上了、实际对不上的假象。这套增量差量加定时对账的方案跑通之后基本再也不用半夜爬起来手工重推任务了。如果你们也在做类似的大华设备对接希望这篇记录能帮你少踩几个坑。