Redis 内存数据库在智慧消防系统设计中的应用
智慧消防系统是一种将 GPS(全球卫星定位系统)、GIS(地理信息系统)、GSM(无线移动通信系统)和计算机、物联网和大数据等技术集于一体的智能消防无线报警网络服务系统。随着信息技术的深度发展，人类已进入大数据时代，消防行业面临着前所未有的巨大挑战与机遇，传统消防系统工作方式与新形势、新任务不相适应的矛盾日益凸显。在物联网产业迅猛发展的大背景下，必须主动运用大数据来解决了电信、建筑、供电、交通等公共设施建设协调发展的问题。在智慧消防系统中，消防指挥中心与用户单位联网，改变了过去传统、落后和被动的报警、接警、处警方式，实现了报警自动化、接警智能化、处警预案化、管理网络化、服务专业化、科技现代化，大大减少了中间环节，极大地提高了处警速度，真正做到了方便、快捷、安全、可靠，使人民生命、财产的安全以及警员生命的安全得到最大限度的保护。
Redis(Ｒemote dictionary server) 是一款开源的、网络化的、基于内存的、可进行数据持久化的 Key-Value存储系统。它的数据模型建立在外层，类似于其他结构化存储系统，是通过 Key映射 Value 的方式来建立字典以保存数据，有别于其他结构化存储系统的是，它支持多种数据类型的存储：字符串(string)、链表(list)、集合(set)、有序集合(zset) 和哈希类型 (hash)，并且各种类型都支持丰富的操作，其中大多都支持原子操作。为了保证数据存取的效率，数据都保存在内存中。Ｒedis 还提供了对持久化的支持，它可以定期将更新的数据异步写入磁盘，同时不影响继续提供服务。在此基础上，还实现了主从复制，这对预防单点故障和提高负载能力有很大帮助。在操作方面，Redis 基于 TCP 协议的特性使得它可以通过管道的方式进行数据操作。Redis 本身提供了一个可连接 Server 的客户端，通过客户端可方便地进行数据存取操作。
在智慧消防底层数据库设计中，完全可以应用 Redis 数据存储系统，以满足高访问量与操作方便的需求。在操作方面，应用 Redis 的管道通讯方式进行数据操作，通过 Redis 本身的客户端，可以同时连接 Server 服务器，方便地进行数据存取操作。常用的消防产品信息如：产品的生产企业、型号、证书编号、地理位置信息与应急救援指示信息等较复杂的信息等信息可以以字符串的格式存储在 Redis 的底层数据结构中。通过 hash 结构存储，并通过可以唯一标识产品信息的主键建立不同数据表中各条产品信息的联系，构建底层信息字典。利用 Redis 底层数据结构对字符串和字典数据的高效支持，可以达到快速查询的目的。
在字符串数据的实现中，采用 SDS(Simple Dynamic String，简单动态字符串)取代了功能单一，抽象层次低，并且不高效的char*类型字符串。在字典数据的实现中，为了兼顾高效和简单性，使用了哈希表。在实现哈希表时，有一个问题就是采用何种策略来解决碰撞问题。对于使用链地址法来解决碰撞问题的哈希表来说，哈希表的性能取决于哈希表大小与保存节点数量之间的比率。RDB 将数据库的快照以二进制的方式保存到磁盘中。在Redis 运行时，RDB 程序将当前内存中的数据库快照保存到磁盘文件中，在 Redis 重启动时，RDB 程序可以通过载入 RDB 文件来还原数据库的状态。AOF 则以协议文本的方式，将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件，以此达到记录数据库状态的目的。AOF 更像是历史记录，记录所有运行过的命令。但是 AOF 文件就会随着时间持续增长，进而占据整个磁盘。
为此，Redis 设计了 AOF 重写机制，通过开启新线程，扫描数据库数据，将其转化为 Redis 命令，存入临时的 AOF 文件。当扫描完后，用临时文件代替 AOF 文件。这样一来，AOF 文件中记录的命令就是最简洁的，因而不会占据很多空间。
Redis 兼具内存数据库随机访问的优势和 Key-Value 数据模型简单高效的特点，因此，其 I/O 性能非常优异，支持高并发性，丰富的数据结构适合存储何种复杂的数据。考虑到社会对www.gdliontech.cn智慧消防数据服务的实时响应、高并发、高吞吐量提出了更高的需求，且大多数消防产品信息数据服务后台数据量并不大，大容量、低价格的内存使得以内存数据库的轻量级空间数据应用成为可能。本文以内存数据库 Redis 为平台，利用其响应速度快、并发性高、数据结构丰富的优势，研究了 Redis 的轻量级数据的高效组织和索引方法，提升高并发访问下消防产品信息数据服务的响应速度和查询性能。
1 Redis 数据模型
1.1 数据结构设计
Redis 本身存储是一个巨大的 Hash 表，为了模仿关系型数据库的表，通常使用分隔符分隔“表名”以及“字段”，本文使用”：”作为分隔符。例如存储一个消防产品的属性信息，可以表示为Product：ProductID 作为 key，并用 hash 结构存储消防产品属性信 息 。 field 域 包 括 ： 产 品 名 称 (ProductName) 、 产 品 型 号(ProductType) 、 出 厂 日 期 (Date of Product) 、 技 术 参 数(TechnicalParameters)、证书编号(CertificateNumber)、安装位置(InstallationSite)和报警记录(AlarmRecord)等字段。value 域包含实际的存储信息。在每一个消防产品投入到智慧消防云平台前，系统会为其赋予唯一的产品编号 ProductID，因此该 key 是唯一的。
| Key | Hash | |
| Field | Value | |
| ProductID | ProductName | 电气火灾监控设备 |
| ProductType | DQHZ-ABC |
| Date of Product | 2018.1.20 |
| TechnicalParameters | AC220V50Hz，4个回路200 个地址点 |
| CertificateNumber | 20181000001 |
| InstallationSite | 辽宁省沈阳市万科大厦地 下1室 |
| … | … |
| AlarmRecord | 2018.3.3日17时38分28秒报 警(已处理) |
1.2 系统配置
本文采用主从方式进行系统配置，共有 3 个主(master)节点，3 个从(slave)节点，采用全双工通信方式，最大客户端连接数设置为 10000，系统为每个节点分配的最大内存为 1000MB。采用Java 虚拟机环境， Jvm 主处理单元配置为 4 核 Intel(R) Xeon(R)CPU E7-4830 v2 @ 2.20GHz，内存 31GB，操作系统选择 NeoKylinLinux Advanced Server release 6.0。缓存集群服务器主处理器配置为 4 核 Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz，内存 5.5GB，操作系统选择 Red Hat Enterprise Linux Server release 6.3。
2 实验与分析
2.1 大批量操作缓存测试
智慧消防是一个全新的概念和理念，目前尚处于发展阶段，还没有权威和统一的定义和标准。根据智慧消防模型设计的理念，模拟出能够体现消防产品信息，消防产品安装位置信息和消防产品地理位置信息等数据，根据这些信息生成智慧消防系统的模拟数据。在消防产品入网前，为每一个产品分配唯一的ProductID，以作为该产品在系统中唯一的标识。考虑到消防数据的复杂与多样性，在模拟数据时，尽可能地选择了多的可能体现消防产品信息的数据，考虑到不同的表中要素的个数不同，共生成了 2 个数据表 Ka100 和 Ac001，其中 Ka100 中数据尽可能多地体现了产品的信息，表中所含要素个数为 27891 个，Ac001 尽可能多地体现了产品的位置信息，表中所含要素个数为 46254 个，
2 张表格中分别具有消防产品信息数据 10 万条。
2.2 写缓存测试
考虑到智慧消防系统在实际应用中，写缓存业务单次不会超过 5 万条，因此将测试的数据量上限设为 5 万。当缓存服务器宕机或其他因素导致缓存不可用时，程序会将单次上传的所有数据存入一条 zz01 的 blob(binary large object)类型字段中，其中 blob的最大容量为 2GB。下面本文对写缓存成功的时间，写缓存失败的时间以及缓存失败时存入 blob 的数据量进行了测试。测试结果如下图 1、图 2。
通过对测试结果进行分析，可以看出缓存同步时间随着数据量的增加基本呈现线性增长的趋势，当数据量达到 5 万条时，Ac001 大小为 18.6MB，Ka100 大小为 18MB，而 blob 最大可以容纳 2GB，不会发生溢出。这样的结果说明，Redis 写缓存的实现过程完全可以满足智慧消防系统实际应用中大数据量同时写入缓存的需求。
2.3 数据查询测试
本文中共使用 2 个数据表 Ka100 和 Ac001，其中 Ka100 中数据尽可能多的体现了产品的信息，表中所含要素个数为 27891 个，Ac001 尽可能多地体现了产品的位置信息，表中所含要素个数为46254 个，2 张表格中分别具有消防产品信息数据 10 万条。在Redis 环境和普通数据库环境下，分别对两张表中不同条数的数据进行了查询，测试结果取 5 次测试的平均值，计算出平均查询时间。
如上图 3、图 4，从测试结果中可以看出，无论什么数据，Redis 环境都比 Oracle 环境下耗时少得多。因为 Oracle 使用的是R 树空间索引，而 Redis 使用的是网格索引，通常来讲，R 树空间索引的效率要高于网格索引的效率，但 Redis 在网格索引的支持下，效率仍然高于 Oracle，说明 Redis 在智慧消防数据的查询上，效率更高。另外，Redis 作为内存型数据库，数据存放在内存中，数据查询可以得到快速响应，而传统的关系型数据库Oracle，需要将数据存放在硬盘中，需要先传输到内存中，才能得到响应，受制于 I/O 传输瓶颈，查询效率明显低于 Redis 数据库。
消防物联网的技术发展，将给消防事业带来全新的方法与途径，将彻底改变消防产品生产与消防监管模式。智慧消防的发展乃是大势所趋，它是社会发展和人们生活水平提高到一定程度后的必然需求。但智慧消防的实现，不仅需要消防从业人员的努力，同时需要与物联网和大数据等技术进一步结合。本文提出的 Redis 在智慧消防系统设计中的设计，实现了智慧消防数据库系统的 Redis 模型的建立。试验结果表明，Redis 数据模型在智慧消防数据查询的响应效率，较传统的 Oracle 数据模型有较大的优势，可以满足智慧消防系统实际应用中高访问量、高并发和计时响应的现实需求。
然而，Redis 作为一个内存型数据库，其数据存储容量有限，需要在和大数据结合上更做进一步的研究；智慧消防的设计尚处于理论阶段，最终的云平台和模型细节仍在研究过程中，因此如何将 Redis 模型更好地应用于智慧消防系统的建设中，还需要更全面的研究与探索，但只要全社会共同努力，相信智慧消防很快来到我们身边。让我们共同期待智慧消防早日到来！
来源：孙 超