使用Fiware Orion Broker、QuantumLeap与CrateDB时的数据丢失问题

可能的原因及排查方向 #

1. Orion通知机制积压或丢弃 #

• Orion采用异步通知模式，默认通知队列大小为1000，高并发下队列溢出会直接丢弃通知。查看Orion日志是否有notification queue is full或failed to send notification相关报错。
• 调整Orion启动参数优化：
  • 增大通知队列容量：-notificationQueueSize 5000
  • 提升数据库连接池：-dbPoolSize 20
  • 调整通知重试策略：-notificationRetries 3 -notificationRetryWait 1000

2. QuantumLeap处理瓶颈 #

• Redis消息队列堆积：QuantumLeap依赖Redis缓存待写入数据，若worker处理速度跟不上，队列会溢出丢失数据。进入Redis容器执行LLEN quantumleap查看队列长度，若持续增长说明处理能力不足。
• worker数量不足：默认WORKERS=4，可通过环境变量调整为WORKERS=8提升并发处理能力。
• 日志级别掩盖错误：当前LOGLEVEL=WARNING会忽略大量调试信息，改为LOGLEVEL=DEBUG后重启容器，查看是否有接收失败、数据库写入超时的日志。

3. 容器资源限制 #

• 用docker stats查看Orion、QuantumLeap容器的CPU、内存占用，若出现CPU拉满、内存不足的情况，会导致请求处理超时。可在docker-compose中添加deploy.resources配置扩容资源。
• 容器网络问题：高并发下网络拥堵可能导致Orion无法将通知发送到QuantumLeap。在容器内部执行curl http://quantumleap:${QUANTUMLEAP_PORT}/v2/notify测试连通性和响应时间。

4. JMeter请求发送有效性 #

• 检查JMeter日志，确认所有请求是否成功发送，是否存在超时、报错的情况。对比JMeter发送量和Orion access日志中的请求数，若Orion收到的请求数少于发送量，问题出在JMeter或前端网络。

5. QuantumLeap批量写入策略问题 #

• QuantumLeap默认批量写入数据库，若BATCH_SIZE过大或BATCH_TIMEOUT过短，可能导致批量写入失败且未重试。可调整环境变量BATCH_SIZE=100、BATCH_TIMEOUT=500优化批量逻辑。

排查步骤建议 #

1. 核对请求链路数据：先统计Orion收到的请求数（查看access日志），确认是JMeter发送丢失还是后续环节丢失。
2. 开启详细日志：将Orion和QuantumLeap的日志级别调至DEBUG，捕捉报错信息。
3. 监控中间组件状态：实时查看Redis队列长度、容器资源占用，定位瓶颈点。
4. 逐步调整参数：先优化队列和连接池，再调整worker数量，每次调整后重新压测验证。

内容的提问来源于stack exchange，提问作者Nuno Rolo