基于MongoDB和RabbitMQ的物联网水表抄表应用服务系统-杭州脉图人工智能技术有限公司

English

语言

中文版

English

新闻动态

NEWS CENTER

首页

基于MongoDB和RabbitMQ的物联网水表抄表应用服务系统

发布时间：

2025-09-12

当前物联网在各行各业正在广泛应用推广中，把现实世界中物品终端通过信息传感设备与互联网连接起来，进行信息交换，即物物相息，以实现智能化识别和管理。本文依托于智能水表统一抄表平台系统，针对其物联网平台架构中应用服务平台在大规模设备接入场景下的性能瓶颈，设计一个基于MongoDB作为数据存储、RabbitMQ作为消息中间件的方案。通过MongoDB的自有分片副本集群方案对设备上下行数据进行存储；建立设备数据在数据库中的文档存储模型，提高了应用服务系统的并发性能和数据持久化的效率。通过RabbitMQ消息队列把协议接入、协议解析、协议解析后的数据推送等功能进行系统解耦，提高系统数据实时性。

摘要

引言

当今互联网的快速发展下大量的智能设备终端数量在飞速增加，万物互联的物联网协议因此而产生。作为连接用户和终端设备的关键桥梁的应用服务平台系统，设备产商因面对海量智能设备终端、海量的多种不同类型的感知数据对此平台系统的架构就需符合高性能、高并发、高扩展。全文先对文档型数据库MongoDB和消息中间件RabbitMQ做了一个简单介绍，再集合实际情况提出一种基于NoSQL数据库MongoDB 和消息中间件RabbitMQ的应用服务系统架构，同时对新架构的系统进行测试以验证该方案的可行性和有效性。

正文

1 技术背景

1.1文档型NoSQL数据库MongoDB

从数据存储结构上分类，数据库可分为关系型数据库（通过二维表格组织数据）与非关系型数据库。非关系型数据库通常也被称为NoSQL(Not Only SQL) 数据库，从数据模型角度分又可分为四类: 键值（Key-Value）数据库、列存储数据库、文档数据库和图数据库。文档数据库中的文档一词指的是文档中松散结构的键值对集合而不是一般意义的文档或表格。文档数据库将文档当做一个整体，不会将文档分割成多个键值对。

MongoDB 作为文档型数据库的典型代表，兼具关系型数据库和非关系型数据库的部分特点和功能，因其无需预先定义表结构故数据结构较为灵活松散，支持内嵌文档等复杂结构，因此尤其适合物联网平台大量终端设备的海量半结构化和非结构化异构数据的存储。

1.2 RabbitMQ消息中间件

消息队列中间件作为分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削峰等问题。实现高性能，高可用，可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。

RabbitMQ是采用Erlang语言编写的AMQP开源实现，具有跨平台性，支持多种语言的客户端。它主要特点是面向消息、路由、队列，而且保证消息传递的高可靠性。它支持点对点传输，发布订阅、路由、通配符等多种消息交互模型。通过RabbitMQ提供的图形化的管理界面，可以方便开发人员在相关问题上的开发定位。以下介绍RabbitMQ中几个重要的概念。

1) Exchange

消息生产者把消息发送到Exchange，Exchange再根据对应的路由规则即Routing Key将消息转发到对应的queue上。

2) Routing Key

Routing Key需要与Exchange Type及Binding Key一起使用。发送消息给Exchange时，通过指定Routing Key来决定消息转发到哪个具体的Queue。

3) Queue

用于存储消息的队列，消息消费者只需要监听队列即可进行消息消费处理。

4)Exchange Type

Exchange Type会指定Routing Key和Binding之间的匹配规则。RabbitMQ常用的Exchange Type有fanout、direct、topic、headers这四种。以上Exchange、Routing Key、Queue等的关系如图1所示。

图1 Exchange、Routing Key、Queue关系图

2 方案研究

目前物联网抄表系统存在以下2个特征。第一终端设备数量庞大。相较于普通互联网应用的几万几十万的用户量，物联网动辄就是百万千万级别，如此之大的终端数量对系统的高并发、高性能的要求更高。第二设备数据多样性且结构不一。一台终端可携带多种传感数据，不同传感数据结构无法事先统一这就导致了设备数据存在多源异构、结构松散等特点。

