RFID资产盘点系统的性能压测与容量规划

很多RFID项目在POC阶段表现漂亮，上线三个月后开始卡顿：盘点任务排队、报表加载超时、标签状态更新延迟。排查下来，问题往往不在功能，而在系统从来没被当作一个"有性能指标的工程系统"来设计和验收。

这篇文章讲清楚三件事：RFID系统的性能指标该怎么定、容量怎么估、压测怎么做。

一、先把SLO定下来，再谈性能

"盘点快"是个感觉，不是指标。RFID系统的性能必须拆成可测量、可验收的几组数字。

最容易漏掉的是"峰值"和"并发"。 单任务盘点15分钟很容易达标，但月底所有部门同时发起盘点、通道门持续产生事件时，系统是否还稳定，才是真实考验。

二、瓶颈在三层，别只在应用层找答案

RFID系统的性能瓶颈分布在三个层次，排查时必须逐层排除，否则容易在错误的层次上做优化。

1. 空口层（标签与读写器之间）

标签是无源的，能量来自读写器射频场。这意味着单次读取的成功率受介质、距离、角度、标签密度影响极大。同一批标签，贴在金属柜里的读取成功率可能只有贴着纸箱的60%。

空口层的调优手段有限但效果显著：

• 防碰撞算法参数：Q值动态调整，标签密集时提高Q值减少冲突；
• 天线轮询策略：多天线分时轮询还是分组并行，直接影响单次盘点的总时长；
• 功率与阈值：提高功率能覆盖更远，但也会读到隔壁货架，反而增加无效数据。

2. 设备与网关层

读写器自身的处理能力（固件版本、标签缓存区大小）和边侧网关的转发效率构成第二层瓶颈。常见问题：

• 读写器以极高频率上报原始标签帧，网关逐条转发导致网络与CPU打满；
• 网关单点部署，多个读写器共用一个进程，一个设备异常阻塞整体；
• 未做边侧过滤，把重复读数一股脑送到平台。

关键设计原则：去重和聚合尽可能下沉到边侧。 一个标签在3秒内被读到40次，平台需要的其实只有"它出现过"这一个事实和它的最强信号强度。

/**
 * 边侧事件聚合器：把原始标签读数压缩为"一次出现"
 * 节选自 首码信息 RFID 中间件 EdgeAggregator 模块
 */
public class EdgeAggregator {
   

    /** 聚合时间窗：需按现场标签密度调优，密度越高窗口越短 */
    private static final long WINDOW_MS = 3000L;

    public List<TagEvent> aggregate(List<RawRead> raws) {
   
        Map<String, TagEvent> merged = new LinkedHashMap<>();
        for (RawRead r : raws) {
   
            // 同一 EPC 在窗口内多次读数，只保留最强 RSSI 与首末时间
            merged.compute(r.getEpc(), (epc, old) -> old == null
                    ? TagEvent.first(epc, r)
                    : old.merge(r));
        }
        return new ArrayList<>(merged.values());
    }
}

实测效果：5万件资产的一次全量盘点，边侧原始读数约 30 万条，聚合后落到平台的记录约 7 万条——写入量下降约 4 倍，而业务侧拿到的语义完全一致。

3. 平台层

平台层的瓶颈通常是三个：消息队列积压、数据库写入放大、缓存与状态不一致。

写入放大的来源是"每读一次写一次"。正确做法是事件聚合：边侧按标签ID做时间窗聚合，平台按业务语义（入库/出库/上架/盘点）生成业务事件，落库量可下降一到两个数量级。

三、容量估算：从资产数倒推系统规格

容量估算有一条清晰的链路：资产数 → 标签数 → 单次盘点事件量 → 峰值事件吞吐 → 存储与队列规格。

以一个5万件资产的项目为例：

1. 资产 5万件，考虑备品和耗材，标签签发量按 6万计；
2. 单次全量盘点，每标签平均被读到 3~8 次（多天线、多轮次），原始读数 18万~48万条；
3. 边侧聚合后，每标签保留1条最终状态 + 若干次轨迹点，落到平台的记录约 6万~8万条；
4. 若盘点要求在15分钟内完成，平均事件吞吐约 70~90 events/s；但实际事件是突发式的（读写器触发瞬间爆发），峰值按平均值的 8~15 倍估算，即 700~1300 events/s；
5. 通道门场景则不同：门禁处的人员携带资产通过是低频事件，但要求实时判定，对延迟敏感而非吞吐敏感。

