数据读写分离（共4篇）
数据读写分离 篇1
1 概述
近几年随着移动互联网技术的高速发展以及移动终端的迅速广泛普及,互联网的技术架构体系也在不断的进行演进和发展以适应客户的需求。其中,技术架构体系的演进和发展之一是平台和业务的水平扩展能力,而数据库层面的水平扩展能力是核心。鉴于互联网公司业务的特点和技术要求,目前在新兴的大型互联网公司,数据层面的水平扩展主要采用的是同构的数据库读写分离技术,同构的数据读写分离典型案例包括苹果APPSTORE采用的Oracle-Oracle、阿里的MySQL-MySQL的方案。然而,由于诸多客观因素,对于部分大型互联网的早期系统,特别是采用传统架构技术的遗留系统,考虑到技术的积累、系统平滑迁移、项目实施风险、技术难度以及实施成本等因素,很难一步到位采用同构的读写分离方案。主要提出一种可以在大型互联网公司成功实施的异构读写分离技术方案。
2 技术简介
目前在互联网等行业中,随着业务的快速发展,针对“读多写少”的业务场景,越来越多的企业在数据架构上采用读写分离的水平扩展技术。
2.1 读写分离
读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器,这样能有效地减轻数据库压力,也能减轻10的压力。主数据库主要提供写操作,从数据库提供读操作。当主数据库进行写操作时,数据要同步到从数据库,并确保数据完整性和一致性。
读写分离架构利用了数据库的复制/同步技术,将读和写分布在不同的处理节点上,从而达到提高可用性和扩展性的目的。这种架构适合read-intensive类型的应用,通过增加从数据节点的数量,读的性能可以线性增长。为了避免主节点(即写节点)的单点故障,集群一般都会采用两台主数据库做双机热备,所以整个集群的读和写的可用性都非常高。
读写分离架构的优点是:应用到数据库的数据写入与查询从双向通行变成了单向通行,通行效率更高,大大避免了相互影响。“借道行驶”的情况不再出现。读写分离方案采用的是水平扩展架构体系;同时可以根据读写的特点,主库可以是小型机,在确保系统整体系统的前提条件下,从库可以采用相对廉价的PC机或者刀片服务器等,有效降低成本。读库可按需扩展;读库高可用性,坏掉任何一个读库,不影响整体业务;同时本架构容许了读库物理设备本身的不稳定性。
由于上述特点,读写分离方案非常适用于电子商务的适合读写分离数据(例如:商品数据),例如:苹果的APPS TORE、淘宝、腾讯、百度、微博等[1,2,3,4]已经广泛使用。在读写分离的数据库中,目前业界主流的关系型数据库为Oracle和MySQL数据库。
2.2 MySQL数据库
MySQL作为移动互联网公司主要架构LAMP的一部分,近年来迅速发展,不仅仅在中小企业得到广泛应用,目前大的移动互联网公司均已经或者正在采用采用MySQL。目前全球前20互联网公司,有19家已经采用了MySQL数据库,全球前10位的电信系统制造商,均使用MySQL在其主要系统与设备中。
MySQL数据库的主要特点包括:
(1)高可靠性:可达到99.999%。
(2)高性能:单台PC Server可达5万以上TPS。
(3)代码安全:装机量超过1200万台(占全球互联网公司80%的数据库市场),开放源代码减少排除了蠕虫、后门存在的可能。
(4)开放性:与普通硬件有很好的匹配性,与众多开源软件的集成非常好。
MySQL由于采用了share-nothing的架构体系,处理节点可以线性增加,采用集群架构,没有单点故障,可用性和扩展性基本可以做到按需扩展[5]。
2.3 Oracle数据库
Oracle数据库是目前世界上使用最为广泛的数据库管理系统,作为一个通用的数据库系统,它具有完整的数据管理功能;作为一个关系数据库,它是一个完备关系的产品。
Oracle数据库系统主要采用的是Oracle RAC方式。Oracle RAC的实质是位于不同操作系统的Oracle实例节点同时访问同一个Oracle数据库,每个节点间通过私有网络进行通信,互相监控节点的运行状态,Oracle数据库所有的数据文件、联机日志文件、控制文件等均放在集群的共享存储设备上,而共享存储设备可以是RAW、ASM、OCFS2等,所有集群节点可以同时读写共享存储。由于Oracle RAC采用的是共享存储的架构体系,其主要缺点是:RAC集群能力扩展有限,系统建设投入较高。
鉴于Oracle数据库的成本、性能等综合因素,目前Oracle数据库在业界更主要使用在核心业务系统和交易型业务系统。
3 方案
早期的移动互联网的数据库主要采用的是Oracle数据库,且在建设方式上采用集中式架构。对于数据库性能的提升主要采用RAC的方式,但是RAC方式增加到3机或更多时,性能提高很少;按业务拆库会带来额外的数据同步及跨库访问消耗资源高等问题,分拆粒度是有限制,特别是随着业务的快速发展,业务压力、系统压力、运营压力将会越来越大,同时用户的体验要求也越来越高,在数据架构上采用数据读写分离技术是典型的技术演进方向之一。
读写分离技术的重点和核心是数据复制技术或者数据同步技术。复制使一个数据库能从一个物理地址或者系统拷贝/复制数据的变化到另一个物理地址或者系统(通常是从“主”到“从”系统)。实现数据复制的技术很多,主要分为3大类:(l)基于OS层;(2)基于存储复制(中高端存储大多都支持,以及工具DRBD等);(3)基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的数据整库同步,会涉及到业务数据选择以及多源整合等问题,因此OS复制和存储复制多数情况并不适合做读写分离的技术首选。基于应用分发或者基于数据库层的技术主要采用基于数据库的日志进行复制。Oracle数据库主要的是redo log,MySQL的主要是binlog等。
针对适合读写分离的业务系统(业务要求“读多写少”),采用读写分离主要考虑2种不同的技术方案:(1) O2O (Oracle-数据同步工具-Oracle)方案;(2) O2M (Oracle-数据同步工具-MySQL)方案。
针对两种不同的方案,主要从Oracle RAC源数据库、数据同步工具和Oralce/MySQL目标数据库等方面进行评估。
3.1 源数据库
主要测试源数据库读写分离后性能提升情况,主要评估技术指标如下:
(1)资源消耗:通过OS层面监控数据同步工具对资源的使用和消耗情况,并监控网络带宽的消耗。
(2)读写分离后写库能力提升评估:数据库读写分离后,评估数据库的能力提升情况——写库的能力提升情况(包括后台写操作的计算时间、对资源占用情况等)。
3.2 数据同步
数据同步是源和目标数据沟通的桥梁,主要评估技术指标如下:
(1)数据同步工具的复制延迟:使用数据同步工具复制时,数据从源数据库系统到目标数据库系统会存在一定的延迟,通过测试获得各种场景下数据同步工具的数据复制的延时数据。
(2)数据复制的一致性:使用工具检测数据源和目标的数据一致性。
(3)数据同步工具的资源消耗:在各种场景下,记录数据同步工具在正常工作时对源数据库系统和目标数据库系统的资源消耗。
(4)健壮性:测试数据同步工具是否能在各种异常事件后,重新同步源-目标主机数据,并保证源-目标数据库数据的一致性。
(5)网络带宽:测试数据同步工具在进行数据同步时,对网络资源的使用情况。
3.3 目标数据库
验证目标端MySQI/Oracle方案是否能够满足功能性和非功能性要求,其中包括数据库复制的功能、数据库复制的性能、MySQI/Oracle群集的统一访问、MySQUOracle群集的读写分离、负载均衡、高可靠性及性能的需求。
(1) MySQI/Oracle功能测试:主要测试MySQL/Oracle目标数据库的统一访问能力、负载均衡能力、故障切换能力以及水平扩展能力。
(2)其他:测试MySQL对中文、对特殊数据类型(例如:CLOB、BLOB)等数据类型的支持情况以及压力测试。
3.4 方案对比测试
主要从性能对比(查询响应时间、并发量、业务吞吐量等)、其他方面(统一数据访问能力、读库性能线性扩展能力、负载均衡能力、特殊字符和数据类型兼容性等)等进行全方的对比测试。
3.5 技术方案
搭建测试环境,并导入准现网数据作为测试数据进行测试,最终确认O2M方案完全可以代替O2O方案满足要求,且整体性能和技术指标优于O2O方案。O2M的技术方案核心是:主库采用Oracle RAC的方式提供写操作,主库采用共享存储;从库则采用MySQL数据库实例,由于MySQL的share-nothing架构,从库的MySQL的数据均保存在各自的存储节点上。主库以读写方式打开,向外提供写服务;所有的从库以均以只读方式打开,向外提供实时查询服务,并实时接收来自主库的Redo Log日志文件,Redo log文件进行处理成供MySQL可以恢复和使用的binlog日志或者兼容的日志格式,进行介质恢复。从而可以达到数据读写分离的目的。
采用O2M方案的技术要点如下:
(1)写库为Oracle RAC,读库为MySQL数据库,数据同步采用数据同步工具,其中Oracle数据通过数据同步工具同步到MySQL集群管理中间件,由MySQL集群管理中间件负责将数据同步到所有MySQL数据节点。
(2) MySQL集群通过统一数据集群管理中间件的功能包括:自动化数据读写分离、应用内负载均衡、在线故障迁移能力、数据一致性、高可用、统一数据访问、对表分片,实现读写的横向扩展。同时提供安全、监控和管理等功能。
(3)写库为集中式的Oracle RAC环境,提供数据安全性保障。
(4)读库使用MySQL,采用数据分片,分库分表,每台MySQL放少量的数据,单个数据分片内部采用MySQL复制机制。
(5)读库的超大内存容量,起到了很好的缓存作用,在内存中的数据查询性能远远高于在硬盘上的性能。
(6)利用好当前的高端硬件,保护好自己的投资。
(7)该技术架构体系可以适应多站点部署的需要。
4 关键技术
4.1 数据中心化
按照数据解耦和中心化的思想,对适合读写分离的数据进行重构,建设统一的数据中心。例如:针对商品数据可以建设商品中心、针对交易型系统建设交易中心、针对用户数据建设用户中心、针对物流数据建设集中的物流中心等。针对不同的数据中心中数据的特点和属性,在业务层面采用不同的策略,例如:针对用户中心,用户数据可以在源端集中写,而在目标端进行读操作。
4.2 数据结构重构
数据同步工具的原理是通过实时读取事物日志,捕捉数据变化,按照顺序将数据传递到目标端数据库,并执行所需的数据变化,将数据提交到目标数据库。
因此需要针对系统全局性的数据:例如,自增长系统主键、系统自生成函数、触发器、存储过程等进行改造,以满足业务要求。
4.3 数据一致性
采用读写分离后,在业务上不能降低数据一致性要求。数据一致性包括事务、数据一致性校验和数据一致性稽查。
同步线程组:由于数据同步工具主要通过读取日志的方式捕捉数据变化,而数据的日志主要依赖写库的数据事务边界,因此,为了确保读库的数据的一致性,将需要同步的数据表分为若干个同步线程分组,每个线程分组中的数据表确保在数据生成的时候在一个事物内进行。
数据一致性校验算法:数据校验主要包括写库Oracle和读库MySQL Master以及MySQL Master和MySQL Slave节点的数据一致性,数据一致性采用CRC检验算法。主要思路是将数据表的数据构造CRC值,然后比较源和目标的CRC值的一致性。
数据一致性稽查:异构间系统的持久化数据交换主要由软件保证正常流程的一致性。但为了避免异常情况的发生,必须建立数据稽核功能。
4.4 同步延迟
根据适合读写分离数据(例如:商品数据)的特点,适合读写分离数据的同步时延要求在秒级别范围内,针对同步延迟主要解决措施为:数据同步网络采用专线、避免线程阻塞、避免批量数据生成,采用实时增量数据生成、各个网元节点的高可用(包括:Oracle RAC、数据同步工具、MySQL集群管理中间件、MySQL Master等)。
5 结语
采用异构的数据读写分离O2M方案,对某大型移动应用商场进行了重构,现网运行情况表明,经过重构后系统性能指标等取得了极大的提高,重构后读库共计600万TPMC刀片机,读库性能得到较大提升。读库并发量可达10000以上,数据库响应时间提高了90%以上,目前约10-30ms,系统吞吐量达到10000以上;更为关键的是读库的性能可以做到按需做到线性扩展;并且整个架构体系可以支撑多站点的部署。
结果表明,采用O2M的异构数据读写分离方案,可以顺利将目前现有的系统进行平滑过度,可以有效解决数据架构层面的水平按需扩展能力;该方案同时可以平滑过度到M2M方案。
摘要：在互联网行业,越来越多的企业采用了数据读写分离的架构,其中同构的数据读写分离架构被广泛使用,而成功的异构读写分离架构则较少。鉴于目前遗留系统的技术架构体系与新出现的成熟技术架构体系在应用,技术、架构和部署方面存在较大的差异,考虑到新旧技术的兼容性,并确保系统能够顺利实现平滑过渡,提出了异构的数据读写分离架构。实践证明,该架构在满足业务需求的同时,成功采用新的技术架构体系,既保护了现有的投资,又具备良好的技术前瞻性和技术延续性,具有良好的参考示范价值。
关键词：读写分离,数据同步,数据一致性,异构
数据读写分离 篇2
1 研究背景及现状
传统的电力信息系统建设多为地市分散部署, 且采用单数据库的简单系统架构, 由于服务应用范围较少, 数据量少, 能满足日常使用。随着系统的网省级集中式部署, 系统应用量及业务量激增, 单数据库的架构难以支撑系统使用, 运行风险突显。
1.1 企业信息孤岛现象严重, 数据共享效率差
以往的信息系统建设主要以应用为驱动, 一般是随着各类业务需求逐渐建设的。当出现一类新的业务时, 需要为其建设一套独立的支撑系统, 保存该业务的主要数据。一段时间后, 容易形成各大系统应用互相独立运行, 且在不同的维度管理着不同的业务单元及数据对象。这些数据对象都存放在系统的数据库中, 出于系统安全性、稳定性或改造难度等原因并不便于对外开放接口实现共享访问, 导致形成了一个个的“信息孤岛”。系统之间缺乏中间数据库实现畅通安全的信息交流与共享, 阻碍了企业信息化建设的整体进程。
1.2 数据报表、大数据量查询性能低下
随着业务管理颗粒度的精细化及管理范围的扩展, 系统数据量呈现爆发性的增长, 与此同时, 企业决策人员需要更全面、更实时的业务分析报告。企业运营人员需要使用更复杂、更灵活的数据挖掘、报表统计工具。而这些大数据量环境下的统计、查询业务受到单一数据库系统架构的制约, 为了避免由于资源的争用导致正常业务受影响, 不得不降低统计分析的频率、推迟报告时间, 难以满足业务的要求。
2 主流数据同步复制机制与方法比较
通过对电力业务系统数据进行读写分离, 能有效地解决系统信息孤岛及统计性能差的问题。数据读写分离依赖于底层数据的多份副本同步复制。同步复制是保证数据一致性的有效方式。主流数据同步复制技术从作用对象维度上可分为基于应用、数据库、主机、存储等四个维度。
2.1 基于应用的数据同步复制
基于应用的数据同步复制机制指的是在源端及目标端搭建完全相同的应用服务及数据库环境, 当源端发生数据变更时, 同时触发目标端重做数据变更, 且仅当两端数据库均成功更新的情况下, 该操作才能成功完成。该同步方式主要适用于数据量变更不频繁的非关键系统和双活灾备环境, 其最大的优点是能有效保证两端数据的一致性和完整性。但由于对单个业务数据变更需两端数据处理均完成才算成功, 在高并发环境下, 同步速度慢, 时延高, 故障风险及维护成本高。
2.2 基于数据库的数据同步复制
基于数据库的数据同步复制机制主要应用于系统负载均衡、数据大集中、副本灾备等场景。一般有四种复制方式。
一是基于触发器法, 在业务数据表中创建相应的触发器, 当提取/ 复制对象进行变更 (插入、修改、删除) 时, 由触发器触发提数程序, 将变化写入目标数据库中, 但这种占用系统资源较多, 对复杂的复制任务需要繁琐的配置实施, 管理极不方便。
二是基于日志法, 通过分析数据库日志的信息来捕获复制对象的变化序列, 如:INFORMIX的CDR、DSG的Real Sync等业界技术均是通过读取逻辑日志来获取变化信息的, 该方法不仅方便, 而且占用资源小, 不但能提高效率和保障完整性, 还能在对等复制时提供详细的控制信息。
三是基于时间戳法, 基于时间戳的方法需要应用系统中每个表都保留有时间戳字段, 以记录每个表的修改时间, 这种方法不影响系统额外运行效率, 但却需对系统进行较大改造, 且增加数据量庞大。
四是基于API法, 在应用程序与数据库之间引入中间件, 在API上完成应用程序对数据库修改的同事, 记录复制对象的变化序列, 这种方法可实现对异构数据库的复制, 也减轻了DBA的负担, 但是对于不经过API的数据操作是无法捕捉到, 且当复制逻辑复杂时, 可能影响应用程序的运行效率。
2.3 基于主机的数据同步复制
基于主机的数据同步技术主要通过系统服务器主机层面磁盘卷的镜像或复制实现数据的同步容灾。但该方法需要消耗较多的主机CPU资源, 且因TCP/IP传输效率较低, 对系统整体性能影响较大, 一般仅被应用于规模较小的存储环境内, 不适用于大数据量级的企业级系统。
2.4 基于存储的数据同步复制
基于存储的数据同步技术是一种纯粹的硬件实现方式, 其核心是通过光纤连接两台或多台磁盘阵列, 将源磁盘镜像至目标磁盘。当源端系统对本端存储阵列进行写操作时, 存储设备自动将磁盘阵列上发生变化的数据块复制至目标端阵列对应位置上。这种方法常用于大型数据中心异地跨机房远程灾备环境中, 数据传输速率快, 不会占用主机资源, 扩展性及效率高, 优点明显。但硬件设备投资成本较高, 且存在磁盘写错误、高速缓存数据丢失、同步崩溃等数据一致性与完整性风险, 在业务数据变更频繁时仍存在一定风险。
综上比较各大主流的数据同步复制方法及机制, 基于日志法的数据同步复制技术复制效率及可靠性高, 对系统资源占用小, 可定制化程度高, 对于电力大集中系统读写分离架构的实现能起到有效支撑, 适用于系统的数据架构设计。
3 电力大集中系统读写分离架构设计
电力大集中系统无论从功能规模还是数据规模上看均为十分庞大的系统, 必须采用合理的读写分离策略。以某省级电力营销系统为例, 系统功能规模上覆盖10 个一级业务和28 个二级业务, 含1122 个功能子项, 程序代码逾900 万行。数据规模上覆盖用电客户3000 万, 计量资产6500 万, 存量数据共计14TB, 每日增量达300G。
电力营销系统支撑电力抄核收、计量、业扩、客服、用检稽查等对外业务, 对数据处理能力有很高的要求。面对如此海量的数据, 采用基于数据库的数据同步复制策略能有效分流数据库压力。
3.1 数据分离架构规划
对营销系统数据库分拆为生产库、管理库、历史库, 三个库的表结构一致, 通过设置不同的应用模块指向不同的数据源减少数据库资源争用, 避免服务性能降低。生产库保留三个月的业务数据, 主要应用于联机事务处理, 满足营销系统日常业务办理的高并发、高性能、实时响应的要求。管理库保留三年的业务数据, 主要应用于联机事务分析处理, 满足营销系统查询、统计分析业务的大运算量要求。历史库保留五年及以上的业务数据, 用于历史数据的回溯及备查, 不直接对外服务。
生产库和管理库之间的数据同步采用数据库的准实时复制技术, 将营销系统的数据从生产库完整、准实时地复制到管理库中。管理库和历史库之间的数据通过ETL数据抽取技术定期地迁移。业务数据处理上通过生产库和管理库的分离, 一方面可以有效地分担数据库的压力, 另一方面也可隔离统计查询对一般业务办理的影响与冲击, 保证系统的业务连续性。
3.2 数据调用方式规划
由于数据同步无法避免管理库存在一定时延, 业务数据操作类功能应连接生产库, 加强数据实时性, 比如功能中先查询数据, 紧接着进行增删改操作, 或先变更数据, 紧接着查询数据的业务。如电力营销前台收费业务场景, 营业厅人员需先查询用户欠费信息, 得到欠费金额后进行缴费业务消除欠费记录, 最后再一次查询复核缴费成功状态, 此类业务应连接调用生产库。
对于涉及数据量较大的统计报表及单独实时性要求不高的查询等功能应连接管理库, 减轻系统综合性能压力。对于五年以上的历史数据查询单独连接历史库。
3.3 数据存储配置规划
数据存储层用于存储营销系统涉及的全部数据, 并遵照结构化数据与非结构化数据分离、生产数据与管理数据分离、当前数据与历史数据分离的原则。非结构化数据采用文件服务器存储。结构化数据采用关系型数据库存储, 并配置三套独立存储分别存储生产数据、管理数据、历史数据。生产数据、管理数据需配备高端高性能存储提高数据处理效率, 历史数据则只需配备低端大容量存储用以满足数据的保存。
3.4 数据准实时复制方式规划
电力大集中系统数据准实时复制机制采用基于日志法的数据同步复制方式。生产库与管理库的数据同步复制需遵循严格的数据分析、传输、校验流程, 保证数据复制的准确性与一致性, 共分为五个步骤。第一步日志抓取, 通过代理程序模块定期检查数据库控制文件SCN (系统变更号) 来判断数据源端是否产生新的交易。当发生SCN号变化确认存在新交易时, 代理程序模块获取当前数据库重做日志及其位置信息。代理程序根据这些信息将上次抓取时记录的日志位置与本次读取的最新日志加以分析, 并将这些数据存在缓存中, 等待下一步交易合成。第二步日志分析, 将数据库的所有更改都记录在日志中, 代理程序通过对日志进行分析, 得到该数据库执行的所有SQL指令。第三步交易合成, 由于SQL指令是交叉出现且非连续执行的, 因此为了保证系统的逻辑完整性, 避免数据丢失, 通过对抓取的数据进行交易整合, 以Transaction (事务) 作为单位进行复制, 更好地控制复制的过程。第四步交易传输, 数据在传输之前首先存入源数据端的Cache (缓存) 中, 然后通过TCP/IP数据包传送至目标端, 目标端将接收到的数据包存入Queue (队列) 中。第五步数据装载, 目标端从队列中接受数据包, 并根据包头描述的包大小进行完整性检查, 成功后严格按照交易的顺序装载数据信息, 保证数据的同步复制有效, 完成整个数据复制流程。
4 结语
本文对新时代环境下电力大集中系统如何引入新架构应对数据量、业务量的激增进行了探讨分析, 对现今使用较为广泛的四种数据同步复制技术方案进行对比后, 对电力大集中系统的数据分离架构、调用方式、存储配置、准实时复制方式进行了具体设计与规划, 具有很强的指导意义。通过读写分离架构的引入, 能有效提高系统运行效率, 提高业务报表响应时间, 加强企业内部信息流通共享, 进一步挖掘数据价值。
参考文献
[1]万勇.解决企业信息孤岛问题的策略与方法研究[J].技术经济与管理研究, 2006 (6) .
[2]沙光华, 陈泳, 张长江.读写分离技术在运营支撑系统中的应用[J].计算机工程与应用, 2015 (12) .
[3]王欣, 左春.企业级数据复制平台的构建方案计算机工程与应用[J].2003 (3) .
基于modbus协议的数据读写 篇3
1 Modbus TCP协议模式的数据帧格式
TCP/IP协议相对于Modbus TCP/IP协议, 是偏向于外层的, 那必然是Modbus TCP/IP协议的数据帧被打包成TCP/IP协议数据帧中的数据单元, 即Modbus TCP/IP协议的数据帧作为TCP/IP协议中的基础数据, 发送给各种控制设备。当某些控制设备收到Modbus请求时, 且支持Modbus协议, 则根据功能将结果返回给客户端或写入控制设备。本设计的Modbus TCP协议模式的数据请求和响应帧格式如图1所示。
MBAP Head包括事务标识、协议标识、长度、单元标识和Data启动位置的Area。如表1所示。
事务标识:该Area中的数据可以由用户自主设定, 且事务处理的配对由事务标识决定, 例如每一帧的序号放在事务标识中。
协议标识:该标识的Area用于整个系统内的多路复用 (多种协议) , 而当系统使用的是Modbus协议时, 则该值为“0”。
长度:该Area中的2字节数据表示后续区域的字节个数, 包括单元标识、Data启动位置和协议数据。
单元标识:识别远程单元 (从单元) , 方便单元路由功能。当使用这片区域时, 服务器的响应帧内容必须使用相同的单元标识, 来返回该区域的数据。
设计中读写功能在Modbus Function的定义如表2所示。
协议数据包括Function和Data两部分。本文以写入和读取2个寄存器的数据为例, 对该帧格式的进行设置。
Function:读多个寄存器的功能码为0xAA, 写多个寄存器的功能码为0xFF, Function占用大小为1Byte。
Data:数据部分包括两大部分, 即起始位置 (地址) 和所要读的字节数 (所要写的字节数) 。起始位置占用大小为2字节;读的字节数和写的字节数为2, 占用大小为2字节。Data中的起始位置会与Head中启动位置进行匹配检验。
2 读取写入功能的实现
本设计在Modbus TCP协议模式的数据帧格式的基础上, 使用VC开发环境, 实现基于Modbus TCP协议模式的数据帧格式的读取和写入功能, 采用Modbus Simulator作为Modbus的TCP Server。
数据启动请求的核心代码示下:
数据启动响应的核心代码示下:
本文实现了Modbus TCP协议模式的数据帧格式的读取和写入功能, 如图2数据读取写入客户端所示。
设定MODBUS Simulator的地址40000-40001写入534。如图3服务器Modbus所示。
当客户端读取数据, 则首先点击“connect Server”按钮, 若客户端提示服务器连接成功, 这时点击“Start Timer”按钮, 则启动客户端的周期性任务, 定时从服务器Modbus中读取数据, 并显示在客户端。
3 结语
本文以VC软件开发环境为基础, 建立基于Modbus协议的数据读取和写入的数据帧格式, 并使用VC的对话框应用软件开发, 实现本设计的数据帧的数据读取和写入功能。通过该功能, 客户端可以读取PLC控制器上的数据或向PLC控制器写入数据。
参考文献
[1]杜雯雯, 史运涛, 刘伟川.基于PC的Modbus软件网关的实现[J].微计算机信息, 2012, (9) :353-355.
[2]刘波, 张文三, 魏霞.基于Modbus协议的TCS-3000DCS系统与S7-200PLC之间串行通讯网络的实现[J].工业控制计算机, 2012, 25 (2) :33-35.
[3]杨永生, 施笑安.基于串口嵌入式操作系统的远程监控系统[J].西安科技大学学报, 2005, 25 (2) :204-207.
[4]T.Sridhar著, 彭甫阳译.嵌入式通信软件设计[M].北京:北京航空航天大学出版社, 2004.1.
RFID读写器内存数据结构 篇4
在小型的RFID应用中, 进入RFID读写器读写范围内的标签被RFID读写器读取, 读写器将读取到的标签数据直接发往后台的应用程序或中间件进行处理。由于小规模应用时使用的读写器数量以及卡的数量不多, 大量的重复数据不会造成严重的问题。在大规模RFID应用中, 读写器每一次读取的标签数量可能很大, 并且一个中间件服务器可能连接有众多的读写器, 因此读写器如果直接将每次读取的标签数据发往中间件, 不但中间件服务器负担沉重, 而且网络数据的传输量将非常庞大。一般的做法是将数据处理环节推前, 即把RFID读写器读到的标签数据在读写器内进行过滤、分组等处理, 只向后台中间件发送经过处理的数据。这样可以大大减少网络数据传输流量及中间件服务器的处理数据量。为了提高读写器数据处理效率, 保证数据处理的实时性, 需要一种高效的标签数据过滤算法及相应的内存数据结构。
1 RFID读写器的读周期、事件及标签状态
在一个RFID读周期内, RFID读写器对读写范围内的所有标签进行读操作。由于RFID读写的射频物理特性, 在一个RFID读周期内, 并不能保证每一个在读写器识读范围内的标签都能被读到, 个别标签可能会在某个读周期内丢失, 当标签处于读写器识读范围边缘时这种丢失现象会更加明显。如下图所示。
由图1可见, 判断一个标签是否已进入读写器识读范围需要知道这一标签处于被读取状态的时间, 当一个标签在连续几个读周期 (超过一个阈值) 内被读写器读取, 则可以认为该标签进入读写器识读范围。同样地, 判断一个标签是否已离开读写器识读范围, 需要知道该标签处于丢失状态是否已超过某一个阈值。一般的来说, 一个标签从进入读写器识读范围到离开, 标签会在RFID读写器内经过五种状态:未知状态、第一次被发现、已进入、丢失、已离开。标签在读写器内所处的状态及转变机制如图2所示。当标签还未进入读写器识读范围时, 处于未知状态 (状态0) 。当标签进入读写器的识读范围边缘时, 第一次被读写器读取。这时的标签处于状态1, 即第一次被发现状态。由于在读写器读写范围的边缘因此读写器对该标签的读取不太稳定, 标签在下一个读周期内可能会丢失。如果在以后的时间里, 读写器在大于一个阈值 (Tenter_threshold) 的读周期内连续读到该标签, 则该标签被确认为进入读写器读写范围, 即处于状态2。处于状态2的标签如果在某个读周期内不能被读到, 则被认为是丢失了 (状态3) 。当丢失的时间超过一个阈值 (Tlost_threshold) 后, 该标签被认定为离开 (状态4) 。当处于离开状态时间大于一个阈值 (Tleave_threshold) 后, 标签回到状态0[1,2]。每个读周期结束后, 读写器向后台中间件或应用程序发送本次读周期内处于各状态的标签集合 (事件数据集) 。对于后台应用来说, 关心的事件数据集有:当前读周期新发现的标签集, 当前读周期刚离开的标签集, 当前读周期处于读写器识读范围内的标签集。
2RFID读写器生成的主要数据
由上一节读写器对标签的读取特点可以知道, 在RFID应用中读写器的数据处理是以读周期为单位进行的。在每个读周期结束后, 读写器需要将当前读周期读取的标签与当前读周期以前的各状态标签进行比对, 并将标签按照在当前读周期后处于新发现状态、已进入状态、新离开状态等几个状态进行分组, 形成各事件的标签集合。以下的公式表示了各事件标签集合的产生关系。
当前读周期的标签集合表示为
Sn={T|Tn} (1)
上式中Sn表示第n个周期读写器读到的所有标签集合, Tn表示第n周期读到的标签。当前读周期结束后, 处于发现状态的标签集合表示为
SnF={T|T∈Sn∩T∉S (n-1) E∩T∉S (n-1) F} (2)
上式中SnF表示第n个读周期后处于新发现状态的标签集合, S (n-1) E表示为上一周期结束后处于进入状态的所有标签集合, S (n-1) F表示为上一周期结束后处于发现状态的所有标签集合。当前读周期结束后, 处于进入状态的标签集合表示为
SnE={T|T∈Sn∩T∈S (n-1) F, tlast>tTenter}∪{T|T∈
S (n-1) E, tleave<tTleave} (3)
上式中SnE表示第n读周期结束后处于进入状态的标签集合, S (n-1) F表示为上一周期结束后处于发现状态的所有标签集合, tlast表示该标签处于发现状态的时间, tTenter表示标签由发现转入进入状态的时间阈值。S (n-1) E表示第n-1读周期结束后处于进入状态的标签集合, tleave 表示标签处于丢失状态的时间, tTleave表示标签由处于丢失状态转为离开状态的时间阈值。
当前读周期结束后, 处于离开状态的标签集合表示为:
SnL={T|T∈S (n-1) E, tleave>tTleave} (4)
上式中SnL表示第n个读周期后处于离开状态的标签集合, S (n-1) E表示第n-1读周期结束后处于进入状态的标签集合, tleave表示标签处于丢失状态的时间, tTleave表示标签由处于丢失状态转为离开状态的时间阈值。Sn、SnF、SnE、SnL 是读写器操作的最主要的四个集合, 其它的所有事件数据都可以从这四个集合得到。
3内存数据结构及操作
由以上的公式可以看出, RFID读写器的数据处理主要是集合数据的比较与查询, 具体的操作分为以下三步。
3.1数据的比对插入
每一个标签被读取后, 都需要与已经存在的标签进行比对, 以确定标签是否存在及处于什么状态。将新发现的标签插入新发现的标签集合, 对于已有的标签进行数据更新。
3.2状态查询
当前读周期结束后, 以标签状态为查询条件, 形成各事件报告。
3.3删除过期数据
对于过期的标签数据进行查询并删除。
由于在每一个读写周期内RFID读写器数据操作存在一个规律, 先做比较、插入操作, 所有标签比对完成后, 再对所有标签做各状态查询生成事件数据, 然后再将部分过期数据进行删除, 所以对于算法及数据结构的选择可以通过分别考察各算种算法及数据结构的比较、插入与范围查询的操作效率来实现。
对于比较与插入操作, 一些常用的对比查找算法特点及时间复杂度对比如表1所示。
顺序查找:主要应用于无序表的查找, 查找效率低。
折半查找与二叉树查找:具有相同的特征, 但是折半查找适合用于静态表的查找, 二叉树适合动态表的查找, 二叉树的查找效率很大程度上取决于建立二叉树时取得数据的顺序, 对于RFID应用来说数据是无序的, 因此二叉树难以保证具有O (lgn2) 的时间复杂度。平衡二叉树 (AVL) :是二叉树的一种改进, 它具有左右子树深度之差的绝对值不超过1的特性。能保证查找的时间复杂度为O (lnn) 。但由于在数据进行插入或删除的过程中会造成平衡被破坏, 所以需要进行平衡处理, 在插入删除操作比较多的情况下, 平衡操作会占去很多的时间。为了减少平衡操作的次数, 引入了T树的结构。在RFID读写器中, 读周期的标签数据查找插入阶段, 可以使用T树的结构, 使标签数据比较及插入过程达到O (lgn2) 的平均时间复杂度。但是在查询生成各事件标签数据集合时需要重新遍历整个T树, 因此降低了算法的效率。
哈希表:理论上利用哈希表查找法可以得到最优的查找效率, 最好的情况下只需一次查找就可以得到结果。哈希表查找法的时间复杂度主要取决于哈希函数及冲突处理算法的好坏。由于RFID标签取值范围很大, 很难做出限制, 所以找一个合适的哈希函数将标签的值均匀地映射到某一个范围内比较困难, 在RFID应用中难以得到很高的时间和空间效率。
对于范围查找操作, 需要将所有的处于某一状态的标签数据全部查找出来。对于以上的各种算法及结构, 都很难达到很高的效率。
4T链表树及数据操作
常用的数据结构及查询方法都不适合用于RFID数据处理。AVL树结构在对比插入操作中需要大量的平衡操作, 并且在状态查询时效率不高。为了减少AVL树的平衡操作, 可以使用T树结构。T树结构是AVL树的一种改进型, 它在AVL树的每个节点上增加数据量, 减少了平衡操作的次数, 提高了增加删除节点的效率, 目前T树结构在内存数据库 (MMDB) 中被大量的使用[3]。T树结构可以大大提高在对比、插入操作阶段的数据处理效率, 但是在状态查询上, 效率不高。如果能在T树的基础上将所有处于同一状态的节点用双向链表结构连接起来, 在做状态查询的时候只需要遍历某一状态的链表就可以将处于某一状态的所有标签遍历出来。因此可以考虑在T树结构上增加双向链表结构, 用于范围查询, 可以显著地提高范围查询的效率[4,5]。这种结构可以称为T链表树结构。这种结构可以综合两种数据结构的优点, 在RFID数据处理的两个阶段都达到较高的效率。一个T链表树的节点结构如图3所示。
每个T节点的各数据单元由五个域组成, 两个指针节点用于建立双向链表, 一个标签记录域用于记录标签号, 一个计数器域用于计数标签处于某一状态的时间, 一个状态域用于标记所处的状态。在T链表树结构中, 处于相同状态的标签形成一个链表, Front Ptr用于指向前一个处于同一状态节点, Successor Ptr用于指向下一个处于同一状态节点。整个T链表树的数据结构如图4所示。
T链表树有两个根指针, 一个Root指针指向T链表的树根节点, 另一个HPtr根指针指向连表的头指针链表。由RFID数据处理的特点可知, 在任何一个时刻标签只能处于四个Sn、SnF、SnE、SnL集合中的一个, 所以T链表树中共有四个链表头节点, 每个节点所链接的节点, 都是处于该集合中的标签。这四个集合分别代表了:上一次读标签后处于发现状态的标签节点链表指针、上一次读标签后处于已存在状态的标签节点链表指针、当前一次读标签后处于发现状态的标签节点链表指针及当前一次读标签后处于已存在状态的标签节点链表指针。
在每一个读周期中, 数据操作方法如下。
4.1查询、插入操作
对于每一个读周期, 新的标签进入时根据T树的查询规则从根节点开始作查询、插入操作。如果标签已存在则读取标签所处的状态值, 如果标签原先处于发现状态则判断该标签处于发现状态时间加上本次读取时间是否已经超过发现状态的门槛值, 如果已超过则更改标签的链表指针, 将节点链接入本次操作后已存在链表, 更改标签的状态, 时间设为0, 并形成本次进入标签的报告。如果未超过门槛值则链入本次操作后发现链表。
4.2删除操作
所有本次读入的标签都已查询完成后, 判断上一次处于发现状态的链表是否为空, 如不为空则根据链表指针遍历所有链表节点并执行节点删除操作。
4.3清除链表
判断上一次处于存在状态的链表是否为空, 如不为空则遍历所有节点, 如果节点的计数值加上本次计数值超出门槛值则表示该标签已经消失, 加入本次的消失标签报告, 从树中删除该节点。如果未超出门槛值则将计数加上本次值后链接入本次读后已存在标签链表。
由以上的操作可以得到, 任何一次读周期完成后, 所有的节点都处于当前周期的两个链表中, 而上一次读周期的两个链表必为空。因此四个链表指针可以循环使用。
5性能分析
本算法与采用多链表、T树结构的性能分析及对比情况如表2所示。
由上表可知, 多链表结构在读周期的新增标签部分效率比较低, 主要是因为需要通过遍历所有已知的节点进行对比。但是在对本次未读到的标签处理上, 只需遍历一次链表就能将所有标签找到, 效率比较高[6]。而对于T树结构, 在对比查找阶段, 由于AVL树的特点, 效率较高, 但是对于本次未读到的标签处理上, 需要重新遍历整个树才能得到所有的标签, 效率低[7,8]。T链表树是一个综合, 在对比查找阶段, 具有T树的特点, 在未读到标签处理上具有链表的特点。T链表树通过增加两个指针节点的空间, 和维护链表结构及T树结构的操作, 来换取查找及删除阶段的高效率。
6结论
根据RFID读写器的读写、输出及数据特点, 提出了T链表树的结构, 及与之相应的数据处理算法。利用T链表树结构及算法在每一个读周期内, 读写器只需对所有标签数据进行一次遍历就完成所有标签状态的维护、各标签报告的生成, 具有很高的效率, 可以极大的提高读写器的实时处理能力。
摘要：在大型RFID应用中, 需要将标签数据处理环节前移至读写器。由于读写器的硬件条件限制, 要提高读写器的实时数据处理能力, 就必须有适合RFID应用的高效的数据处理算法及存储结构。分析了RFID读写器数据处理的特点, 提出了一种特殊的T链表树结构。在T树的结构基础上增加了双向链表结构, 使得读写器在读周期的各个数据处理阶段都能保持很高的效率。在T链表树结构基础上, 还设计了一套数据处理算法, 结合特殊的数据结构, 可以极大地提高读写器的实时数据处理能力。
关键词：RFID,读写器,T树,T链表树,数据结构
参考文献
[1]EPC global.The EPCglobal architecture framework EPCglobal final version.July1, 2005
[2]EPC global.The application level events (ALE) specification version1.0.September15, 2005
[3]Lu Hongjun, Yeung Yuet, Tian Zengping.T-tree orB-tree:main memory database index structure revisited.Database Conference, 2000.ADC2000.Proceedings, 11th Australasian31Jan—3Feb2000
[4]Choi Kongrim, Kim Kyungchang.T*-tree:a main memory database index structure for real time applications.Real-Time Computing Sys-tems and Applications, 1996;Proceedings, Third International Work-shop30Oct—1Nov1996
[5]卢炎生, 邓立峰, 朱英武.支持实时数据库的L树.研究计算机工程与应用, 1997; (4) :5—7
[6]严蔚敏, 吴伟民.数据结构 (第二版) .北京:清华大学出版社, 1992
[7]The application level events (ALE) specification V1.1;EPCglobal Inc, www.epcglobalinc.org, 27—February, 2008