通过分析现有系统发现两处与上述特点不相适应之处，第一在大规模设备接入场景中，设备接入层不易扩展导致出现性能瓶颈。第二传统关系型数据库SQLServer其固定的表结构及字段属性无法较好地适应异构松散的设备数据，同时严格的数据库事务约束也限制了读写效率且数据库的部署架构导致数据存储存在单点情况从而导致数据无灾备性。第三由于通过定时器的方式对数据进行推送导致数据实时性无法满足用户需求。针对上述问题，提出一种基于MongoDB 数据库和消息中间件RabbitMQ的应用服务平台方案，改变设备接入集群原有的对接方式，改变数据持久化方式和推送方式。该方案中采用性能更优的Netty将通过不同渠道接入系统中相对分散的设备上报消息数据汇聚至 RabbitMQ。应用服务器集群中解析服务节点分布式消费 RabbitMQ中的上报消息，从而实现一次数据汇聚，并在完成相应处理后以分片策略持久化至MongoDB。

图2 应用服务系统架构图

3 应用服务系统设计实现

基于本文提出的方案，应用服务平台架构如图2灰色部分所示本方案采用消息中间件集群方式完成接入集群与应用服务系统对接，两者较好的并发性能会提高数据流转效率。同时所有数据统一汇集至RabbitMQ进行缓冲，可提高接入并发性能。利用MongoDB数据库集合(Collection)中文档数据结构的灵活性，对半结构化数据直接存储, 避免繁琐的数据结构转换，同时同步MongoDB的副本方式可对数据存储进行灾备。MongoDB提供的如聚合方法aggregate( )以及支持Map-Reduce计算模式等功能，可以应对业务系统对大数据分析及海量数据高并发操作的业务需求。

本方案主要从数据的格式、存储模式、操作三方面切入。数据格式采用MongoDB自带的BSON存储格式便于发挥MongoDB松散数据结构优势进行数据存储。数据存储选用MongoDB数据库,部署方式采用3分片1副本。根据此集群方案本地测试, 在读写平衡场景中MongoDB可达17500ops/sec。在此基础上，面向设备接入系统采用RabbitMQ与MongoDB相结合方式，旨在减轻大规模数据写入时数据库工作负荷。首先设备数据汇聚至RabbitMQ缓冲, 避免直接对数据库造成冲击。其次利用RabbitMQ 消息队列特性，在生产者-消费者模式中应用服务器集群各节点以消费者身份消费消息数据完成数据在持久化。

4 系统性能测试

本文基于MongoDB的3分片1副本集群和消息中间件，结合实际对系统响应性能指标需求（1000千万设备数8小时内离散上线100%成功，应答在3秒内）完成搭建部署。系统运行如图4所示。

使用Jmeter测试工具，构造500虚拟设备终端并发访问云平台，系统在1分钟后到达500并发量，并且一直持续10分钟，这期间事务失败数为0.03%说明系统达到性能顶点。从测试结果分析报告，可见在测试环境中500并发下，平均响应是150毫秒，满足系统3秒响应要求；TPS为1800左右，满足系统业务要求；平台服务器节点CPU利用率收敛于70%，内存占用处于合理范围，平台吞吐量总体趋于平稳，可见平台具有较好的性能稳定性。

图3 系统运行效果图

5 总结

本文依据物联网平台存在2点共性，分析现有系统的3点不足之处，针对抄表应用服务提出一种基于NoSQL数据库MongoDB和消息中间件RabbitMQ的系统方案，改变了接入平台与应用服务平台之间的对接方式，改变了数据流转方式和持久化方式，解决了多模块之间耦合严重问题。实验结果证明本文提出的方案有效可行，平台并发性能、数据实时性得到提高，并且后续开发维护难度降低，对业务扩展提供了更好地支持。

通过RabbitMQ集群服务提供的自带可视化的监控页面，更加方便有利于对平台系统消息集群的监控和维护，后期再通过引入Grafana+Prometheus的界面监控体系，可以更加便捷的查看监测整套系统各个性能指标。

囿于篇幅，舍去注释，完整版本请于水表网下载阅览

来源：三川智慧

作者：祝志云

编辑：李京帅

一审：周琦

二审：詹志杰、黄震威