CN111209467B - 一种多并发多通道环境下的数据实时查询系统 - Google Patents

一种多并发多通道环境下的数据实时查询系统 Download PDF

Info

Publication number
CN111209467B
CN111209467B CN202010017843.8A CN202010017843A CN111209467B CN 111209467 B CN111209467 B CN 111209467B CN 202010017843 A CN202010017843 A CN 202010017843A CN 111209467 B CN111209467 B CN 111209467B
Authority
CN
China
Prior art keywords
data
module
real
time
channel
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010017843.8A
Other languages
English (en)
Other versions
CN111209467A (zh
Inventor
周斌
朱晨鸣
张家健
万修远
王佳晓
黄明科
张海峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhongtongfu Smart City Engineering Construction Co.,Ltd.
Original Assignee
China Information Consulting and Designing Institute Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Information Consulting and Designing Institute Co Ltd filed Critical China Information Consulting and Designing Institute Co Ltd
Priority to CN202010017843.8A priority Critical patent/CN111209467B/zh
Publication of CN111209467A publication Critical patent/CN111209467A/zh
Application granted granted Critical
Publication of CN111209467B publication Critical patent/CN111209467B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/953Querying, e.g. by the use of web search engines
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种多并发多通道环境下的数据实时查询系统,包括客户端模块、服务器模块、数据库模块、实时数据查询模块、Redis模块、定时管理模块、数据生产者模块和缓存清理模块;系统采用数据缓存机制支持数据的实时快速查询,支持多并发环境下,每个客户端连接的实时数据查询各自独立,并且每个客户端连接下,不同的数据通道的数据互相独立,多个客户端连接可以共享相同的数据通道,且实时数据查询彼此独立,互不影响;与此同时,保证每个客户端每个数据通道查询的数据连续递增,不重叠,不遗漏;系统还可以根据查询的频率动态设置数据缓存时间,以便有效利用内存资源。

Description

一种多并发多通道环境下的数据实时查询系统
技术领域
本发明涉及一种多并发多通道环境下的数据实时查询系统。
背景技术
目前流数据的应用十分广泛,流数据是一组顺序、大量、快速、连续到达的数据序列,一般情况下,数据流可被视为一个随时间延续而无限增长的动态数据集合。应用于网络监控、传感器网络、航空航天、气象测控和金融服务等领域。流数据是由数据源持续生成的数据,通常也同时以数据记录的形式发送。流数据包括多种数据,例如客户使用移动或Web应用程序生成的日志文件、网购数据、游戏内玩家活动、社交网站信息、金融交易大厅或地理空间服务,以及来自数据中心内所连接设备或仪器的遥测数据。此类数据需要按记录或根据滑动时间窗口按顺序进行递增式处理,可用于多种分析,包括关联、聚合、筛选和取样。
其中一种流数据的应用是对摄像机的监控视频进行分析,不同的摄像机产生不同的视频流数据,形成不同的数据通道,应用系统需要针对不同的通道分别进行分析,分析的数据通常需要实时展示,以便实现视频的监控和视频信息的智能分析实时同步,帮助监控人员快速理解视频中的对象、事件。
流数据的分析结果通常会先存放到消息队列中,然后再统一存储到数据库中,也可以直接存储到数据库中。存储到消息队列中,通常是因为避免流数据产生过快来不及处理,或者分析结果有二次处理的需求。有的系统是将原始数据或者中间结果存储到消息队列中,以此缓解处理速度滞后于数据产生速度的问题。当客户端需要实时展示流数据的分析结果时,通常的做法是使用一个服务程序从消息队列中不断取出新入列的数据或者从数据库中读取新插入的数据,然后发送给客户端展示,或者由客户端从消息队列读取或从数据库连续递增查询。其中从消息队列取数据时,一个客户端取完,其它客户端可能就无法再取到,从数据库查询时,性能比较低下,并且随着数据的增长,性能问题越来越严重,除此以外,客户端需要查询多个数据源的数据,即涉及到多通道数据的展示问题。
针对多并发多通道场景下查询获取实时数据,目前普遍采用的是C/S架构,由客户端向后台注册订阅数据,然后后台每当获取新的实时数据后,将数据逐个主推给各个订阅客户端,其系统架构图如图1所示,其中客户端模块用于在前端实时展示最新的数据,服务器模块用于处理客户端的服务请求,包括接收客户端的注册,并向消息处理模块订阅实时数据,以及从数据库模块中查询历史数据;消息处理模块用于侦听消息队列模块中的消息,当发现有新的数据消息时,立即取出来进行处理,包括将数据持久化存储到数据库模块中,以及根据服务器模块注册的实时数据订阅客户端列表,将数据主推给这些订阅者;消息队列模块用于缓存实时数据;数据生产者模块用于源源不断对原始数据进行采集和分析加工,并将分析的结果临时存储到消息队列中;数据库模块用于持久化存储数据。
以下描述现有技术的缺点:
(1)多个客户端同时查询实时数据时,并非完全并发,并且相互影响:
由于实时的数据是存放在消息队列中的,需要通过消息处理模块及时取走消息并处理,以免因断电造成数据丢失或者内存溢出,客户端需要实时展示这些实时数据时,需要向服务器模块注册,并最终形成向消息处理模块的数据订阅请求,消息处理模块在取走最新消息的时候,可以依据当前的订阅列表进行逐一推送数据。由于推送是按照时间有序进行的,因此对每个客户端来说,实时数据查询并不是完全并发的,并且当其中一个客户端发生网络链路故障后,将会导致其它客户端出现数据展示延迟,除此以外,后台需要管理客户端的订阅和主推逻辑,维护数据和客户端的映射关系,一旦出现逻辑错误,将影响全局;
(2)客户端中多个通道的数据叠加在一起,每个通道无法独立并发查询数据:
在客户端中,通道的原始数据和加工数据是分别集中展示的,当客户端同时管理多个通道时,这些通道的数据就会叠加在一起混合展示,虽然可以通过关闭通道的开关来控制任意时刻只有一个通道的数据从而实现切换通道的目的,但是无法支持多个通道同时独立查询数据,而且即便所有通道的开关都打开,它们获取数据的方式也是串行的,因为数据是由消息处理模块主推的,消息处理模块从消息队列中有序取出各通道的数据,并逐一主推给订阅该通道的客户端,所有通道的实时数据并发查询受限于消息处理模块的串行处理,当多个客户端共享相同的通道时,这意味着消息处理模块要多次重复主推共享通道的数据,若重复主推的逻辑实现有缺陷,则将导致多客户端共享通道时不可靠,并且自身的网络延迟将会影响其它客户端中的通道;
(3)每个通道查询的数据可能存在冗余和遗漏的情况:
当客户端开始订阅实时数据查询时,消息队列中可能有未处理完成的消息,此时消息处理模块会将这些消息主推给客户端的相应通道,造成数据冗余,同时主推过程中,若发生链路超时或其它故障,将导致客户端接收的数据有遗漏。
(4)缓存的数据不支持有效期设置,无法保证一段时间内可重复查询:
由于实时数据存储在消息队列中,并由消息处理模块侦听队列和及时取走消息,消息在队列中的滞留时间取决于消息处理模块的处理速度,将是随机的,无法保证数据缓存的有效期,当需要快速获取最近一段时间内的数据时,将无法通过缓存机制来实现。
多并发多通道环境下的数据实时查询的其中一个典型应用是摄像机监控视频结构化分析结果的实时查询,以人脸识别签到为例,参与签到的人员通过查看客户端的实时抓拍人脸识别结果,可判断自己是否签到成功,而管理员通过查看客户端的实时抓拍人脸识别结果,可立即判断当前拜访的人员是需要签到的白名单还是陌生人,同样的,运维人员可以通过查看监控视频和实时的分析结果,判断现场环境、设备配置和程序算法等是否有问题,从而不断调整和优化系统。通常后台的系统支持多路视频的接入分析,也为多个不同的用户服务,因此衍生出多个客户端并发和多路视频通道的数据实时查询场景,针对该场景,目前应用的技术尚存在许多不足,具体如下:
(1)多并发多通道环境下数据实时查询时,多个客户端之间的数据查询并非完全独立,后台需要维护客户端的注册订阅和主推管理,比较繁琐;
(2)多并发多通道环境下数据实时查询时,每个客户端无法实现单个通道的数据独立查询,多个客户端共享同一个通道数据时不可靠,且相互影响,
(3)多并发多通道环境下数据实时查询时,针对每个通道查询的数据可能存在冗余和遗漏的情况;
(4)多并发多通道环境下数据实时查询时,不支持动态设置数据缓存时间,无法保证最近一段时间内的数据可重复快速查询。
发明内容
发明目的:为解决背景技术中存在的技术问题,本发明提出一种多并发多通道环境下的数据实时查询系统,包括客户端模块、服务器模块、数据库模块、实时数据查询模块、Redis模块、定时管理模块、数据生产者模块和缓存清理模块;所述并发是指多个前端客户端同时访问后台服务器,所述多通道是指多个相互独立的数据通道,数据通道即数据从产生到展示的独立业务流程,所述Redis是指开源的内存数据库产品;
其中,所述客户端模块用于实时查询和动态展示所述数据生产者模块产生的数据;
所述服务器模块用于连接两个以上的客户端模块,支持多并发访问,并且转发所述客户端模块的实时数据查询请求到所述实时数据查询模块;
所述数据库模块用于持久化存储数据以及数据的元数据信息;
所述实时数据查询模块用于按照所述服务器模块的数据查询请求从所述Redis模块获取目标数据,并以程序包的形式集成在所述服务器模块中,保证所述客户端模块并发查询数据的性能;
所述Redis模块用于缓存来自两个以上的数据生产者模块的数据,并保证不同数据生产者的数据隔离存储,实现两个以上的数据通道完全独立并发运行;
所述数据生产者模块用于持续不断产生需要查询和展示的实时数据,数据生产者模块一方面将数据缓存到所述Redis模块,用以支持数据实时快速查询,另一方面将数据冗余存储到所述数据库模块,实现数据的持久化存储;
所述定时管理模块用于接收用户对数据缓存有效期的配置,还用于定时触发所述缓存清理模块对所述Redis模块中的过期的数据进行清理;
所述缓存清理模块定时收到由所述定时管理模块启动的定时器触发的清理消息,定期清理所述Redis模块中缓存的过期的数据。
所述数据生产者模块在不断产生实时数据的过程中,将数据双备份到Redis模块和数据库模块。
所述数据生产者模块的工作流程包括如下步骤:
步骤a1,数据生产者模块产生任意需要查询展示的数据;
步骤a2,数据生产者模块将数据持久化存储到数据库模块;
步骤a3,数据生产者模块判断数据是否需要缓存,如果需要,执行步骤a4;否则执行步骤a5;
步骤a4,数据生产者模块将数据缓存到Redis模块;
步骤a5,数据生产者模块判断是否停止产生数据,如果是,结束工作流程,否则返回步骤a1。
所述实时数据查询模块和数据生产者模块共享相同的系统配置,并对客户端模块和服务器模块屏蔽数据访问的细节,实时数据查询模块能够与服务器模块集成在一起,运行在服务器模块的上下文环境中;
系统配置即Redis模块缓存的数据的元数据信息,所述元数据信息包括数据的存储位置、存储结构、访问方式。
所述服务器模块用于连接两个以上的客户端模块,支持多并发访问,具体包括如下步骤:
步骤b1,服务器模块接收客户端模块的连接;
步骤b2,服务器模块判断网络连接池是否已满,即是否达到最大允许连接的客户端数目,如果是,执行步骤b3,否则执行步骤b4;
步骤b3,服务器模块向客户端模块应答连接失败,然后执行步骤b8;
步骤b4,服务器模块从网络连接池分配一个连接给当前客户端模块;
步骤b5,服务器模块接收客户端模块的数据查询请求;
步骤b6,服务器模块通过实时数据查询模块获取Redis模块缓存的数据;
步骤b7,服务器模块向客户端模块应答步骤b6获取的数据;
步骤b8,实时数据查询模块判断是否停止服务,如果是,结束工作流程,否则返回步骤b1。
所述实时数据查询模块针对服务器模块的数据查询请求工作流程包括如下步骤:
步骤c1,实时数据查询模块接收服务器模块的实时数据查询请求;
步骤c2,实时数据查询模块获取数据库模块存储的所述元数据信息,包括数据存储位置、存储结构、访问方式;
步骤c3,实时数据查询模块根据查询请求的参数筛选数据;
步骤c4,实时数据查询模块向服务器模块返回数据。
服务器模块是承上启下,客户端模块要先连接服务器,用Http协议连接,连接上了发请求给服务器模块,服务器模块再转发给实时数据查询模块,进行数据的获取,然后有服务器模块应答给客户端模块。服务器模块调用数据实时查询模块用的是SDK调用协议。
所述客户端模块采用通道切换的方式单独查询每个通道的实时数据,具体包括:当客户端模块要展示两个以上通道的数据时,采用切换式的方式进行每个通道单独展示,客户端模块首先激活需要展示的通道,如果切换到新的通道,则清空展示区的数据,并开始展示新通道的数据,如果重复激活当前已经处于激活状态的通道,则保持现状。
所述客户端模块采用B/S架构的方式实现每个通道独立并发查询实时数据,具体包括:为每个通道单独新建一个页面,每个页面单独和服务器模块建立一个会话连接。
在Redis模块中缓存各通道的实时数据时,针对每个通道,分别单独建立一个数据队列,队列的key为所述通道的编号,用于唯一标识一个通道,每个通道的所有数据均存储到相对应的key的数据队列中。
当客户端模块查询实时数据时,系统执行如下步骤:
步骤d1,客户端模块的一个通道第一次查询数据时,先询问数据的编号信息,从而得到查询数据之前的数据范围;
步骤d2,实时数据查询模块收到客户端模块的数据询问后,查询相应通道的有效期内的数据编号范围,予以返回;如果客户端模块询问的时候,缓存内还未产生第一笔数据,即数据编号还未开始,则数据起始编号和中止编号均返回0;若缓存中的数据全部过期,或者全部已过期清空,则返回的数据中止编号为当前编号值,数据起始编号为中止编号的下一位;
步骤d3,客户端模块收到询问数据范围的应答后,即得到当前通道的数据的当前编号;
步骤d4,实时数据查询模块收到客户端模块的实时数据查询请求后,根据限定的数据编号范围,抽取相应的数据,并封装打包,予以返回;
步骤d5,客户端模块收到第一次查询的结果后,存储数据中止编号,并在第二次查询时,以该中止编号的下一位作为起始编号进行查询;后续的查询重复这一过程,即收到查询结果后,将数据中止编号的下一位覆盖到数据起始编号,并在下次查询时传递该覆盖后的起始编号;
所述定时管理模块的工作流程包括如下步骤:
步骤e1,定时管理模块接收用户对通道的缓存数据有效期设置;
步骤e2,定时管理模块更新相应通道数据生产者的缓存有效期配置;
步骤e3,定时管理模块检测当前通道是否启动了定时器,如果是,执行步骤e4,否则执行步骤e6;
步骤e4,定时管理模块立即触发定时器;
步骤e5,定时管理模块关闭已有的定时器;
步骤e6,定时管理模块启动新的定时器;
所述缓存清理模块的工作流程包括如下步骤:
步骤f1,缓存清理模块接收定时器触发的定时信息;
步骤f2,缓存清理模块根据通道编号定位数据队列;
步骤f3,缓存清理模块获取当前系统时间和最新的数据有效期时间;
步骤f4,缓存清理模块遍历距离当前系统时间有效期以上的数据记录;
步骤f5,缓存清理模块判断是否有下一条数据,如果是,执行步骤f6,否则执行步骤f8;
步骤f6,缓存清理模块判断数据是否过期,如果是,执行步骤f7,否则执行步骤f5;
步骤f7,缓存清理模块对数据进行清理;
步骤f8,结束工作流程。
本发明具有如下有益效果:实现多并发多通道环境下数据实时查询时,各查询客户端完全并发,完全独立,有效保障系统性能和可靠性;进行细粒度的数据控制,保证每个通道的数据独立查询,同时分别展示;
确保每个客户端的每个通道无数据冗余和遗漏的情况;实现动态设置数据缓存时间,支持最近一段时间内数据可重复快速查询,并且缓存时间到期后自动清理,有效保证性能和内存利用率。
附图说明
下面结合附图和具体实施方式对本发明做更进一步的具体说明,本发明的上述和/或其他方面的优点将会变得更加清楚。
图1是目前多并发多通道环境下实时数据查询系统架构图。
图2是本发明系统架构图。
图3是数据生产者模块工作流程图。
图4是服务器模块工作流程图。
图5是实时数据查询模块工作流程图。
图6是单通道独立并发查询数据原理图。
图7是单通道独立并发查询数据流程图。
图8是定时器管理模块工作流程图。
图9是缓存清理模块工作流程图。
具体实施方式
本发明对于多客户端并发查询实时数据的具体实现:
(1)在系统架构中引入Redis模块
如图2所示,增加Redis模块,Redis是一款轻量级的内存数据库,支持分布式部署,支持高并发访问数据,由于Redis中的数据位于内存中,存取数据的速度非常快,因此用于缓存数据,以便支持实时数据的快速查询。由于Redis中的数据对各数据访问者具有只读共享权限,因此支持多个数据客户端重复读取相同的数据,并且彼此完全独立,互不影响。
(2)数据生产者模块同时进行数据的持久化存储和临时缓存
数据生产者模块在不断产生实时数据的过程中,将数据双备份到Redis模块和数据库模块,存储到数据库模块,可以有效保证数据的持久化存储,并且由于数据不进消息队列,无存储的延迟,因此也避免了因断电造成的数据丢失,由于数据库的磁盘IO相对于内存有较大的性能损耗,并且随着数据的积累,从数据表中读取数据的速度越来越慢,因此针对数据的实时查询场景,改用从Redis内存数据库中查询,因此数据生产者模块需要将数据备份到Redis模块中,专门用来支持实时的数据查询,并且当没有实时数据查询需求时,可以关闭开关,自由控制数据的缓存,丝毫不影响现有的业务。每个数据生产者仅负责其中一个数据通道的数据采集和处理,以便保证所有通道的数据能够并发独立处理,数据生产者的工作流程如图3所示;
(3)使用实时数据查询模块统一管理数据的访问和查询
实时数据查询模块和数据生产者模块共享相同的系统配置,因此实时数据查询模块维护着数据的存储位置、存储结构、访问方式等元数据信息,对客户端和服务器模块屏蔽数据访问的细节,实时数据查询模块可以与服务器模块集成在一起,运行在服务器模块的上下文环境中,因此可以独立并发工作。服务器模块工作流程如图4所示;实时数据查询模块的工作流程如图5所示;
本发明对于单通道独立展示数据以及独立并发获取数据的具体实现:
(1)客户端采用通道切换的方式单独查询每个通道的实时数据
当客户端要展示多个通道的数据时,采用切换式的方式进行每个通道单独展示,首先,需要点击激活需要展示的通道,然后如果切换到新的通道,则清空展示区的数据,并开始展示新通道的数据,如果重复激活当前已经处于激活状态的通道,则保持现状。
(2)客户端采用B/S架构的方式实现每个通道独立并发查询实时数据
采用通道切换的方式查看单个通道的数据时,同一个界面同一时间只能展示一个通道的数据,为了方便用户同时分别查看多个通道的数据,可通过同时打开多个界面来实现,如果采用传统的C/S架构,将很难实现重复打开相同的页面并且保证每个页面独立工作,因此采用B/S架构,为每个通道单独新建一个页面,每个页面单独和服务器模块建立一个会话连接,由此,将并发度从客户端粒度细化到通道的粒度,实现了每个通道完全独立并发工作,即便在同一个客户端下重复打开同一个通道,也视为不同的会话连接,据此可以很方便的模拟不同的用户对共享通道的数据查询。单通道独立并发查询数据的原理如图6所示;
本发明对于单通道数据无冗余、无遗漏的具体实现:
(1)为每个通道的数据单独分配存储空间,单独编号
在Redis模块中缓存各通道的实时数据时,针对每个通道,分别单独建立一个数据队列,队列的key为该通道的编号,用于唯一标识一个通道,每个通道的所有数据均存储到相对应的key的数据队列中。数据队列的数据表如表1所示:
表1
数据编号ID 数据记录时间 有效期 数据项
1 2019-10-10 11:30:00 5min ...
2 2019-10-10 11:31:00 5min ...
3 2019-10-10 11:32:00 5min ...
其中数据编号连续递增,采用64位整型编码,最大可以编到2^64-1。采用数据编号后,客户端的每个通道可以明确查询指定编号范围内的数据,过滤掉冗余数据,同时数据查询失败后,可以根据指定的编号重复查询,避免数据遗漏。
(2)客户端查询数据时,自行限定数据的范围
客户端查询实时数据时,数据的连续递增和断点续传,不必由服务器来管理,服务器也无须为每个客户端单独维护数据查询进度信息,只需要客户端在查询数据的时候指定数据的起止编号即可。具体如下:
第一步:客户端的某个通道第一次查询数据时,由于不知道当前缓存中已经存储了多少数据,数据编号编到何值,因此通道在启动查询前,需要先询问数据的编号信息,参数表的赋值如表2所示:
表2
通道编号 数据起始编号 数据中止编号
1 -1 -1
数据中止编号指定为-1时,代表不限制数据的末尾,以实际的数据条数为准,收取起始编号之后的全部数据。数据起始编号设置为-1时,代表是查询数据之前的数据范围询问。
第二步:实时数据查询模块收到客户端的数据询问后,查询相应通道的有效期内的数据编号范围,予以返回。返回的数据字段见表3所示:
表3
通道编号 数据起始编号 数据中止编号
1 50 100
如果客户端询问的时候,缓存内还未产生第一笔数据,即数据编号还未开始,则数据起始编号和中止编号均返回0;若缓存中的数据全部过期,或者全部已过期清空,则返回的数据中止编号为当前编号值,数据起始编号为中止编号的下一位,以此表明数据编号到何值,并指示已产生的数据均已过期,尚无有效数据。
第三步:客户端收到询问数据范围的应答后,即知道当前通道的数据当前编号到何值,该值亦代表截至当前时刻,该通道最近产生的数据。由于客户端要展示通道的实时数据时,通常只关心启动查询时刻之后的新的实时数据,因此稍后的第一次数据查询时,以询问应答返回的中止编号的下一位作为起始编号进行数据请求,请求参数见表4所示:
表4
通道编号 数据起始编号 数据中止编号
1 101 -1
第四步:实时数据查询模块收到客户端的实时数据查询请求后,根据限定的数据编号范围,抽取相应的数据,并封装打包,予以返回。如果范围内没有数据,返回的字段如表5所示:
表5
通道编号 数据起始编号 数据中止编号 数据列表
1 101 100 null
如果范围内有数据,返回的字段如表6所示:
表6
通道编号 数据起始编号 数据中止编号 数据列表
1 101 150 ...
第五步:客户端收到第一次查询的结果后,存储数据中止编号,并在第二次查询时,以该编号的下一位作为起始编号进行查询。后续的查询重复这一过程,即收到查询结果后,将数据中止编号的下一位覆盖到数据起始编号,并在下次查询时传递该覆盖后的起始编号,由此,实时的数据即可源源不断的连续递增展示,并且查询失败后,可以多次重复查询,保证数据无遗漏。
综上所述,客户端单通道独立并发查询实时数据的完整过程如图7所示;
本发明对于设置数据缓存时间的具体实现:
(1)系统引入定时管理模块
定时管理模块一方面可以接收用户对数据缓存有效期的配置,另一方面定时触发缓存清理模块对过期的数据进行清理。
用户通过定时管理模块,可以针对每个通道单独设置数据缓存有效期,并且期间可以动态修改,即每笔缓存数据拥有自己的有效期,在有效期范围内,均可以通过检索缓存来进行查询,大大提高最近一段时间内的数据查询性能。
除此以外,对缓存的数据设置有效期,可以实现一段时间内的数据去重,有效降低数据冗余度。
如图8所示,为定时管理模块对缓存数据进行有效期管理的工作流程,用户通过客户端交互界面设置的缓存数据有效期,会被服务器模块发送给定时管理模块,定时管理模块收到用户的设置信息后,更新数据生产者的有效期配置,如表5-1所示,数据生产者再往缓存表写入数据时,将根据当前的有效期配置,将配置值和数据一并写入到缓存,以便对每笔缓存的数据进行有效期标识。由于有效期发生变更后,缓存的过期数据的清理频率也将发生改变,因此需要检查是否已经有定时器启动,若有,立即触发定时消息,将从上一次清理缓存的时刻以来的时间段内过期的数据进行全部清理,并关闭旧的定时器,然后重新开启新的定时器,按照新的定时设置触发清理频率;若还没有启动定时器,则直接启动一个新的定时器。
(2)系统引入缓存清理模块
缓存清理模块,定时收到由定时管理模块启动的定时器触发的清理消息,以便定期清理缓存中过期的数据,避免过期数据滞留内存,造成内存资源浪费。
如图9所示,清理过程为,首先按照通道编号确定数据存储的队列,然后根据当前的有效期时间和当前系统时间遍历距离当前时间有效期时间以上的数据记录,结合数据的插入时间和其自身的有效期时间判断是否到期,若到期则删除数据,若未到期,则继续保留。
本发明提供了一种多并发多通道环境下的数据实时查询系统,具体实现该技术方案的方法和途径很多,以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。本实施例中未明确的各组成部分均可用现有技术加以实现。

Claims (6)

1.一种多并发多通道环境下的数据实时查询系统,其特征在于,包括客户端模块、服务器模块、数据库模块、实时数据查询模块、Redis模块、定时管理模块、数据生产者模块和缓存清理模块;
其中,所述客户端模块用于实时查询和动态展示所述数据生产者模块产生的数据;
所述服务器模块用于连接两个以上的客户端模块,支持多并发访问,并且转发所述客户端模块的实时数据查询请求到所述实时数据查询模块;
所述数据库模块用于持久化存储数据以及数据的元数据信息;
所述实时数据查询模块用于按照所述服务器模块的数据查询请求从所述Redis模块获取目标数据,并以程序包的形式集成在所述服务器模块中,保证所述客户端模块并发查询数据的性能;
所述Redis模块用于缓存来自两个以上的数据生产者模块的数据,并保证不同数据生产者的数据隔离存储,实现两个以上的数据通道完全独立并发运行;
所述数据生产者模块用于持续不断产生需要查询和展示的实时数据,数据生产者模块一方面将数据缓存到所述Redis模块,用以支持数据实时快速查询,另一方面将数据冗余存储到所述数据库模块,实现数据的持久化存储;
所述定时管理模块用于接收用户对数据缓存有效期的配置,还用于定时触发所述缓存清理模块对所述Redis模块中的过期的数据进行清理;
所述缓存清理模块定时收到由所述定时管理模块启动的定时器触发的清理消息,定期清理所述Redis模块中缓存的过期的数据;
所述数据生产者模块在不断产生实时数据的过程中,将数据双备份到Redis模块和数据库模块;
所述数据生产者模块的工作流程包括如下步骤:
步骤a1,数据生产者模块产生任意需要查询展示的数据;
步骤a2,数据生产者模块将数据持久化存储到数据库模块;
步骤a3,数据生产者模块判断数据是否需要缓存,如果需要,执行步骤a4;否则执行步骤a5;
步骤a4,数据生产者模块将数据缓存到Redis模块;
步骤a5,数据生产者模块判断是否停止产生数据,如果是,结束工作流程,否则返回步骤a1;
所述实时数据查询模块和数据生产者模块共享相同的系统配置,并对客户端模块和服务器模块屏蔽数据访问的细节,实时数据查询模块能够与服务器模块集成在一起,运行在服务器模块的上下文环境中;系统配置即Redis模块缓存的数据的元数据信息,所述元数据信息包括数据的存储位置、存储结构、访问方式;
所述服务器模块用于连接两个以上的客户端模块,支持多并发访问,具体包括如下步骤:
步骤b1,服务器模块接收客户端模块的连接;
步骤b2,服务器模块判断网络连接池是否已满,即是否达到最大允许连接的客户端数目,如果是,执行步骤b3,否则执行步骤b4;
步骤b3,服务器模块向客户端模块应答连接失败,然后执行步骤b8;
步骤b4,服务器模块从网络连接池分配一个连接给当前客户端模块;
步骤b5,服务器模块接收客户端模块的数据查询请求;
步骤b6,服务器模块通过实时数据查询模块获取Redis模块缓存的数据;
步骤b7,服务器模块向客户端模块应答步骤b6获取的数据;
步骤b8,实时数据查询模块判断是否停止服务,如果是,结束工作流程,否则返回步骤b1。
2.根据权利要求1所述的系统,其特征在于,所述实时数据查询模块针对服务器模块的数据查询请求工作流程包括如下步骤:
步骤c1,实时数据查询模块接收服务器模块的实时数据查询请求;
步骤c2,实时数据查询模块获取数据库模块存储的所述元数据信息,包括数据存储位置、存储结构、访问方式;
步骤c3,实时数据查询模块根据查询请求的参数筛选数据;
步骤c4,实时数据查询模块向服务器模块返回数据。
3.根据权利要求2所述的系统,其特征在于,所述客户端模块采用通道切换的方式单独查询每个通道的实时数据,具体包括:当客户端模块要展示两个以上通道的数据时,采用切换式的方式进行每个通道单独展示,客户端模块首先激活需要展示的通道,如果切换到新的通道,则清空展示区的数据,并开始展示新通道的数据,如果重复激活当前已经处于激活状态的通道,则保持现状。
4.根据权利要求3所述的系统,其特征在于,所述客户端模块采用B/S架构的方式实现每个通道独立并发查询实时数据,具体包括:为每个通道单独新建一个页面,每个页面单独和服务器模块建立一个会话连接。
5.根据权利要求4所述的系统,其特征在于,在Redis模块中缓存各通道的实时数据时,针对每个通道,分别单独建立一个数据队列,队列的key为所述通道的编号,用于唯一标识一个通道,每个通道的所有数据均存储到相对应的key的数据队列中。
6.根据权利要求5所述的系统,其特征在于,当客户端模块查询实时数据时,系统执行如下步骤:
步骤d1,客户端模块的一个通道第一次查询数据时,先询问数据的编号信息,从而得到查询数据之前的数据范围;
步骤d2,实时数据查询模块收到客户端模块的数据询问后,查询相应通道的有效期内的数据编号范围,予以返回;如果客户端模块询问的时候,缓存内还未产生第一笔数据,即数据编号还未开始,则数据起始编号和中止编号均返回0;若缓存中的数据全部过期,或者全部已过期清空,则返回的数据中止编号为当前编号值,数据起始编号为中止编号的下一位;
步骤d3,客户端模块收到询问数据范围的应答后,即得到当前通道的数据的当前编号;
步骤d4,实时数据查询模块收到客户端模块的实时数据查询请求后,根据限定的数据编号范围,抽取相应的数据,并封装打包,予以返回;
步骤d5,客户端模块收到第一次查询的结果后,存储数据中止编号,并在第二次查询时,以该中止编号的下一位作为起始编号进行查询;后续的查询重复这一过程,即收到查询结果后,将数据中止编号的下一位覆盖到数据起始编号,并在下次查询时传递该覆盖后的起始编号;
所述定时管理模块的工作流程包括如下步骤:
步骤e1,定时管理模块接收用户对通道的缓存数据有效期设置;
步骤e2,定时管理模块更新相应通道数据生产者的缓存有效期配置;
步骤e3,定时管理模块检测当前通道是否启动了定时器,如果是,执行步骤e4,否则执行步骤e6;
步骤e4,定时管理模块立即触发定时器;
步骤e5,定时管理模块关闭已有的定时器;
步骤e6,定时管理模块启动新的定时器;
所述缓存清理模块的工作流程包括如下步骤:
步骤f1,缓存清理模块接收定时器触发的定时信息;
步骤f2,缓存清理模块根据通道编号定位数据队列;
步骤f3,缓存清理模块获取当前系统时间和最新的数据有效期时间;
步骤f4,缓存清理模块遍历距离当前系统时间有效期以上的数据记录;
步骤f5,缓存清理模块判断是否有下一条数据,如果是,执行步骤f6,否则执行步骤f8;
步骤f6,缓存清理模块判断数据是否过期,如果是,执行步骤f7,否则执行步骤f5;
步骤f7,缓存清理模块对数据进行清理;
步骤f8,结束工作流程。
CN202010017843.8A 2020-01-08 2020-01-08 一种多并发多通道环境下的数据实时查询系统 Active CN111209467B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010017843.8A CN111209467B (zh) 2020-01-08 2020-01-08 一种多并发多通道环境下的数据实时查询系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010017843.8A CN111209467B (zh) 2020-01-08 2020-01-08 一种多并发多通道环境下的数据实时查询系统

Publications (2)

Publication Number Publication Date
CN111209467A CN111209467A (zh) 2020-05-29
CN111209467B true CN111209467B (zh) 2023-05-26

Family

ID=70784160

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010017843.8A Active CN111209467B (zh) 2020-01-08 2020-01-08 一种多并发多通道环境下的数据实时查询系统

Country Status (1)

Country Link
CN (1) CN111209467B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113064921B (zh) * 2021-03-09 2023-09-29 上海金融期货信息技术有限公司 一种前后台大容量业务数据查询方法
CN112669353B (zh) * 2021-03-16 2021-07-13 腾讯科技(深圳)有限公司 数据处理方法、装置、计算机设备和存储介质
CN113064580A (zh) * 2021-03-29 2021-07-02 上海金融期货信息技术有限公司 一种水平扩展的客户端系统
CN113010560A (zh) * 2021-03-30 2021-06-22 建信金融科技有限责任公司 Redis缓存刷新方法及装置
CN115408371B (zh) * 2022-10-31 2023-01-31 之江实验室 一种redis数据库动态冗余部署方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101090401A (zh) * 2007-05-25 2007-12-19 金蝶软件(中国)有限公司 一种群集环境下的数据缓存方法及系统
US8543554B1 (en) * 2010-08-10 2013-09-24 ScalArc Inc. Method and system for transparent database query caching
CN109101580A (zh) * 2018-07-20 2018-12-28 北京北信源信息安全技术有限公司 一种基于Redis的热点数据缓存方法和装置
CN109684358A (zh) * 2017-10-18 2019-04-26 北京京东尚科信息技术有限公司 数据查询的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101090401A (zh) * 2007-05-25 2007-12-19 金蝶软件(中国)有限公司 一种群集环境下的数据缓存方法及系统
US8543554B1 (en) * 2010-08-10 2013-09-24 ScalArc Inc. Method and system for transparent database query caching
CN109684358A (zh) * 2017-10-18 2019-04-26 北京京东尚科信息技术有限公司 数据查询的方法和装置
CN109101580A (zh) * 2018-07-20 2018-12-28 北京北信源信息安全技术有限公司 一种基于Redis的热点数据缓存方法和装置

Also Published As

Publication number Publication date
CN111209467A (zh) 2020-05-29

Similar Documents

Publication Publication Date Title
CN111209467B (zh) 一种多并发多通道环境下的数据实时查询系统
CN106709003A (zh) 基于Hadoop的海量日志数据处理方法
CN106534257B (zh) 一种多层次集群式架构的多源安全日志采集系统及方法
CN104604240B (zh) 准时分布式视频高速缓存
CN103716343B (zh) 基于数据缓存同步的分布式业务请求处理方法及系统
CN109639754B (zh) 一种电网调度服务网关数据审计的实现方法
CN104639374B (zh) 一种应用程序部署管理系统
US8542695B1 (en) System and method for storing/caching, searching for, and accessing data
CN101848245B (zh) 基于ssl/xml的数据库访问代理方法及系统
CN103870570B (zh) 一种基于远程日志备份的 HBase 数据可用性及持久性的方法
CN111177161B (zh) 数据处理方法、装置、计算设备和存储介质
US20060230170A1 (en) Streaming media content delivery system and method for delivering streaming content
CN107038162A (zh) 基于数据库日志的实时数据查询方法和系统
CN107332719A (zh) 一种cdn系统内日志实时分析的方法
CN104778188A (zh) 一种分布式设备日志采集方法
CN103731298A (zh) 一种大规模分布式网络安全数据采集方法与系统
CN101132269B (zh) 数据同步方法及使用该方法的iptv内容分发网络系统
CN105991520A (zh) 内外网交互方法及系统
CN109213752A (zh) 一种基于cim的数据清洗转换方法
CN106797327A (zh) 使用与自适应比特率流传输相关联的消息执行对移动平台的媒体监视
CN109600410A (zh) 数据存储系统以及方法
US20030055910A1 (en) Method and apparatus to manage data on a satellite data server
CN105871919A (zh) 一种网络应用防火墙系统及其实现方法
CN106066877A (zh) 一种异步更新数据的方法及系统
JP2004005085A (ja) ストレージネットワーク性能測定システム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20230805

Address after: A1-1302-5, Building A, Kexing Science Park, No. 15 Keyuan Road, Science Park Community, Yuehai Street, Nanshan District, Shenzhen City, Guangdong Province, 518100

Patentee after: Zhongtongfu Smart City Engineering Construction Co.,Ltd.

Address before: 210019 No. 58 East Street, Nanxi River, Jianye District, Nanjing, Jiangsu

Patentee before: CHINA INFORMATION CONSULTING & DESIGNING INSTITUTE Co.,Ltd.

TR01 Transfer of patent right