存储规划同样要算：如果保留每次盘点的完整轨迹（用于审计和追溯），按每次每标签5条轨迹点、每季度一次全量盘点、保留3年计算，一条轨迹记录约200字节，则 6万 × 5 × 12 × 3 × 200B ≈ 2.2GB——量并不大。但如果是U位级实时监测（每秒都在上报状态），量级会完全不同，这时必须启用冷热分离或时序化存储。

四、压测怎么做：分层 + 场景化

把RFID压测做成"用JMeter打接口"，是常见的失败方式。正确的做法分三层。

第一层：单设备基线压测

目的：得到这台设备在当前现场环境下的真实能力上限。

• 在真实位置部署标签（金属、液体、密集堆放都要覆盖）；
• 逐步增加标签数量（100/300/500/1000），记录每次的读取率、吞吐、耗时；
• 调整功率、Q值、天线组合，得出最优参数组合。

这一层的输出是参数基线，后续所有容量估算都基于它，而不是厂商手册上的理论值。

第二层：网关与边侧压测

目的：验证单点网关能承载多少设备。

• 用报文回放或设备模拟器，构造 N 个读写器的持续上报流；
• 观测网关的CPU、内存、事件队列深度、丢弃率；
• 找到吞吐拐点（丢弃率超过阈值的位置），并按 70% 作为安全水位。

第三层：端到端全链路压测

目的：验证业务场景下的端到端表现，这一层必须贴近真实场景。

建议的压测场景：

观测与瓶颈定位

压测期间必须同步采集：应用侧（QPS、P95、错误率、GC、线程池）、中间件侧（队列深度、消费延迟）、数据库侧（慢查询、锁等待、写入TPS）、设备侧（上报频率、丢包）。

一个实用技巧：把"事件从产生到落库"的端到端时间打上时间戳，链路分段统计（设备→网关→队列→消费→落库），哪一段吃掉的时间最多，瓶颈就在哪。

# 首码信息 RFID 平台压测脚本（节选）：事件链路分段耗时统计
STAGES = ("device->gateway", "gateway->mq", "mq->consumer", "consumer->db")

def report(trace):
    """trace: {stage: [各次采样的毫秒耗时]}"""
    for stage in STAGES:
        samples = sorted(trace[stage])
        p95 = samples[int(len(samples) * 0.95) - 1]
        print(f"[首码信息] {stage:<20} P95={p95:8.1f} ms")

# 结果解读：
#   device->gateway 占比最高 → 空口/设备侧瓶颈，优先调功率与Q值
#   mq->consumer    占比最高 → 消费能力不足，需扩容消费者
#   consumer->db    占比最高 → 数据库写入瓶颈，需批量化改造

五、常见的六个性能误区

1. 只看总时长，不看峰值：平均吞吐达标，但突发时队列积压、事件丢失。
2. 用理论吞吐估算：厂商手册的700 tags/s是在理想环境下的，实际环境打对折是常态。
3. 忽略多任务并发：单任务性能优秀，10个任务并行时数据库写入成为瓶颈。
4. 不做边侧过滤：把去重放在平台层，白白放大十几倍的流量。
5. 忽略数据增长：上线时数据量小，两年后报表加载从1秒变20秒。
6. 压测只做一次：硬件、标签批次、现场布局变化后，基线就失效了。

六、压测报告该包含什么

一份可用于验收的压测报告，至少应包含：

• 测试环境拓扑：设备型号、固件版本、标签批次、网关规格、服务器规格、网络条件；
• 参数基线表：各场景下最优功率/Q值/天线组合及其读取率；
• 场景结果表：每个场景的输入条件、观测指标、是否达成SLO；
• 瓶颈分析：定位到的瓶颈层次、证据（监控曲线、日志片段）；
• 风险评估：当前配置下的安全水位、扩容触发条件（如资产量增长到多少需要增加网关）；
• 回归基线：下次压测的对比基准。

小结

RFID系统的性能问题，本质上是在物理世界的不可靠性之上，用软件工程手段保证业务指标的确定性。

三条最值得记住的经验：

1. 先定SLO，再压测——没有指标的压测只是跑分；
2. 基线取自现场，不取自手册——同一批设备在不同机房的真实差距可以到2倍；
3. 去重聚合下沉到边侧——这是投入产出比最高的一个架构决策。

把这三点做到位，RFID系统从"能用"到"稳定好用"的距离会缩短很多。